Bug fixing: Two Steps Forward and One Step Backward

Currently I am leading the testing effort of couple of software frameworks which have fairly good user base. They are frameworks because they allow software developers to build a software product as opposed to provide an out of box software product for end users. While fixing bugs and testing them, all of sudden, I realized that bug fixing overall does not necessarily improve the inherent quality of software whether it's a software framework or software product. This self realization some how had a theoretical familiarity to me.

Going down the memory lane, I had read few good books on software design and development as well as software project management as part of my preparation for job interviews when I was about to graduate. One such book was The Mythical Man-Month by Mr. Frederick Brooks, JR. Back then it had made some sense but it it was one of many books that I had read. Its significance and relevance might have fizzled in elegance of other good books that I read notably GOF book on design patterns. I revisited Mr. Brooks literary creation and behold, it talked about exactly what I felt in chapter 11. ( I did not think Mr. Brooks had any pun intended when he talked about bug fixing and maintenance cost being 40% of development cost. These days I hear too many chapter 11 instances in financial news ;-) ).

In this chapter, Mr. Brooks describes bug fixes as two steps forward and one step backward. Here are the main points on why:

• Fixing a defect has 20-25% of change of introducing another.
• Whole set of regression testing is very costly.
• All bug fixes tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing flaws introduced by earlier fixes.
• Things are always at their best in the beginning. Bug fixes increases disorder of the system and users get more sophisticated
• Software Development is an entropy decreasing process, hence inherently metastable. But maintenance is entropy increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.
  

Given that Mr. Brooks and many others observed these so many years back and I observe it as well, I wonder how much improvement we have made in terms of software project development as a whole. May be it's because of the fact that the only constancy is change itself and designing a system for change is more widely discussed in the literature than practiced. Mr. Brooks, you definitely make more sense to me now than what you did four years back. Not your fault though.