# Engineering: Introducing simplicity to engineering

Fri, Feb 11, 2022 ❝Introduction to the series on Simplicity in engineering❞## Contents

In this series of posts, we look at the prevalence of *simplicity* in engineering, in particular Computer Science and more generally in programming. This series in founded on the article that defines simplicity. In the post, I pose rather strong claims about the definition of *simplicity* (and its dual: *complexity*). I will assume the definition of simplicity is complete (i.e. the three dimensions cover all aspects of simplicity/complexity) and sound (i.e. the three dimensions are orthogonal, so partitioning over these three dimensions is deterministic). We look at engineering, more specifically software engineering, in order to explore ideas, methods, paradigms, best-practices to see what sense we can make using this notion of simplicity as a foundation.

Simplicity and complexity are critical goals in engineering. The term ‘simple’ is used informally to explain that some ways/mechanisms/choices are better. The term ‘complex’ has been measured in countless ways with metrics as basic as counting lines, to complicated composites, but nowhere is simplicity/complexity defined.

An earlier series of articles on Object-Oriented Programming dives into various parts of OOP. In that introduction, I already point to the fact that there are multiple interpretations of Object-Oriented Programming. Each taking a significantly different perspective. Different to the point that very few programming languages can actually claim to support OOP in all prevalent perspectives. Similarly, people have been trying to make sense of this ecosystem and its controversies leading to, among other things, as many posts arguing against OOP as there are arguing for it. However, even if there are different interpretations of OOP, based on different emphasized values, there might still be truth to be found. This series explores (software) engineering with the definition of *simplicity*, and its dual: *complexity*, in mind.

We already started the series with a post on prematurely abandoning simplicity, in which we explore what the common terms “*premature optimization*”, “*premature generalization*” and “*premature expansion*” would mean in light of the definition of simplicity.

**Disclaimer** please note that, as stated above, I intentionally adopt a biased view in order to map ideas and practices of software engineering onto this notion of simplicity. This is a deliberate effort. *The challenge* on my part is to be sufficiently conscious and objective to avoid going overboard with this.