Life, Liberty, and the Pursuit of Agility

I’ve had the great fortune lately to have a little extra “uncommitted” time to spend exploring things that I’m interested in.  On the top of my “to be explored” list is Approval Tests.  I’ve been using it a bit over the last few months, but haven’t had time (until now) to dig deeper.

Approval Tests is an open source project with the purpose of providing a very simple way to solve some difficult testing problems.  For example, one thing that Approval Tests makes easy is to provide characterization tests for legacy code.

I use characterization tests to lock down the existing behavior of code I need to work on - in other words, it is a test that proves the code does whatever it is currently doing so that I can refactor and clean it with confidence that I won’t accidentally change it’s behavior.

I first came upon the term in Michael Feathers amazing book (Working Effectively with Legacy Code), and have commonly used mock object frameworks to implement my characterization tests.  However, that can be a complicated and time consuming process, and can sometimes require some refactoring to modify the code so it can be tested.  Usually these are very safe refactorings - but can still introduce bugs.  Another issue is that coverage is typically very localized to the method of interest and perhaps a few depended-on objects.

Enter Approval Tests:  You get a lot of bang for the buck.  For example, in one of the presentations I do (Code Excellence for the Average Programmer) I show how a real life project that had become impossible to maintain or enhance was revived using very simple code-cleaning techniques.  It only took four unit test methods of a few lines each using Approval Tests to introduce sufficient code coverage to be able to confidently work on the project.

The essential concept of using Approval Testing this way is to allow the code you want to test to produce a result that you then capture by “Approving” it (which saves it).  This approved result will then be used when you run the test to verify the results.  Whenever anything changes, the test will fail and you’ll be shown the differences.  Sounds simple, doesn’t it?  And it is!!!  Approval testing has a number of other uses, and perhaps I’ll have a chance to write about those sometime soon.   I bet you can’t wait.

I encourage you to take a look the next time you get a chance: Approval Tests.   The Approval Tests project was invented by Llewellyn Falco and Dan Gilkerson, and they invite your suggestions and help on expanding and improving it.  Also, they have a talk they’ve been doing at various conferences and code camps.  If you get a chance to see it I am sure you’ll find it an eye-opener.  The next scheduled presentation is at the Silicon Valley Code Camp, and it’s called “Unit Testing the Easy Way”.   I’ll be helping out on that one since Dan can’t make it, and I’m really looking forward to that.

Lately I’ve been partnering up with Llewellyn Falco doing a presentation we call “Code Excellence for the Average Programmer.”  The main theme is that using small steps, simple techniques, and stick-to-itivness we can produce code that is pleasant to work with.  The bulk of the talk is hands-on where we take a real project (slightly simplified) that has become un-maintainable and transform it into a thing of beauty that is once again a living project. [That is an overstatement perhaps, but it isn’t far from the intent of our talk]. We’ve presented it at 4 or 5 developers groups, and at the Fullerton Code Camp. It’s a lot of fun for me, and hopefully it has been interesting and useful for the people attending.

Happiness On The Job

One thing that really struck me during our last presentation at the SDJUG on Tuesday this week is that messy code can drastically reduce our level of job satisfaction.  Somewhere in the middle of the talk I asked the audience for a show of hands if they enjoy working in the code of their daily job.  Almost no one out of 40 or so people raised their hand.  That is, nobody was happy.  So, I reversed the question and almost everyone raised their hand.  That is, almost everyone was unhappy working in the code they spend most of their day with. 

Of course, we can’t blame that dissatisfaction entirely on the condition of the code itself, and we can’t assume that having clean code would make anyone happier.   For myself, however, I can boldly assert that I am MUCH HAPPIER when working on clean, easy to read, understandable code than I am when the code is an obscure, cluttered, and complex maze of cryptic detail.  That has one important motivation for me to learn how to make my code more readable and pleasant to work with. I figure that if I am happier in clean code, then it is likely that others will be happier as well.

Why not be happier?

So, this brings up a question (or two): Why do so many developers put up with messy code?  Why don’t we make an effort to fix things and make our life (or at least a small part of it) better?  There are certainly some constraints that seem to block us and make us feel we can’t do much to improve our code.  I often hear developers say “my manager won’t let me refactor because it is too risky” or “my boss says don’t waste time on improving the code, we need to get this out tonight!”  The fundamental problem with these “reasons” is that the result is probably not a faster fix or less risk, but the opposite: More testing and fixing, and more risk.  Still, these and many other pressures make it hard for us who are writing the code to find the path that leads to code excellence. 

A few ideas on how to make things better

That, of course, brings up the next question: What can we do about it?  How can we improve our situation and still produce under the pressures we seem to be under? 

First: Get Informed. Buy and read Robert Martin’s “Clean Code” book.  Study Martin Fowler’s “Refactoring” book.  Borrow Michael Feathers “Working Effectively with Legacy Code” and don’t return it until you have memorized it.  Get your hands on Joshua Kerievsky’s “Refactoring to Patterns”.  That is a good start.  Get the knowledge and practice your skills.  Even come to a code camp or dev group meeting where someone is doing a session on the subject, or put together your own session and present it at some local group you attend.

Second: Always leave your code in better shape than you found it. Never touch code without making it just a bit cleaner and easier to read. Stop allowing the “quick fix” to increase the clutter and complexity.  It only takes a second to improve the clarity of your code by formatting it properly, or using an intention-revealing name for a new method (and so on.)  Vow to never again add to the mess.

Third: Take baby steps.  There are many simple improvements you can make that no boss or manager can complain about.  Find out what they are and do them.

Fourth: Find like-minded co-workers and discuss this stuff with them.  A whole team working toward cleaner code can bring a more pronounced result.

Fifth: Never give up, Never Surrender.

What do you think?