Technical damage

The term "technical debt" is as old as software development itself. According to Wikipedia, it refers to the implied cost of future rework when a solution prioritizes convenience or speed over long-term design. Over time, this debt accrues "interest" that needs to be "repaid."

We believe that negative impact of this analogy on modern software development is huge. Financial debt is something most people deal with daily — mortgages, credit cards, car loans — and the idea of accruing interest is completely normal, especially when rates are low. Access to debt is perceived positively as a way to achieve desired outcomes earlier.

Technical debt is nothing like this. Software engineers often quit en masse over unfixable technical debt. It's not unheard of for people to resign on their first day after seeing the horrid state of a codebase. According to the latest Stack Overflow Developer Survey, technical debt is the top frustration at work for professional developers, cited by 63% of respondents. Technical debt kills the joy of development and collaboration; it frequently destroys entire codebases, which is why rewrites are so common in the industry.

Technical debt does not reflect the true nature of the underlying phenomenon and does not create the vigilance needed to combat it. It’s very hard to persuade business decision-makers to invest in addressing technical debt because its real cost remains hidden from them until it’s too late.

That's why Swinlanes coined a new term: "technical damage." It encompasses everything that hinders a flawless, uninterrupted user and developer experience. This includes bugs, unreadable or convoluted code, incorrect configurations, and broken patterns — all of it is technical damage.

This redefinition has serious implications for daily software development. With Kanban, bugs always take priority over low-quality code that needs refactoring, and the latter often gets de-prioritised and buried deep in the backlog. It's hard to justify to the business the need to refactor code that "just works," even if it's spaghetti code prone to bugs nobody wants to touch.

Technical damage is a great equalizer of bugs and bad code, as well as misconfigurations, DevOps, and SecOps issues affecting the product.

Bugs Are Anti-Work

Kanban boards often encourage low-quality development by representing "user stories" — the actual work — and bugs visually in the same way, making them seem equal in workload. But bugs aren't work; they're anti-work. They're additional effort caused by coding errors, missed steps, insufficient checks, and bad decisions by specific individuals. Software engineering is a unique profession where you get paid for your mistakes, usually without major repercussions.

The root causes of most bugs remain hidden from engineering and product managers, whereas they should serve as learning material for developers to identify why issues happened and how to prevent them in the future. It's also unfair to have other developers fix someone else's coding errors. That being said, in some cases, fixes from people who introduced the bugs might even make the codebase less stable.

Swinlanes doesn't use a separate visual entity to track issues. Instead, it provides a separate lane for every feature iteration, forcing developers to identify where a bug was introduced and who was responsible for that iteration. Some might say this could lead to blame game and a toxic environment. Swinlanes treats it as built-in radical candor, expecting professionals to take responsibility for their work's quality.

We're in This Together

Technical leaders often stress the importance of hiring the best engineers with strong work ethics. What they really mean is avoiding those with weak work ethics. Causes of low performance may vary — skill issue, laziness, lack of attention to detail — but the impact of a wrong hire can be devastating over time. A single person who writes low-quality, buggy, or unreadable code can make development unbearable for the entire team, especially if that person influenced early architectural decisions. Later, there won't be enough time to fix faulty foundations.

This is also why early startups often have to rewrite their entire products after securing funding. They hire cheap dev shops that create low-quality codebases, and then professional developers can't maintain or extend them.

Swinlanes, with its mandatory bug-feature linkage, visually exposes those who don't produce high-quality work. If engineers struggle and are unwilling to improve and learn, they must be let go as soon as possible. Kanban makes it easier to hide low-quality work, benefiting incompetent engineering managers because each wrong hire is ultimately their mistake, and it's simpler to sweep problems under the rug.

In the end though, codebase degradation reaches a point of no return, people leave, and new managers declare that the product needs a rewrite, incurring huge costs to the business. Kanban enables ideal conditions for this kind of death by a thousand papercuts.

Knowledge Silos Are Technical Damage

Another aspect of technical damage isn't just about bugs or unreadable code — it's about overengineering and creating knowledge silos, which is common in the industry. A key sign is when only one engineer can work on a particular part of the codebase because no one else knows it. Sometimes this happens without malicious intent, but fairly often people hoard knowledge, overengineer solutions so others can't easily make changes, and become irreplaceable — sometimes to protect against layoffs.

Swinlanes lists all iterations for a feature with all developer lanes, making it easy to see who worked on most iterations. We encourage assigning different developers to subsequent features so people don't get locked into certain areas, lose context on others, and regularly review each other's work. Code reviews are very important, but actually working on someone else's code provides the deepest context.

Engineering and product management should not underestimate the danger of knowledge silos. When a knowledge hoarder eventually leaves, the product risks much slower development and more bugs due to lack of context. In the worst-case scenario, you might have to rewrite that part entirely.

Technical damage is an evolving term, and we'll be discussing it with the community. Please follow us on X to keep up with the latest developments.