My Personal Manifesto of Software Engineering

Solutions

Unlike pure mathematics, software development immediately addresses problems that occur in the real world. In other words, programs are solutions for problems.

On the other hand, a solution that is not transparent is not a solution but a substitute problem.

A software that is not documented and is not transparent in what it does and how it does that may make the symptoms of a problem go away at one point, but if environment parameters change in a way that makes the software seize to function or the problem to occur in a different context, and if under those circumstances, the software is not documented and transparent in what it does, chances are that the same effort has to be invested to adapt the software as was required to construct the software initially.

Even worse, having integrated the software into an own process environment under the assumption that it constitutes a viable solution, that process environment may have become reliant on the software – the software has become indispensable. Now, the effort for updating that undocumented, intransparent software easily exceeds the effort that was required to solve the modified problem anew, from the ground up.

That is not how problems should be solved; documentation and transparency of operation matter for software as they do for all other solutions that claim to be scientific.

Please note that software providers who hold sufficient malign intent can of course read this entire section „the wrong way around“ – as an instruction on how to accomplish just that: luring unaware customers into dependencies on intransparent software and turning the massive problematic overhead that occurs in the later lifecycle of the software into lucrative business. They have a different understanding of what „software development“ means than i have.