Technical Debt: a beast to get rid of!, really?
Debt ? Someone has to pay ! And someone is waiting to be paid.
Technical ? Ok, debts must be canceled with computers and robots ?
If you belong to the audience I used to work with, you have heard enough of : “ Wait! Write down in our log: this feature has to be done sometime after implementation, we have no time. Our efforts are focused on core features ! “
It is a promise that something will be taken care of in the future -a debt- and companies end up paying for with time, money and resources, usually by looking at the schedule rather than the quality of the product.
In our “new reality/normality” companies are trying to adapt their technology and services to offer new digital channels of interaction with their customers as soon as possible.It is a great opportunity to take the market from their competitors.
IT professionals, meanwhile, are debating the effects of technical debt versus business growing.
Is technical debt always a bad thing? Let’s go ahead …
The short-term mindset can compromise an attitude of planning and forecast for operations and resources, which is necessary to set the course of business to stakeholders. But what happens when the market is as rapidly changing/volatile as it has been in 2020? or as we think it will continue to be in the years to come?
This attitude of cutting features and postponing solutions may not be so harmful.
Is this technical Debt ?
Twice a month, I have the task of cleaning the house, sometimes I don’t get enough time for the job as it was agreed with my wife , so I do a light clean but everything looks as if I’ve done things right.
Have I generated a technical debt ? my wife says: you have to pay ! you have to work harder next time.
What Is Technical Debt?
When the business environment remains the same before and after the implementation of a solution, and you have left unfinished features, the technical debt is the measure of the cost of reworking your solution.
You choose a quick deployment, which means less features or features with less functionality, and you will have to pay for your crime.
May you pay for it with computers and robots? No way ! Have to pay with time⏳, effort 🏋🏼♂️, money 💰and ashamed.🙏🏻
You have gone to market with half-baked features, but your competitors didn’t have a single one, isn’t that a good thing?
If your competitors have entered the market after you, but with complete and better features than yours, isn’t it negative ?
In my belief, having a radial definition/position for technical debt is not valuable, since there are so many factors involved beyond the technical ones. It seems to me that the concept is very focused on the to-do tasks that technicians perceive as debts in their pending logs.
What if the market needs are changing while deployment, if the features that we thought were favorable to our market actually are not?. We came out later than our competitors with more features, but now we realize that some are not used/understood in the perception of our users! What do we do? We spend more marketing money and surveys to persuade our users to use them ?!
And what about that other company that left those features incomplete? They will know that features have not been successful, from our experience, and will simply cancel them from the backlog! Or they will rework it based on our not-so-positive experience.
In this context, the company that generated the technical debt benefited by taking that decision.
Someone took the risk, but was conscious about it ?
I know of two banks that have both applied their own level of technical debt. They competed and emulated each other’s features and eventually stabilized. Many surveys were sent to get the user experience feedback. Today, both of them have similar digital options.
There is only one feature that differentiates them, and the decision of their implementation is not related to technical competences.
Classic definition
Technical debt can drain resources, time, energy and the opportunity to innovate, adapt and grow. May be difficult to identify and manage and even more difficult to prevent.
There are scenarios where a technical debt could have been identified but then canceled without effort due to the negative perception of the market for these delayed features, and the competition helped us, involuntarily, in assessing this perception. So, a list of technical debts has its own levels of risk, and again, we are not talking just of technical issues.
Causes of Technical Debt
When you develop a solution, you are able to anticipate some things and then you will spend most of your time planning the project and perfecting the code. Other things are out of your control, and that can lead to technical debt:
- Time pressure: Development teams may even shortchange performance and quality to get to market quicker.You know, you have to beat your competitors, just business !
- Constant market change: Full-featured applications completed on time may arrive in the marketplace already out of date. Ever-increasing customer expectations, the rise of new market opportunities, new cyber threats, and developer turnover create ongoing challenges for IT leaders.
- Changing customer expectations: you know that your customer is asking for features they are not going to use , internal games may be developed in requirements sessions, so you — as technical leader — decide to put them in the large calendar.
- Outdated technology: Developing modern applications typically involves several coding languages, developer frameworks, and libraries, which can become obsolete or not supported each year.
There is also technical debt when talking about old and legacy products.
But technical debt can appear from day one. For example, when you are in the planning phase of your project and you realize that you cannot meet a specific requirement within the deadline.
You can change it later, why not! You are confident that you will find the way to get time in future. You know, deep in your mind, that in that same future other new projects await you, extensions of old ones and also other postponed features, and the eternal unforeseen events in the IT area. So, postponing requirements almost always leads to their cancellation; they will not be developed.
Welcome to the Technical Debt, a place where you are always welcome.
A Pandemic among us
A technical debt scenario has been raised/placed for the last two years. Many major retailers already had online storefronts, but did not prioritize building on scalable platforms for giving services to many concurrent users.
Doing so would have taken longer. So they pushed that feature off into the future. At the time , this was fine because it would be improbable for their online stores to have many concurrent users at once.
With many retailer’s websites infrastructure failing the scalability requirements, retailers went to add digital band-aids such as creating a virtual queue. Most of those customers didn’t wait and instead went to other sites, with scalable and performant online stores.
Companies that took the time to build with scalability and performance in mind right for the first time (like Amazon, eBay, and AliExpress) took all the advantage from 2020/2021 pandemic environment.
As you know, a pandemic is a black swan — hard to predict — , so what would have happened with all the investments of mentioned companies if the pandemic had not arisen ? The annual ROI for scalability investment would have been smaller, only large companies can live with a low ROI for a long time.
So, to set a technical debt, there are a lot of factors that are playing on, and in my thinking , some of them are not related to IT.
Finding a suitable balance between quick Deployment and Quality
Defining quality is not easy, but once defined it contributes along with performance to a great user experience. Business objectives are likely to be met if the user has a good experience using your digital products.
Rapid implementation of technical solutions may enable you to meet deadlines, but as a project manager you should be aware of the cost/risk involved, if you have failed to meet quality requirements.
As technical debt accumulates between the various projects you manage, you may reach a point where speed and agility are no longer an option.
From this point is where you start to pay your debt, you may also ask for a loan, and this is when you start your career as a debtor trying to deal with something that can not be created; time.
It is normal to identify novice IT Managers as they fall into the temptation of ignoring the debt until it accumulates through the roof. There can also be challenges in identifying and resolving it.
Right now organizations are focused on accelerating time to market and empowering citizen developers to create enterprise applications, with tools based on agile methodologies and low-code technologies.
I must say that the risk of technical debt increases and the importance of its management leads to the training of new skills or the recruitment of expert profiles.
In any case, there are ways to reduce and manage technical debt.
How to Manage and Reduce Technical Debt
When talking about technical debt, you have to ensure a balance between time, quality and cost. But you have to take into account the governance model, the toolset and the mindset of the people building the software. Getting the right mix in this equation is crucial. And, while not exclusive, the right technology can also help.
Companies are increasingly turning to modern application development platforms to deploy unique and differentiating solutions and avoid the pitfalls of short-term solutions, such as technical debt.
Enter OutSystems
Applications built with OutSystems rely on standard architectures and frameworks–no proprietary components, runtime engines, or interpreters required. With this in place, technical debt is limited before development even begins.
OutSystems orchestrates the entire deployment process using a combination of automation, AI, and analytics to identify architecture errors, faulty logic, and broken dependencies — during development, in real-time.
To do so, OutSystems offers several functionalities that combined help you reduce technical debt, including:
Start Fixing Your Tech Debt Today
To learn more about reducing your tech debt from day one, take a look at Handling Technical Debt with OutSystems. This paper discusses how OutSystems helps reduce technical debt during development and assists in building a best-practices architecture to deal with it in the future efficiently.
