Fix your problems early and adequately

the Broken Window Theory in Tech

This coming week, I want to start by focusing on what we are currently working on as a company, the SaaS product behind it, and what we have learned. One of the significant learnings was the Broken Window Effect.

Little idleness here and there, and sooner as we think, we have problems everywhere. This applies to basically everyone and every company. However, with this one, I want to write about the possible consequences that smaller businesses, like startups or traditional SMBs, can suffer.

I wrote about the Broken Window Effect in Software Development; this article was more directed to the consequences of avoiding efforts to fix things or make them the right way early on. However, strategic technical decisions are the same.

What is the Broken Window Theory about?

In short, a criminology theory from 1982 describes the resulting decay of buildings if society stops caring about them. For instance, once a building window is broken and does not get fixed, another one will likely break soon. People will subconsciously notice that no one cares about this building anymore; No one seems to take ownership anymore. Other problems like Graffiti will appear, or waste will be carelessly dumped. It's a downward spiral.

When you stop caring for it, the same will happen to your project, product, or codebase. Taking care means addressing problems directly, not telling yourself you can fix them someday. Ensure that ownership and responsibility are everyday practices to avoid the Broken Window Effect.

Shortcuts are short-thought

A transition into a different architecture is nothing your current teams will be able to handle next to their daily tasks

When a new software development starts, the teams working on the project are eager and motivated, with resolutions to make it good this time. But as development progresses, everyday life kicks in, and the motivation drops daily.

Many small negative things happen; every single one of these themselves isn't noticeable but accumulated; they could do serious harm or fail the project.

These shortcuts often appear during the development of the foundation of the new software. Unfortunately, excuses favor Shortcuts with the wrong intention that we can always change later. It doesn't matter if it's a strategic decision, an operational one, or one based on code. As a result, shortcuts have a high chance of coming short.

Picking a software architecture that is too simple will likely produce a lot of technical debt. While everyone thinks the projects start fast, get to speed, and make enough revenue to fix whatever we need later. When you choose this approach, be aware of the following:  You do gambling. 

You don't know the circumstances in 6-12 months; you don't know the available resources or how many employees you have available. The only safe thing for you is that you need to pay back your debt. A transition into a different architecture is nothing your current teams will be able to handle next to their daily tasks; it's extra effort, which you need to take into calculation in the beginning. So think twice if you want to be in that situation.

I want to explain the following: It is technically possible to change later, but you must be aware that you must be sure if it is practically possible. This is a crucial business decision, not a technical one.

The same goes with poorly written code in a hurry, missing tests, or lousy documentation. Everywhere where people think they can Shortcut and catch up later.

As a business, you need to make it right in the first place.

The sad thing about this is that making it right isn't much more work in the beginning than most think

Many voices say you must get into the market quickly and take it from there. Everything will be easy as soon as you have the money. Many have proven this right, but the opposite happens more often than you think. When it happens, you need to have a plan at your disposal.

My experience in 15 years of being an entrepreneur in the SMB area with clients and own projects is that a high technical debt rate will quickly be your dominant problem.

The sad thing about this is that making it right isn't much more work in the beginning than most think. The essential point is that it is nothing in terms of effort compared to what it will be in a year or later.

Results of conversations with CTOs and founders.

Revenues recently earned are necessary to pay back investments or finance new business ideas but were never intended to rebuild what was already built.

Companies ending up with their new main business to pay back technical debts often have horrible times. Revenues recently earned are necessary to pay back investments or finance new business ideas but were never intended to rebuild what was already built.

The development teams are often declared guilty of the "mess they have produced." So they need to fix it themselves.

The results are even more devastating when overall motivation and loyalty suffer. In addition, the company suddenly faces "unpredictable" problems, which leads to stress and overload.

In December 2022 alone, I met two tech leads with similar stories. Both worked with their teams to migrate their Legacy application, and we discussed the approaches. In the first case, the migration is a new greenfield application on a new foundation. After the new application is ready, data will be migrated between the old and new solutions. The other case is a strangler fig approach, as described by Martin Fowler. The idea here is to migrate the application step by step until the Legacy no longer exists. 

Both projects are mission-critical and shall be migrated within half a year. But here is the point: Both applications are just in their second year of existence!

Is it really necessary to go to market that quickly? And if yes, think twice if you, as a tech lead, want to be part of it.

The core dev teams' primary focus is building what's already built, while frustration arises everywhere, starting from the bottom and bubbling up to management. As a result, new features are delayed because the teams need to work on them. In both cases, the process is ongoing and backed up by management, but the overall mood is way below the acceptable limit. 

I ask myself if this is worth it. How much time do companies save by rushing recklessly toward their goals? Is it really necessary to go to market that quickly? And if yes, think twice if you, as a tech lead, want to be part of it.

My conclusions and advice

Imagine yourself two years reviewing your own effects. Can you still live with those results?

Think twice about the coming years, and create a solid strategy. As a tech lead, you should not fall into the trap of business promises; instead, ensure you find sustainable ways. Your strategy should go beyond year One and should cover most eventualities.

The same applies to non-leader roles; as developers or creators, ensure your work follows sound principles. Be a professional, and make sure you are happy with the result. Imagine yourself two years reviewing your effects. Can you still live with those results?

The Broken Window Effect in this context

Isn't it good to know that your company's ideals are to make things right?

Make sure you fix things early on. This includes using the proper foundation and measurements when it counts. Once you or your teams start to shortcut, it's likely to become an unwanted culture, resulting in over-indebtedness.

Take care and ownership of your product; it's your company's creation and foundation. Treat it well and with respect. If you need to Shortcut, make sure the reason for it is still valid in the years to come.

If you keep up ownership, maturity, and responsibility, you may be slower in the first place but sustainable in the long run. Isn't it good to know that your company's ideals are to make things right?

After all these years, I would prefer a sustainable way over gambling. What about you?

Take-Aways & Learnings

I want to share a broken-down article version to help you remember what’s important.

The Broken Window Theory

✅ Ignoring small issues in a codebase or project leads to a cumulative, downward quality spiral.

✅ Ownership and immediate action are crucial in preventing project degradation.

The Cost of Shortcuts

✅ Transitioning to a different architecture later due to shortcuts is often impractical, costing extra effort and resources.

✅ Decisions to take shortcuts should be business decisions, not just technical ones.

✅ Shortcuts in software development may seem quick but accumulate into significant technical debt over time.

The Reality in Small Businesses

✅ Going to market fast is not always the best strategy; consider the long-term impact of your technical decisions.

✅ Technical debt can quickly dominate team morale and business success. Avoid technical debt becoming an imminent problem for your company.

Personal Conclusions

✅ Think long-term and don't fall for quick business promises. Create a strategy that covers most eventualities.

✅ Be a professional: ensure your work follows sound principles, and you'll be satisfied with it retrospectively.

✅ If you have to take shortcuts, make sure they are justifiable in the long-term, not just convenient in the moment.

Cultivate a mature working culture. Maturity and Competence will help prevent the negative effects of the broken window effect 🍀

Thanks for reading!

Adrian Stanek,