The first time I heard the term "technical debt," I thought it had something to do with buying 45 Nintendo Game Boy Color consoles on credit the day before the Nintendo DS came out. And while I certainly associated the right sentiment (shortsightedness, to be exact) with the term, I was way out of the ballpark. But the list of terms surrounding agile is growing, and fast — so fast, it's hard for many people and companies to keep up. So what exactly is "technical debt," and how can your company avoid it? Put down your credit card and pay attention.
"Technical debt" describes the long-term consequences of designing software poorly. Developers create such debt when they build software first and test later. Though some clichés advocate this sort of shortsightedness — "Five fast nickels is better than 10 slow dimes" comes to mind — other, more logical suggestions, such as "Measure twice, cut once," insist that we make sure we know what we're doing before we do it.
That seems reasonable. And it fits with the agile workflow, which can sometimes trade thorough testing for development speed. The important distinction to make is this: With careful implementation of a "test first" protocol, companies can improve their software success rates without sacrificing agility in the long run, whereas delivering a poorly made app wastes resources and results in unhappy customers down the line. When you cut at 15.9" instead of 16.5", you'll wish you had measured twice. And whatever time you saved by not measuring disappears when you have to drive back to Home Depot and measure two more times.
Whether you're building software or a house, separating builder and tester can help. If you assembled a frame in a day, you'd be hesitant to dangle from the second floor to prove its strength; if you rushed to build an app, wouldn't you only build tests it could pass? Having independent inspection not only helps to keep devs honest, but ensures stronger software by finding gaps that might have been overlooked during inception. And, by challenging developers to build software that's good rather than something boring that satisfies the minimum requirements on a checklist, you can both satisfy your end users and bolster your brand.
Understanding why objective tests are necessary is one thing; implementing comprehensive, thorough, iterative testing procedures is another. Making it a point to run penetration tests before, during and after any product rollout will eliminate a major category of technical debt: buried vulnerabilities that are just waiting to be unearthed and exploited. This type of dynamic testing can and should be performed before a product is completed and continued after it is launched.
Beyond pen tests, running background checks that track and test your software as it's built and updated is key to avoiding technical debt from day one. And the only way to really ensure that a product remains safe is to continually test it against the latest attack methods — a task made easier by automated security solutions with updated databases and routine test procedures.
Once an app is delivered to the public, it must continue to pass tests. From post-launch penetration testing to task tests and visual inspections, static testing should be regarded with equal importance. While it may seem tedious, observing code behavior is another major way to minimize debt.
Don't just knock on the frame of your latest app and call it good — make it bear weight and pass visual structural examinations that can hint at future problems. You wouldn't build or buy a house with a visibly cracked foundation, no matter how sturdy it seemed otherwise. Likewise, you should never release fast, untested software that's built on quicksand but looks pretty in the short term.
Of course, no number of dry runs can prepare a building for enduring years' worth of weather, just like no amount of testing can fully protect software from accruing technical debt. A product begins aging the second it is launched, but it also can grow stronger if code refactoring and preventative security measures continue to fortify it. It seems like no matter what we study, the message is the same: Build it right the first time, test it often and keep making it better once it's finished. A developer's work is never done.
One last cliché: "You never finish writing a novel. You just give up." While that's arguably true in the writing world, it's definitely true for code. Even when your software goes live, only constant tweaks and relentless testing will keep it secure and ahead of the curve. Don't give up.
Photo Source: Flickr