I’ve been running a lot of training courses recently and I’ve noticed that once people have chosen where they’re going to sit, they return to that position every day. We are creatures of habit, and some habits seem to form very quickly. If I rearrange the room before the second day, or ask people to change places, no-one seems particularly bothered – they simply go and find another seat. So, having a fixed seating position seems to be a habit that’s easy to slip into, yet easy enough to break.
Other habits are harder to shift. We’ve all probably tried to modify our behaviour using rational thought and wishful thinking. For short periods of time it can even look like we’ve succeeded, but then some stimulus knocks us off course and we revert to our previous behaviour. It’s for this reason (I guess) that members of Alcoholics Anonymous always consider themselves “alcoholics that haven’t had a drink for <some time>” where <some time> can range from hours to years. Avoiding your old behaviour is certainly the first challenge. The next, and harder, challenge is becoming comfortable with your new behaviour. This is as true for our work habits as it is for any others.
The habit that I see many teams having trouble breaking, is the habit of forgetting their quality aspirations when they come under pressure. As deadlines loom I often hear people talking about “adding the tests later” or doing something “just for now”. A lot has been said about technical debt (see Martin Fowler’s excellent post or my contribution to “97 Things Every Programmer Should Know”), but I think many of these habitual, time-driven responses can’t really be considered technical debt. They’re more like ignoring common sense like lighting a fire near a gas leak or operating a chain saw without a chainbrake. As software developers we may not be putting anyone in physical danger, but these old habits guarantee future rework and leave us open to the very real risk that we’ll take longer delivering the work that we’re doing now and that when we do deliver it, it won’t work.
One way to become comfortable with a new habit is to do it lots. Until it becomes second nature. Practicing a new way of working at your day-job is certainly helpful, but since this is exactly where you’re most likely to come under pressure it is often not sufficient. It’s really good to do some “deliberate practice” outside of your work environment. Code retreats and dojos are excellent ways of doing this, but they require a chunk of time investment that many people are unable to commit. I’ve talked about Cyber-Dojo before, but there’s always time to talk about a good thing again!
Cyber-Dojo is an online resource that lets you hone your software development in small increments, from wherever you have access to a web browser. It currently supports practicing in 14 languages, and if the one you love isn’t there, then why not add it! There are 26 exercises to practice on, but you can set yourself any challenge you like, because the only difference between each exercise is the textual instructions page. You can work on Cyber-Dojo alone, or you can share your practice-id and work in parallel with others. Each time you run your tests Cyber-Dojo stores a snapshot of your code, so you can compare how different people solve the same problem and also step back through time to watch the solutions evolve. I’m particularly interested in giving people a safe place to practice behaviour driven development (BDD), so a few months ago Jon Jagger and I added Cucumber-JVM to the choice of practice environment (we named it Java-Cucumber).
Cyber-Dojo is not a place to practice you GUI skills, which disappoints some people, but makes me very happy. Why? Because too many people continue to equate BDD with “testing through the GUI”. The difference between BDD and more technical ways of exercising the system is that BDD scripts should be written using a ubiquitous language that is understandable by all stakeholders, not just the technical team. There should be no need for mediators or translators. The skill that we need to nurture is that of being able to describe meaningful behaviours in a non-technical way, while only exercising that portion of the system that’s relevant. Have a look at this exercise that I’ve created in Cyber-Dojo, which is intended to show how you could grow an enterprise web application from the outside-in, using examples.
It’s hard to change any habit, but once we’ve decided that we want to it’s up to us to make the effort, with the constant realisation that the hacker inside each of us is just waiting to get back in the driving seat. Maybe every day, when we sit down to code, we should say to ourselves “I’m a hacker who has been growing my code from examples for <some time>”
Leave a Reply