Due to various realisations recently, I’m coming back to coding day to day, which is very cool. For some practice, I thought I’d try my hand at a little Sinatra, fully TDD’d, running on heroku for fun.

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!

It’s the sort of thing that doesn’t happen as often as it should.

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.

Bob Martin (universally known as Uncle Bob) swung by the Eden Development office to see us today. He’s in the UK for a short period on holiday and we were lucky that he was free to make the trip down to Winchester to meet us.

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!

Geohashing is a game, best described as a random adventure generator! It combines the Dow Jones stock market index with the current date, performs an MD5 hash function, and converts from hexadecimal to decimal coordinates in order to generate a series of geographic coordinates all over the country. There’s usually a geohash within about 50 miles of your location, and it changes every day.

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

So, BizConf. A conference for people who do business on the web, with only 75 attendees, Florida, 20-21 August. It was a stretch to go that far, but it was so worth the trip. Some highlights for me:

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.

I’ve been working on improving our build process recently and have been inspired by several articles on Extreme Feedback devices.

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 <myjabberaccount@myjabberdomain.com> <mypassword>

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.

We’ve had the great pleasure of having Liz Keogh doing some agile coaching with us for the last two days.

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 <role>
I want <feature>
so that <benefit>

You have:

In order to <deliver some business benefit>
<these people>
will need <these features>.

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!

A couple of days ago I ran a BDD workshop the day before Rails Underground. Skills Matter videoed the event and will provide the podcast + slides here, but if you’re impatient download the slides here.

I really enjoyed doing my first talk about Ruby/Rails – teaching it was great fun. Even though I’m sure we can improve further, we get a lot of value from BDD, Cucumber and RSpec and it was good to pass that on and give something back to this excellent community.

The workshop was free – if you got something out of it please make a donation to the Red Cross through the Rails Underground donation page.

Update: the video is now available here. If you were there, there’s a rating and feedback page for it.

Rob Dempsey posted an interesting article a little while back on the future of software development firms in the new economy. It discusses offshoring, the recession, and a shift towards the employment of permanent staff within companies for Ruby on Rails work.

This is the sort of thing I muse about all the time: I keep a close eye on the web development market to ensure Eden is still in a position to add real value to potential customers. The results are important for deciding what we want Eden to look like in the future.

Ultimately, I want any decision to use Eden to be the best decision for a customer’s business. If it’s not, I prefer to point people elsewhere. So how do some of the indicators Rob mentions stack up against our business model? Are we still the best decision a customer can make?

Offshoring still a way off

The rise in offshoring development doesn’t particularly worry me. I’ve worked with offshore agencies before and there are some excellent companies out there, but the distance and the communication issues do present barriers to the addition of value. The price is lower, but the value added is commensurate.

If the spec is very (very) clear then I think that an offshoring project could work: but the risks are high and difficult to mitigate. I would hate to tie down any of our customers to a particular spec, which is why we always work in an agile a fashion as possible. It’s easier to manage risk with an agile process and to do agile well you need very clear communication pathways.

Bringing it in-house

I have also noticed a move to using permanent staff and in-house contractors to get websites built. The pool of people with Ruby on Rails skills is growing and there’s often no need to hire a contractor at a distance.

However, hiring a big experienced team takes time and the best people are difficult to find. My experience leads me to believe companies will always look to specialist development agencies to get larger jobs started quickly, and to ensure they’re done to a certain standard. We have a number of customers to whom we’ve provided development services in this fashion, often as a kick-start to an in-house team in the process of being hired.

Shifting our focus

We have had to make changes recently: I realised a few months ago we needed to shift our focus away from smaller projects, where the scope was tighter and contractors or offshore teams could price us out of the market. We grew the team to the point where we’re no longer a small group of coders with our own small independent projects. We’re now a well functioning cohesive development agency, taking on larger projects in bigger teams.

We’re looking to diversify too: we’re full of ideas for new web applications we’d just love to build, and we’ll be making some time over the summer to kickstart some prototypes. Watch this space.

Web developers: we always have to be thinking about the market we’re in, especially one as fast moving as ours, where things seem to change by the week. What are your thoughts on the ever-moving web development market?

I’ve just finished updating the website to let you know we’ve been working with the BBC for the last three months on updating an exciting internal project called MOO.

This has been an exciting project to work on and a lot of fun. There were some pretty big technical challenges on the way, but I’m very proud of the team: they really rose to the challenge and delivered some excellent work.

Read the full case study here for more details on what it’s all been about.