Are common abstractions a sign of engineering maturity?

It has often been said that software engineering is not as mature as other engineering disciplines. I can agree with that, often it seems that the way we design large software systems is more akin to how great cathedrals in europe were constructed, with a blend of some basic understanding of mechanics, craftsmanship and artistry. We don’t have the equivalence of finite element methods for doing structural calculations etc.

But I realised ne thing that also sets software engineering apart from e.g. mechanical or civil engineering. We don’t have a universally accepted set of abstractions that we work with. A mechanical engineer has e.g. a blueprint (often drawn in a CAD program) which everybody can read regardless of where they are educated or which company they belong to (even if they are not familiar with a specific CAD program).

We don’t have a corresponding set of abstractions in software, if you go fromĀ one company to another they will use a different set of abstractions, form the low level (.g. choice of programming language), via design descriptions (which could be UML), to how to describe properties or requirements. And our tolls follow that, it is almost the other way around, the abstractions we use are dictate by the tools we choose, instead of the tools adhering to a common “view”, and what they differ in are things like UI, features etc.

I don’t think that software engineering will be considered a mature engineering domain unless we actually have a set of universally accepted abstractions which all software engineers are familiar with.

Leave a Reply

Your email address will not be published. Required fields are marked *