(14 votes, average: 4.93 out of 5)
Loading...Have you ever heard of “Technical Debt”? If you work in IT, you’ve more than likely fallen victim to the effects of the coding counterpart to Financial Debt.
If you’re one of the lucky few who hasn’t, consider this your crash course!
I’ll be demystifying what Technical Debt really is, explaining why it’s sometimes acceptable to use a “duct tape” solution and how to respond when the adhesive of your short-term fix disintegrates.
Technical Debt is a concept in programming that reflects the extra development work arising when easy-to-implement code is used in the short run instead of applying the best long-term solution. Contact us to learn more!
What is Technical Debt?
The term “Technical Debt“ was coined by Ward Cunningham (creator of the wiki and co-author of Extreme Programming) in 1992 to better conceptualize an abstract issue to non-technical stakeholders. This metaphor to financial debt was so appropriate because technical debt, too allows you to invest early on, but can be really dangerous if not kept in check.
Technical debt is essentially, a series of bad business and technical decisions that have a snowball effect if not addressed swiftly.
Should You Care About Technical Debt?
In short – YES!
While the term shows us where the debt is situated, it can be created by any department or level in a company and affects everyone – including clients or partners.
Let’s get more clarity on this by looking into the effects of technical debt.
Is Technical Debt Affecting You & Your Team?
1. Development & Business Teams
-
Do you find yourself under constant stress? I’m not talking about situations that push you a bit out of your comfort zone, I’m talking about constant firefighting.
-
Is there a collective fear of change in your team no matter what or how small?
-
Is your help/support desk consistently swamped?
2. Management
-
Are you, as a manager or leader seeing low morale across the team?
-
Are you seeing less output even when product resources and funding have increased?
3. Clients
When clients experience a drop in product quality or service they’re bound to lose trust sooner or later. In mismanagement of Technical Debt, you’re not only leaving a customer unhappy, but losing them to your competitors.
4. Shareholders
Decreased revenue in a company coupled with a bad reputation lead to a poor evaluation and inevitably – a drop in ROI.
If you’re experiencing one or more of these signs as a part of your daily work life, your company is more than likely affected by Technical Debt.
Contact us today! Pentalog’s consultants will provide the support you need to scale up code quality and reduce Technical Debt.
Why Does Technical Debt Appear?
There are a multitude of reasons people go into financial or “Technical Debt”, but I’ll group them into two main categories and give some examples:
-
The Acceptable
-
The Unacceptable
1. The Acceptable:
– Say a new law is going into effect in a month and non-compliance can incur multi-million fines – your company will have to bite the bullet and implement a “duct tape” solution to avoid going bankrupt.
– You need to be first in the market before a new investment round
– Production is down and clients are unable to use your product or buy your services.
2. The Unacceptable:
– Lowering standards to avoid a deployment delay that won’t affect the company significantly
– Bad Practices
– Inexperience
– Lack of Communication
Let me harp on this last reason – communication, because this is an area where quantity is constantly mistaken for quality.
Business stakeholders and non-technical managers are usually not aware of the downsides of snowballing technical debt or don’t trust practices in place. They don’t fully understand or simply refuse to accept the time and resources needed to prevent and otherwise manage this issue.
This damage control is often referred to as “non-business value work”. But, if techies didn’t think their work had business value, why would they waste their time?
The benefits of managing Technical Debt might not be immediately tangible, but it still is a necessary medium-long term investment because doing so:
-
Allows you to work more efficiently
-
Enables you to use less resources in the long term (people & hardware)
-
Improves overall processes
-
Keeps you competitive within the industry.
Let us refer to a common Enterprise Architect technique – The Common Vocabulary.
“The enterprise must establish the initial common vocabulary for the business. The definitions will be used uniformly throughout the enterprise.” – TOGAF’s Architectural Principles:
While we might use the same words they can sometimes mean very different things. Take for example, two people from different departments requesting that a graphic designer add a car to a brochure. One person’s idea of a car is a Prius – another is a Land Cruiser, two cars with very different use cases and driver demographics.
Who Should Manage Technical Debt?
At this point, it should be no surprise that I think everyone should be held accountable. But, to be fair, the responsibilities are quite different:
– Leaders should always balance short term with medium to long term goals and avoid opting only for “duct tape” solutions.
– Business and Technical teams that develop and support the product or service should avoid adding new debt while continuously reducing the existing one.
It’s not possible to put one person in charge of managing technical debt or keeping it under control, especially in an Agile context. This responsibility must be shared between the development team, Scrum Master, Product Owner and business.
Preventing Technical Debt
It should all start with establishing clear, concise and consistent communication in all departments of a company – and at all levels.
Continue by establishing and implementing best practices such as Agile methodologies, automation, peer reviews, etc. Ramp up will ensure project success.
Learn more about the Agile transformation and how Agility and fast ramp up will ensure project success.
Manage Your Technical Debt
In line with an old adage, keep your enemy close. Conduct a thorough audit to see what systems, applications and components have the most debt and prioritize accordingly. If something does go wrong backtrack to fix the root cause.
Automate. In any form – be it acceptance, unit tests or devops. Automation is the investment gift that keeps on giving.
In the finance world they say the best time to invest was 10 years ago and the second best time is now. Whatever you’re doing – start adding automation and you’ll see almost immediate benefits.
Returning to Communication (One More Time)
When implementing best practices you will have to present these proposals to a wider audience. You must start with the “why” instead of “what”.
Most technical people will open a discussion with, “I want to do scripted infrastructure and implement continuous integration.“
Instead, start with the “why” and explain in clear terms what benefits the project will bring.
“To fulfill the CEO’s top priority of this year, which is doubling the size of our tech team, we need to add some missing capabilities like:
– Scripted infrastructure which allows fast provisioning of new environments for new teams and globally implement cost savings mechanisms.
– Continuous integration to simplify our development process and get features to production faster.”
Now What?
I hope my (very) abridged primer has given you some insight and perhaps thrown you a lifeline if you’ve been feeling overwhelmed in the tumultuous sea that is Technical Debt. Rest assured – you are not alone!
If you need advice on managing Technical Debt or help setting up your Agile-based project, reach out to our consultants who are ready to support you throughout your entire project lifecycle.
