Does Technical Debt Cause Employee Turnover?

Posted October 20, 2014 by Tim Ottinger

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

Does technical debt cause employee turnover?

A picture of a very messy storage room

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".

Gargantua

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.

  • Pingback: Does Technical Debt Cause Employee Turnover? - ...()

  • Michael Kaufman

    Overall, I agree with your point on Technical Debt. Especially in situations where the Debt is never addressed, and keeps increasing release to release, exacerbating the situation and the frustration of developers as they work on “the next” release.
    However, I do worry about developer autonomy. In a large organization, you really do need coding standards, guidelines, and consistent _approaches_. You need to have all developers having full awareness of the _entire_ codebase, to reduce duplication ensure overall efficiency. I don’t disagree that individual developers are motivated by autonomy and mastery. But letting a bunch of developers loose on a large code base all in the name of “autonomy” has its own problems, and would cause many of the problems Gargatuan and Time Pressure are already producing.
    Give the developers autonomy, _within_ guidelines and a full, robust set of standards.
    Otherwise, these autonomous developers are no better than ones in silos.
    My $0.0.2

    • Tim Ottinger

      We talked about this at #ACCUS this year.

      The sound bite from the conversation was “does team autonomy trump individual autonomy.”

      Also consider bounded autonomy rather than unbounded supremacy. 🙂

      But I think that most programmers, let loose on a code base, would ask what you would like the code to do, and would still add features that people want. Certainly mores if the team is all aligned to solve customer problems.

    • CurtisCooley

      I’ve always viewed autonomy as “how to do it” not “what to do”. The best Agile teams tend to be self organizing, and self organizing teams tend to feel more autonomy.

      You can also nurture autonomy through 20% time or FedEx days. A company I coached has “hack-a-thons” where developers and customers can get together and for two days build whatever they want. That’s the kind of autonomy that also builds mastery and purpose.

      I think the concept of stewardship agreements (http://www.brefigroup.co.uk/acrobat/stwrdshp.pdf) pretty much detail how to delegate and provide autonomy.

  • Pingback: Dans mon Pocket: Does Technical Debt Cause Employee Turnover? | sashock blog()

  • Pingback: Stop Per-Person Swimlanes - Industrial Logic()