-
Occam's Architecture
I have seen IT environments where delivering applications or automations has become progressively slower and more difficult, and the human cost of maintenance keeps rising and I suspect an under-appreciation of simplicity is to blame.
Software overdue for maintenance is as common as grass. And yet in many cases the maintenance still doesn’t happen, or only happens when a deficiency finally becomes a disaster. I believe this happens because an engineering team needlessly multiplies entities. An operating environment accumulates complexity bit by bit until there are more items in it to maintain than there are people or man-hours. Management is always going to be somewhat distant from such problems, and so might not be aware of the severity. They may also simply believe there are other, higher priorities. They might even be right!
When choosing between theories, Occam’s razor is a rule of thumb that says you should prefer the one with the fewest parameters. “Entities should not be multiplied beyond necessity.” Kevlin Henney in his programming talks is always reminding audiences to design their solutions with as little invention as possible. I think a policy like this applies every time you’re bringing in long term commitments like a software framework for your IT department. Try to solve these problems with as few added entities as possible. Each entity adds not only its own overhead, but it becomes a new member in the population of possible things competing for the shared attention of the teams you work with. The fewer entities you introduce, the fewer entities are going to have to traverse the organization and overcome all the sources of friction throughout that human network. Look closely at off-the-shelf solutions to make sure you understand how many entities you’re actually bringing in. It’s often not just the one thing on the label.
Organizational friction and competing priorities are natural and inevitable things, so don’t forget them when you are choosing an architecture or new tool set. When your team takes a new dependency on board, you’re probably already thinking about its care and feeding, but it is also going require the occasional time, attention, and comprehension of others outside your team. You will eventually need their cooperation for larger maintenance tasks, and if their bandwidth is already maxed out, you and your end users could be left stuck in a very uncomfortable position.