As software engineers, we often find ourselves racing against tight deadlines and competing priorities. In the face of these challenges, it can be tempting to cut corners or make compromises to get the job done. However, these shortcuts and trade-offs can have serious consequences in the long run, leading to what is known as technical debt.

Technical debt – a problem not worth putting off

Technical debt, also known as code debt or design debt, refers to the accumulated cost of shortcuts or poor design decisions made during the development process. Just like financial debt, technical debt accrues interest over time, which can become a significant burden on a project if left unchecked.

The concept of technical debt was first introduced by software engineer Ward Cunningham in the early 1990s. Cunningham used the metaphor to describe how shortcuts and poor design decisions can accumulate over time, resulting in a growing burden on a project. 

The broken glass theory illustrates how technical debt can seem like a small, insignificant decision at the moment but can quickly grow into a major problem if left unchecked. Like a broken window, technical debt can be tempting to ignore at first, especially when there are more pressing issues to deal with. However, ignoring it can have serious consequences in the long term, leading to reduced efficiency, increased maintenance costs, and even project failure.

Broken glass theory vs. practice

So, how can we avoid the pitfalls and prevent the broken glass theory from becoming a reality? Here are a few tips for managing technical debt in software engineering:

1. Don’t ignore the problem: The first step in managing technical debt is acknowledging it exists. Don’t bury your head in the sand and hope the problem will go away. Instead, take a proactive approach to identify and addressing technical debt as it arises.
2. Make a plan: Once you have identified areas, it’s important to create a plan for addressing them. This could involve re-architecting parts of the codebase, refactoring existing code, or simply writing better documentation. Whatever the solution, it’s essential to have a clear plan in place for addressing technical debt.
3. Prioritize your efforts: It’s unlikely that you’ll be able to eliminate all technical debt at once, so it’s important to prioritize your efforts. Start by focusing on areas of the codebase that are causing the most problems or are most likely to result in future issues.
4. Make time for prevention: While it’s important to address technical debt as it arises, it’s even more important to prevent it from occurring in the first place. This means taking the time to write clean, maintainable code from the start and being willing to spend a little extra time upfront to avoid future problems.
5. Communicate with stakeholders: Technical debt is not just a problem for software engineers — it affects the entire organization. Make sure to communicate with stakeholders about its impact and the steps you are taking to address it. This can help build support for the necessary investments in time and resources.

Managing technical debt is an ongoing process that requires a combination of proactive planning, careful prioritization, and effective communication. Following these tips and staying vigilant can prevent the broken glass theory from becoming a reality and ensure that your software project stays on track.

Forward-looking action

Another important aspect of managing technical debt is understanding the trade-offs involved. While it may be tempting to take shortcuts or make quick fixes to get the job done, it’s essential to consider the long-term consequences of these decisions.

For example, using a third-party library or framework can save time and effort in the short term, but it can also introduce additional dependencies and maintenance costs down the line. Similarly, patching a bug with a quick fix may solve the immediate problem, but also create new issues or make the code more difficult to understand and maintain in the future.

It’s important to carefully weigh each decision’s benefits and drawbacks to choose the option that will have the least negative impact in the long run. This might mean taking the time to write custom code or refactor existing code rather than relying on third-party solutions or quick fixes.

Control and verification in managing problems

It’s not always possible to avoid technical debt entirely. In some cases, it may be necessary to accept a certain level of it in order to meet project deadlines or address immediate needs. However, it’s important to be aware of these decisions’ consequences and make a plan for addressing the technical debt as soon as possible. One way to do this is by tracking technical debt and prioritizing it alongside other tasks and priorities. This can help to ensure it doesn’t get overlooked or pushed aside in favour of more pressing issues.

It’s also important to have a process for regularly reviewing and addressing technical debt. This could involve setting aside dedicated time or resources for refactoring, re-architecting, or simply incorporating technical debt management into the everyday development process.

Finally, be transparent and honest about the presence of technical debt. This means acknowledging w its existence and being open to the potential consequences and trade-offs involved. By doing so you can build trust and support from stakeholders and ensure that the necessary resources and attention are allocated to addressing the problem.

The broken glass theory is a useful metaphor for understanding the consequences of technical debt in software engineering. By recognising the signs and taking a proactive approach to managing them, software engineers can prevent them from becoming a reality and ensure that their projects remain efficient, maintainable, and successful.