When watching IT shops over the years it seems some, despite trying to cram two weeks worth of work into six days a week, never seem to move very far forward. And yet other teams seem to make tremendous strides in productivity and outcomes despite not working as many hours as the poorer performing organizations.
Why is this? Like many aspects of life and business, it’s about working smarter, not harder. When it comes to enterprise IT that often means avoiding technical debt. The generation of demand for work to fix issues that should have, could have, been avoided had the work been completed properly the first time. “In an engineering context, I believe we are talking about the negative side of the tradeoff ledger,” says Kevin Behr, the chief science officer for the CXO and Board Advisory Practice at Praxis Flow. “Engineering inherently involves trade offs between what we would like to do and what we can actually do, so we often cut corners in the name of expediency,” Behr says.
Aater Suleman, co-founder and CEO of Flux7 put it another way: “It’s when you have urgency that takes precedence over the right thing to do. In that rush, you’re not making decisions the right way, you’re just getting things done really quickly in the heat of the moment. And you have to go back and fix those later,” Suleman says.
The high cost of technical debt
How much technical debt does your organization have? How much latent work is hiding in rework and hurdles that need to be leaped because of shortcuts taken and ongoing bad decisions made in design, infrastructure, and operations. How much debt has been accumulated today, this week, month, or year? And, more importantly: how do you pay down that debt and not accumulate new debts in the future?
According to Donnie Berkholz, an analyst at Redmonk, DevOps relates to technical debt in that DevOps is a more collaborative approach to software development and enables the people building and running the software to have a fuller understanding of all the places technical debt can live. “Sometimes it’s not directly in the code base but rather in the release tooling, or the production systems,” he says.
An example Berkholz cites as a n example of the potential cost of technical debt is Knight Capital’s $460 million loss due to lack of documentation and automation of their server configuration.
Paying debt down
As a way to help reduce technical debt, Berkholz advises enterprises consider running “blameless postmortems” after outages or issues. “It’s about explicit acknowledgment of the facts as well as setting aside time to fix underlying problems without searching for blame,” Berkholz says. “Technical debt won’t fix itself; you need to set aside time and effort to pay it off, without worrying where it came from beyond lowering future debt as much as possible,” he says.
And for avoiding technical debt during ongoing operations, Suleman advises enterprises continuously test their operations and applications. According to Suleman, most companies that have taken on significant amounts of technical debt actually don’t have adequate testing in place. That, by itself, is a challenge itself, but it turns out many organizations actually have another issue – some enterprises hold an unsubstantiated level of faith in their testing. “I’ve seen many companies where they think they have automated testing, and hence, they rely on it. But the testing is not exhaustive or complete enough to actually rely on,” says Suleman.
For instance, Suleman explains, it’s rare that enterprises conduct performance tests on the code they commit. “Which is why performance testing provides a classic example regarding technical debt, because the enterprise can be doing everything right, and adhere to all of the general DevOps methodologies, and yet the application doesn’t run properly because they haven’t tested correctly,” he says.
When balancing the IT ledger, think long term
While it may sound straightforward enough to start testing applications and system changes continuously, and spending a little more time thinking through design issues upfront to avoid trouble later – continuous improvement efforts, such as trimming past technical debts incurred, don’t take root in organizations overnight. It takes time to build these processes in. Think marathon more than sprint. “Continuous Improvement is not as much for the impatient as it is for those willing to invest in steady, long-term activity,” says Behr.
