Constantine's Equivalence

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

Turns out that mental model of software, as a _thing_ that is _made_ & 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.

We are ready to understand coupling's significance. In the original work on coupling and cohesion, Structured Design by Edward Yourdon (of blessed memory) and Larry Constantine, they 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). If the goal is to minimize the cost of software, what costs are those?

That 70% turns out to be way 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 before we can be said to be "changing" it, but who cares? That period is economically insignificant.

cost(software) ~= cost(change)