We started with a quick recap of what technical debt is. If you're not familiar with the term, take a look at our blog post on technical debt.

One of the most recent and widely discussed examples of technical debt is Twitter, which has recently had a lot of technical problems related to technical debt. One of Elon Musk's tweets:

Well, whether a rewrite is the best idea is another matter. But you get the point: a lot of technical debt hasn't been addressed in the past, developers are no longer in the company to maintain the code, and the rest simply don't know how different parts affect each other.

One sentence I really loved in yesterday’s discussion: every project has technical debt. The difference is whether you're aware of it or not.

Awareness & Culture

So how do you create awareness? One important aspect is culture. It's about company culture, team culture and error culture. If that doesn't work, technical debt may be hidden out of fear and shame. If there's a culture of openness, it's no big deal to discuss decisions transparently and at eye level. For example, if a feature is important and the team needs to get it done before the deadline, and it can't be done without a hack or a shortcut, it's perfectly fine to do it. As long as it's communicated and documented and definitely addressed in the future.

Basic technical understanding

Another aspect is the understanding that code can be completely messed up if you are not careful. It's more than just the pretty interface that people see in their browsers. But some managers do not realise that code also needs to be clean and readable to be maintainable in the long term. They start to worry when things start to go sideways, work takes longer and features break. Often this will cost a lot more money than if the problem had been dealt with earlier. For example, a manager came to us with code developed by an offshore company. It looked great to the user, but when we looked at the code, it was a complete mess. There was no hope of saving this code without spending an unreasonable amount of money, a complete rewrite was the only option. Well, that's money down the drain, isn't it?

Creating and establishing systems

In the Carrot Monthly someone also mentioned David Allen's book Getting Things Done. Basically, it's about setting up a system and developing habits to get things done. There is an analogy with technical debt. You need the habits and a system to report, manage and address technical debt. And you and your team need to see the benefits of establishing these systems. Let's take automated testing as an example. At first, it feels like a lot of extra work - a bit like starting to go to the gym or start jogging. You need to invest time and effort and create a habit to stay consistent and see the benefits. It takes time and consistency, but it’s totally worth it.

Can perfectionism avoid technical debt?

We discussed whether perfectionism is a strategy for dealing with technical debt. One example was Steve Jobs with the first MacBooks. The conclusion: even if you write the perfect code - which, by the way, you can't - you may still have technical debt. In general, writing the most perfect code is very often not a sustainable strategy. Costs explode and you don't get results fast enough. And technical debt doesn't go away.

Throwaway mentality

Another aspect we've discussed in the Carrot Monthly that may be particularly relevant to smaller businesses is understanding the difference between a website and a web application or SaaS. A website is something that can be easily - and for some businesses often - redesigned and rebuilt. The old stuff is thrown out to make way for a new site with an even better design. There's a cost, of course, but it's often not a big deal. A web application, on the other hand, is something more complex and you don't want to throw it away because you don't want to invest the money again. So ideally you want to build a high-quality web application that will last for years. We think it's harder to understand and manage technical debt if you come from this throwaway culture and don't understand the difference between a website and a web application in terms of lifecycle management.

Working with third-party development companies

One important thing we've noticed is that it can make a difference whether you're working with your own team or outsourcing. In your own team it is easier to create a culture of failure, whereas most external companies try to make everyone happy instead of being transparent and saying that feature x can be done on time, but the consequences are technical debt that has to be dealt with later. Especially when you're working with external companies, you need to make sure that you have transparent communication and that you can trust them or that you have technical quality management in your team. In our experience, it is important that the external partner sees itself as part of the team and vice versa. This is ideal for transparent communication and good results.

There are certainly more aspects, but the time went by so quickly and before you knew it, an hour had passed. We really enjoyed the discussion and we’re looking forward to the next Carrot Monthly on 18 April at 4 pm CEST (online). Want to join the discussion and knowledge sharing, grab your free ticket now, there is only a limited number of spots for the Carrot Monthly online Zoom meeting. The next Carrot Monthly will address automated testing.

Get your FREE Ticket