Imagine an old bridge on a busy route.
As years go by cracks in the support beams and loose bolts appear making the bridge unsafe.
Since there is no money to make major repairs the authorities make periodic and cosmetic repairs, patching one part of the superstructure while another part develops problems.
This break-and-patch regimen can keep the bridge open and working up until one day, something gives and the entire edifice crashes down.
Software has a similar problem.
When products are being built coders sometimes take design decisions that prioritize speed and cost over stability or scalability.
In civil engineering terms teams focus on quickly constructing a building that can accommodate a family of four instead of taking the time planning one that can house forty, because four people needs a roof over their heads right now.
As the codebase grows in complexity and features keep on getting added the code keeps on breaking down as it was not written taking into account all use cases.
Temporary hacks and patches can keep the lights on but they are more in the nature of using string and bubble gum.
And this is how technical debt is accrued.
Companies who are under tight deadlines to ship products rack up plenty of technical debt. This debt in itself is not a bad thing, as in a hyper competitive market time is of essence.
In an ideal world developers would go back and fix the code so that it’s scalable. But in the short term that’s not attractive and developers often slap on more bubble gum and duct tape to keep everything together, piling up more debt. This problem is frequently seen in the fast paced world of Agile Development.
In this scenario technical debt could be fatal- the product can crash frequently, take up too many resources, or have gaping security holes.
Most people think of technical debt in terms of buggy code. Nothing could be further from the truth.
Technical debt is code that becomes less agile as the product becomes more mature. The code was okay when you launched with a few features, but will break down as more features are added.
Technical debt is actually less of a coding problem and more of a cultural problem as it stems from a focus on shiny new things instead of getting the basics right. Hence developers are not the only people who should be responsible for paying it off.
Here are some strategies for ensuring that you don’t have a Greece like problem with your product.
It’s a very bad idea to lump in all your code together. If you have a mobile app the code that deals with user interfaces shouldn’t have any dependencies with code that pulls data from a third party.
Writing tightly coupled code means that even if your initial code is perfect it will turn into a train wreck soon as adding new code can cause existing code to break in unexpected ways.
Businesses should be focused on customer experience, and towards this end it is critical that they keep the debt in user facing code as low as possible. If you have segmented your code, it’s a lot easier to test and ensure that user interfaces or data structures have low technical debt because their performance matters to the user.
It’s also critical to stress test those parts of your application that receives highest traffic because that can degrade overall performance of an application.
Technical debt should not be used as an excuse not to innovate. Software constantly evolves and no one knows what future demands will be imposed on the code.
Instead of going for a complete rewrite of the code which sounds good in theory but is impossible in practice product owners should focus on improving code quality in cycles while continuously making improvements.
It might feel good to write code that’s technically perfect. But it’s even better to move fast, push code out AND adopt best practices so that the code is stable and scalable.
Debt, financial or technical, is not a four lettered word. The critical thing is to ensure that there is a balance between adding new features and ensuring that the underlying foundations are firm.
How to create an effective technology vision and strategy
Green IT Initiatives for the Twin Transformation of Industrial Enterprises
CIOs in 2021: New Mindsets, Cultures and Leadership Rules
Top Strategic Priorities for CIOs in 2021
Seven Ways COVID19 has Changed the CIO Role
The role of CIOs in fostering an agile and innovative DevOps culture
The benefits of cybersecurity mesh for distributed enterprises
Deliver personalized experiences to improve customer engagement using machine learning
Smart Contracts for Innovative Supply chain management
We're here to help!
No obligation quotes in 48 hours. Teams setup within 2 weeks.
If you are a Service Provider looking to register, please fill out this Information Request and someone will get in touch.
Outsource with Confidence to high quality Service Providers.
If you are a Service Provider looking to register, please fill out
this Information Request and someone will get in
Enter your email id and we'll send a link to reset your password to the address
we have for your account.
The IT Exchange service provider network is exclusive and by-invite. There is
no cost to get on-board;
if you are competent in your areas of focus, then you are welcome. As a part of this exclusive