Why do your developers want to leave?
The economic impact of bad architecture and quality
Software engineers love to job hop. What triggers them leaving? Let’s explore.
I stumbled upon an whitepaper review by Swizec: System Design and the Cost of Architectural Complexity (2013), a PHD by Daniel J. Sturtevant.
Now seemingly worlds apart, Swizec and I used to be class mates in university. We ended up choosing the same career specialisations with training and coaching in software. Though he did have a significant head start in the market and followed his passion early on. That has little to do with this daily issue. But he’s an inspiration to me and I wanted to mention it.
Emerging Complexity in Legacy Software
The dissertation highlights a common reaction by engineers: we hate working on old, complex software we don’t understand. It turns out— we hate it so much that we’re prepared to throw in the towel and roll the dice at a shot with another company. Granted, relationships with peers and managers play a significant role in this, that can’t be denied and it is not refuted or strongly correlated by the paper.
The study found two important factors:
[Accidental]emphasis mine complexity causes up to 50% drop in productivity
Developer that spend significant time in complex architecture are more likely to leave
The paper uses the phrasing “Uncontrolled” complexity to capture what I call accidental / needless complexity. We’ll used these terms interchangably in this issue— though I’m aware they have important nuance that we cannot cover at the moment
“Veterans” working on your “Core”
What concerns me is that I’ve seen this. Often. You may have too.
Your most complex architecture is generally found in the core domain of the product. A core domain is generally of high cohesion and high coupling. If you don’t mind— here’s a refresher that contains a video by Vlad Khononov. I love that video! Hope to meet Vlad some time.
Putting one one one together:
Architectural Complexity that hampers productivity causes developer churn
Your best, veteran engineers work on the most complex—core—systems
They are the first ones out the door. Most companies I coach are seeing— no, living this reality. Yet, they don’t seem to be doing much to prevent it or even to signal awareness of this.
Conclusions of the Study
Architecturally complex source code files have a much higher defect density. The most complex code was found to have triple the defect density of the least complex code.
Architectural complexity impairs the productivity of software engineers working with it. If a hypothetical group of engineers working in the least architecturally complex regions of the codebase were to be moved into the most complex regions, their productivity would decline (conservatively) by 50%.
Architectural complexity causes staff turnover. Software engineers working in the most complex regions of the code had a probability of leaving the firm that was ten times greater than their peers working in least architecturally complex code.
Code Health, Quality and Employee Wellbeing are Not Optional
It’s 2023. And it’s time to wake up. I see plenty of teams following mediocre industry advice churning out mediocre software at a slow pace and spending a ton of money doing so.
Salaries are the biggest expense in most software companies followed by software licenses and server costs. Most of that salary budget is leaning towards recruitment and onboarding.
The Software Industry is Obsessed with Inspecting Bad Quality rather than building it into the software.
Focus Areas— Two Accelerators
The solution is simple in terms of complexityhah, punny!—sadly, it requires a lot of politics:
Shift development processes out of “management” and “product” into the engineering department. Make the team vertically integrated and integrate the Product Manager as an exclusive IC within the team who mobs or pairs frequently.
This takes care of accelerator number one.
#1 Cut Scope, define high quality business requirements
And it has a caveat, the requirements have to be understood, defined and agreed to by the engineering team. In that order. I know most VPs of product and Product Managers are rolling their eyes. You might hate your VPs reaction to this notion. But this is the major floodgate for all of the above problems with developer retention. Granted, this is for new features.
Which brings us to accelerator number two.
#2 Quality must be a Core Value that costs you
No one said quality is cheap. But bad quality is more expensive. These concepts are not orthogonal. Just like with workout, if you don’t work out you’ll have less energy. Which will make you feel tired and discourage you from working out. It’s a spiral that you don’t want to end up on the wrong side of.
Here’s a number of initiatives to point you in the right direction for quality:
Maintain the Team Unit, stop planning, blaming or rewarding per-developer efforts
Plan the exit of each project. How is it planned, released, maintained, sunset? Who will retain knowledge of it? Who will maintain it and understand it?
Pair program and write implementation test-first.
Failing that, write test-first solo and pair for the code review.
Failing that, write test-first and review pull requests asynchronously.
Failing that, pair just the documentation and the tests, then implement solo.
Failing that, don’t build commodity software you don’t deem worth testing or documenting.
Architect the team’s capabilities. Read Team Topologies.
Plan their focus, optimise for Flow. Encourage them to expand their boundaries.
Push to focus and iterate on one thing several times rather than pressing deadlines.