Why you should care more than just your code.

We are living in exciting times when frameworks we are using are becoming more and more extensible and giving us more power to build highly complex systems. In my previous few posts, I have written about how to use the extensions/patterns to simplify your code while providing solutions for equally complex domains. In this post, I want to discuss how we can burn our hands if we are not careful in our use of these extensible systems.

Power comes with responsibility
A common saying “power comes with responsibility” holds as relevant in software development as it does in our normal life. I understand why some people say that “I just have to know enough to do my job”, I think subtlety lies in the definition of the ‘enough’. If your definition for ‘enough’ falls little shy of what is required, you risk exposing your application to unexpected behavior that could lead to disastrous consequences depending on how critical your application is.

The story of an intermittent issue

I was once called in to help a team to troubleshoot an intermittent bug, discovered during load testing, which was performed bit late in the SDLC followed by that team. It was a good thing that there was some load testing, but unfortunately was not part of their build pipeline, so this was the risk to delay the critical release for which the communications were already gone out.

The problem was some sort of the mix up of data. Development team already confirmed the usual suspects like the use of statics declaration, caching etc. and found none to be the culprit. Being of an intermittent nature it was only visible in the load testing, which was taking overnight to run and we were up against time.

When it helps to know more than just enough

They were partly on the right track but bit blindfolded by reusable components provided to them. In this case, they just need to understand how their components are being used in the ASP.NET MVC pipeline. As in typical n-tier application i.e.

• Presentation
• Service
• Data

Employing AOP (Aspect-oriented programming), the team decided to implement a cross-cutting concern using one of the ASP.NET MVC extension points called ActionFilterAttribute. So this action filter was receiving dependency injection (IoC) of a service component, which further gets injected a data component.

Even though the service component that was injected to the ActionFilter was of a transient lifetime (i.e. created on every time container resolves) but because ActionFilter’s life scope in ASP.NET MVC pipeline is a singleton, so any dependency injected in is going to stick around for its lifetime. Unfortunately, two levels deep dependency (data component) was using some module-level variable in a non threadsafe way, may be assuming the transient life span of itself and its immediate parent. So this caused the non threadsafe data to be a victim of race condition and result in the mix up of the values.

Fortunately, it was discovered in the load test. It could have been better if this non-functional requirement testing was more incorporated into the build pipeline so that these behaviors can be discovered at earlier stages. Regardless of how rigorous quality assurance process is in place, I think it is developers responsibility to go beyond just his/her own code and get a better understanding of the ecosystem in which their code is going to live in. Knowing little extra helps a lot.

Originally published at codesimple.blog on June 11, 2016.