Life, Liberty, and the Pursuit of Agility

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?

Here is a link to a nice little article on the idea of Interuption Driven Development by Vikas Hazrati at InfoQ: Interruption Driven Development

Vikas discusses the situation where a team needs to work on unplanned bug fixes and other “emergencies” during a Sprint thereby diminishing the value of following the Scrum methodology.  Here is the situation he describes:

Scrum talks about having minimum disruptions during the sprint so that the team can work effectively in achieving their target. The Scrum master, is responsible for removing those impediments which might hamper the velocity of the team. However, in a practical situation, when the team is churning out deployable increments of functionality, they have to support production issues along with new feature development. These interruptions, might seem like a disruption to the team but they are important impediments to the system users and the product owner. The product owner, would not see any value in adding new functionality to the system if the existing system is not working fine.

He covers a few approaches to dealing with this scenario.  It is a good, quick read.

Jason Kerney and I are going to once again present our NMock2 Exploratory techniques presentation.   This time at the XPSD meeting on April 3rd.

See their site at XPSD.org to get the details on the group… or just read this which I just copied from their site:

Meeting Information & Location

XP San Diego meets the first Thursday of each month to informally discuss and exchange ideas. We feel we learn best from our peers, the merely curious, active practitioners, as well as experienced consultants, when they share their skills, knowledge, concerns and experiences. We encourage everyone to participate in our monthly forums and learn something new. We meet on the SAIC Corporate Campus from 6 PM to 8 PM; 10260 Campus Point Drive, a.k.a. Building C, in the fifth floor conference room. Please find parking on the street and check in with security in Building C before heading upstairs. See our mailing list (http://groups.yahoo.com/group/xpsandiego/) for more information.

Here is the synopsis of our talk:

“A Little Taste of NMock2 For That Smooth, Relaxing, Unit-Testing Flavor”

We’ll explore how the NMock2 library makes it easy to remove dependencies and test behaviors in unit tests, allowing you to quickly set up tests that confirm your code does what you want it to be doing.

This code-intensive presentation covers the motivation for using Mock Objects, and once we have covered the basics, we’ll show our unbelievably effective technique for using dynamic mock objects as an exploratory discovery tool for introducing characterization tests for “legacy” code (that is, code without sufficient tests as described by Michael Feathers).

NMock2 is a free, open source dynamic mock object library for .NET that can help you isolate the target and test only the localized functionality. This is very easy to do, and you can be up and running in just a few minutes. Mock objects can give you years of trouble-free pleasure that you otherwise miss out on if you don’t come to this presentation.

I hope that you can make it, or to some future meeting of the XPSD.  I always learn a lot at the XPSD meetings – the people that show up are among the best XP/Agile folks in the country. 

The Fullerton Code Camp was a big success, as far as I could tell.  I attended at least 4 or 5 presentations (besides the ones that I as presenting myself) and was impressed with the quality of both the speakers and the content.  Unfortunately I could only attend a few of the dozen or so I wanted to see.  Here are a few short reviews of sessions I was able to see: Continue reading ‘SoCal Code Camp – Excellent Weekend’ »

I’m doing 3 talks – maybe more – at the SoCal Rock & Roll Code Camp this year January 27 & 28th, 2008, at the Cal State Fullerton Campus. 

Agile Development Basics  – In this presentation I cover the Agile values and principles, as well as the a little about why we need something like Agile.

A Quick Introduction to Scrum – Here I’ll present the who, what, and how of Scrum.  Scrum is one of the most common methodologies for managing an Agile effort.

Agile Coding Techniques for Legacy Apps – This talk shows various techniques for introducing unit tests and micro tests into an application that has insufficient tests. 

Last year the Code Camp was a lot of fun with a lot of great presentations and get-togethers with fellow developers.  I’m looking forward to seeing everyone again and learning a lot of new, useless stuff.

Okay.  I guess I am going to have a blog, at least for a while.