Everyone in the software development life cycle needs to recognize the importance of the design phase and other work leading up to coding. Object-oriented programming is more than implementing classes and creating objects. You must embrace the design phase as the precursor to writing code. Some developers mistakenly allow implementation to drive design. When this occurs, the resulting solution is compromised. If the design models the implementation, there is a detachment between the problem domain and implementation, which diminishes the effectiveness of the solution. It is difficult, but not impossible, to write procedural code in the .NET environment. This is especially true of solutions ported from the native environment into .NET. When this happens, you lose most of the benefits of object-oriented programming. Unlike procedural programming, it is estimated that the average developer should spend 40 to 50 percent of his or her time in design and not writing code. If you plan to spend so much time on anything, you should do it well. That is what this chapter is about.

Sometimes culture prevents developers from a "design-first-and-code-later" approach. The reality persists in many organizations that programmers are evaluated by quantity—lines of code generated. This is a false barometer. Managers in particular must understand this and provide an opportunity and even encourage an investment in other aspects of the software development life cycle. Deadlines often amplify this behavior. When deadlines are approaching, management should not encourage an abandonment of the process and a direct-to-programming mindset. Shortcutting or omitting portions of the software development life cycle—particularly requirements analysis, design, and testing—compromises quality. Implementing a well-documented and automated development process that requires the team to go through each of the process steps for every project is a defense against deadline-induced process shortcuts. A quote from Benjamin Disraeli is relevant here: "The secret of success is constancy to purpose." This is especially important because, in most methodologies, design is an iterative phase, which requires follow through. Not updating the design as needed throughout the software development life cycle negates most of the benefit of the original work. This is primarily the responsibility of developers and testers who validate the design through implementation and testing. Therefore, your help is required to keep the design documents relevant.

In Chapter 1, we established that finding flaws within our applications early in the development life cycle significantly contributes to the overall quality and stability of the final output. 2-1 compares the amount of effort required to fix bugs found early versus late in the software development life cycle. For example, uncovering a bug during design would be early, while finding a bug during maintenance would be considered late. This table comes from "The Economic Impacts of Inadequate Infrastructure for Software Testing," a report by Gregory Tassey, PhD, and published by National Institute of Standards and Technology. It shows that it takes about four times longer to correct a problem in testing than to correct one in the design phase. This is another confirmation of the importance of investing the appropriate time in the design and other early phases of the software development life cycle.

Keeping a design current and available is imperative. Similar to comments and just as important, the design documents a program. When new resources are added to a project, such as a quality assurance engineer or additional developer, the design provides critical information. This helps someone without prior knowledge of the software system to navigate the intricacies of a product. As mentioned already, the design phase is iterative. Design documents should be updated to consistently mirror changes to the implementation. Stale design documents are more detrimental than no design documents because stale design documents represent disinformation. Finally, design documents should remain available even after product development is completed. For this reason, checking versioned design documents into source control is strongly encouraged. You should have a version of the design document checked into source control for every public version of the product. That preserves them while maintaining appropriate versioning. Unfortunately, most companies I have consulted with have outdated or entirely misplaced design documents. In the Hitchhiker’s Guide to the Galaxy, Douglas Adams wrote, "It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’" Make sure your design documents are not in that filing cabinet.

Modeling the solution is part of the design phase and integral to documenting the software system. It should be done in a known syntax, such as Unified Modeling Language (UML). UML is the de facto standard for software modeling. UML is a general purpose modeling syntax and was created from the combined effort of the three amigos: Grady Booch, James Rumbaugh, and Ivar Jacobson. These three are the pillars of object-oriented programming and originally had competing syntaxes for domain modeling. All three now work for IBM at Rational Software. For domain-specific modeling, Domain-Specific Modeling (DSM) is an alternative to UML. Either approach provides a representation of the software application or system that can then be implemented.