One of the ongoing discussions in our eLearning is on the topic of Technical Debt.

Does technical debt cause employee turnover?

A very messy storage room

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 aligns closely with the idea of Minimum Viable Products and incremental releases. This ties into the Lean Startup idea of Build, Measure, Learn.

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.

However, the conversation in our Code Smells album uses a definition more in alignment with Wikipedia’s definition of poor code or poor design.

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.

Under Pressure

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?

Research suggests that developers tend to leave their jobs because of culture. Some may leave because of morale, money, or burnout. Others have differences with their supervisors or colleagues.

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.

Join Us?

You can weigh in in the comments (below) or maybe you would like to join our discussion:

Each album or box set is available in multiple programming languages.