31/05/2022
Blog Business Technologies

Business on credit, or how to manage technical debt when your priority is rapid growth

Dariusz Kropop 10 min Read

Sometimes, in order to reach the intended goal as quickly as possible, we decide to take shortcuts – this also happens in the case of software development. We want to be the first to satisfy a market need or verify a hypothesis. Which is why we reach for suboptimal solutions that can be activated in a short time and start earning money quickly. In this way, we knowingly (or worse: without knowing) incur a technical debt that we will have to pay off. Otherwise, the development of our company will be stopped and the implementation of further business goals will be blocked.

And since time is a currency as important as money for companies focused on rapid growth – including startups – they are particularly vulnerable to making decisions that will cause them to be in debt in the future.

So far, the IT world has not developed a single, ideal path that would allow flawless work on creating and developing software. However, there are many methodologies and frameworks designed to keep errors and risk to a minimum (including our “Software as a Journey” approach). Still, each code change has consequences that may reduce the quality of the software. If we do not introduce an appropriate approach from the beginning, we will allow their accumulation, and these will change over time into the so-called technical debt.

It is a natural phenomenon, and we can work with it. Worse, is if the debt is due to our mistakes, limitations or bad design practices; then we have to reckon with the fact that sooner or later we will be drowning in interest repayments.

“The longer we delay the payment of technical debt, the more expensive it becomes. Therefore, you need to learn how to avoid it or learn how to manage it. And considering that it is practically impossible to completely avoid at least minimal debt, every person responsible for creating and developing software should know where it comes from and how to assess the risk associated with it.

Technical debt is not something abstract. It can be estimated and measured, and then presented with a specific plan that will lead to debt repayment step by step. If you see symptoms of technical debt in your company, and you do not know what to do, please contact me”.

Prem Górecki

Chief Technology Officer, Altkom Software & Consulting

What technical debt are fast-growing companies exposed to?

  • Selection of non-optimal technology;
  • Application development based on an inefficient/outdated framework;
  • Lack of care for the readability and cleanliness of the created solution’s code;
  • Failure to take into account the scalability of the project;
  • Ignoring errors and agreeing to incomplete functioning of the application;
  • Informed consent to reduce the performance, reliability or endurance of the final software.

Where does technical debt come from?

Aside from those issues when a company consciously decides to incur debt (we write about this below), technical debt usually results from a lack of awareness from decision-makers, the desire to make a quick profit or pressure imposed on the team.

Startups and companies for which rapid development is a priority, most often incur unwanted technical debt when:

  • They are under pressure to release the software earlier than originally assumed by the project (which means that an unfinished, truncated or buggy product hits the market);
  • They focus on quick profit rather than forward-thinking (earn less at first but reap more rewards later);
  • They are not able to precisely define their requirements at the beginning of the project (thus creating software that does not respond to the real needs of the company and its future users);
  • They announce changes in requirements too late (for which there is no time or budget).

All the above-mentioned aspects may give the impression that technical debt is the responsibility of business managers who are unfamiliar with technology and look at it only through the prism of earnings. However, this is not true and the decision-makers in the IT team are equally often responsible for technical debt. This is due to their lack of experience or non-business approach to software development. The result is the lack of a broader view of the project from the perspective of the company’s development.

The IT team most often incurs technical debt due to:

  • Choosing too rigid, limited solutions (which in the future make it impossible to adapt the software to new needs);
  • No initial imposition of standards and good practices used in the construction of systems and applications (which makes the solution illegible over time and the development of such standards is difficult);
  • Ignoring the need for refactoring in the initial phases of the project;
  • Lack of competences among those involved in the project.

Is technical debt always bad?

It would seem that indebtedness in such an important project as software development is inherently wrong. However, there are justified cases when it is worth incurring such a debt and benefiting from it.

Advantages of technical debt:

  • Starting a project even when there is no knowledge, competence or a full team to implement it;
  • Lower initial software development cost. Profitable when we know that in some time a new version will be created, created from scratch;
  • Quick release of the application and fine-tuning it “live”, thanks to feedback collected from users.

How to manage technical debt?

Conscious technical debt management is a complicated process. A small amount of debt (which affects almost every company) pays off on a regular basis. Developers, in their daily work, read the existing code and constantly improve it (e.g., make a small refactoring), catching elements that may cause debt in the future. Such small works do not require much planning, but it is important that each team member feels responsible and takes care of the quality and readability of the code.

Building a sense in the team that everyone is responsible for paying off the technical debt, combined with good design practices, help to keep the project in check, eliminate debt at the source of its occurrence and prevent its accumulation.

Medium technical debt requires more careful planning and work on it as part of sprints. Start by identifying the debt and determining how it affects the work of the development team and the company’s key initiatives. On this basis, it is possible to prioritise the debt and evaluate its cost. The biggest obstacle to paying off small or medium debt is the reluctance to waste hours of the work of developers who could be developing software at the same time. Therefore, the key is to understand that technical debt has to be treated like any other action – planned in a sprint and repaid regularly. Even if it delays the introduction of some new functionality (in the end, when we decide upon debt, we have to take into account the interest).

Working on technical debt does not seem to bring any value to the company, which is why it is often pushed aside. The priority is the implementation of functionalities that will entail real values (e.g., the influx of new customers). Estimation and valuation of technical debt help one understand that debt repayment also brings tangible benefits, and work on it also makes commercial sense.

High technical debt, that’s a real problem. In an ideal world, any company should avoid this situation completely, counteracting debt at a strategic level.

There are three basic rules to start with:

  • The IT strategy must be created based on the company’s business strategy. These two elements cannot function separately from each other. Each IT initiative should implement a specific business goal;
  • The simplicity of systems, applications and processes makes technical debt management easier. Companies that have very complex products and non-standardised processes often get lost in their own solutions that multiply and duplicate the same tasks over the years;
  • Technology, like company employees, benefits from integration. Systems that function completely separately from each other generate many issues, leading, among others, to a situation where a full view of the data is not available. Introducing new solutions, without taking integration into account, is asking for trouble.

However, we know that reality is not always so rosy, and many companies are facing serious technical debt. Such debt cannot be solved with an immediate action or with a single sprint. Here you need the involvement of software engineers who will indicate the most indebted areas, and team leaders will prioritise activities and efficiently weave the payment of technical debt into work on the product.

There is no single method of action when you are in heavy debt. Each case requires individual assessment and different activities. Sometimes as part of daily work, and sometimes as part of additional activities (e.g., hiring new people). Sometimes technical debt requires a more revolutionary approach, for example rewriting part of the system, breaking the monolithic architecture of the solution or introducing a new system that will be responsible for the integration of individual processes.

Remember to avoid serious technical debt:

  • Do not incur debt in relation to key business areas and processes. If you need to save time and money somewhere, let your debt be only about side topics and functionalities;
  • Before incurring a technical debt, evaluate the risks involved. How big will it be, and how will it affect your business?
  • If you are incurring a debt, justify it in business. Plan it just like any other activity: set the date and method of repayment in advance;
  • Make your team feel that everyone is responsible for technical debt. It’s not only the engineers, architects, programmers and testers who should know about the debt and the method of its repayment, but also, e.g., product owners, analysts, project managers and scrum masters;
  • Invest in technology regularly. Current software updates, although they may seem expensive and time-consuming, when postponed entail considerable technical debt, the repayment of which will be severe.

Important:

A good process for designing, creating, implementing and maintaining custom software is the best protection against technical debt. Therefore, if your company has already fallen into debt, serious mistakes have been made at one of the stages of work on the product.

To all those who plan to start working with Software House (regardless of whether it is your first project or you already have experience), we recommend that you familiarise yourself with our Software as a Journey framework. After all, prevention is better than getting out of debt later, right?

What happens to your company if you manage your technical debt poorly?

  • Your competitiveness will be limited;
  • Budgets and deadlines will be constantly exceeded;
  • The number of errors will increase;
  • Product safety will decrease;
  • The entire IT focus will be centred on system maintenance;
  • The implementation of innovations will be forgotten;
  • Work will slow down and stress will increase;
  • Employees will start to leave;
  • Any code change will become costly.

And perhaps over time it will turn out that work on the product is too expensive – to such an extent that the so-far dynamically developing business will stop earning money.

 

Do you want to avoid debt thanks to good design practices and our Software as a Journey approach? Or maybe you are in a situation where you need to start reasonably paying off your technical debt?