Why do some teams allow technical debt to accumulate and others are better at recognizing the debt and actively reducing it? One possibility is a skill difference. This skill difference could be the result of differing experience or differences in intelligence. In any case, the theory is that a more experienced, skilled team will generally be better at managing the quality of their software. This is certainly logical. However, I think there may be another aspect to consider.
An effective team may accumulate some debt from time to time, but they are good about not allowing it to become excessive. My own experience is that I start noticing technical debt when it starts causing me some form of pain. The pain might be caused by code that’s difficult to reuse or refactor or it might be bugs or poor performance of either the production or the tests. It could also be code that’s difficult to read or is overly complicated (also related to reuse and refactoring in some cases). When I start clearly feeling the pain of technical debt, I become motivated to clean it up. Sometimes, just the thought of the pain of technical debt is enough to keep me disciplined to use development practices intended to prevent that technical debt from even being created. However, there are other developers and teams that don’t seem to feel the same pain I do in similar contexts and I’m curious about that.
What if we are seeing the effects of a difference in sensitivity rather than a difference in skills? I’ve known people who were very skilled in various aspects of software development but still wrote code that was difficult to understand, refactor, extend and maintain. I sometimes wonder if the key difference here is that these other people and teams have a different threshold of acceptable pain than I do. They don’t feel the pain that I do from that form of software source code. And likewise, I’m assuming there are people who have a lower threshold of pain than I do and that the code I write would cause them some degree of discomfort.
If this theory is true at all, then I have many questions. What’s the real source of the pain? What are the side-effects of very high or very low thresholds of pain? What’s the most productive level of sensitivity? And on and on.
As for the source, I’m sure it differs according to the individual. Some people feel pain when they see dynamic languages without type checking. Others feel pain when see code with excessive, useless comments. Others feel pain when see minimally commented code, regardless of the readability of the code itself. Speaking for myself, I tend to feel pain when I know that the existing code is going to slow me down in the future — or is currently reducing my ability to move forward. That’s why I feel less pain when I read code that’s well structured, with meaningful naming, well-written tests, and useful comments that don’t duplicate what the code already communicates.
What if someone has a very high threshold of pain? I’d expect to see lots of crud (technical debt) in their code and although the original author might (maybe) understand the code, most other people probably wouldn’t understand it very easily. The high threshold developer doesn’t mind spending weeks on new features that would otherwise require days or hours with clean code. And they don’t mind staying at work all night fixing bugs before a major release or spending countless hours babysitting the production system after it’s been released. It doesn’t seem to bother them to spend significant time away from family and friends or to have limited time or other interests and hobbies. In extreme cases, not only do these developers not feel much pain from this situation but they sometimes experience pleasure at being the "hero" who saved the company from the bugs they created. These developers might complain, but the complaining just reduces the pain — removing a potential motivating force to improve their productivity.
If a high threshold of pain can be a problem, what about a very low threshold of pain? I have less experience with this situation but I suspect that it might lead to pedantic, overly critical and rigid behaviors that serve as a defense mechanism for their high sensitivity. This might lead to excessive refactoring or testing that provides increasingly diminishing returns. It might also lead to an overly idealistic perspective on software development if the messy realities become too much to bear.
I know my own pain threshold varies over time as I’m guessing it does for everybody. Some days I am more numb than others. That’s one benefit I’ve seen from pair programming. It tends to average people’s thresholds so that code quality is more consistent. I’ve also found it useful to be able to intentionally modify my threshold (or intentionally ignore the pain) in certain situations.
As you may have guessed, I believe the most productive threshold is somewhere between the extremes — high enough to minimize technical debt, but low enough that courage and flexibility is not reduced too much.