Does Technical Debt Cause Employee Turnover?
One of the ongoing discussions in our eLearning is on the topic of Technical Debt.
Does technical debt cause employee turnover?
What the Heck Is Technical Debt Anyway?
Technical debt, as defined by Ward Cunningham, refers to a conscious choice to work with your current understanding of a problem, even though you know it's incomplete. The code you write, of course, should be excellent.
Ward's definition is in stark contrast to the idea of building messy, unclear code with (or without) an intention to clean it up later.
Represented in the discussion are two camps, which we will call "Gargantua" and "Under Pressure".
Gargantuan projects have a lot of everything: a lot of code, a lot of developers, a lot of promises outstanding, a lot of bureaucracy, a lot of time, and a lot of defects.
In gargantuan projects employees usually have high job stability and are not necessarily motivated to make code more malleable.
The large number of developers makes it hard to establish standards of code hygiene. Many styles of programming and problem solving will be present, and many cases of accidental code duplication.
One expects people in gargantuan teams to develop narrow expertise in an isolated area of code. Being "the only one who can work in this code" creates a dependency that provides job security.
When developers work outside of their own silo, they make changes which require the least amount of change. Rather than refactoring, it seems safer to just add a flag and an if statement and get out of the code quickly. These shortcuts complicate the code.
The urge to quickly burn through the defect list may create additional competition for programming time, resulting in more shortcuts and complicated fixes. These eventually result in more defects.
Nobody denies that working in lousy code is a source of stress. Nobody suggested that people create the technical debt intentionally.
It is suggested that tolerating a certain degree of technical debt can work to an individual's benefit.
In the second camp are organizations with a sense of constant crisis.
Their culture is one of overwhelming short-term expediency. Ward Cunningham reminded us that we can reach a point of significant burden this way, but expediency demands that future issues are ignored while short-term issues loom large.
It might seem that people under constant time pressure would be the ones who can least afford mess and clutter. However, it is more common that they defer hygienic code practices.
Because of constant crises, developers in high-pressure shops feel that they are being more responsible by merely getting the code to a working state and then moving on.
Whether they are right or wrong is a complicated issue. We aspire to find the right balance so we clean any software which impedes us.
Big Projects Under Pressure
Some developers are in the unenviable position of being in gargantuan projects that have amazingly tight deadlines, which makes them subject to all the above forces.
Regardless of the situation, our eLearning community cautions against being overly patient with clutter and mess.
So, Does It Increase Turnover?
Will poor code drive good developers away? Here are a few quotes from the developer community:
- "Nobody likes swimming in a septic tank of lousy code and fragile design".
- "Employees get paid regardless of whether their work is agreeable."
- "Technical Debt management is stress reduction."
- "Good programmers are more likely to leave than mediocre or poor programmers" (the Dead Sea Effect).
What Do We Think?
We agree that poor code slows development work. Professional developers can see that their project's code could be easier, more obvious, and faster to develop. They leave it messy if they feel they are not permitted to improve it. Being "forced" to leave the code in a poor state creates considerable frustration.
Daniel Pink's research suggests that developers are motivated by autonomy, mastery, and purpose. Developers restricted from managing their code base feel a lack of both autonomy and mastery. They tend to feel it as disrespect.
We have seen developers rescue code from technical debt through the practices of refactoring and microtesting. Having the permission to make these kinds of improvements maintain profluence and satisfaction.
We believe that technical debt contributes to the dissatisfaction developers feel in their daily work. That dissatisfaction may lead to leaving (or being dismissed). However, other factors seem to be more significant.
Our experience suggests it is prudent to establish an environment where people feel safe to do their best work every day and to make cost/benefit tradeoffs together. We know that we are finding greater satisfaction and stronger ties to our organization this way.
You can weigh in in the comments (below) or maybe you would like to join our discussion:
- Join the Code Smells Album
- Go one better and learn to correct technical debt issues in our Code Smells And Refactoring box set.
- Learning all the advanced testing and refactoring skills represented in the Testing And Refactoring Box Set
Each album or box set is available in multiple programming languages.