Most CIOs have heard of the term Technical debt. All projects have to face them, and so do all developers. The only difference lies in the situation: Whether they have paid it off, have an intention, or run out of chances to do so.
Unfortunately, these technical owning-loaning things are not as simple as the Hebrew bible’s rule of an eye for an eye. In the IT industry, technical debt is never œa code for a code but must be paid with a combination of money, time, efforts, or worse, your team’s working spirit and enthusiasm over time.
For those who aren’t familiar with the concept, CMC Global has bad news for you: it could be a major strain source in your IT departments or offshore team, which eventually causes major inefficiencies and lost opportunities. So, what truly are technical debts, and how can you avoid them at their max? (since we can never get rid of them) Check out our latest insight to get yourself prepared and updated with 9 strategies for CIOs to manage technical debt!
What is Technical Debt?
Technical debt, also known as design debt or code debt was originally created by Ward Cunningham, the father, and creator who developed the first Wiki and was an early proponent of agile programming.
Referring to software development only, Cunningham’s creation can be extrapolated to any technology implementation that prioritizes time over quality. He describes the debt as a tradeoff that programmers make to gain immediate speed over the long-term efficiency, scarifying correct scalability, security, supportability, and many key architectural principles.
In real-life projects, shipping the first code is considered going into debt. This helps speed up the development process and is somehow harmless as long as developers remember to pay back quickly with a code rewrite. If they don’t do it quickly or forget about the small little debt they have owed, every minute spent on the wrong/ contemporary code counts as interest on that debt. This will add up and at some point, lead to terrible consequences: the entire engineering organization is forced to stand still and torn between a hard dilemma: untangle the mess they’ve made, or start the project all over again?
This doesn’t mean Cunningham opposes getting a fast, working product to meet an immediate need. Called “rough consensus and running code approach” by The Internet Engineering Task Force, which develops the communications protocols to undergird the Internet, the technical debt is not the result of cutting a few corners for quick implementation but failing to go back and modify the debt and their interest into alignment.
Types of Technical Debt
There are many ways to classify technical debts into categories, and CMC Global will have deeper insights into that. But in this article, we will divide the debts by programmer’s will, which are:
Deliberate Technical Debt
Normally, programmers know which is the right way to do something, as well as the quickest way to do the same job. In an ideal environment, the quick way is the right way and we can use that to avoid over-engineering. Yet, in a not-so-ideal situation, programmers must bear the expense of technical debt to do something the wrong way because they need to deliver the product to the market/ the client as soon as possible.
Accidental/Outdated Design Tech Debt
The things that can hold accountability for this type are the programmer’s knowledge and experience, poor practices, or rollout issues. Before the project starts, it is hard to control all cases as well as the business restructure.
A Debt that requires No Payback
That’s true, there ARE debts that require no paying back. How? You may ask. These are debts coming from young and small start-up clients who take the risk of launching their MVP as soon as possible. However, according to a compilation of start-up statistics, an estimated 90% of new startups fail. This means your debt is gone and you don’t have to pay for it anymore.
Are there any exceptions? Well, there is. Friendster – a social entertainment site focusing on gaming and entertainment failed not because it had too many customers, but because it had too many technical debts.
Reasons for Technical Debt
CMC Global has identified 5 main practices that can lead to future technical debt.
1. Neglecting a Proper Architecture
If you don’t have an architecture to follow in the first place, adhering to it is impossible. But sadly, the very first thing that is wiped out on the road of speeding up is building a proper technology architecture.
A well-thought-out architecture concerns everything, from security, and scalability to supportability. Thus, a technology initiative without the right architecture can lead to incurring technical debt.
2. Isolated Implementations
If CIOs assign different groups to implement technologies without a robust collaborating process, high chances are technical debts can be generated through incompatibilities
Take a virtual desktop infrastructure (VDI) for example. If one group focuses on implementing VDI and the other on rolling out desktop video conferencing, without an infrastructure to properly support workgroup collaboration technologies, the results can clash, demanding cumbersome workarounds.
3. Short-term Project Focus
CIOs with software backgrounds and little business knowledge about business are particularly subjected to this problem. Many applications are built to tackle a specific business problem existing in the here and now. For a CIO who doesn’t know the core problem or how it will evolve or what other adjacencies it pertains to, the consequences can be messy.
For example, a customer accounts database created without proper insight into how it is integrated with the sales/prospecting database can lead to hours and hours of transforming or importing contacts.
4. Disconnect between Development and Operations
This can be attributed to personal attitude. An engineer who designs a product without considering how their colleagues can operate, maintain and support it can result in cumbersome, error-prone, and inefficient products. This is one of the most popular problems in large organizations, which lies in the disconnect between development and operations
5. No Full-lifecycle Vision
Technologies are evolving at an unprecedented speed, so the old technologies or business processes will retire when a better version emerges. This means having an end-of-life (EOL) strategy in place for technology initiative launching is a wise move. Otherwise, the lack of an EOL is a red flag for the possibility of technical debt.
There are many more reasons that can contribute to the debt:
- Lack of knowledge or proper process for software developmentÂ
- Ambiguous requirements from clients/ Not understanding the requirement while implementing
- Time pressure from clients
- No testing
- Last-minute changes
- Lack of all party’s collaboration and miscommunication
- Software not user-friendly but clients-friendly
- Lack of documentationÂ
- Code monolithic
- Programmer’s carelessness, irresponsibility, or laziness
9 Strategies for Technical Debt Management
There are strategies that you can use to eliminate these practices and minimize the chances of technical debts. These are:
Build a Proper Architecture
When initiating a project, a CIO or business leader should adhere to architecture with explicit mechanisms for managing, securing, supporting, and integrating the technology into adjacent technologies.
A proper architecture to follow can actually speed up the developing process and avoid technical debts that are associated with “after-the-fact” fixes.
Teams Coordination
Different teams in the same organization should have a broad view of what the other teams are doing, their timeline, and the potential impact of those projects on theirs.
Keep An Eye on the Big Picture
Even if you are implementing a short-term project, one person within your team/ organization needs to keep an eye on the bigger picture to make sure projects don’t overlap or conflict with each other.
DevOps and DevSecOps Approach Is Highly Recommended
CIOs must always think of the question “How will we support this?” when developing something. Any team wishing to avoid technical debts must ensure that there are built-in strategies for operational support, including security for any proposed technology.
Begin with The End In Mind
Being left behind must become CIO’s worst fear so that they are well equipped with technology updates. As long as CIOs have a clear understanding of technologies, all the updated and obsolete ones, the chances of technical debts can be reduced.
Honesty, Honesty, Honesty
One thing to notice is, not every client has a technical background. That means CIOs or PMs need to understand their requirements thoroughly and explain technical debts to them. You may want to provide a cost-benefit analysis (CBA) to give them an indication of cost changes in terms of technical debts.
Project Backlog
Agile methodologies need to be used, Scrum in particular so that all the work to be finished on the project can be indicated in the backlog and everyone can have a good view of it.
Quality as a Rule
When the whole team has the same mindset of building quality products over speeding up launching time-to-deliver, with the right established processes and constant, correct communication, there is no place for technical debt.
Revisit Your Projects Regularly
Even the best projects have to carry their own amount of technical debt. So, programmers should revisit their projects with an eye towards reducing the debt by seeing how they can be minimized.
Summary
At the end of the day, everyone will have some form of debt, and the tech world is not excluded. Today, technical debt has become a familiar friend for most software developers, and we must say, it is not THAT bad. The debt will only become a real problem when it is left out there, hanging and neglected until it is too late.
That’s why finding yourself a trusted, experienced, and knowledgeable partner when it comes to software development is a critical task that must be done right.
With over 27 years of experience in the market working with many international clients, CMC Global has extensive insights to give you practical consultation. We make it easier for you to choose from those complicated ways of software outsourcing.
