Working with legacy code

Alastair Aitken 4 September 2013 0

To the best of my knowledge, Michael Feathers has only authored one book, Working Effectively with Legacy Code, which was published way back in 2004. But if he never writes another tome again then his contribution to the enrichment of the library of software development practice wouldn’t be diminished. Put simply, if, as a software development professional, you don’t have this book then, in the slightly hyperbolic words of a German acquaintance of mine, “YOU ARE NUTZINK!”

Working Effectively with Legacy Code defines legacy code as “any code without unit tests”. It’s more than 12 years since the Agile Software Development Manifesto appeared, outlining an alternative to documentation driven, heavyweight software development processes. Yet I’ve lost count of the number of developers (and their accompanying code) that I’ve come across who appear to believe that they are following an agile development approach simply by refusing to perform any design work and by not bothering with documentation. And for many coders their copies of Extreme Programming must have had the bit about writing tests printed in invisible ink because more often than not I still take over projects that are without one single line of test code.

Design patterns, design schmatterns

Whereas before the Gang of Four’s opus appeared many in the industry churned out spaghetti code, this code is now infused an infusion of design pattern spaghetti code – where design patterns are applied piecemeal with little understanding of how they fit into the whole.

But I use FrameworkFlavourOfTheMonth

Frameworks can help but they’re not a panacea if the developer then chooses to ignore the patterns presented within the framework and continues as though a function with thousands of lines of code and a staggering array of dependencies isn’t likely to render a subsequent developer insensible.

Are we there yet?

So, no tests, no documentation, ill-thought out designs, poorly implemented design patterns and a ton of procedural code. It doesn’t really feel we’re making progress.

You’re running out of excuses

I was first introduced to test first development in 2002 during an in-house training session. There were many sceptics in the room and I was one of them. The training material was based upon a simple greenfield simple bank accounting project where it was possible to create a comprehensive suite of tests to cover every eventuality of moving money from one account to another. Attempting to shoehorn the methodology onto the reality of large web forms proved problematic, primarily because the tools didn’t really exist or were way too slow to be thought of as unit tests. Now there is no excuse for not creating end-to-end tests, whether unit, functional or acceptance tests.

Why now? We’ve seen it all before

Why write about Feathers’ book now? Because observing the code that I’m still seeing being churned out, the messages in his book can’t be repeated often enough. Ignore the books written about using agile development on a Noddy project, this one addresses the bread-and-butter situations that you’re far more likely to encounter in the real world.

 

Alastair Aitken (124 Posts)

As a contract developer and manager I’ve worked in a wide range of enterprises in a variety of countries where I’ve encountered everything from great work, awful work, bizarre work, all the way down to quasi-legal work. If you think that you recognise your own organisation within my articles then you’re undoubtedly wrong, where you work isn’t that unique.

Leave A Response »