Reducing the Cost of Software Regression

H.G. Wells Time MachineA widely held notion among computer scientists is that 80% of a programmer’s time is occupied maintaining code while the other 20% is spent actually writing the software. This inefficient allocation of effort was the subject of a master’s thesis at the Lund Institute of Technology called “Formalizing Use Cases with Message Sequence Charts.” According to a 2002 NIST study entitled “The Economic Impacts of Inadequate Infrastructure for Software Testing“, the annual cost of testing and fixing buggy software in the U.S. is estimated to be between $22.2 and $59.5 billion. What are the root causes of this costly inefficiency?

Unfortunately, corporate culture is naturally a contributing factor for this problem. Companies that produce commercial software are in business to make a profit first and foremost. Release schedules are expedited so the program can be released to market quickly and copies are sold sooner rather than later–making code work as expected for baseline use cases takes priority over regression testing. Any aspect of the software development process that does not appear to be fully in-line with company interests is considered a waste. Usually, far too much emphasis is put on project progress. The overall progress is only perceived progress because unforeseen problems will inevitably pop-up later on. In the long run, bugs end up costing much more to fix down the road and the entire business apparatus pays the cost of maintenance. Some secondary losses are customer support costs, internal communications and a negative impact on the company’s public image all of which can be preempted by proper preliminary work.

Since there’s so much emphasis on speedy release code writing starts as soon as possible, often with disregard to planning ahead beforehand and ensuring quality afterwards. Furthermore, programmers tend to implement items that they are most familiar with first because it seems like the easy way to do things. In most cases, the most difficult parts of a task are best handled first, not last. Handling the difficult items first allows more time and attention to the important stuff; it also allows the developer to recognize how the simpler pieces will fit into the grand scheme of things.

Planning ahead is an essential during the inception phase of a software project. Appropriately analyzing the problem and carefully designing the solutions will minimize the accumulation of technical hardships in the future. In fact, by taking advantage of the popular Unified Process for software development and diagramming specifications in UML the need for writing code almost disappears. UML CASE tools such as IBM’s Rational Rose will translate UML diagrams into program source code (typically an object-oriented language such as C++ or Java.) Of course creating detailed requirements and specifications is still extremely helpful even if UML is not practical for the task at hand. Writing code early on gives the illusion that progress is being made but in reality it is a recipe for disaster. No code should be written until all implementation issues have been resolved.

Threat modeling and secure design principles need to be key focal points during the initial phases of a software project. After the code has been written security issues will also comprise a large chunk of ongoing maintenance work. When software developers handle security fixes they have to stop what they’re doing, modify or maybe even rewrite the offending code, test the new code, report their progress, etc. Since developers are rarely security specialists, they tend to write fixes in such a way that the security hole is not closed completely. As a result, the vulnerability persists and leads to more code rewriting. This cycle of stopping, rewriting, and continuing severely detracts from productivity in programming. The majority of a developer’s time should be spent doing what they do best–adding new features to software.

Removing developers from the patch creation process significantly increases their utilization. Dedicated security experts are most fit to create patches and conduct regression testing. A dynamic program analysis tool accelerates the regression testing process. Building security in by default from the ground-up will minimize software bugs along with subsequent patching and testing. In conclusion, proper planning, resource allocation, and testing procedures can greatly reduce the costs associated with software regression.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: