Just treating the symptom can land you in the ER

Software bugs and administering the correct antibiotic.

I don’t know how many times I have told myself these words: “Oh hey! If I just tweak this, the error will go away.” Saying this, knowing that the real reason for a software defect goes much deeper. We are all tempted from time to time to do the quick and easy fix and save the day. Unfortunately these “rockstar” moves don’t pay off any dividends. Instead you’ll end up with more technical debt later on.

A bug is merely a symptom of an underlying problem in the process of building software. I’d like to think of the tools, processes, people and culture in the software development life-cycle as a biological being. When we initially stare a bug in the face we tend to shoot from the hip and wack in a few lines of code, kiss it all better and never return to the wound. Until it starts to fester! You see, when we do this we are really just patching things up and hope that the day doesn’t come when the underlying cause cripples a system, the user experience or your team’s productivity.

As a developer, I start off with some introspection and dig into my code that’s throwing up all over the show. I pinpoint that one line, method or class and forget about what really went into the mix when that “gogga” germinated. It might be one person writing the code, but it’s an entire team involved in the planning, construction and assessment. Things can go wrong on many levels and one has to ask some questions to start root cause analysis:

• Are we dealing with a flawed architecture?
• Can the frameworks and libraries we use lead us into sub-optimal solutions?
• Are we using our own home-baked solution while there are superior alternatives available?
• Do we have high quality software specifications that leave little to no gaps?
• What are the gaps in the our specification and how did we close them during construction?
• How do we make sure every code change or addition to the mainline product is of a high standard?
• Do our developers have adequate test coverage with meaningful test assertions?
• How do we manage request for changes in the product?
• Does our process require all parties to be on board and are changes visible to the team?
• Has our quality assurance team aligned their testing strategy with the expectations of business and clients?
• etc.

When you answer these kind of questions in the context of the bug, you can start to unravel why it ended up there in the first place. You can’t always treat the problem at it’s source in the time required as many teams have strict SLAs for resolving issues. In my experience I found it useful to administer the antibiotic that fixes the bug and treats the symptom, but to follow up and become proactive in building a better product that will progressively build immunity to bugs (at least the crippling ones).

It’s wishful thinking to believe you can have bug-free software. By applying root causes analysis and proactively injecting a healthy dose of critical thinking you can be assured you and your team are crafting a product that is always a little better than the day before.