Are we doomed to make the same mistakes forever?

By: 
John Paliotta

November 03, 2015

I've been thinking a lot about how the software industry has changed (or not) since I started my first job 30+ year ago.  I've come to the conclusion that things are much different, but very much the same.  The first application that I worked on was a legacy code base, completely written in assembly language and run on custom hardware.  The only development tools we had were an editor (EDT) a compiler, and a primitive debugger that supported a single hardware breakpoint.  Although the system was fully functional, the customer wanted to make some enhancements, and the decision was made to rewrite a large portion of the system using a high-level language. 

I was on a team of about 40 developers.  After about two years, we were done with the new development and unit testing and went into an integration phase.  It took about three months before the system would come up in a stable state.  There was every flavor of dumb bugs: "my requirements document says the message ID for system initialization is 10, your doc says it's 20," etc.  This system got fixed and released (late) and was then totally thrown away and rewritten for a third time in the early 1990's. 

Two weeks ago I did some press briefings about technical debt and software quality, and one of the questions I got asked was how to deal with legacy code bases and the technical debt that they all contain.  In the November 2015 issue of Vehicle Electronics, we discussed rewriting versus fixing and I mentioned that one reason companies choose to rewrite is they don't know how to improve their existing code bases.  Our VectorCAST tools deal with this exact problem by helping customers to identify the "worst offenders" for simple technical debt metrics and making it easy to create test cases to aid in refactoring. 

In my experience, the biggest danger in application rewrite is that the new application will perform worse than the existing application, in both functionally and dependability.  Without test cases which formalize the behavior of an existing application, it is very likely that the refactored system will be a step backwards, at least initially.  After all, we're not that much smarter when we write an application for the second time, and there is a real danger that all of the in-use improvements that have been made to that code base over time will be lost.

So before you throw away your code base, talk to us about how we can help get you on the path of incremental improvement.