The Fallacy of the Big Round Ball

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 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).

Unfortunately, such strict controls have the unintended side effect of making a software system less useful to its end-users. Such decisions, often based upon short-term economics, were greatly responsible for the alienation of information technology departments from their user bases in the 1990s and the subsequent development of smaller, often duplicate, software systems within business units during that period.

The sands of requirements constantly shift under our feet. Requirements for software projects change for some very good, and very simple, reasons. First, they can. Software is a malleable medium. It is generally much more cost effective to change software than to make equivalent changes to hardware.

Second, users of software most often exist within competitive environments. They compete with each other and with other organizations. As they struggle to compete, they turn to the most malleable parts of their systems for new advantages. Software's flexibility is enticing.

If we give up on the Fallacy of the Big Round Ball, we can become more comfortable with changing requirements and see software malleability for what it is; a huge advantage that we control. Requirements will change. We will have to maintain our code. We will have to inject new requirements that will lead to violations of our designs. That is a feature, as the saying goes, not a bug.

We can design adaptable software, but only if we adapt our thinking first. Adaptability, flexibility of design, and readiness for change should be the cornerstones of any new software project.