April 18, 2005 - Sustaining Legacy Code

Last month I visited some customers and prospects in India. One of them was an outsourced provider of software engineering services. Sure enough, some projects they get are to maintain and sustain an existing body of code. "So how does Agitator help?" they ask.

Well - with no tests available with the code (hence Legacy), it's better to add a test or two for any change they make. This way, over time, they will have at least a change detection suite for follow on changes - they will build better knowledge (and with the tests being the spec, have a partial spec too) for the code. While it may not be a perfect state to be in, it's a better state than they were before the last change they made. Over time, they'll get closer to a "good" state.

With the Agitator's ability to "observe" behavior of the code, it becomes that more easy to observe side-effects that your changes may cause. Agitate before the change - observe behavior. Agitate after the change - and compare.

In continuing with my rant about the Developer Testing Burden - the tools job is to reduce the time it takes to add good tests to the code.

I have come to realize the power of the Agitator in these situations. I don't believe any other technique/method of testing or tool gets even close to addressing this issue - and this scenario happens fairly often!

Have you had the fun task of maintaining and improving legacy code? How did you go about implementing code changes - did you add tests as you went along? I'll be interested in your opinions.


Posted by Ashish Kumar at April 18, 2005 10:38 PM


Trackback Pings

TrackBack URL for this entry:
http://www.developertesting.com/mt/mt-tb.cgi/153


Comments

Our experience has been somewhat similar. We had an extremely large and successful system in place and have been Agitating new projects as well as attacking the existing system using the dashboard's risk metrics.


We recently had an interesting observation:

A key component for us was recently integrated after a major protocol revision. The revised component was implemented and tested before we were using Agitator, showing a good performance and reliability improvement, but then it was shelved because of incompatability. During our training I attacked the old version of this component. When we integrated the new version I found that my numerous @BUG'd statements were fixed. This validated the usefullness of Agitar for us and has been a good example of how we can use it to make incremental use of Agitator in legacy code.

Posted by: Karl Pauls on April 19, 2005 10:18 AM

Post a comment




Remember Me?