Software is not Efficiency
What is it then?
January 10, 2025
Searching online and discussing with colleagues, I’ve often found that many people believe that ‘Software Is Efficiency’. But that’s the wrong way to think about it. Software is not efficiency. It’s just that efficiency is often the desired outcome of building software.
What is software, then? Definitions tend to be incomplete. For example, if we said that “Software consists of computer programs that instruct the execution of a computer”, even if technically true, it would be a stretch of the imagination to think of video games as software. Some might argue that interfaces are separate from software but, in the real world, the physical limits of things are part of things. Interfaces are part of the objects: our understanding of an object cannot be separated from the way we interact with it. The skin is part of a person’s body, the color is a property of an object’s material.
So I will propose an updated definition:
Software is a collection of programs and interfaces built for a purpose.
This definition highlights that interfaces are a key component of software. It makes it easier to see that video games are software, since people play video games to interact with the graphics and sound (interface), without caring about the underlying data. It also focuses on the process (“built”) and the purpose. No software is accidental, and all software is developed with a goal in mind, even if the goal is not stated explicitly. Even if a hobbyist developer wants to build a simple proof of concept, the goal is “to see if something works”. If he wants to build something for fun, the goal is “to have fun”.
A key part of this new definition is that software is built, that is, software construction plays a fundamental role. Like the physical construction of buildings, houses, and bridges, coding is a complex process that can lead to the success or failure of the software.
Construction is the only activity that’s guaranteed to be done The ideal software project goes through careful requirements development and architectural design before construction begins. The ideal project undergoes comprehensive, statistically controlled system testing after construction. Imperfect, real-world projects, however, often skip requirements and design to jump into construction. They drop testing because they have too many errors to fix and they’ve run out of time. But no matter how rushed or poorly planned a project is, you can’t drop construction; it’s where the rubber meets the road. Improving construction is thus a way of improving any soft- ware-development effort, no matter how abbreviated.
— McConnell, Steve. Code Complete: A Practical Handbook of Software Construction. 2nd ed.
To get a clear picture of what software is it’s helpful to know some of its properties. The world of software has different properties from our physical world. Let’s call this world ‘the digital realm’. Software is:
- Distributable: it can be copied cheaply without degradation of quality.
- Flexible: it can be modified.
- Scalable: it can be distributed to handle more work.
- Shareable: multiple users can use it without it being depleted.
These properties lead to desirable effects in our world:
- Minimum marginal cost: the cost of building an extra unit of deliverable software is almost 0.
- No degradation: unlike physical goods, software doesn’t get stale or damaged.
- Repeatable processes: a given piece of software always produces the same output, given the same input, same state, and same conditions.
- Efficiency, sometimes: efficiency is defined as the ratio between the output and input of a process. So if software is faster, produces more units of value, or uses fewer resources, then it is indeed more efficient than the process it’s aiming to replace.
But software is not efficiency and building software does not guarantee efficiency. For example, a new digital product might need constant manual monitoring, or it might not be as fast as expected. Modeling processes to build software can also lead to accidental complexity, that is, creating unnecessary abstractions making the code more complex than it needs to be.
The good news is that, when built properly, software is worth it. Digital products built with thought and skill improve processes, save time, reduce risk, and make a more efficient world.