Why Johnny STILL Can't Unit Test His Legacy Code - And What You Can Do About It
Back in 1955, Rudolf Flesch wrote his seminal book “Why Johnny Can’t Read”. The book became a flash point about how American education was depriving children of the joys of knowledge by not properly training them in the correct way to learn to read, by phonics, rather than the "whole word” guessing that was popular at the time. The book was a bellwether about the “crisis in education” at the time. Today’s session will not be about education, reading, or whether phonics are desirable or not. But the session today does address a serious problem that just about everyone in the IT industry faces. We suffer because our legacy code is not unit tested.
Actually, lack of unit testing in legacy code (which is really a tautology) is just an easily observed symptom of the real issue, which is lack of quality and lack of knowledge in the code that we depend on day after day. When the code shows a defect, most organizations expect a quick resolution to the problem and hope for the best. The same tack is taken when the code needs to be extended. This technique, called “code and pray” rarely ends well.
Organizations that try to do the right thing will give their development team the additional responsibility to unit test their code. Everyone knows that unit testing will go a long way in addressing the quality issue. The bet is that the time and effort taken to unit test the code will fix the quality problem. And they’re right. There are many studies that show this result.
But there is one fatal flaw in these best intentions. Unit testing legacy code is hard. Really hard. And many times, this one fact torpedoes the entire effort that was supposed to make things better.
This is one part of a two part series on Johnny (the other being “Why Johnny Can’t Unit Test His Legacy Code”). In this session, we will look at the organizational and managerial issues surrounding refactoring legacy code. There is no full frontal code in the session, and you needn’t fear any lack in technical knowledge. You will leave with a better understanding of what you can do about solving the problem.
Outline/Structure of the Talk
- 5 minutes of introduction
- 15 minutes on the steps your teams will take as they gain expertise in fixing this problem
- 20 minutes on management’s role in the process
- 5 minutes of Q&A
- Better knowledge of techniques and approaches to take with legacy code refactoring.
- Understanding of not just whys and hows, but whens and whos and how much.
Developers, architects, technical managers, mid level (and above) managers