Software is eating the world. Those of us who work, live, and love software do not usually stop by to think about its meaning.
TL;DR: We will address current software design problems in a minimalist way.
In university and industry, we use 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 we understood that software is much more than a program.
We still don’t have good 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.
The definition is by the complement (everything that is not hardware). Or by physical omission (everything that cannot be kicked and can only be cursed).
Yet, the only purpose we have whenever we build software that is:
To mimic something that happens in a possible reality.
We are forgetting about 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 with most computer software applications today.
Returning to the origins we 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.
Under a certain lens and a particular perspective with a certain paradigm.
It is not the truth revealed.
It is the best possible conception at a certain moment with the present knowledge. Since Plato’s time, human beings have tried to build good models of reality.
Photo by Max LaRochelle on Unsplash
Why is it a (A)bstract?
We can only understand and observe it with instruments such as a black box based on its behavior in the face of our stimuli.
Like Schrödinger’s cat.
We 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 that can keep up with model evolution.
Why is it (P)artial?
We will make a partial cut of the reality that interests us for the problem we are modeling.
This is common to scientific models.
Taking certain simplifications on aspects that do not interest us 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 us observe its evolution.
It allows us to reason and predict behaviors in the reality we 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 we define the software, we can begin to infer good modeling and
design practices.
Starting Point
We have the axiomatic definition presented in this article.
We will infer principles, heuristics, and rules to build excellent software models.
https://dev.to/mcsee/the-one-and-only-software-design-principle-3086
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://dev.to/mcsee/object-design-checklist-2p4
We look forward to comments and suggestions on this article.
This article is published at the same time in Spanish here.
Top comments (1)
It's fascinating to mirror on the definition and cause of software program as some thing that is frequently taken for granted in our every day lives. It's genuine that software program has emerge as ubiquitous, and it is handy to overlook about the intricacies concerned in its creation. I think that the minimalist method to addressing present day software program diagram issues is a clever one, as it is essential to focal point on the necessities and no longer get bogged down in pointless complexity. Looking again to the origins of programming languages like Simula can additionally furnish precious insights into the genuine reason of software program construction as well. So defining software program as the building of an Abstract Partial and Programmable Explaining Reality (M.A.P.P.E.R) is a innovative and thought-provoking way to suppose about the underlying reason of software. Check a great post to read about cross-platform app development. thesmallbusinessblog.net/significa...
Some comments may only be visible to logged-in visitors. Sign in to view all comments.