Benjamin Franklin once said, "An ounce of prevention is worth a pound of cure." This is especially true of creating a software system. Good practices and policies early in product development can reduce future problems. Instead of the normal avalanche of bugs, you only have a trickle. You can spend less time debugging and more time developing new products, learning state-of-the-art technology, or playing the latest Xbox game (only for intellectual stimulation, of course).
Preemptive debugging is not defensive programming. Defensive programming consists of best practices and policies that developers apply to coding. For example, the coding style of 1==x instead of x==1 is an example of defensive programming. Preemptive debugging is a macro approach to preventing bugs. Many of the techniques do not apply to a particular role, such as a developer, but to everyone working on the project.
As mentioned several times in this book, do not short circuit the software development life cycle. Completely fulfill the requirements and analysis, design, and other phases. This means most of your application development is spent on modeling and not coding. This modeling is the blueprint for drafting your application. If the blueprint is abbreviated or hastily created, everything derived from it is suspect. 9-2 shows the trend of spending less time with coding and more with design. This figure was from the master thesis titled "Formalizing Use Cases with Message Sequence Charts," presented by Michael Andersson and Johan Bergstrand. Today it is expected that 70 percent of the software development life cycle is dedicated to modeling (everything before coding).
Table 9-2. Comparative ratio of time spent in each phase of the software development life cycle.
Requirements Analysis | Preliminary Design | Detailed Design | Coding and Unit Testing | Integration and Test | System Test | |
|---|---|---|---|---|---|---|
1960s–1970s | 10% | 80% | 10% | |||
1980s | 20% | 60% | 20% | |||
1990s | 40% | 30% | 30% | |||
Everyone has an opinion on the primary reason for software problems: lack of attention to detail, short deadlines, lack of knowledge, "code first, think later" approach to programming, and so on. From my experience working with customers with real world problems, the primary culprit is the lack of knowledge. Fifteen years ago, I could read Programming Windows 3.1, by Charles Petzold (Microsoft Press, 1992), and know everything about Windows programming. In 1,000 pages, you could learn everything needed to write a Windows program. It was the seminal text of its time. Now 1,000 pages is barely an introduction to Windows Presentation Foundation (WPF). The breadth of information that anyone must learn to program in the Windows environment has grown exponentially. With few exceptions, everyone is now a specialist. This verticalization creates a fertile breeding ground for bugs. How is this resolved?
Education. You must encourage and support technical training for engineers. For this reason, time for learning must be included in the project schedule. This prevents bootstrapped solution or kluges that often lead to problems.
Extend deadlines. Everyone needs more time to research and learn applicable technology. When there are deadline problems, time for research or learning is generally curtailed first with predictable results.
Know what you don’t know. Create an environment where developers are encouraged to collaborate and share expertise. That combined expertise can resolve the knowledge gap.
Know the problem domain. There should be a close relationship between the real world, software model, and your code. If not, the program may work flawlessly initially. However, the world is not static. If your code does not model the real world, incorporating future customer changes (the world is dynamic) will invariably lead to problems. Someone on the team should be a subject matter expert (SME). For large projects, there should be a customer liaison to facilitate communication between the software team and the customer. This additional knowledge of the problem domain leads to a better solution and fewer problems in the future.
Avoid feature creep to prevent future problems also. Each new feature adds potential complexity and a possible harbinger of trouble. Fight the temptation to add "cool" features to the product particularly near project completion. Instead, trim features as you near the project deadline. This provides additional time for the remaining features to be fully developed. You must lock down or freeze the code base a reasonable period of time before product release to allow for adequate testing. At that time, only bug fixes and other critical changes should be allowed. This should not be discretionary and must be enforced through management approval. Remember, when deadlines are looming, cut features—especially features that you are unable to test adequately in the remaining time. Customers prefer reliable products with fewer features over unstable products with some extra features.
Even after fully implementing the software development life cycle, addressing the lack of knowledge, and understanding the problem domain, you will still have bugs. However, there will be fewer problems than otherwise. The key is finding these remaining problems early, which is where proactive debugging can help.