I’m not even sure if software engineering exists, or whether it should be called as such. See my opinionated post below.
How software emerged
As a reference, I have a ‘mechatronics engineering’ MSc, which is mostly a mix of electronics and mechanincal engineering. These classic engineering fields are called ‘engineering disciplines’.
Mechanical (and also civil) engineering is about 200 years old, electrical engineering is about 70-80. Whatever you’re designing, you’re leaning on the ‘shoulders of giants’, leveraging knowledge that may be more than a hundred years old.
Computer science has in fact branched from mathematics. In order to create computers and programming languages, we needed the computability notion of Turing completeness and the primal computer architecture (still holding today) envisioned by John Von Neumann.
Computer engineering, the practical side, kind of branched from electronics engineering, since software in first- and second-level programming languages were very close to the hardware.
You couldn’t just write an app in some high-level language, but rather needed to know a lot about low-level stuff like hardware architecture and CPU instructions.
Software gained huge traction in about 35 years ago, when personal computers became affordable, and embarked on a journey to eat the world. and now people call themselves ‘software engineers’. Heck, my employer calls me a software engineer!
Software engineering vs. hard sciences
Software engineering activities are similar to existing engineering practice in that you are modeling, measuring, researching and methodically refining a design in order to work towards some concrete end goal i.e. a software product. You can apply all the known engineering approaches and methods to design, implement, test and maintain software.
On the other hand, software engineering is totally different, much ‘softer’ (no pun intended) than mechanical, electrical, chemical or civil engineering that have something in common: they build on natural sciences.
In these classical disciplines, if you want to do something, you refer to some relevant physical or other scientific models, formulae, tables, standards whatever; get some results, maybe measure and simulate a bit and get a concrete result. Multiply by it some safety factor and there you go.
You can be sure because these standards and laws have been known for decades if not hundreds of years, they have been battle-tested in millions of applications. (Buildings, power and electronic systems, infrastructure, machinery, chemical processes etc.)
Compare this with software? Not so much. In that sense, it reminds me of non-natural sciences like social sciences or economics.
For each software problem to solve, you have 10 different languages, 100 frameworks, 20 totally different ‘paradigms’ with their own consultants, zealots and flamewars. Several could produce a satisfying solution to your problem, but they usually get replaced every 5 years.
Good old times?
5 years old software is called ‘legacy’, software that is 15 years old is often called a classic game or an anachronistic joke. Software expands like gas, taking up all available storage space and computing performance, but as time passes, in return we get many more layers of abstractions and a more complex development infrastructure. (Plus a nice UX, more ads and less privacy.)
We may think back of the ‘good old times’ when an operating system with several userspace software was able to run on e.g. a 233 MHz computer with 16 Mb of RAM (this was way after ‘640 kb was ought to be enough for anybody’). But we definitely don’t want to develop software the way it had been done back then, because we can create more, (maybe better) products, significantly faster.
As Uwe Friedrichsen puts it in his post about reusability:
…assume you need to build a not too challenging solution, e.g., a small e-commerce web shop that needs to run in a desktop browser and on mobile devices. If we leave aside for a moment that we can create such solutions today with tools like Shopify in a day or two, then this would be a task for a small team (5-7 persons) for 3-6 months.
But if you would need to start at the level of a bare programming language (3GL, turing-complete, no standard libraries, no ecosystem), this would be a daunting task: Probably a 100 or more people working for years, not knowing if they will succeed at all.
This enormous difference in productivity is the merit of reusability. If you needed string processing in C++ in the early 1990s, you needed to implement it yourself. Today, you start a whole HTTP server and more with a single line of code. This is reusability!
Uwe Friedrichsen, The reusability fallacy – Part 4
E for engineering, S for software
As we see, with classical engineering disciplines, the primary driver of progress was scientific research. Published in peer-reviewed journals, they meant a foundation for engineers to create well-documented and tested applications.
Software is changing much faster and it’s… well, soft.
- We don’t have (natural) laws, we have ‘paradigms’ – one essentially never changes, the other apparently changes every few years.
- We don’t have measurements, we have ‘metrics’ – we measure something but the goal is usually not to improve some model or control a system in a feedback loop, just to examine some system as it’s running, and restart it when it crashes…
- We do have some standards (like ISO, ANSI), but compared to the speed of standards bodies, software is moving at a neck-breaking speed, and they are unable to catch up. Organizations like IETF and W3C represent ‘software standards’ much better, and work in a substantially different way.
- We have some common terminology, but there is a lot of hype and buzzwords going around. The latest and greatest framework, architecture, language, paradigm, engineering method, whatever, promising easy and fast results. Of course.
Mother Nature doesn’t want to earn money on you when it comes to physical models. Consultants on the other hand do, when trying to sell their latest & greatest paradigms, ’10x’ engineering practices and lean methodologies.
Firms and managers can’t buy natural laws (though they do pay a lot to access ISO standards :)), but they love to rewrite their software into the latest and greatest architecture or framework, often without enough justification.
Summing up
What engineers/developers are doing may be similar to classical engineering practice but is way less exact. We may reason about programming languages, application architecture and business logic, but ‘clean coding’ practices and everyday ‘which library/framework should I use?’ questions are far from anything formal.
All in all, ‘software engineering’, although shows some similarities in approaching problems, is fundamentally different from existing classical engineering disciplines, changes much-much faster and probably we should come up with a better term for it, rather than abusing existing terminology.
I heard for example software craftsmanship… but I’m unsure.
What do you think about this?
Leave a Reply