Life, Liberty, and the Pursuit of Agility

I like to talk

I was given an opportunity to present a session at the Agile San Diego group last night.  I have some pretty clear ideas about how to be productive in developing software (and a fair number of solid successes in turning out useful software), and those who know me are sick of hearing this stuff.  I am always looking for an opportunity to find someone new to bore.  Thanks for stopping by. 

Agile Success seems elusive

Over the past 13 years I’ve been using (or sometimes fighting to be allowed to use) an Agile approach in software development.  For about a year I have been slowly gathering my thoughts into a talk on Agile Success.  I’ve given about 5 talks on this theme now – each very different, and the audience has mostly been folks new to Agile thinking.  

Agile San Diego is a group of highly sophisticated Agilists who are typically expert debaters and highly competent loud arguers –  I like it very much.  So I took this opportunity to solidify my materials and put it to the test.  The results were so-so, IMHO, but it is in the doing of a presentation that I discover the presentation that I must do.

Agile Success – Why Not Me Too?

In its current state, the talk is called “Agile Success – Why Not Me Too?”.  It’s mostly about the “Why Not”: we tend to block ourselves from achieving good result by hanging on to “old and busted” thinking and practices.  Perhaps we do this because the old ways seem so right (but they are oh so wrong) , or perhaps just because we are comfortable with them, or “our customers (or boss, or manager, or marketing) require it”,  or … well  – there are a lot of reasons we keep doing things the same old way – you get the idea, I am sure.

For this instance of the talk, my main goal was to show that we are typically our own worst enemy.  More specifically, it is the things we think are most solid, meaningful, useful, and productive in our process that are the most likely to be hampering our progress and wasting our time and money – and we don’t have the skills or openness or whatever to recognize this.  In other words, those are our blind spots. 

The Maxims

Here are my three main talking points.  I call them Maxims (to differentiate them from the Values and Principles):

Critical Maxim 1:
It is in the doing  of the work that we discover the work that we must do.

Critical Maxim 2:
Embracing change is IMPOSSIBLE if your code is not Easy to Read, Easy to Maintain, Easy to Grow, and Easy to Change.  Everything else is secondary.  Everything.  This applies to “lean start-ups” too!  Code becomes HARD really fast – often within a few hours if we are not paying attention.

Critical Maxim 3:
Question Everything

In my own work, I use the Agile Manifesto and Principles as a guide to evaluate everything.  I use them as a quick sanity test for every practice that I am using or thinking of using.  However, I also recognize that I am the inventor of the process I follow, and therefore use the 3 Maxims to keep from getting off track. 

Using Maxim 3, I also question the value of the Maxims and the Agile Manifesto/Principles themselves.  It is a vicious, never-ending continuous loop of vicious, never-ending continuous loop of… – so I don’t get too serious about it.  Whenever my brain starts bleeding I take a break, let things coagulate, and then get back to it.

Also, the 4 values, 12 principles, and 3 maxims are not written in stone.  It is likely that there are other important missing maxims/values/principles, and there might be errors and partial omissions.  But this is a living thing – adjustments are allowed – cells split, some things become vestigial – and so on.  Complete re-writes are allowed.  Nothing is sacred.  Continuous improvement must include improving the things we improved previously and think can’t be improved.  Throwing some things out and letting other things die off is okay.

The talk took less than an hour, plus about 1/2 hour for discussion.   Not bad for solving all the problems that ever were or ever could be.  Well, no one else saw it that way, but this is my blog and I can make up anything I want.

However, what I was trying to show is that my current thinking (which is based on real, every day cranking out of healthy, usable functionality) is that:

• most development efforts are chock-full of harmful practices that we hold sacred yet are massively wasteful or even counter-productive
• that we are the cause of most of the problems
• and there is a way to make things better.

I won’t cover the rest of it here unless enough people actually ask for more.  That has never happened yet, as I don’t think anyone reads this blog, and most people who attend my talks spend most of the time trying to find a way to respectfully withdraw. 

The most important thing:

For me, acceptance of Maxims #1 & #2 gives a clear way to evaluate 90% of the badness I have encountered in software development.  They are on an equal with the Agile Principles in the way I use them.  Maxim #3 keeps me honest about Maxims #1 & #2.  I have another 3 or 4 slides on Maxim #3 that guides the questioning process.  Perhaps I’ll write about that sometime soon.  It is not the 5 Whys, and I don’t think there is a Japanese word for it either.

There you go. 

Have a nice day.

I’ve signed up to do a few talks at the upcoming SoCal Code Camp at Cal State Fullerton.  You can follow this link to see the details of all the talks (including mine):

SoCal Code Camp Sessions

The date this year is January 29/30, 2011

This year I’ll do at least a couple presentations with Llewellyn Falco:

• A Coding Dojo
• Core Agile Development Values

And I’ve signed up to do a shortened version of our Code Excellence talk:

• 10.5 Easy Code Excellence Techniques

My talks are always fun and a good learning experience (for me).  If you happen to have a little free time and are in the neighborhood of Cal State Fullerton in late January, please stop by and pretend to enjoy yourself.

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?