Five Koans of Software Architecture
Random advice I find myself repeating a lot…
“Those who should decide on the architecture are those that will be on call for it”
Software architecture is fun. So much so that there’s never any shortage of smart people eager to jump in with their opinions. In my various engineering leadership roles throughout my career so far I have received many unsolicited architecture diagrams from ambitious, well meaning, software engineers absolutely convinced that they have found a brilliant solution to a really hard problem I owned.
My first question is always the same: “…are you going to be on call for this?”
Nothing is more effective at defusing and dispersing rubberneckers and backseat drivers than that question. I mean … the people who say yes get brought into the inner circle — obviously — but those people are few and far between.
At the end of the day the people who need to make the decisions around what the technology looks like are the people who are going to be woken up at 3am when it goes wrong. Accountability is important at work, but it’s essential in engineering.
A lot of engineers get pulled into the trap of thinking there’s one right way to build a thing and allow themselves to be drawn into arguments over technical correctness. Those fights are likely to be difficult enough to handle between colleagues within the on call team, you don’t need more opinions from people who want the glory of a win but won’t put any skin in the game.
The most important feature of an architecture is that the team running it feel comfortable with running it. Solving every other problem comes second.
“Build it the stupid way first”
Most attempts to make systems “scalable” and “resilient” from the beginning fall back on assumptions of what operating conditions will be that aren’t realistic. You end up making the system complex in places where complexity doesn’t serve any of your interests. All because you’re afraid of design flaws making you look dumb.
It’s much wiser in my experience to start with a simple and naive design, figure out how it will go wrong in theory, monitor or…