Cleaning Code – Tools and Techniques for Large Legacy Projects

Here are the slides from the presentation I gave at the ACCU conference this year:


Filed under Uncategorized

Prefactoring re-coined

Two pieces of input struck me this week that caused a bit of a brainwave.  The first stimulus I chanced upon was Michael Feathers’ article on the sloppiness of refactoring, in which he proposes a nice solution to getting the habit of refactoring to completion: do it first.

For every story/feature that you accept in planning imagine how you would implement it if the code was in a state where it would accept the feature easily.  Then, create a task for that refactoring work and make sure it is done before the other tasks for the feature

I like this idea a lot, and I want to introduce it in to the working agreement (how I hate that term) of our team.  This would solve a lot of forgotten refactorings that seem to only be remembered at retrospective time.

The second thing that I chanced upon is The Mikado Method book.  In it the authors propose a method for improving legacy code that begins with determining the dependency graph for the mini-tasks in the implementation, then starting the work at the leaves of the graph (these are the most independent areas of change in task).

What both these approaches essentially give us is a pre-refactoring step in implementation.  I was so excited by both these commalities that caused me to coin the term Prefactoring.  Imagine my dismay at learning that not only Prefactoring was already coined as a term in our lexicon, but also that there was even a book written with that title.  Unfortunately it means something entirely different…


Filed under Uncategorized

Global Day of Coderetreat 2012 – Beijing, China

Global Day of Coderetreat 2012 - Beijing, China

Beijing will participate in Global Day of Coderetreat again this year! Sign up here:


November 29, 2012 · 12:24 pm

Teaching TDD from the ground up

One of the first steps in any embedded software project is to implement an assert macro.  This is true for a few reasons:

  • you have certain assumptions about how the hardware should behave and you want to know when those assumptions are broken,
  • you need a way to signal outside of the custom hardware when something has gone wrong,
  • there is no standard function that can deal with these problems.

This might seem like a wasteful thing for every project to undertake, but actually it is a very constructive place to start.  Firstly, it frames the development around verification.  Secondly, when you find a bug you don’t start printf debugging, instead focusing on adding assertions.  And finally, from the very outset of the project you demystify the black box of your embedded system.

In the same way, I think that the first step in learning test driven development should be to write a testing framework.  And it needn’t be difficult – a simple test framework can be written in a few lines of code.  This is the test framework for testing the fake function framework.

/* Test Framework :-) */
void setup();
#define TEST_F(SUITE, NAME) void NAME()
#define RUN_TEST(SUITE, TESTNAME) printf(" Running %s.%s: \n", #SUITE, #TESTNAME); setup(); TESTNAME(); printf(" SUCCESS\n");
#define ASSERT_EQ(A, B) assert((A) == (B))
#define ASSERT_TRUE(A) assert((A))

It could be even more concise, but I wanted to make it compatible with the googletest framework so I can re-use the test cases in both C and C++ without modification.  Anyway, you get the point.

I am a big fan of testing frameworks, and for sure there is no need to re-write junit every time we start a new java program.  But for learning TDD, I think a lot of the mystery would disappear when participants make a simple test framework and use that to make their first few tests.


Filed under fff, software, testing

Test Seams in C: Function pointers vs. Preprocessor hash defines vs. Link-time substitution

When replacing production C code with test doubles (or fakes), there are three basic approaches: function pointers, preprocessor hash defines, and link time-time substitution.  All three are examples of what Michael Feathers calls a seam, or a way to change the behavior of a program without editing in that place. We use seams when we unit test software to decouple and localise the software under test.  Each of these types of seams has different trade-offs for testing embedded C.  Here’s what I think.

Function Pointers (run-time substitution)

  • + Easy to substitute at runtime for test functions
  • + Makes for more decoupled design
  • – Harder for IDE to jump to definitions, etc.
  • – Can make static code analysis mot work so well

Preprocessor hash defines (preprocessor-time substitution)

  • + Good for getting legacy code under test
  • – Needs discipline to structure the hash defines well
  • – Can make code harder to read and understand
  • – Definitions can be hard to locate because they can be set on the command line (-D), include path, header files, etc and can be overridden at any location

Link different function implementations (link-time substitution)

  • + Good for getting legacy C under test (limited changes needed to production code)
  • – Need to check the link definitions to understand what is running for any given executable
  • – Can’t have multiple implementations of a function in one executable
  • – Can create the need for multiple test executables

You can use the fake function framework to generate the fake functions for testing, whatever type of seam you choose.  It just creates a function and the supporting structure to capture arguments and provide return values. You can find more information about the fake function framework here:


Filed under Uncategorized

Have Your Own Object Calisthenics Refactoring Dojo

We have been having lots of fun at work by having regular coding dojos.  In particular, we have been using refactoring dojos to hone our skills at improving existing code guided by tests.  For this weeks dojo, Juven and I created a particularly crappy implementation of TicTacToe to be the starting point.  Feel free to use the code and associated slides to host your own.  Fun guaranteed!

Further reading:

Leave a comment

Filed under Uncategorized

Hierarchy of Software Needs

What happens when I apply Maslow’s hierarchy of needs to software?
Maslow's Hierarchy of Needs


  • Breathing: There is a user for this software.
  • Sex: It compiles.  Software that does not compile has no future.


  • Morality: It adds value.  Software that does not add value does not survive.
  • Security of body: The software is under version control.
  • Security of health: There are no compiler or static analysis warnings.
  • Security of resources: There are limited signs of broken windows.  Tests, if any, run successfully.  Commented out code is minimal.


  • Friendship: The software meets the needs and expectations of the users
  • Family: Developers enjoy working on the software


  • Achievement: Developers are proud of the software
  • Confidence: tests and quality assurance mean making changes is a low risk proposition.
  • Respect of others: Future developers needs are considered
  • Respect by others: Users and stakeholders trust in the software to meet their needs.


  • Morality: The code is “Good”.
  • Acceptance of facts: The software has executable Acceptance Tests to define it’s requirements.
  • Lack of prejudice: The problem domain is perfectly expressed in the source
  • Creativity, Spontaneity: It is easy and cheap to experiment with the code.
  • Homoiconic?

This may be a flawed extension of a flawed model, but the central point is that before the basic physiological and safety needs of the software are meet it is really difficult to focus on the higher motivations of software development.  This might also provide some clues as to where to start cleaning house on legacy renovation project.

1 Comment

Filed under legacy, quality, software, Uncategorized