ACCU 2009: The aftermath

The ACCU conference is without doubt, the technical highlight of my year. A chance to put down the tools for a while, and spend time with other like-minded developers who care about crafting great code.

ACCU 2009 was last week. I'm now recovering! Every year the conference induces brain overload, and sleep deprivation. I never fail to learn exciting new stuff, to be encouraged to think new thoughts, and to meet interesting fellow developers.

I'm not going to provide an enormous writeup of this year's event here. There are many people who have done such a thing already in their blogs. If you didn't go, then no doubt they'll make very interesting reading.

This year, I learnt that going to bed before 4am does help with the delivery of your session the next day! Perhaps I was not as animated as usual, but I trust my session on Living with Legacy Code was useful.

It's a great technical conference, but it has a wonderful social aspect, too. This year spaces drunk tabs under the table (well, around it, at least) to settle an old score that a game of squash simple couldn't answer: which is God's One True Way To Format. And over the course of the event much money was raised for Bletchly Park, a suitable and very worthy cause.

My thanks go to the dedicated team of conference organisers and administrators, to every speaker, and to the delegates who made the event another incredible success. If you missed it this year, I highly recommend booking a place at next year's conference. I have no idea what the programme will look like, but I already know it'll be good.

Subversion, KDiff3, and Cygwin

Recently I've been doing work in a Windows environment, which is a bit of a culture shock for this Linux/Mac weenie.

As ever, I installed cygwin early on to make my life bearable. I'm not sure how I'd navigate without vim, grep and ctags. Are there actually any IDEs with genuinely useful code navigation?.

To make subversion usage the mirror of my Linux setup, I installed the excellent Windows port of kdiff3. My usual trick is to set a simple svn alias that involves kdiff3 when I need it. Something like:

alias sd="svn diff --diff-cmd kdiff3 -x ' -qall '"

(The nasty -x parameter is a workaround for some problematic kdiff3 invocations on Linux.)

However, the same trick did not always work under cygwin. From time to time, kdiff3 would complain that it could not find a file.

It turns out that this is a subtle problem where cygwin sometimes tries to convert filenames to DOS format before passing them to kdiff3.exe. When it does this, it fails and creates hybrid half-DOS/half-unix filenames. Handy.

The trick to make it work is to create a little kdiff3 wrapper script and use that, rather than kdiff3 directly. The magic rune you need to incant in the script is cygpath.

#!/bin/sh

LEFT=`cygpath -d ${6}`

RIGHT=`cygpath -d ${7}`

LEFT_NAME=${3}

RIGHT_NAME=${5}

/cygdrive/c/Program\ Files/KDiff3/kdiff3.exe $LEFT $RIGHT -L1 "$LEFT_NAME" -L2 "$RIGHT_NAME"

Speaking: Journeys (The loss of a child)

A few weeks ago I spoke at Cambridge Community Church with my wife in a talk entitled Journeys. We spoke about a particularly hard time in our life: seven years ago when we lost our beautiful 12 week old baby girl in a car crash.

Perhaps this is a slightly unusual (and somber) topic for this blog, but if you're interested in our deeply personal and unashamedly Christian viewpoint on the loss of a child, and the importance of our faith, the support of friends, and the church family then you can hear the pair of us speak here. We begin speaking about 24 minutes in.

In the talk we mentioned the song I played at Jess' thanksgiving service, and a few people have subsequently asked about it. If you'd like to listen, there's a rough version of it available to listen to on MySpace here.

Writing: Beautiful Architecture reviews

O'Reilly's Beautiful Architecture book has been out for a while now and has met some good reviews. May I draw your attention, for example, to the following review in the On Ruby blog, which gives an honourable mention to my chapter, A Tale of Two Systems:

Like most anthologies it has some chapters that different people will like or not. To me, some of the real winners are: Peter Goodliffe's "A Tale of Two Systems", ...

A little appreciation goes a long way :-)

Remember that all proceeds from the sale of this book go directly to charity.

Solo Software Development

Many people have been asking me how life in my little world of Solo Software Development is going. So I figured I'd best just write about it here and be done with it.

The prologue: those that know me will recall that just before Christmas my company laid off my entire office. Except me. I was the sole survivor. Left holding the bomb, as it were. We were using XP to develop cool C++ code.

It's an interesting experience moving from work in a highly social collaborative software development shop to a bloke on his own.

But I'm really enjoying it.

Working on your own presents a developer with a new and different set of challenges. I'm aiming to keep up a very high quality of code, and wherever possible will maintain the XP processes we used for development. Is that possible, and how much has my XP experience changed?

• Pair programming was perhaps the most obvious casualty. Clearly, in a team of one there isn't any pairing. We didn't religiously pair program, but wherever pairing was missing we would always perform a code review. I really, really miss this discipline. The best substitute I can come up with is to carefully go over every checkin prior to committing.
  
• Planning development with stories, tasks, etc is still very useful. I can keep the planning game, and I'm maintaining it all in the same xplanner system we used previously. I've switched down from two week to one week iterations, as that seems to fit my one-person efforts better.
  
• Unit testing. I'm keeping up with this. Without the accountability of other coders sharing the codebase, TDD definitely requires more discipline. It's very tempting to skip writing the tests and just code form the hip. But I've enjoyed the benefits of automated tests for so long, I simply couldn't consider living without them. When I skip tests the code is often incomplete, buggy, or badly designed. My unit tests are the closest to team accountability I have!
  
• Morning standup meetings. These provided a great heartbeat to the weekly development effort, and I miss them. Without this meeting I miss the chance to assess my progress and discuss if I'm still on track or doing the right thing. I've tried to set myself daily goals and reassess each morning, but honestly it's not going too well.
  

Being a one-man-band has given me the liberty to make some sweeping code changes that had been put off for a long time. With the whole team in place as they were too intrusive to other people's work, but they'd been annoying me for long enough that it feels great to purge my demons. I've had the chance to perform a lot of overdue tidying up of the code, the design, and restructuring of the file structure and build system.

There are many pros to my situation: for a start, I still have a job. And I get to work on good code, and I get to ensure that it stays good. Oh, and no one complains when I play music very loud.

There are many cons to Solo Software Development, many of which I will have to adjust to or work out ways to deal with:

• No one to talk to
  
• Motivation is harder to get; you have less accountability
  
• No chance to learn tips and techniques from peers
  
• Trips to The Wrestlers have taken a hit
  
• Getting "stuck" on a gnarly problem halts the entire development effort, not just one person's tasks.
  

And many things are just plain different. For example:

• Version control discipline is different. I needn't always create a branch for a piece of work. No one else is going to mind when I shuffle stuff around on the trunk. (That doesn't mean branching isn't valuable)
  
• I'm spending longer on the phone to the managers in the US. My working hours are consequently changing.
  
• I'm liaising with people I'd not have talked to before - service providers, estate agents, admin and finance people.
  

I'll be honest, work on my own isn't ideal, but it's not turned out as bad as I expected it to.

It looks like I'll be moving on to some different projects shortly. This will serves to highlight how good our old code was, but it's good not not get stuck in a ghetto.

And I'll be moving office soon. Sadly, to something less palatial.

Code: File structure matters

When working on your software project, how much thought do you give to the shape of your project's file structure?

Many people plug away within their IDE of choice (most commonly Visual Studio or Xcode, but perhaps Eclipse or somesuch). They accept the default file structure imposed on them by the tool. Depending on the size and nature of your project this may be sensible. It may not.

I've seen gargantuan projects managed like this with thousands of source files in one directory. If the IDE provides a mechanism for drawing logical hierarchies of files, but leaves the filesystem in a mess does it matter?

Yes, it does.

Good file structure makes working with your project easier:

• Managing/viewing code changes in source control is sensible, especially when you're using tools outside the IDEs limited set.
• Introducing a newcomer to your project and showing them the structure is easier.
• Using other build system is easier, perhaps significant when porting the code to another platform.
• Navigating around the project outside of an IDE is easier.
• It's easier to see old files that are no longer relevant and that can be deleted.
• Keeping a tidy house encourages code quality in many other areas.

At the most basic level, I try to maintain these principles for file naming:

• The file name matches contents of the file. Essentially, there is only ever one class per file, and the file reflects that class name. E.g. ClassName.java, or ClassName.h and ClassName.cpp)
• Directory structure matches namespace/package names. E.g. Foo::Bar::ClassName is in the file "Foo/Bar/ClassName.h"
• Tests are kept in consistently named files beside the corresponding source files. I create a tests subdirectory with a test file of the same name as its testee. E.g. "Foo/Bar/ClassName.cpp"'s unit tests are kept in "Foo/Bar/tests/ClassName.cpp"
• For libraries, I keep the public header files in a covariant source tree. Internal "private" header files are therefore clearly distinguished from public heeaders. E.g. "include/Foo/Bar/PublicClass.h" with implementation in "lib/Foo/Bar/PublicClass.cpp".

The naming and location of derived built files (e.g. object files or java bytecode) is another thing. These days I like to keep another covariant tree containing object files. The trees are separates by target platform name and build type (release/debug/etc).

What rules do you follow to name and structure your software project? Do you know how to configure your development environment to change the default locations of files? Do you think this matters at all?

Software: Dropbox

This week I was given a referral to try the beta version of Dropbox. I was impressed.

Dropbox is a simple file synchronisation service for multiple computers. It's your granny's rsync, if you like. Installation is simple, as is signup. You point the software at a magic folder that it will keep in sync with every other computer tied to your Dropbox account. It's simple, fast, and works well.

The free version offers 2G of space. You can pay for more, if you need it. If you're not on a machine with Dropbox installed there's a web interface for you to access your files.

It's working really well for me. I'm working on my presentation for this year's ACCU conference, and Dropbox is making my life easier. Rather than carry around the presentation with me to edit at work or at home, I just save it in my Dropbox folder, and the latest version is ready for me to edit wherever I am.

Check it out.