How to pull your business out of technical debt?
An average developers spends 41.1 hours at work per week. 13.4 out of those are spend on technical debt. Is there a way to be more efficient with the time of your developers and your own resources?
So, your team needed to borrow a little bit of time in order to push that very necessary feature forward a little bit faster…
…One thing led to another and now you find your It and operations teams carrying an enormous bowl of spaghetti code on their shoulders. Productivity has plummeted to the ground, releases of new functionality are now nothing short of a Herculean feat, and saying that user experience is deeper than Challenger II in 1951 is an understatement.
The implications of technical debt
Technical debt is the silent killer of not only legacy systems but long lasting software development projects as a whole. Poor documentation, lack of established processes, difficulties in onboarding all lead continuous development cycles to their inevitable end. End they take your team back to the drawing board.
- When in debt, sustaining efficient development processes is no longer an option: on average, organizations waste 23- 42% of the overall development time due to technical debt.
- Hiring new developers becomes a chore as it increases coordination costs. Getting a new team familiarized with spaghetti code makes the development less efficient.
- Technical debt transforms introduction of new functionality into either re-work or completely wasted work. Organizations are stuck investing months of man-hours on improvements that either do not offer an immediate business value or are simply not urgent at the moment.
- Based on data, many organizations pay for 100 developers, but are only getting the output equivalent of 75 developers.
More on the matter, technical debt impacts much more than just your technology. The lack of appropriate tools and frameworks that are necessary to running operations in the 21st century leads to “process debt”.
The lack of workforce leads to accumulation of “people debt”. This one is even more painful because, as you spiral down the rabbit hole of technical debt, you’ll find that fewer and fewer developers on the market have the necessary skill sets to support or maintain the technologies that have now become obsolete.
One thing leads to another and, after a few years have passed, you may find yourself with software you’ve spent hundreds of thousands of dollars on but can’t even continue using.
This leads us to the bread and butter of our article. How does one get themselves out of the endless pit of technical debt?
Calculating technical debt
Let’s face it, eliminating unplanned work entirely is impossible. That said, high-performing organizations can show you a good baseline for indulging in unplanned work. According to Accelerate: The Science of Lean Software and DevOps this baseline is 15%. This baseline allows us to calculate the actual cost and impact of technical debt on your business.
Waste (%) = Percentage of unplanned work – 0.15
Untapped Capacity ($) = Number of developers * Their average salary * WasteTweet
Process is king
If you could pinpoint one key thing that has led your company towards accumulating technical debt, that thing would be the lack of established processes.
Ironically enough, getting involved in developing a viable, reliable framework for getting out of technical debt might be your saving straw. For starters, development of runbooks, disaster management plans, appropriate technical documentation, and development policies will streamline your “culture of modernization”.
Sticking to these plans will prevent you from accumulating new debt in the process of fixing the software.
Following a plan to a T will ensure that – after a continuous and challenging journey – you will be left with a lightweight, scalable solution you’ll be able to use and maintain for years to come.
Is it really as simple as following a plan?
Technically, yes. But as any other thing that’s brilliant in its simplicity – the task is easier said than done.
Where does one start?
Get a top-down view of existing infrastructure
- Rely on either internal auditing or an experienced external partner to identify and consolidate systems, applications, networks, devices, accounts, (code/data) repositories and anything else you can inventory.
- Index and centralize existing documentation, procedures, and policies. Talk to your developers or DevOps to get more insights. Alternatively, you can hire someone to help with technological archeology.
- Analyze the costs – past, present, and future.
- Map out the necessary business services. Make sure they fit nicely into established business processes and help your team or the end user to be more productive. Put the benefit of the end user at the head of the table.
- Compare the functionality you need to current industry-leading benchmarks to make sure you know what to expect and how you want the product to turn out.
- Net out productivity gains from previous investments using total cost of ownership studies if available or conducting internal return on investment analysis through OpEx/CapEx tools.
Yes, this may seem like a challenging and daunting process.
Yes, it will take a lot of time, effort, and resources.
But, at the end of the day, these investments outweigh the issues from losing core elements of It infrastructure entirely. Even after spending thousands of dollars on upkeep.
Getting down from the bird’s point of view
Now that we’ve settled with the big picture changes, the time has come to resume more efficient development by launching processes that will continue to support your product with new features. The other aspect of these goals lies in slowly but steadily dealing with the tech debt your company has accumulated.
CI/CD refers to Continuous Integration and Continuous Delivery. Being a part of the DevOps pipeline, the methodology emphasises implementation of more efficient pipelines in application delivery through higher levels of automation, testing, and updating.
Diving a little bit deeper into all of the benefits such an approach brings would be an article in and of its own, but – for now – let’s focus on ways a new development methodology can help you climb up from technical debt.
A snowflake environment
The prevalent form of technical debt usually comes from what engineers call a “snowflake environment”. This describes an application that works in Dev, but fails in either Prod or Pre-production. In 9,5 cases out of 10 consistency (or lack thereof) is the root cause of the challenges.
Why does this happen?
The absence of coding culture and refined development methodologies such as infrastructure-as-code – whether intentional or not – leads to hundreds of system configurations, application dependencies, or any additional settings. Sorting through this mess takes the lion’s share of your team’s time causing more debt to pile up.
The DevOps emphasis on automation as well as the practice of holding it as code on GitHub rather than in documentation makes iterations much simpler and quite faster. The time you needed to troubleshoot can now go to actual development and elimination of technical debt.
Looking forward to finding out more? Reach out for a free consultation and we’ll gladly guide you through the process of climbing out of technical debt for your business!