How can we build software applications that are resilient to changes in the engineering team?

A while back, I posed the question “Are software applications getting harder to maintain?” and then I read this tweet yesterday which again touches on the consequences of high engineer turnover and potential for misaligned incentives:

Replies to Dare’s tweet seem to focus on solving the problem of “How can we get engineers to stay longer in the same company?”, with ideas for improving internal company culture and other non-compensation related quality of life aspects. This is all noble stuff and I don’t disagree with these suggestions. But as someone who (a) has not been a full-time employee for almost a decade, and (b) believes that exposure to many working environments is the best way to learn and grow, I don’t feel I’m in a position to weigh in on that debate.

Instead, I’m more interested in asking the question: “How can we build software applications such that they’re resilient to changes in the engineering team?”. The old bus factor discussion. Begin with the assumption that there’s a chance that some key team members may not still be there in a few months’ time and act accordingly.

The high-level approach to doing is a pretty boring one: KISS when choosing tech and architecture, write tests, write good docs and automate your releases. Obviously this is much easier said than done. And perhaps it’s true that many FTE engineers with lots of job opportunities don’t have enough skin in the game to devote time to some of these, or worse, are actively incentivised to do the opposite and choose more complex techs in order to further their career.

I don’t know the best way to change this, but it’s something I’m going to think more about. Would love to hear any thoughts or experiences you’ve had in this area.

— Paul