Technical stuff Requirements are like water. They're easier to build on when they're frozen.

If you emphasize quality at the beginning of the project, you plan for, require, and design a high-quality product. If you start the process with designs for a Pontiac Aztek, you can test it all you want to, and it will never turn into a Rolls-Royce. You might build the best possible Aztek, but if you want a Rolls-Royce, you have to plan from the beginning to build one. In software development, you do such planning when you define the problem, when you specify the solution, and when you design the solution.

Since construction is in the middle of a software project, by the time you get to construction, the earlier parts of the project have already laid some of the groundwork for success or failure. During construction, however, you should at least be able to determine how good your situation is and to back up if you see the black clouds of failure looming on the horizon. The rest of this chapter describes in detail why proper preparation is important and tells you how to determine whether you’re really ready to begin construction.

I just started delving into “Code Complete” and it’s fun and fascinating to read. I think that everyone involved in the software development process should understand the implications of every aspect. The time when we said “web applications should go to the market as fast as they can” is now gone. I do agree that in the web world things are moving pretty fast, but who will use a buggy / mis-designed software just because its authors wanted to get the first slice?