Change is the Value of Software

The easier it is to change software, the more value it has. Software that is difficult to change is a liability.

On its surface this idea appears kind of mundane... but so is most of the software we make! The further I go in my career, the more profound it seems to me, and that part is interesting.

Cliché compressed version.

Here's the TLDR version, with so much detail removed it becomes a truism.

Software that cannot change has no value.

Below are a few longer versions with more detail.

For fun, I typed out a paragraph freely as thoughts came to me, made no edits, and then asked a few language models to refine it.

Here is the "best cut" — a synthesis of my favorite model revisions. I've highlighted my favorite parts from each model below. The original unedited version is also included.

Full final version.

Software exists to amplify human capability. Doing "more with less" makes it fundamentally an economic endeavor. From this economic lens, software quality must be measurable, so that we can make tradeoffs between cost and value. The most meaningful measure of software quality is its cost of change, because in our chaotic and unpredictable world, requirements inevitably shift, making adaptability the key to remaining valuable. Software that is expensive to modify becomes a liability rather than an asset. This makes maintainability not just a technical consideration, but the fundamental economic property that determines a software system's long-term value.

Spicy version.

If you cannot measure how easily your software can adapt to change, it isn't worth building at all.

Original, unedited.

"One idea that I always come back to in software engineering is that, because software is a tool that people use "to do more with less" it is a fundamentally economic endeavor. What does this mean? To me, it means that the quality of software is tied to how good it is as creating more value with less cost. That in turn means that I believe that no software is worth building if its quality is not measurable. The way I choose to measure quality is: how expensive is the software to change? The reason I chose this measure of quality has something to do with the fact that requirements change a lot, because the world is fundamentally chaotic and unpredictable."

My prompt: Can you help me take all of these sentences and compose a logical, elegant, concise argument that explains my core philosophy?

ChatGPT o3-mini-high.

Software exists to amplify human capability—doing more with less—so its value is intrinsically economic. Quality, then, must be defined in terms of delivering greater value at reduced cost. In a world where change is constant, measurable quality means ensuring that software can be adapted at minimal expense. If adapting software is costly, its economic utility diminishes, undermining its purpose. Therefore, if you can't quantify quality—by how easily the software can change—it isn't worth building at all.

ChatGPT o3-mini.

Software is fundamentally an economic tool designed to generate value while minimizing costs. Its quality, therefore, must be judged by how efficiently it can adapt to change — because in a chaotic, unpredictable world, requirements continually evolve. If you can't measure quality, particularly in terms of the expense required to modify the software, you're essentially flying blind in an environment where change is inevitable. Thus, a well-engineered system is one that provides significant value with minimal cost of adaptation, ensuring it remains relevant and effective over time.

Claude 3.5 Sonnet.

Software engineering is fundamentally an economic discipline because its core purpose is to help people do more with less. From this economic lens, software quality must be measurable to justify its creation and maintenance. The most meaningful measure of software quality is its cost of change, because:

1. The world is inherently chaotic and unpredictable.
2. This unpredictability means requirements will inevitably change.
3. Therefore, software that is expensive to modify becomes a liability rather than an asset.

In essence: good software maximizes value creation while minimizing adaptation costs in an ever-changing environment. This makes maintainability not just a technical consideration, but the fundamental economic property that determines a software system's long-term worth.

ChatGPT o1.

Software is fundamentally economic because it exists to help people do more with less, which means its value depends on how effectively it reduces cost while increasing output. Consequently, no software is worth building if its quality — defined by its ability to create value — cannot be measured. To me, the best measure of quality is how costly the software is to change. This is important because requirements inevitably shift in a chaotic, unpredictable world, making adaptability the key to remaining valuable.

ChatGPT 4o.

Software exists to help people achieve more with less, making it fundamentally an economic endeavor. Its value is tied to its efficiency in creating more benefit at a lower cost. Since requirements are constantly evolving due to the chaotic and unpredictable nature of the world, the true measure of software quality is how expensive it is to change. If software is too costly to adapt, it fails its fundamental purpose. Therefore, no software is worth building unless its quality is measurable, and the most meaningful measure of quality is its adaptability over time.

Conclusion.

I think what's probably most absent from the above has something to do with the "science" part of Computer Science. The above perspective is fundamentally engineering-focused and economic in nature. Most of the decisions I make in my day-to-day work are primarily economic: where in the system to invest time and effort. I try to be as keenly aware as possible of the tradeoffs I'm making and the constraints I'm working under.

That being said, I did not become a programmer because I love constraints. I became a programmer because, from the outside, programming looked like magic, and I wanted to understand how it worked.

This principle says nothing about how programming works.

Or does it? 🤔