Are Software Developers Interchangeable?
When I first started my company, I believed developers were cogs in a machine. You could simply swap them out at will with little detriment to your business. After all, if you properly architected the codebase, clearly documented all the business requirements, and fully unit tested the code, interchanging programmers should be easy. But it’s not. In my experience with my healthcare clients, replacing developers, either internally or externally, has often led to bugs and missed deadlines. So I changed my perspective.
An article by Peter Naul called “Programming as Theory Building” provides an academic view of my new mindset. One quote stood out to me: “The programmer must be able to explain, for each part of the program text and for each of its overall characteristics, what aspect or activity of the world it is matched by it.” [1] In human-speak, this means the programmer must fully understand the business to create software around it.
It seems simple but the point is profound. Documentation is no substitute for understanding. I am by no means against technical specs, business requirements, and code comments. The more the better! But these must be on top of the developer’s mastery of:
Business Processes and Workflows
Parameters
Outputs and Inputs
Edge Cases -- anything that is outside a common scenario
Fundamentally almost all software, especially in the B2B space, is about understanding processes and rules. If an engineer does not understand the business, they cannot encapsulate it in code. Software is strict and does what it is told. Humans can adapt and quickly fix a process if something goes wrong, while software does not have that ability. It is why spotting edge cases are so important, as they determine what happens when software meets non-standard workflows. If a developer does not understand the business, it will cause significant problems, and likely bugs, due to lack of understanding.
This is the reason it is painful to replace a programmer. You must train a new software developer to understand your business and your underlying rules. This takes time and money. In the developer’s mind, they need to reconstruct your business in their head to start implementing features. Documentation certainly helps speed this process along, but it is no substitute for institutional knowledge. Working with another developer’s software is like being dropped into a foreign country without understanding the language. If you have a guide, you will eventually become fluent, without it you will flounder.
This has significant costs to the company. To replace a frontline developer, it can vary widely--a few thousand dollars up to 170% of their total salary [2]. Turnover is often very expensive. New programmers are unproductive their first few months on the job. For developers to start adding value, they must first understand your business which takes time.
Lots of companies have high developer turnover because programmers switch jobs every 2-3 years [3]. Good software skills in this market are liquid gold. Competition for great programmers has increased as COVID has forced companies to offer remote work. Most developers are flooded with high-quality offers daily from past employers, recruiting companies, and friends.
Is there a way to make developers more interchangeable?
No.
However, companies can retain their developers for longer than 2 years with one easy attitude change. Showing respect. It is why the idea of programmers as cogs is so demeaning – it dehumanizes them. If a developer feels respected and appreciated, he or she is more likely to stay and be a valued employee.
Respect sounds easy in principle but hard in practice. Respect manifests itself differently with each individual. To some, respect means they are given opportunities to lead large projects and grow their skillset. To others, they want their autonomy to work their own hours and have a say in important technical decisions. Respect to someone else might mean being highly compensated monetarily or in equity. Oftentimes it is a mixture of different things, which depends solely on the individual. As an owner, it is your responsibility to figure out what makes your employees feel appreciated.
I believe companies should be treating developers like snowflakes, not cogs. Each unique and special in their own way. Without programmers, you have no product to sell. The goal of your company should be to have zero turnover among developers. Achieve that and your business will thrive.
[1] A good article explaining Peter Naur’s Programming As Theory Building and a link to the original PDF: https://hiringengineersbook.com/post/autonomy/
[2] There Are Significant Business Costs to Replacing Employees – Center for American Progress. PDF Link: https://www.americanprogress.org/wp-content/uploads/2012/11/CostofTurnover.pdf
[3] This is based on a survey of 10K software engineers in San Francisco. Here is the survey with the findings: https://hackerlife.co/blog/san-francisco-large-corporation-employee-tenure
