97 Things Every Project Manager Should Know

Chapter 62. The Fallacy of the Big Round Ball

David Wood

PICTURE A BALL, manufactured to be perfectly spherical, perfectly smooth. The only design requirement for this ball is that its diameter be exact when measured at any point. This ball is polished, and polished, and polished some more, until it is perfect. Once no defects can be found, all work on the ball stops. It may not be changed. It is perfection.

Does that sound like any software project you have ever worked on? I didn't think so. Software just doesn't work like that.

Software changes constantly throughout its life cycle. Design decisions, so often based on initial requirements, suddenly seem restrictive when new requirements emerge. Hacks to adapt the code to new requirements violate the design and make the code progressively less maintainable. The ball, however round it was intended to be, becomes battered and bruised.

The Fallacy of the Big Round Ball is the delusion that software system requirements don't change appreciably after delivery or, worse, that they can be controlled.

Early software engineering researchers believed that if requirements could be fully understood before coding began, there would be no maintenance crisis. Some took note of problems created by post-delivery changes to requirements and labeled them evil; static requirements yielded more stable systems. Some sought to limit a user's right to request ...