Tina Fletcher used a clever imagery to help explain legacy code, and that was to look at ancient architecture with modern buildings built over/on top of it.
Tina Fletcher
Senior Test Strategist, D2L
Legacy code is code you inherited, don’t understand or is difficult to change. It’s also murky stuff to look through, and it can feel a great deal like speaking a new dialect of a language you may feel like you know, but the dialect throws you for a loop.
Testing is, of course, important, but there is a number of options available to the tester that doesn’t require “just do more testing” as the standard response.
Five areas that Tina suggests to help do better with in regards to managing legacy code are:
Code Stewardship – If you have an area of code that you have either created, or maintained, or even just owning the code, can do a lot to help make you focused and mindful about that code. Actively recruit people to take ownership. Many people may not feel up to the task or be willing to volunteer themselves, but if we present to them that they are the ones who are active in the code base, that often speeds up the desire to take on the code stewardship role.
Knowledge Management – One key consideration is “what does the code do today, rather than what was it intended to do”. We want to help prevent rel-learning the same lessons, or at least not have to have everyone go through the exact same struggle to get the code to work or be able to understand. If there are illogical or strange elements in the code base, let’s highlight them and share why that is the case. Truth be told, documenting everything does not guarantee that there will be no mistakes, but there is a lot of benefit to documenting well what the code represents so that others can learn about and contextualize what the code is and what it does.
Test Coverage Analysis – 100% test coverage doesn’t mean you have lessened risks. Code coverage itself will not tell you how good your tests are, but it will at least let you know of areas you don’t have covered. Most important, focus on knowledge of what the code is doing rather than justs providing coverage. Knowledge will give you both ideas about what code should remain or be built and what code should be removed or degraded gracefully.
Team Shadowing – take a walk on the wild side every once in awhile. Spend time outside of your immediate day to day work team. Shadow the developers. Shadow support. Shadow sales. See what their pain points are, and what they have put in place to deal with certain issues. You may think that you are doing this as a “good deed”, offering your expertise to others, but don’t be surprised if the person who benefits most is you. Team shadowing also helps to identify areas where you may be duplicating effort. Just as though you may want to shadow other teams, allow them to shad yours as well.
Culture Change – Do we really value quality above deadlines? How can we confirm that? What are some ways we can change how we handle these things? An approach is crowd-sourcing your “done” criteria. Encouraging people to help you make this culture shift. Make it a low to no risk approach and encourage others to come along with you on the journey.
These areas are all ways to lessen the unknown, reduce risk, and help keep systems in the know as well as the people who work on it. This stuff will take time, so go slow, make a goal you can achieve, and have a way to chronicle your achievements.
Recent Comments