Why Johnny 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 STILL Can’t Unit Test His Legacy Code”).  In this session, we will look at the technical issues surrounding refactoring legacy code.  There may be full frontal code to look at and discuss.  You may be called on to help us achieve greatness in technical discussions.  You will leave with a better understanding of what you can do about solving the problem.


Outline/Structure of the Talk

  1. 5 minutes of introduction (definition of terms, etc.)
  2. 10 minutes on preparing for safely refactoring code
  3. 10 minutes on various topics related to code dependencies  
  4. 15 minutes on patterns and other topics related to refactoring
  5. 5 minutes of Q&A

Learning Outcome

Better knowledge of techniques and approaches to take with legacy code refactoring.

Target Audience

Developers, architects, technical managers

schedule Submitted 4 years ago

Public Feedback

comment Suggest improvements to the Speaker
  • Fincy Yousuff
    By Fincy Yousuff  ~  3 years ago
    reply Reply

    Hello Howard!

    Thank you for proposing this topic!

    The topic is a very interesting one. Personally, I can relate to this topic pretty well, and I'm sure, so will other managers or leads who are in a fix about what to do in order to help kick start and then motivate their teams while keeping code refactoring and cleaning up of legacy code as their agenda. 

    Do you happen to have a video of any of your previous talks? This is just to see your presentation skills. Also, I do understand that the intensity of the topic calls for a 45 minute talk but practically would the audience be attentive for 45 minutes especially when audience interaction for this topic may not be much. What are your thoughts?

    Thanks and Regards,


    • Howard Deiner
      By Howard Deiner  ~  4 years ago
      reply Reply

      Hi Fincy!

      First of all, thank you for thanking me.  :-)  I am really jazzed about this topic and related ones, such as Microsoft Pex and auto generation of edge case unit tests.

      There are several YouTubes out there with me presenting (including some Agile India ones).  But I do have a favorite, I think.  https://www.youtube.com/watch?v=ZrVNlxSmREY  A couple of minutes into the presentation, I said some words to the effect of "... and that four letter word called governance...."  Unknown to me, this prompted Seb Rose into a long series of tweets of the presentation, starting with "Governance is a four letter word."  I spoke to Seb about this last week, and was all smiles.

      Based on the short demo I did last week at Software Architect 2015 in London, I'm pretty sure that demoing will go well.  Once I got the audience attuned to what PIT does, I was able to ask them things like "why in the world does this println cause a mutation error?"  Those sorts of comments generated audience participation and interest.  So, I'm pretty sure it will work in India as well. 

      Anyhow, thanks again for your kind words and thoughtful feedback. Please don't hesitate to question more!

      --  howard