My apprentices are James Hunt and Richard Patching, both excellent and talented developers who joined Eden straight from university in 2007 and 2008 respectively. They’ve gained a lot of experience and skills already, and I’m really looking forward pushing them far beyond their comfort zones to be the best software craftsmen they can be.

They’ll both be blogging about their experiences: this blog will carry their posts also in the future. Mentoring others is not something I’ve done explicitly before, so I also intend to blog occasionally about lessons learned.

James and Richard’s first task was to present a software kata implementing the Binary Chop algorithm in Ruby and RSpec, using Test Driven Development to find a solution. They have two weeks to prepare. I’ll let you know how it goes…

As those who have visited the little Granary office know, we’ve been too big a company to fit in the space for about six months. It’s been our home for the last two years and we were fond of the beautiful views and walks, but we were very ready to move somewhere new!

The new office is four times the size of the old one, with four distinct areas that we’ve separated into workspace, café, meeting room and training/pairing room. It’s in the centre of Winchester, only five minutes walk from the train station.

Here are a few pictures: Part of the main workspace:

The café area (still partly unfurnished)

The meeting room.

The whole set is on flickr here. You are very welcome to drop by: just give us a call to let us know you’re coming!

Tris and Richard did a multi-user dungeon game using Rails, Javascript and Juggernaut: The Fall. It was impressive and extensible. It was cool that it was already responding to multiple players by around about lunch time! They did a great job on the user interface.

Chris worked on an integration system between multiple contact lists. Big City. The demo example was between Highrise and Google Contacts. The synchronisation didn’t quite work, but we could see its potential.

Enrique and Steve made an ambitious framework for customers to put features into git with scenarios and steps. Gourd. It will link up with projects and iterations, storing the features safely until it is time for them to be automatically inserted into the filesystem for the appropriate iterations.

Todd spent the day learning how to make iPhone applications, and successfully followed a demo app known as “Whoops, i broke my iPhone!” which made us all laugh … at least 3 times! ;)

Spencer did a useful Sinatra app to help people send HTML-formatted emails. Easymail. I think the idea is to write an HTML template, and then use the tool to add in content. It handles inline CSS and multipart correctly without any fuss.

I (aimee) wrote my first Adobe Air application. Pomo. It is something like the OSX pomodoro application. Not having found a suitable Linux equivalent, i thought i’d write my own in Air to make it cross-platform.

I think we all had a great day, learnt a lot of new things, and enjoyed seeing what we’d all managed to produce at the end of the day. Which is your favourite idea? All these projects are open source, so if you’d like to help out, dive in!

The result? Sing Pomodoro:

It’s a little app to track just how well your pomodoros are going. It’s not much right now, but it does have a rather useful README on github which explains how to hook up to its API. You can easily use it with Pomodoro.app on the mac, which is how I’m currently using it.

All it currently does is track Pomodoro timings. We could do with some ideas for which statistics would be most helpful to people. Feel free to fork the repository and commit away!

Recently I had the great fortune of discovering a movement of like minded people, whose ideas, ethics, principles and practices were extremely similar to my own, and everything that I’ve attempted to build into Eden.

The Software Craftsmanship movement has existed for only about a year, but during this time has brought together a community of several thousand people with a common philosophy about software.

So what is it? Amongst many things, it is the realisation that creating software can be very helpfully described using a craft metaphor. A few highly skilled craftsman can create wonderful applications with higher quality and faster delivery than ten times the number of average programmers. It focuses on teaching and training very highly skilled individuals rather than enforcing a process to counter the mistakes of mediocre developers. There is much more focus on relationship and personal commitment to delivery.

For more, I encourage you to read the manifesto and especially Pete McBreen’s prescient 2001 book.

Now, I’m not a fan of cargo cults. I’ve seen many come and go. The reason this isn’t bandwagon jumping is simply that we now understand to a greater degree who we are and where we belong. I’ve been espousing this metaphor since starting Eden five years ago – I even wrote a paper entitled ‘The Master Craftsman’ shortly after founding the company. The ethics almost entirely match our existing statement of values.

That’s not to say we don’t have much to learn. This is exciting because we’ve been walking a similar road for a while, and it has often felt like a lonely journey. It’s fantastic to realise there are many others walking with us. I am especially grateful for those ahead of us, who can teach us, mentor us and help us to improve. We have been given a new, useful language to help describe our company, our ethos and our aspirations, along with a well trodden path ahead of us to make the way forward easier.

Software Craftsmanship is now even more part of our company because of a wonderful meeting of minds that happened a couple of weeks ago. Corey Haines and I spent a bunch of time together at BizConf in August, and he introduced me to Enrique Comba Riepenhausen. We chatted via twitter a few times and agreed to meet up in London one Wednesday. By the end of the week we’d offered him a job, and he’d accepted. Enrique has been involved with the craftsmanship movement from the early days and I’m humbled and privileged that his journey has brought him here.

What metaphors have shaped the way you think about who you are, and where you belong? Do you agree with the analogy? We’d love to hear what you think.

We’re going to be blogging more about craftsmanship in the future: watch this space for updates.

We spent an hour or two showing him around our company and processes, and then several of us went out for a long lunch. Along the way we had some great conversation and some useful insights:

A few small things (amongst many) that I picked up from our conversations:

Hire passion over experience: I’ve already been doing this, but it’s nice to see it underlined so strongly.

An apprentice model works: Bob takes on an appentice once every few months for several weeks: often someone locally known to him, or a member of his family. Pairing with an experienced mentor is the best way to learn your craft. You don’t charge out an apprentice, although they’re often a very good pair and help round out the team. People are also more disciplined over their practice when an apprentice is in the office, and it’s very rewarding for everyone to be able to pass on skills. I’m very excited by this: the idea of being a ‘teaching company’ really appeals.

Break the link between the persistence and the domain: Rails (and specifically ActiveRecord) gives us a lot of nice things, but one unwanted gift is a mentality that the domain layer should always be wrapped up in the persistence of that domain. The application objects really need to be as far as possible from the persistence layer: indeed, it’s much better if they don’t know how they’re persisted. We’ve run into this problem more than once now: next time around we’re definitely going to take this more to heart.

Good programmers should be language agnostic: We already know that programmers need to learn a new language every year – it should be easy to be move fluidly between them. We talked about running coding dojos during a day in three radically different languages: say, Java, Clojure, and Erlang? As an aside: wouldn’t it be great to get a bunch of people together for just coding dojos as a training workshop day? This could be a real boost to people trying to learn the craft, and good practice for the more experienced people… if you want to help kickstart this or know of something like it lets talk.

And finally:

The number of times you have to say “No” to your customer is a measure of the deficiency of your design: Think about that one for a minute…

If you’re in the area and fancy stopping by the office, get in touch: our doors are open and we love great conversation!

The aim of the game is simply to reach the coordinates, with possible side effects being the opportunity to get out, see new places, meet other people doing the same thing, play games at the geohash, etc.

On Sunday 30th August 2009 something very exciting happened: the geohash landed at Barton Farm, right next to the office of Eden Development! This was especially exciting since I (Aimee) am a keen geohasher! I came home early from my weekend away in Essex, and 4 geohashers came to celebrate!

We had to photograph the location for documentation purposes.

Chris very kindly let us have a geohash celebration party in the office!

I did a little tutorial on the whiteboard about how the geohash is calculated, and how it ended up on Barton Farm.

We printed and laminated a poster, showing us celebrating the geohash! Hopefully it’ll stay there for a while to come!

Here is a video montage i’ve made, with animoto.com:

For more information about the day’s events have a look on the geohashing wiki: wiki.xkcd.com/geohashing/2009-08-30_51_-1

Photography Seminar

The Content: There were four tracks, which surprised me for such a small conference, but after a while I realised that it was a deliberate play to get the numbers in the seminars down. It worked: every seminar I went to was interactive and interesting. I especially enjoyed the Improv seminar with Jesse, and the photography seminar with Duncan Davidson (pictured above). Most conferences I end up at are very tech-focused, and it was refreshing to try some different things.

Three hour impromtu Jerry Weinberg hallway seminar

HallwayConf: the conversations in the hallway are in my opinion the best bit going to these things. In this case, the speaker/attendee ratio was 1:2, which meant that the level of conversation was the highest I’ve experienced at any conference. We talked agile (small ‘a’ :-), ruby, business, cashflow, hiring, pairing, solving intractable world political issues over scotch, you name it. There were no cliques, and everyone listened as much as talked. Everyone threw a few thoughts into the mix, and collected some great ideas in return.

Jerry Weinberg and Corey Haines

Jerry Weinberg: talking and listening to Jerry was humbling. It’s so easy to forget your years and think you’re some hotshot, whereas actually with my paltry decade of experience I’m at the very beginning of my professional career. I’ve a lot to learn and had an amazing opportunity to rethink many of my own ideas in the light of hard earned wisdom.

Five hours for breakfast

Perhaps this experience sums it up: I went down for breakfast the day after the conference at about 9:30am (my jet-lag got me up rather earlier than expected after a great after-party). People drifted down at different times and we all got talking. And talking. The conversation continued right there in the restaurant for another five hours: I stayed so late after breakfast I got hungry again and had lunch too. I only reluctantly left to catch a plane. Nobody wanted it to stop.

I started some great friendships with some fantastic people and I’m looking forward to continuing the conversation, starting now. I’m only beginning to realise how much I’ve got out of it now I’m back in the office: a decision I’ve been putting off now appears obvious, my head is buzzing with ideas, and I feel inspired to raise my game even further.

Thanks to Obie for hosting and the Hashrocket guys (especially Jen and Jim for doing such a great job). I’ve put together a reading list of some of the books that were recommended here.

Specifically, this blog post at Pragmatic Automation caught my attention: I really liked the idea of being able to listen to complex systems such as a project management flow. Wouldn’t it be cool if you could control a varied soundscape with, say, Jabber messages?

So after four hours of hacking late last night, Jabbersonic was born.

It’s pretty easy to get started. If you’re on a mac with iLife installed it should work out of the box:

sudo gem install gosu xmpp4r-simple
git clone git://github.com/ChrisMDP/jabbersonic.git
cd jabbersonic
bin/server  

This will kick off a gosu app which will listen for Jabber messages sent to the provided account and play different sounds corresponding to different events. An example of usage:

Jabbersonic in Action

It’s currently set up for a continuous integration system – it should be trivial to make the Hudson Jabber plugin talk to it, and write a tiny API app for Hoptoad for example. It’s not confined to project management though: there’s a simple configuration file which allows you to make it work for pretty much any complex system you might want to model.

For more information, see the README. Opinion is divided here as to whether a soundscape is actually useful for project management or just an irritation: I guess it will mostly depend on the sound design, but we’ve yet to try it out properly.

Let me know if you try it out, or use it for anything useful.

I invited Liz after meeting her at the BDD workshop I ran last week. We were very lucky that she was free and available at short notice. I felt we had a pretty good agile system set up here, but we’d not scaled it to a larger team (6+) before and we were coming up against issues (such as the best ways of estimating) which we felt Liz could help us with.

It’s been enormously beneficial to have Liz with us. Much of our practice were validated: pair programming, co-location, BDD, outside-in, continuous integration. These are core tenets of our process which have been proven in many companies. Instead of changing our basic practice, Liz has helped us to the next level through much conversation and discussion.

Here’s a few snippets of what we’ve learned and how we’re tweaking our process to give our clients the maximum number of features with the shortest possible lead time.

Use Feature Injection to force the value question

One small change with big ramifications is the concept of Feature Injection.

In brief, this means changing the way you write stories so that instead of having:

As a 
I want 
so that 

You have:

In order to 

will need
.

Rather than just a way of specifying technical stories, we realised that by putting stakeholder value first, we are forcing the question of what’s actually necessary about this feature that causes us to do it in the first place. This ties our stories very much to stakeholder value, which ensures that everyone knows exactly what value is being provided when they’re working on a story.

Read more about Feature Injection here.

Keep completed stories visible

Once our stories are clearly about stakeholder value, it’s important for everyone to see exactly which features currently exist, preferably broken down by stakeholder. We’re working on ways of getting the features list that we’ve already completed more visible to our clients. Once everyone can see what’s been delivered so far, it’s much clearer what should be worked on next.

One way of doing this might be a small Rack app which handles /admin/features and returns all the features grouped by tag… does anyone know of a Rails plugin that might do something similar?

Ensure you can always release

If we’re truly doing BDD, then we are delivering tiny slices of functionality that can be released immediately. Often we batch these into releases, often accompanied by a rather laborious and crunch-like polish process.

However, there’s no reason that we shouldn’t be ensuring that the site is release ready at any point. If this is the case, the stakeholders have the option to say “Done – ship it!” whenever they like, and we’re able to do this straight away, rather than after a three week polish + skin period, and the dreaded IE6 compatibility check.

Lesson learned: Get a site release-able as fast as possible, and keep it there.

Put performance tests in the build

As developers we are always concerned about timing our performance improvements. How do we balance over-optimising a site with doing performance testing too late and risking a meltdown? How do we ensure that performance is kept at an acceptable level?

If the goal is to always keep a project release ready, then we need to ensure that our new system hasn’t introduced any serious performance issues, which bring it below a minimum performance level. If you are guaranteeing to your client that your site can handle a certain level of traffic, then anything that breaks that effectively breaks the build. Therefore, what better way to do this than make your performance tests part of your build?

And there’s more…

I plan to blog further about some of the other things we learned: including the major insight about the benefits of a Lean approach, which is worthy of its own post.

Do you have strong opinions about the above? Do you disagree? Let us know!