Are you working on a project that needs to test older Legacy applications? Do you feel that your skills are being wasted on older technology? No worries! Your position might actually have more benefits than you would get if you were on a completely new Greenfield project.
Why don’t we like Legacy code?
First off, we need to change our perspective. Legacy code has gotten a bad rap and one reason may be the way we name things. Legacy code is also sometimes called brownfield, dirty field, [email protected]!field, or rescue work. Notice all of these terms have a decidedly negative connotation.
Terminology like this can have an impact on the way we view something, and these terms definitely don’t help. So the first hurdle we need to get over is the negativity of the terms we use for code we did not write.
Being a Code Archaeologist
Dealing with Legacy code is almost like being an archaeologist. We have to dig through the bits and pieces of someone that came before us and try to figure out what was in their head while they were doing it. It’s difficult to know the constraints the person was dealing with when they created the code.
Have you ever heard of the curse of the pharaohs? It’s a curse believed to be cast upon any person who disturbs an ancient Egyptian mummy. If you’re responsible for maintaining some Legacy code, it may sometimes feel like the code base you’ve inherited is cursed. That curse sometimes paralyzes us with fear when we need to make a change to some older areas of code in our application, but we should never allow that fear to prevent us from improving the code.
Continuing with the archaeologist theme — our tests are like Indiana Jones’ trusty whip. They should provide us with some security in knowing that if something goes wrong they will be caught. Building a trust test harness should allay some of our fears.
When we make changes to code we can introduce errors, but when we cover our code with tests before we change it, we are more likely to catch any mistakes we may have made.
It follows, then, that when you start making changes to Legacy code you can overcome some of your fears by always having unit tests around the code you are making changes to.
In his book Working Effectively with Legacy Code, Michael Feathers provides a handy Legacy code change algorithm to help us when we’re making changes to code. The five steps are:
Identify change points
Find test points
Make changes and refactor
When you start the writing tests step, Michael calls these types of tests “characteristic” – referring to a test that characterized the actual behavior of a piece of code. He shares another algorithm for writing these types of tests:
Use a piece of code in a test harness.
Write an assertion that you know will fail.
Let the failure tell you what the behavior is.
Change the test so that it expects the behavior that the code produces.
There’s actually a whole chapter on “I need to make a change, but I don’t know what tests to write” that offers lots of advice to help you create a test harness that gives you piece of mind when working with Legacy code.
Even if you have a solid test harness, some people still get frustrated when working with older technologies and feel like they are being held back, but if you’re a test engineer it shouldn’t be a concern.
Using newer test tools
There are many opportunities in the testing space to use modern testing tools against an older product. You needn’t limit yourself to only the testing tools that were available when the product was originally written. Since the tests execute outside the application, you actually have quite a bit of control. And since tests run in an environment that you control, you can definitely benefit by focusing your efforts on improving the testing.
For example — one of the current trends in testing is behavior-driven development. If you’re testing Legacy code there’s no reason why you can’t use a tool like Cucumber to start testing your Legacy application(s) using a BDD methodology.
Testing Job Security
If you’re working on something old, by its very nature you are being asked to keep it alive. It’s providing some value to the people that are paying you to work on it, and that value is not likely to go away.
It’s not a hypothetical value like you can often have with a startup. In a startup you’re in effect betting that the application you’re about to build has value, whereas with a Legacy application the value is already proven and it’s a given that it’s important enough for you to be working on it.
I know of an engineer who had been working at a company for 40 years and created some of the code that still exists in his company’s current code base. He was never without a job and never in jeopardy of a layoff. He made himself so valuable that he basically recession-proofed his job. How many startup engineers can say the same thing?
The last time I checked, the company was asking him to delay his retirement while he helped to re-write the application with newer technology.
So, if you’re worried about job security, Legacy code isn’t so bad.
Grow your skills with Legacy code
At the end of the day, testing Legacy code can be incredibly rewarding. If you ask most engineers they would probably agree that some of the hardest problems they’ve had to overcome were against Legacy applications — not new projects.
Wrestling with some of the technical issues usually seen on older projects has helped them gain a deeper understanding that has helped them grow as engineers.
Still not convinced that Legacy code is cool? Check out my TestTalks podcast interview with Scott Ford, the Code Whisperer: http://www.testtalks.com/29