Emad Georgy is an expert at hunting (and killing) bad code hidden deep in the recesses of enterprise applications. His firm, Georgy Technology Leadership, is hired by Fortune 1000 companies to solve problems on both the people and technical side of enterprise software development.
Digital Journal caught up with Georgy to discuss the optimal strategy for software developers.
Digital Journal: What is technical debt?
Emad Georgy: Technical debt is the cost of cutting corners in software development. It usually occurs when developers fail to take the time required to recognize and repair small coding errors, often unnoticed by the customer, that can linger and result in the need for major bug repair in the future. The debt grows as software continues to be developed using the version with errant code as the foundation.
DJ: Why is technical debt bad?
Georgy: Like any debt, not knowing how much you owe and subsequently, how you will pay it off, is dangerous. The hidden nature of how technical debt arises is bad in and of itself. Unlike other aspects of software engineering that are measurable, our industry has not figured out a way to predict and understand the infinitude of daily decisions that can lead to technical debt. No team or company wakes up one day and realizes it has a product or application that has amassed an unbearable amount of technical debt. Instead, this happens over a series of small, often hidden, daily decisions by software engineers.
The other way technical debt is bad is when it is unbearable enough that it requires capacity, time and energy from software teams to reduce, thereby incurring a significant opportunity cost (the team could be using that time for features that drive revenue). Conversations ensue about dedicating time to reduce technical debt in the roadmap, or increasing the ratio of team time to reducing it. These are all defensive maneuvers that are riddled with risk and failure. At the same time, companies are not actually understanding the root cause, making it difficult, if not impossible to take more direct preventative measures.
DJ: What is an effective method for reducing technical debt without killing operations?
Georgy: One way to address technical debt without disrupting operations (too badly) is to establish a pre-determined ratio of time during which a team is dedicated to reducing technical debt, leaving ample time to revenue-generating activities. The alternative (losing a week or month or quarter to battle the full swath of debt in one shot) is often an operational death knoll. Just because we arrived at a place of unbearable technical debt does not mean we, as techies, get a free pass to take away time from product roadmaps to reduce it. We must always generate customer value.
DJ: What’s the best way to plan a software project that ensures technical debt is either minimized or eliminated?
Georgy: Focus needs to be on building durable architecture. Every architecture decision, technology stack decision, and even code review should have an eye for durability – does this progress our architecture forward? Will this scale for years to come, for 10x and onwards of our growth? When teams are under pressure to meet deadlines, they take shortcuts that are seemingly harmless at the time. Teams that succeed have metrics, accountability mechanisms and processes in place that reveal the impact and risk to long-term durability of these daily decisions.
DJ: Is there ever a time when technical debt is actually useful?
Georgy: Yes – when managing it as an exception and not a rule. Every team will run into a situation where we need to satisfy the customer in a short amount of time, or there’s an emergency of some sort and we need to restore availability or functionality. Done deliberately, with a knowledge of the costs and trade-offs, technical debt can be ok. The caveat is that this approved kind of shortcut also needs a plan for how it will be resolved before one line of code is written. We all have been in situations where something is developed for the “short term” or the “right now” and it becomes permanent for years to come. Only approve technical debt as an exception when a plan is in place to reduce it in a window of time.
DJ: Are there other elements of technical debt to consider?
Georgy: There are so many layers to technical debt! It is a serious crisis in the technology industry – but, I believe, underlying the root causes of all technical debt is what I call Leadership Debt. Technology leaders routinely make decisions that positively or negatively impact the durability of the architecture. Often, this is in the hands of middle management. To the extent we can measure, hold accountable, coach and educate technology middle managers about the impact they can have on the durability of the architecture and ultimately on the longevity of their product line, the more successful we will be at reducing technical debt.
