(^124) 97 Things Every Project Manager Should Know
The Fallacy of the Big Round Ball
David Wood
Fredericksburg, Virginia, U.S.
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 cri-
sis. Some took note of problems created by post-delivery changes to require-
ments and labeled them evil; static requirements yielded more stable systems.
Some sought to limit a user’s right to request changes (e.g., “Reduce the need
for change maintenance by planning for and controlling user enhancements”
was one of a list of “solutions to maintenance” suggested by James Martin and
Carma McClure in 1983).