Three Laws of Software Complexity (or: why software engineers are always grumpy) | mahesh’s blog

What I think this article gets very right is that complexity is a fundamental challenge in software systems. The more complex the system, the harder it is to do everything with it. Harder to modify. Harder to support. Harder to keep running. So, it follows that removing complexity should result in easier for all of those things. This is perhaps the foundational belief that drives micro-services. Limit complexity in each service and overall average complexity through the entire system. Balakrishnan highlights three principles.

1. A well-designed system will degrade into a badly designed system over time.
2. Complexity is a Moat (filled by Leaky Abstractions).
3. There is no fundamental upper limit on Software Complexity.

This line caught my eye.

The second derivative of code is always negative in the wild: the rate at which code can change goes down over time.

I think the always in that is too far. This is where the work that DORA has focused on can help. Left unmonitored I agree, the rate of change does go down. Left unmaintained it also will go down. One of the nasty things with software is that when you stop changing it you lose the confidence to change it.

I’m not going to suggest there is a known process for keeping code agile for decades, but for several years applying the right practices can keep things in a "good enough" state.