Simplify! – Introduction

When I look around, I see two evolutions that in combination worry me a lot:

1. IT has become an indispensable part of everyday business and private life.
2. The complexity on the IT solution side grows all the time.

Therefore, I wrote a blog series that discusses this evolution, its effects and what we can do about it. ¹

The series consists of the following parts:

• Part 1 – Software has become indispensable in our everyday business and private life. If the software does not work as intended, we have a problem. At the same time, complexity in IT explodes and we are drowning in ever-growing complexity in IT – a worrying combination.
• Part 2 – The complexity explosion stresses affected people out. As a result they develop counter-productive “survival patterns”: Going for superficial knowledge. Hyper-specialization. Ignoring developments. Becoming “opinionated”. Giving up. Or burning out while trying to keep up. Those patterns lead to vicious self-reinforcing cycles that lead to even more complexity.
• Part 3 – Complexity needs to be divided in essential and accidental complexity. Essential Complexity is inherent in, and the essence of, the problem (as seen by the users). Accidental Complexity is all the rest —- complexity with which the people affected would not have to deal in the ideal world. While we cannot eliminate essential complexity, we need to work hard to avoid accidental complexity.
• Part 4 – We need to distinguish different kinds of accidental complexity: Due to unnecessary requirements not adding value to the solution. Due to overly complex platforms regarding the given problem. Due to a lack of adequate platform support regarding the given problem. Due to overly complex software regarding the given problem.
• Part 5 – Accidental complexity on a market level. Old response patterns to changing market realities lead to a lot of accidental complexity. Many companies face post-industrial markets and try to address changed markets demands by intensifying old industrial response patterns.
• Part 6 – Accidental complexity on a company level. Not understanding IT (especially its primary “material” software) and the role of IT today lead to a lot of accidental complexity, either by imposing counter-productive practices on IT or by blindly copying concepts from others without understanding them.
• Part 7 & Part 8 – Accidental complexity on a project level. Degenerated budgeting and IT staffing processes. Inward-bound focus of the organization resulting in a loss of market focus. Neglecting uncertainty reinforcing the situation. “Agile” and “DevOps” cargo cults, reinforcing industrial practices in a new disguise. The “high utilization means more productivity” fallacy. Rigid project constraints for the wrong reasons. All these and more lead to increasing accidental complexity.
• Part 9 – Technology explosion as the result of an ongoing, not yet completed technology evolution cycle. FOMO and the tendency to blindly copy concepts as reinforcing drivers. And so on. Massively increased accidental complexity as a result.
• Part 10 & Part 11 – Accidental complexity on an architectural level. Unresolved design deficiencies. Black holes and strange attractors crippling evolution. Architecture narcissism leading to bloated designs. Neglecting the business domain and focusing on technology only, and vice versa. The habit of DIY, combined with misconceptions regarding OSS. Missing the technology evolution. All these and more lead to increasing accidental complexity.
• Part 12 – Accidental complexity on an implementation level. Breaking existing designs. Going for implementation shortcuts. Design by Stack Overflow. Show-off implementation. Keystroke theater. Quality theater. All these and more lead to increased accidental complexity.
• Part 13 & Part 14 – An IT landscape consisting of layers of systems never cleaned up. Missing responsiveness of IT leading to solutions bypassing the IT department. Fear of decommissioning old systems. Missing the technology evolution and when to replace complex custom-built solutions. The “no-time to clean up” fallacy. The big clean-up initiative, trying to fix the existing mess “once and for all” with a single approach. All these and more lead to increasing accidental complexity.
• Part 15 – Summing up and some general considerations. We need to simplify to survive in the long run. Some of the general recommendations do not only help in this context. Learn to do the right thing. Do not only focus on doing things right.

I have augmented this series with 3 posts about OSS, the first one discussing the rise and benefits of OSS, the second one discussing widespread misconceptions regarding OSS and the third one discussing the changed role of OSS in a cloud-native world.

Additionally, I discussed the continuous amnesia issue of IT, i.e., that IT as an industry tends to continuously forget everything it has learned. As a result, IT tends to make the same mistakes over and over again, also making to harder to improve with respect to the complexity challenges we have.

Overall, these are 19 posts and admittedly some of them are relatively long. So, together this series is rather a short book than a few posts. Maybe I will turn it into a book later or make it part of a book that also discusses this topic – who knows?

But until then, I wish you an interesting read if you decide to dive into this blog series and hope that it contains some food for thought and maybe some impulses for you. Enjoy!