Letting Defects Coalesce

The quick-fix solution. An approach to bug-fixing that should be reserved for those critical problems impacting production systems. Or where you're in a high-pressure scenario where the software must ship. We all do it. Or at least, we should be hammering out these quick-fix solutions all the time. Because if we didn't, it'd mean we're waiting till we figure out what the perfect program looks like. The problem at hand takes a back seat to our own misgivings about the code we've put together. Quick-fix solutions enable us put software in the hands of users. Period. But that doesn't restrict us from thinking about defects over a longer period of time in an attempt to really understand their causes and effects. Are they just symptomatic of a deeper issue within the system's design?

From this point of view, it's almost as though we're using the bug as a tool, as a magnifying-glass to inspect the interactions between system components and what is actually going wrong. The most interesting software bugs are the ones that turn out to be features. Don't forget, code is really good at doing exactly what it is told, and really bad at understanding intent. These aren't the bugs excised with a quick-fix solution. These are the ones that speak volumes about oversights during the design phase. Yet, we're not restricted from making an attempt at putting a band-aid over the issue, to stop the bleeding but offer no real improvement. Real change to address real defects at the design level requires that the collective team understand the defect in its entirety — teasing out the details by letting them coalesce.

The first phase of a bug's life involves someone using the system and identifying the problem. Maybe it's something obvious, there is a blatant internal problem, exposed in the logs perhaps. Or there is something just semantically wrong — a blatant mismatch between expected behavior and actual experience. The latter is more likely to be a defect in our design, but we'll often never find out. Or worse, people on the team have an idea about what the design problem may be, but keep quite about it because culture dictates that the quick-fix is the solution. And it is the immediate solution when in comes to releasing software, or software already deployed to production.

What we really need is an environment where we can investigate the defects that we know about or suspect. An environment that is detached from the essential day-to-day business of quick-fix. It is in this environment that bugs reveal their true personality and tell us something important about the environment in which they were born.