What is (wrong with) software?
Software is eating the world. If you work, live, and love software, you usually do not stop to think about its meaning
TL;DR: Current software design problems addressed in a minimalist way.
In university and industry, you often find the following definition of software:
Software is a set of instructions that with certain input data generates output data.
This is the definition of a computer program according to Wikipedia:
A computer program is a collection of instructions that can be executed by a computer to perform a specific task.
Many decades ago, computer scientists understood that software is much more than a program.
They still lack clear definitions of what is software.
Again, according to Wikipedia:
Computer software, or simply software, is a collection of data or computer instructions that tell the computer how to work. This is in contrast to physical hardware, from which the system is built and performs the work.
This definition works by contrast (everything that is not hardware) or by omission (everything you cannot kick but can only curse).
Yet, the only purpose of building software is:
To mimic something that happens in a possible reality.
This was essential during the origins of modern programming languages like Simula.
Simula was the first object-oriented programming language to include classification.
In the language, it was clear from the name that the goal of software construction was to build a simulator.
This is the case for most computer software applications today.
Returning to the origins you can define the software as the construction of a:
(M)odel: (A)bstract (P)artial and (P)rogrammable (E)xplaining (R)eality.
Why is it a (M)odel?
The model is the outcome of observing a certain aspect of reality.
Built under a certain lens, perspective, and paradigm.
It is not the revealed truth.
It is the best possible conception at a given moment with the available knowledge.
Since Plato’s time, human beings have tried to build good models of reality.
Why is it a (A)bstract?
You can only understand and observe it with instruments such as a black box based on its behavior in the face of your stimuli.
Like Schrödinger’s cat.
You cannot know what state it is in without disturbing it with our measuring instruments.
The use case technique is an excellent tool to describe a model in a declarative way.
If you are not a declarative programmer, you might lose your job very soon.
Why is it (P)rogrammable?
It has to run in some type of simulator that reproduces the desired conditions.
It can be a Turing model (current commercial computers), a quantum computer, or any type of simulator capable of evolving with the model.
Why is it (P)artial?
You need to make a partial cut of the reality for the problem you are modeling.
This is common to scientific models.
You take simplifications on aspects that are not relevant to isolate the problem.
A 1:1 scale map of the earth would not make sense.
Why is it (E)xplanatory?
The model must be declarative enough to let you observe its evolution.
It allows you to reason about and predict behaviors in the reality you are modeling.
Why is it about (R)eality?
Because it has to reproduce conditions that occur in an observable environment.
The ultimate goal is to forecast the real world, like any simulation.
Once you define the software, you can begin to infer good modeling and design practices.
Starting Point
You have the axiomatic definition presented in this article.
From it, you will infer principles, heuristics, and rules to build excellent software models.
%[https://maximilianocontieri.com/the-one-and-only-software-design-principle]
Acknowledgements
These concepts are based on the thoughts of David West, Máximo Prieto and Hernán Wilkinson.
Part of the goal of this series of articles is to generate spaces for debate and discussion on software design.
%[https://maximilianocontieri.com/object-design-checklist]
I look forward to comments and suggestions on this article.
Spanish version: ¿Qué es(tá mal en) el software?