software is not efficiency

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 successful software projects.

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 and user interfaces as software. One could argue it is computer programs that, behind the scenes, are driving the computer to display the interface, but it's more practical to think of the interface as a different artifact altogether.

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. With it, it's easier to see that video games are software, since people play video games for the single reason of interacting with and becoming immersed in the user interface, including graphics and sound. 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, software construction is a complex process that can lead to the success or failure of a software project.

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.

Our updated definition of software doesn't say anything about design, requirements, and testing, which are not part of software construction. Many times these processes are neglected or ignored, leading to problems during the construction stage, or later, when the product is built. So even if not directly part of the definition, these processes are still key to successful software projects.

To get a clear picture of what software is, besides a definition, it's helpful to know some of its properties. To better grasp these properties, it's better to think of software as existing in a different world with its own properties, different from the physical world we live in. We will call it "the digital realm". Software is:

• Distributable: it can be distributed and reproduced without degradation of quality.
• Flexible: it can be updated or modified without being damaged.
• Scalable: can be distributed and scaled up 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. Note that software can, however, get old (legacy software) when it becomes hard to maintain, or when it stops being useful. For example, it becomes harder to maintain software if it depends on outdated libraries or services, has security flaws that need patching, or it becomes hard to find programmers with relevant expertise.
• Repeatable processes: a given piece of software always produces the same output, given the same input, same state, and same conditions.
• Efficiency: it is defined as the ratio between what you get out and what you put in a process. So if a process is faster, produces a higher output, or uses fewer resources, software is indeed more efficient than the process it's aiming to replace.

A side note. One of the downsides of software is that modeling can quickly lead to unnecessary complexity. That is, complexity that is not part of the original process but is caused by the modeling of the process instead.

So software is not efficiency and software does not guarantee efficiency, because the fact that a process is built in the digital realm does not imply that it will be faster or use fewer resources. If a software project is carried out poorly, its product may be less efficient than the original process it sought to improve. For example, because it needs constant manual monitoring, or because it is not as reliable as expected.

The good news is that, when built properly, software projects are worth it. Proper software improves processes, saves time, reduces risk, and makes a more efficient world. Even if software doesn't mean efficiency, software made with thought and skill will result in more efficient processes.