4 min to read
Bug Driven Development
Some time ago, I was exposed to a project which entered UAT with over a thousand bugs. Obviously, the project itself is not the epitome of perfection. But the sheer number begs some fundamental questions about the assertion that the project was even deemed as code complete to enter into UAT. In general, it has been my observation that software projects get reactive when deadlines get squeezed. Everyone is in a perpetual state of hurry to head to the next milestone - be it requirements completeness, UAT readiness or even production readiness. In this furore, thoroughness takes a back seat much to the detriment of the produced software quality. Deadlines would eventually get missed and re-missed. The pity of it all is that eventually the project would take the full time to achieve completion without the saving grace of quality. It did seem odd to me,at that time, that the above alluded project with all its shortcomings, required a pretty heavy leadership team. (Or perhaps its pathetic state was the outcome of such a lopsided team but that is neither here nor there) In retrospect, it all seems quite evident to me. Bugs do come with a price tag. They need to be triaged, managed, fixed, resolved and finally closed. These activities tend to require a full dedication from several members of the management team. But there is a hidden tag that is not immediately obvious to the casual beholder. Bugs tend to make a project more reactive. Instead of adding more code to add functionality we would add more code to resolve bugs. That is bug driven design in action! At first sight, bug driven design (notwithstanding the demeaning metaphor) may possess the outside veneer of a test driven design or even a functional design. Isn’t it reminiscent of the junit credo that the test bar starts with red and should eventually be made green by code addition or re-factoring? So all features start out as bugs (“red”) and would eventually become “green” once they get implemented. Right? There are several problems with this assertion - some of them leap to the eye and some of them well hidden in successive layers of obfuscation. Let us get to the obvious ones first. First, bugs are not like test cases in TDD. They may describe positive scenarios like test cases do. Ex: System was supposed to do bla bla bla but is not doing it. But this similarity is incidental. The eventual aim of a bug is to document a system deficiency. It is not intended to be a comprehensive description of the intended functionality. Secondly, bugs are not cogently linked to each other like test cases or functional requirements. They are often disparate descriptions of system limitations without any unifying thread binding them all together. Bugs need to be classified and triaged in bunches to make sense . Functional requirements (or their corresponding test cases) already possess this taxonomy. Thirdly, bugs are not amenable for automation. Some of them are linked to automated test cases but for the most part they are not. The most important difference lies in the way bugs are triaged. Bugs are usually assigned priority numbers (P0,P1 etc.) and are solved in the descending order of priority. This strategy harks back to the way bugs are viewed. They are viewed as noise rather than as features of the system. Hence bugs need to be eliminated rather than be allowed to fester. We need elaborate graphs to represent how many exist, how many of them are active and what is our fix versus find ratios. We need people to assign them to developers, obtain status and update all kinds of systems. (bug tracking system, trend trackers etc.) Which invariably means we need more managers to manage this noise and to ensure that the stake holders view progress. This accounted for the “top heavy” team in the project that I was referring to. On the other hand, product requirements or features constitute the product road map. In agile terms, product features make the product backlog. A healthy backlog pipeline is desirable and showcases the strong strategic foresight of the team. A product with a strong backlog requires product managers to do some market analysis, usage research etc. as opposed to relationship managers pacifying disgruntled customers. In short, Bug Driven Design is as bad as it sounds. Stay away from it!
Comments