Topics covered:
When should you start addressing technical debt in a project, what are its consequences, and how should it be managed? These are the key topics discussed in the second part of our podcast on technical debt by: Paweł Kaźmierczak – Project Manager, Damian Maślanka – CTO, and Szymon Kania – CEO.
Paweł: I warmly welcome you to the second part of our podcast on technical debt. My name is Paweł Kaźmierczak, and with me are Szymon Kania and Damian Maślanka. In the first part of our podcast, we reflected on what technical debt actually is, what causes it, how to deal with it, how it affects long-term projects, and how it influences product development. Of course, I encourage you to listen to the first part of our podcast.
Let's move on, gentlemen, to the more business-oriented aspects of debt because last time, we finished discussing more technical topics - how to manage a project, how to prepare for it technically. But what do you think, what could be the business consequences of such technical debt for a given company, for a potential client in the IT industry? How does it primarily affect a company's operational costs?
Szymon: Two aspects I would definitely mention are, first of all, higher costs for the company and often a hit to its image and trust. When it comes to costs, maintaining technical debt leads to a number of different additional necessary actions. Due to technical debt, various problems often arise that customer support has to handle - taking customer requests, searching for solutions, sometimes even looking for workarounds to help customers. Because the system is struggling in some areas due to accumulated technical debt and outdated solutions. This, of course, generates costs because the team, instead of focusing on company development, on product development, is fighting with growing problems. That's just one example. It can also be considered in the context of lost opportunity costs.
If the solution loses its reputation, if people lose trust in a given solution because there are too many problems related to technical debt, we might end up with fewer customers. Customers may leave us, stop using our product precisely because of neglected technical debt that was taken on, never repaid, and now we have fallen into a spiral of debt.
Damian: Yes, I would add here that what Szymon said can essentially be summarized as a kind of hybrid of security, performance, and further development. Security – because undoubtedly, technical debt creates vulnerabilities in the system that can be exploited by hackers, bots, or anything else that finds and exploits weaknesses. Performance – because technical debt makes it difficult to implement newer technologies that are more efficient and faster. As a result, the user experience of the final customer using the system is not what it should be in today's times. Websites might load more slowly, dynamic elements might be missing, for example. So this also has a direct impact. Future development – as we discussed in the first part, assigning additional modules, refining anything, simply costs more than if we had the base code at a higher level-refactored and without technical debt.
Paweł: Okay, so to summarize, we have a few important aspects in business that are worth noting: rising costs – because of constant development, where we are going in circles, fixing endless problems, and in reality, we lack the time and resources to functionally develop our product. Security and performance issues – because we may expose ourselves or our project to external attacks and also lose the trust of our existing customers. They may leave, which could ultimately impact the company's finances. Lost potential benefits – which Szymon mentioned, I think it’s worth adding this to our list as well. This means the potential new customers we could have had if our product had continued to develop at the same pace before debt accumulation.
Now, from the perspective of business and costs, I would like us to consider what risks uncontrolled technical debt brings to a business.
Szymon: One thing is that these costs can also increase uncontrollably because even the operational handling of problems related to technical debt, when there are more and more of them, becomes expensive. If we assume we are scaling the business and the number of clients and users is growing despite everything, we have to keep adding people who will essentially be focused on dealing with existing problems.
Damian: I would also add here that a day may come when we actually hit a wall. We want to update our system, including all outdated packages, and it turns out that one of those packages has disappeared from the internet. And now, the first hurdles begin - how to work around this problem? We are never sure when such a day might come. Another issue - we are never certain that a day won’t come when suddenly the servers say "enough." Because applications have accumulated, incorrect data has been stored, an incompatible database, something along those lines. And suddenly, we try to use the application, and everything takes an extremely long time to load. We’ve exceeded a certain limit, and since technical debt has been accumulating and no one has taken care of it, we couldn’t predict that something like this could happen.
Paweł: I'll add from my side as well—because it varies. If we get too caught up in uncontrolled debt and wake up too late, I have seen situations where a business simply shut down. When estimating the potential costs of eliminating technical debt, sometimes it just doesn’t make financial sense anymore compared to the benefits the business could achieve by simply selling more subscriptions. So I think we should also consider this worst-case scenario, and I would assess this risk as very high for a business. Okay, but let’s move forward. Let’s take a more positive and proactive approach - let’s consider when and how best to make the decision to repay technical debt. When should we have in the back of our minds that we want to rewrite the entire project in new technologies, for example?
Szymon: The best approach is to limit the accumulation of technical debt and manage it in a controlled way, as we discussed in the last podcast. To have control over it and approach it consciously. But when is the best time to repay technical debt? Definitely not during a phase of rapid growth and intense project development. It’s better to wait for a moment when we can afford a slightly calmer development phase - when we have delivered the most essential functionalities, and now, before starting the next stage of the project, we can afford a short pause to pay off the technical debt accumulated in the first phase of implementation.
Paweł: Okay, so you mean that the project is already running stably, there aren't any major bug fixes, but there is a moment for making some developer improvements, some refactoring.
Szymon: Exactly, also not a moment when we are implementing major functionalities, when there is full focus on their execution and integration with the system, because that is usually a critical period during project implementation.
Damian: I would also tie it to the fact that if we have a vision that our company, our product, will now be dynamically growing in the coming years, then we should all the more take this step to eliminate this debt rather than continue accumulating it. This is the most comfortable moment - we know we have everything under control, it will develop stably, so let's invest some resources to ensure it remains at a high level.
Szymon: The sooner we start repaying the debt, the better. It’s a bit like financial debt - if we keep taking it on for too long and fall into a spiral of interest, it becomes much harder to pay off than if we were addressing it continuously, regularly, in a planned and controlled manner.
Paweł: Okay, and from a more technical perspective, if we consider the lifecycle of a product, when is the best time for optimizations, code refactoring, and improvements that will prevent future technical debt?
Damian: First of all, when working on new modules, because that’s a good moment to consider how to approach the architecture of the new module and, at the same time, what impact it will have on the entire application. It’s worth analyzing whether the current system will meet the requirements of this new module. It always involves some additional use of resources, so I would typically leave it for moments when we are developing complementary modules for the entire system. Alternatively, when little is happening in the project, but we see that it is still growing stably without requiring rapid development. Then, we can conduct performance tests, assess whether in a month, six months, or a year, if we maintain the current pace, the project will still function efficiently. We should plan out the entire roadmap, determining what can be improved, what can be refactored, so that everything operates better. We need to anticipate problems instead of reacting to them after the fact, when, as I mentioned earlier, that day arrives when I receive a flood of emails and phone calls saying the application has suddenly started performing terribly.
Paweł: Okay, so based on what you’ve said - just like in the first part - it is very important to plan both the entire project and individual functionalities or modules within it. Now, I’d like to ask: what are the best practices for managing technical debt? Do you know any tools or processes that can be implemented to effectively monitor and manage technical debt in a project?
Damian: From a technical perspective, it’s good to implement various tools that check code syntax, general conventions, and compliance with the base code. There are plenty of such tools, and they can be directly integrated with, for example, GitLab. This way, every developer who commits changes immediately receives feedback on whether the code meets quality standards or not. Additionally, mutual review processes for commits should always be in place. It’s also a good idea to assign a dedicated technical lead - the so-called lead developer - who oversees and ensures that all merge requests and any code changes are both consistent with the overall project and maintain a high standard of quality.
Paweł: So, we have tools like GitLab, code review processes-sometimes done crosswise, sometimes delegated to a tech lead or lead developer in the project.
Damian: From a soft skills perspective, it’s also important to take care of the team itself and give them space for things like weekly meetings, where they can discuss new technologies, inspire each other, and share insights. This serves as collective learning, knowledge-sharing, and helps maintain the right mindset-focusing on quality, not taking shortcuts, and striving to keep the project at a high level of excellence.
Paweł: That is, the use of such agile methodologies, that is, just what you said, a constant focus on the project, such consistency. Here I would have an analogy to sports, that the best teams that win must be consistent. I would also add that one could use just tools for keeping backlog, development tasks and in general such, let's say, software development processes are important from such an angle. Sticking to quality, then some testing, there could be automated testing, manual testing.
Test your solution with us.
Damian: Here it is also worthwhile, in fact this is often not talked about, not thought about, but even such postponement of some warnings from the project. I'm not talking here about some exceptions, some crits, such serious errors, because it's obvious that this is always corrected as soon as possible, but such warnings, such insignificant information, somewhere deposited on the server in the logs, is also such a rich mine of knowledge about our project, because these are such things that we do not pay attention to every day, it is deposited somewhere, but it is already a signal that, for example, this line of code is a bit outdated and, for example, the next version of PHP will be already out of date. This line of code is a bit outdated and, for example, in the next version of PHP will no longer be supported, and it is simply omitted.
Paweł: Oh, it's also a very important thing, taking care of updating the frameworks in the project, because it's often some new versions are released, and often if we neglect it, then later raising, for example, by say 4 full versions, it's already a lot of dev work.
Damian: Well, here it is also important to keep it up to date, and not wait until the support for this particular framework ends, because it is also known from experience that sometimes such things are postponed, well, because we still have time, because this version is still there supported for the next year of time, well, and time has this to itself, that it passes quickly and suddenly we wake up and you just have to do it rapidly already.
Paweł:Okay, and how can development teams and non-developers plan for such a repayment of technology debt, such a plan as if we were to make for ourselves for the future, in order to just minimize this and the negative impact of it, if it currently exists, but the occurrence of such debt in general?
Damian: In general, a good tactic is to reject such a mindset to the team, that on the principle you are doing some functionality and you see that somewhere there is a line of code that could be refactored, then just do it. Not on the basis of, and because someone wrote it wrong there once, it somehow passed code review, it was overlooked. Just take care of that order. It's like maybe a little analogy to the street: that you're walking in the park, you see that there's some trash lying around somewhere, you can just pick it up and put it in the trash, and you can also skip it and actually get covered with that trash after some time, so we take a similar approach to code, that if we see that someone left something there, sometimes it's worth just correcting it and taking care of each other's code, treat it as such one common thing.
Paweł: Ok, that's a good idea, that is, like the Boy Scouts, that if we encounter something and it can be done better, for example, something can be improved, let's do it right away, that is, leave the place even better than we found it.
Damian: Exactly, just to look more broadly, not just narrowly at what we do. We should simply treat the project as such a common part that we all carry out, and not just somewhere in the designated areas of our own, so to speak.
Paweł: Ok, and do you know of any other practices that could help avoid such future technological debt? I don't know, it could be, let's say, something that has already entered our habit and we don't even know what it is. We don't explore it in the process, for example, because we're already doing it, for example.
Damian: Debt sometimes also arises from the fact that someone does not understand the code. He has to realize something, he sees there a piece of code that seems complicated to him, and instead of really thinking about it, well, he tries to get around it somehow, to fit into it. Well, and here a good practice is actually to comment on this code as well, because this will allow you to get into the logic of reasoning faster. Also, even for the person who implemented a given part of the system, after some time it also seems much more difficult for him, not as understandable as when he wrote it. So such comments or documentation strongly improves such management of the code and makes it much easier for us to approach it as if encapsulating it in an optimal way, rather than trying to get around it somewhere, because the entry threshold for understanding it is high.
Paweł So, in general, it's a good idea to write down the knowledge and information about a particular project for ourselves, so that this knowledge doesn't, let's say, elude us somewhere in the future?
Damian Yes, this is the basis. In fact, when a project is not well described, we reach a point where everyone starts to do it their own way, instead of fitting in they make a kind of parallel solution, and at this point there is already a very thin line to cross that threshold of creating technical debt.
Paweł It's still like this at the end, as if we had a situation that, let's say, we have a project running in production, it's growing very fast, let's say that every week something is done and let's say every week some deployments are done in this project. With such a project, how can we manage such technology debt?
Damian First of all, automation, if we have a lot of tests in the project, we also have automatic deploy, if we hook it all up so that it automatically executes and immediately checks if we made a mistake somewhere, that's one thing. As I said before, that any such fixers that check whether the syntax of the code, whether the quality, whether it's all at the level it should be in the project. The more such automation we have, then we also immediately get such feedback, whether what we wrote is right, correct. When there is no such thing, such a pathology can occur, that we do something fast, someone somewhere overlooks something, because, as you know, if it is fast, sometimes it can happen that someone does not notice that somewhere one line of code is written in the wrong way, or we have approached a topic in the wrong way.
Well, and here the lack of such automation may cause it to simply enter this codebase and just work productionally somewhere, while already creating this technological debt.
Szymon Well, and the mindset of the team itself, just as Demian said. If there is a mindset not to take on too much of this technology debt, it will also work differently. And so is the issue of scheduling this development, because even if we are doing a project that is intensively developed, is production-launched, it is also possible to do it in such a way that there will be too little time even for this base development, which is conducive to incurring technological debt, or the whole project is planned in such a way that there is room for, let's say, moderate development, which will be more limiting this creation of technological debt, or give even a small space for such activities, especially with the use of various automations, as Damian said, which will limit the creation of technological debt.
Damian I would also add here that all these automations make us able to do it faster. And consequently, by doing it quickly we have more resources to also make sure that we keep strong quality here, rather than trying to do something worse at the expense of, for example, meeting a deadline or maintaining the pace of software development.
Paweł Ok, that's really a lot, a lot of tips here, how you can prevent, and it's known that prevention is better than reacting later after the fact, because also just getting out of such an already incurred technological debt is also such hard and arduous work. I think we have covered a lot of information here in this podcast. I, for my part, have so much, also thank you for taking part gentlemen. I think a lot of important and useful knowledge for everyone who would like to do some projects in IT. This issue of debt, to know what it is in general and how to plan for yourself. Some sort of exit with your product to avoid this in the future. Also I think that our listeners can learn valuable lessons. Also I, of course, sincerely thank you for your attention. With us were Szymon Kania and Damian Maślanka and Paweł Kaźmierczak.
Damian I here still at the very end can add that the technological debt can be summed up that it is better to play with prevention than cure.
So with that accent we can end. Thanks to all of you.
Szymon Thanks.
Paweł Thanks.
