It would be better to avoid hidden assumptions that lead to sudden surprises by following the example of the Social Security Administration's Unified Measurement System project. Tasked with updating the existing performance evaluation system for 1,300 field offices, Harriet Hardy, the program manager, started by defining the business rules first, then evaluating the existing system to establish the baseline. This process uncovered differences between the documented performance-measurement policies and how the policies were implemented in the software. Had Harriet simply assumed that the existing system was operating correctly because no one said otherwise, the errors could have been perpetuated even longer.
Of course not all management is willing to invest in functional introspection. Discovering and documenting functionality takes time but produces no lines of code, and unfortunately, code is sometimes confused with value. The true, underlying asset—the knowledge expressed in the system—is often neglected. Ironically, it is this knowledge that gives the software value, not the number of lines of code. No one buys software by the pound. Yet time for detailed analysis, planning, and documentation are often squeezed by the need to show supposed tangible progress.
A project to rearchitect one of our core components has taken thousands of hours so far, and most of this was not even analysis or design—let alone coding—just basic domain-knowledge transfer. Unfortunately, I know from expensive experience that assuring a comprehensive understanding by all team members from the beginning will avoid far more costly issues in the future.
So expose your hidden assumptions, bring them into the light, and question them. It may be the most important quality step you can take.