Software gets complicated fast. Most of good architecture and design practise is about trying to slow the rate at which software gets complicated. You can’t stop it, it’s a form of entropy. You can only slow it down and do your level best to stay on top of things.

One way to manage the mess is to maximise the likelihood that everyone knows what’s going on in the codebase. This requires two things: consistency and replaceability. Consistency implies you can make reasonable assumptions about unfamiliar parts of the application. Replaceability means you can kill code easily and replace it with something better.

Dan North argues that code should either be new enough that someone remembers writing it, or well-enough established that everyone knows how it works. It’s code in that awkward middle stage, between brand new and part-of-the-furniture, that gets forgotten about and starts to smell. If code is going to die it should die quickly. If it is going to stick around it should be stable.

In this talk, Dan describes a model for thinking about the age of code and argues for replaceability as a first class concern. He also discovers that if you optimise for both replaceability and consistency you can end up with something that looks a lot like microservices.