One of the most effective catch phrases of my youth was for a product called Fram Oil Filters. Sometime in the 1970’s, Fram came out with a set of television and radio commercials where a mechanic would explain how a simple thing like replacing your oil filter on a regular basis could prevent major engine problems. The catch phrase uttered by the mechanic at the end of each commercial was, “You can pay me now, or you can pay me later.”
The connotation behind the final statement was, of course, that by paying now for a relatively inexpensive item – an oil filter – an automobile owner could avoid paying a lot of money for an engine overhaul down the road.
So successful and true was the statement that it would soon extend beyond just the Fram commercials and would become part of the common lexicon. Whenever someone wanted to point out that a little prevention could go a long way toward avoiding a big problem later, that person even today is frequently heard to say some version of “You can pay me now, or you can pay me later.”
One thing this definitely applies to is application software, because the shortcuts taken and money saved during a built can definitely lead to costly problems later.
Analyzing the Path
The growing recognition of the technical debt issue should be evidence enough that companies need to start looking at their build and customization processes for ways to eliminate issues with application software. As Eric Allman recently pointed out over at the ACMQueue Blog, “Roughly speaking, technical debt is acquired when engineers take shortcuts that fall short of best practices.”
Allman goes on to note a number of different types of shortcuts, each of which is certainly avoidable when developers are working on application software. Failing to adhere to best practices, however, inevitably will catch up with the application. As Eric notes in his blog and as we have time and time again noted here, the cost to fix the inevitable problem that arises is what we’ve called in this blog technical debt.
Another point that we’ve often made in this space is echoed by Allman – the fact that not all technical debt is bad. Since the perfect application has yet to be written, and because there will always be upgrades that need to be made, there will always be some maintenance on application software. But that doesn’t mean an application can just be slapped together and pushed out the door without regard for what will happen once it has been deployed.
Further on up the Road
As Allman astutely states, “Technical debt is inevitable. The issue is not eliminating debt, but rather managing it.” Of course, the best way to manage it is to take the time before deployment to eliminate the hiccups and flaws that go into software. The list Allman offers in his blog of examples of shortcuts taken is interesting, although I’m sure even he would admit it’s only a fraction of those developers have undertaken in the name of “expediency.” His list includes:
- Sneaking around an abstraction because it is too hard (or impossible) to figure how to “do it right,”
- Skipping or scrimping on documentation (both in the code and external documentation),
- Using an obscure or incomplete error message because it’s just too hard to create something more informative,
- Implementing code using a simple but slow algorithm even though they know that a better algorithm will be needed in production,
- Using void* when you really should have created an appropriate union*,
- Using build tools that don’t quite work for the system at hand,
- Skimping on good security practices,
- Not writing unit tests
Just eliminating these shortcuts, though, isn’t enough to manage technical debt efficiently. Even if everything is done by the book, issues can still exist. After all, there’s the “human element” to factor in. And then of course there’s the fact that very few applications are built from scratch anymore, but are instead built upon existing code that may not meet present-day standards.
So to truly manage technical debt, a company should manage its team to make sure it doesn’t take the kinds of shortcuts Allman describes, but it also needs to spend the time during the build process to perform a comprehensive assessment of the application software. The key here is “during the build process” though. Once there’s something worth actually testing to see if it works is too late. With each phase of a software build, issues in the software become more difficult and costly to fix by a factor of 10. By the time a project is completed, a mistake that in the initial phase of the build may have taken 10 minutes to fix, may now take over an hour or more…and as the old cliché says, “time is money.”
By spending a little time and money during the build phases to apply a platform of automated analysis and measurement – which is now becoming more readily available in software as a service (SaaS) form – those little quirks that could bring down an application can be found and then dealt with.
Because after all, when it comes to application software, you can pay a little to fix it now, or pay a lot to fix it later.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.