A Note on Essential Complexity

There's a lot to like in this article, but I would go a step further with its meta-abstractions. At complexity 0, there is no software to be written. In essence, complexity and the software itself are closely related, akin to the relationship between compression and AI. The article's thesis is that minimizing complexity is what engineering is about. That means we're kind of minimizing the total amount of software we have to write and maintain. Makes sense, so far so good.

Next up is architecture. More architecture generally means more complexity in the short term and less in the long term. But that's assuming we know what the long term will look like, which we can often only predict. If we under-provision architecture, there's a good chance we'll get buried in technical debt later on (though by then we may have switched gigs.) Enter the usual Agile arguments favoring the short term.

Last but not least, path-dependency. I think this is where the best designers shine. You might not need all the architecture right away, but you do need to steer clear of dead-ends. These are the bad quick-design decisions that bite you in the rear when the architecture eventually gets refactored in. An extreme example might be the lack of a version field.

IMO, awesome designers are great at predicting where the architecture will be and at forward-provisioning it. They don't need to build the freeway through the middle of town. They'll just plan a park here and a parking lot there, guessing the right spots.