Chapter 30. Constantine’s Equivalence

I remember as a young programmer hearing dire reports that as much as 70% of software development costs went into maintenance. Seventy percent! How poor a job must we be doing that we make a thing and then have to spend twice as much just keeping it working?

Turns out that mental model of software, as a thing that is made and then should run forever unchanged, like some kind of perpetual motion machine, is the opposite of what really happens, and what should happen, too. The future value of a system reveals itself in today’s realities, not yesterday’s speculation.

With the way that coupling affects software development in place, we are ready to understand coupling’s significance. In the original work on coupling and cohesion, Structured Design, Ed Yourdon and Larry Constantine postulated that the goal of software design is to minimize the cost of software (it’s also to maximize the value, but we’ll get to that). But what are those costs?

That 70% estimate turns out to be way too low. If we apply our creativity, we can release value-creating software after only a few percent of its eventual development cost. It’s in everyone’s best interest to do so. The sooner we get feedback from real usage, the less time/money/opportunity we spend on behavior that doesn’t matter.

The first term of what I’ve dubbed “Constantine’s Equivalence,” then, is that the cost of software is approximately equal to the cost of changing it. Yes there is a brief period ...

Get Tidy First? now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.