Forty Days of Fixing
2 June 2014, by Hereward Mills
Writing good code is hard.
We all have an idea of the ideal codebase: clean, SOLID code; fast, easy to maintain unit tests; well structured integration tests… The list goes on and yet the reality of most projects falls short of our high expectations in some way.
A project I work on has a lot of technical debt. Some of the problems are large structural issues that are just too risky to fix. Others are really tiny niggles: commented out code, spelling mistakes… As a team we try to tidy up as we go along (Uncle Bob’s Boy Scout Rule) and we have made some progress in cutting back the weeds: classes have been tidied, methods refactored and tests added. Progress, however, is slow and away from the bits of the code we tend, the undergrowth is still thick and impenetrable. Time to put away the secateurs and get out the bush knife.
Back in March I issued a challenge to Softwire to clean up their code; to take up a challenge over Lent instead of giving something up. Forty days, forty fixes: small or large, to your own code or someone else’s: the only requirement was to do a little bit every day for forty days. Surely that would be achievable? It could not be that difficult.
Turns out: writing good code is hard. Writing a little bit of good code everyday for forty days is really hard. No one completed the challenge without some degree of cheating: doing fixes the day before, the day after or even pulling in two year’s worth of gradual refactoring as one of the forty days. For some day to day life got in the way: holidays, illness and childcare all took their toll. Many of us found it difficult to keep our fixes small enough (an hour is not that long for all but the simplest of fixes) and others just found better things to do with their time.
This does not mean the ‘experiment’ was a failure. Over the forty days a lot of things were fixed that might otherwise have been left undone: forms were commonised, application internals overhauled, lots of unused classes and files were removed, tests were added, small improvements suggested, classes greenified and over 100,000 lines of never-run, broken tests were removed from one legacy codebase.
Forty days of fixing was not easy; we struggled to keep motivated and make those fixes. But we should not be discouraged: every fix we completed was an improvement on what was there before. The code become clearer, the cruft was removed and a test was added. Each fix was something we should be aiming for every day in both our professional and personal work. Next time you have a spare few minutes or are embarking on a change to an existing system remember this: what can I do to make this codebase a slightly better place for everyone?