Understanding Technical Debt
Cloud technologies are known to offer many benefits, but it’s safe to say that two words dominate expectations when it comes to development cycles: faster and nimbler. As more organizations implement agile development, it’s becoming clear that expedited time to market is an expected standard – and so is the speedy development that goes along with it.
As fast turnarounds and flexible production become a baseline of cloud development, so does the necessity for developers to fix, tweak, change and adapt as they go. On a sprint, it’s tempting to prioritize speed over completion, especially when a deadline for an impatient client is drawing closer. As a result, some developers are tempted to rush and cut corners in an effort to meet the delivery deadlines. Because of this, many in our field are becoming familiar with the term “technical debt.”
The danger, of course, is that even though those shortcuts can seem like an efficient way to achieve speed to market, they can damage teams in other ways. For instance, last year when LinkedIn suffered a hack and millions of email addresses were stolen, the company was harshly accused of cutting corners, which led to the vulnerability. Whether they did or did not is still debatable, however the cost to the brand and revenue were apparent from the mere idea that the company scrimped when it came to coding.
Every organization that’s using agile should be well aware that sometimes cutting corners can turn into technical debt that will cost your organization later – and can ultimately cause deadlines to be missed, sabotaging the same cycle time you were trying to protect.
Managing technical debt
Many developers make the mistake of thinking they know what corners they can cut without sacrificing quality. But as development evolves and uncompleted changes and abandoned directions pile up, the team can find themselves staring at a serious technical debt that must be paid.
The causes of debt are fairly common. The pressure to release a product prematurely, a lack of collaboration and knowledge-sharing, or a lack of thoughtful testing or code review and key documentation, are just a few dynamics that can lead to a significant amount of debt. So how do you keep this from happening to your team?
One tip to keep in mind is resolving issues as soon as they appear instead of putting them on a back burner. The earlier the stage of detection, the less expensive those issues will be to fix. Issues left unresolved, on the other hand, will expand into a technical debt that will eventually demand more time and money in eliminating. As one example, consider legacy code where the software engineers spend so much effort in keeping the system running, thereby supporting the debt that there’s not enough time to add new features to the product without additional expense.
Common shortcuts – and their costs
When work cycles are on the line, developers tend to cut some of the same corners over and over. A good example is Quality Assurance work, such as code reviews, unit testing, integration tests and system tests. Many developers feel comfortable skipping tasks here for one simple reason. Because this is work undertaken to validate the code, rather than actually writing the code (other than corrections found by the QA activities), they assume it can be eliminated with minimal risk.
The truth is that cutting corners here can mean sacrificing knowledge and productivity. While it might not be immediately apparent, the overall productivity of the team tends to be higher during a lot of these activities since they increase interactive learning within the team, which in turn leads to higher levels of output.
One way to protect this valuable phase is to implement processes that are used as a check list among every development cycle. In my company, we call this Tiempo Quality System (TQS), a defined set of best practices and processes that standardizes the engineering process. By using a configurator that ensures best practice QA activities are defined up front, TQS minimizes overhead while maximizing overall team productivity. Similar systems can easily be implemented among any development team and are a great way to eliminate technical debt.
Managing quick cycles without cutting corners
All of this might sound as if agile developers need to choose between delivering on fast-paced cycles or executing on solid development. Rest assured, both are possible.
One solution is tracking velocity to produce data that shows the production delays resulting from a backlog of coding issues. By demonstrating the exact fault lines that jeopardize product quality, developers can head off debt at the start. Things like Code Reviews should be looked at not merely as QA activities, but as opportunities for the team to learn together, create improvements on producing the code and work towards optimization.
The shortcuts worth taking
Developers must accept that the pressure to cut corners will never go away. So is it taking a shortcut ever acceptable? Under some circumstances, yes. One category that qualifies would be issues that aren’t showstoppers when working on release or deadline driven products. In this situation, rather than delaying time to market, refactoring can and should be implemented after meeting the deadline.
Predictable release schedules, deadline adherence, and expedited development cycles are good things and should always be prioritized in intelligent cloud development. At the same time, it’s critical to adopt a long view and not sacrifice quality in the pursuit of speed. Manage your technical debt during development and you’ll find it that much easier to deliver a high-performing product – on deadline.
By Bruce Steele
Bruce Steele is the COO of Tiempo Development. He drives Tiempo’s software engineering, professional services, consulting and customer support initiatives. Mr. Steele is a seasoned Executive with over 25 years of management experience in the areas of operations, corporate development, sales and strategic planning with leading technology firms. He can be reached at firstname.lastname@example.org.