15 Applications in 9 months

Posted on Sunday 20 June, 2010 in forward and process

Image from striatic’s flickr stream under the Creative Commons licence

Paul and I recently presented a short overview of how our team of 6 developers was able to deliver 15 applications in the last 9 months. The aim was to highlight the processes our team have evolved during this time and challenge preconceptions about how software can and should be delivered. This Post includes the information from that overview supplemented with many of my own opinions.


Our team at Forward is by far the most experienced I have ever worked with, infested with ex-Thoughtworkers and balanced with members with complementary experience from agencies such as New Bamboo. The most important quality that all the developers share is that everyone really understands the web and has a real passion for technology. As a team we have adopted a very flat hierarchy and the company has shown its trust in us by giving us the autonomy to make our own technical decisions. Perhaps most importantly though we have Carl Gaywood, the definition of a motivated person to build an agile team around.


The projects we have worked on vary from smaller sites such as ukofficeadvisers.co.uk and officeinthecity.com (the latter being written, deployed, and trafficked in less than one day) to applications with a huge feature set like cardwall.co.uk. This application was inspired by agile card-walls and was created to help our agency teams manage projects and collaborate with our clients. Cardwall also provides an interface to many of the other applications we have written. These vary greatly in their requirements, from technical challenges such as spell checking AdWord campaigns across many languages, to large scale problems like downloading and processing tens of gigabytes of data per day. The latter requiring the co-ordinating analytical and statistical checks which run thirteen hundred times daily to provide intelligent notification.

As well as dealing with scale in terms of data and processing, we also needed to provide a service to handle and log the 9,000,000 daily clicks we receive. With an estimated cost of down time of £200 per minute, it has been architected with a geo-distributed high availability infrastructure. It also incorporates a phased deployment strategy that has meant it has yet to experience any downtime.

We are constantly spiking and building new applications. Recent tools we have created include a realtime visualisation of internet search trends and a custom interface to Hive allowing users to generate, run and even automate queries on this data. Alongside this, we have automated SEO checks, produced landing pages and even created an application to view Formula 1 pictures on a iPad.

What did we learn?

Being involved in such a large and varied number of projects in such a short amount of time has required us to be able move fast, maintain a high level of quality, and be able change direction quickly when things aren’t working out. We began with a more traditional agile approach but, in the spirit of constant improvement, have evaluated and evolved, and shed many processes. The following summarises a large part of these changes and highlights some values that helped us achieve this.


In developing these applications we used a wide variety of tools: key value stores; databases; map reduce; virtualised infrastructure; dedicated infrastructure; geo-distributed high availability infrastructure; Java; Ruby; HTML; CSS; Clojure; jRuby; and SQL. We don’t allow ourselves to get locked in to a technology stack, or vendor. Experimentation with tools,frameworks and languages allows for the possibilities of new ways to work, think and solve problems.

Small teams, flat structures

With each application we often split the main team into pairs who manage and run each project. The more people and hierarchy on a project, the more processes are required to keep the team effective. For example, project inceptions are now a 20-minute discussion not a 2-week session without any code. Smaller teams also don’t need processes to aid communication: stand-ups, IKO’s or retrospectives just aren’t necessary when you work constantly with the only other person on the project. Our small, empowered teams, focused on delivering business value, could easily outpace any other teams I have worked in.

Many Hats

An interesting constraint introduced by small teams is that you can no longer just code. You need to be able to talk and interact with other areas of the business to gather and prioritise requirements. Good ‘nix and system administration skills are required to setup and configure servers so any application can be deployed and monitored. Strong database skills are also often required, understanding indexes, query optimisation, and often, in our case, many of MYSQL’s nuances. This self-reliance speeds delivery up as any problems are solvable within the team itself. It also has an added benefit in that it expands the number of ways the team is able to approach and solve a problem.

Test Driven Development?

Maybe the most controversial thing we have done is to stop test-driving all aspects of the application. TDD is a great tool, can help you decompose problems properly, provides a safety when refactoring, and is a great training tool but there are trade-offs. It slows you down and a large test suite can easily stop you from being able to change direction quickly. The lessons learned from TDD can also be applied without dogmatically following the TDD mantra. It is important to choose a level of testing appropriate to the application you are writing and the current phase of its life cycle. In our environment we have found testing the stress points, or having a few high level acceptance tests early on are all we need to allow us to move fast, maintain quality and change direction quickly.

The Rewrite

New technologies allow you to work in different ways. Throwing away code and starting again previously seemed cavalier, perhaps, even dangerous. As you work with a problem your understanding continually develops but from the implementation of the first feature you have started to limit your options in how you can solve it. Ruby has allowed us to use the knowledge of the problem and very quickly reshape an application to conform with our current understanding and this often involves throwing away much of the code.


We also have a culture of real ownership of the applications created. Problems are tackled at any time, wherever we are Snowboarding in Canada or at home Christmas day. This has all been done without an SLA or any of us having to be on call. As a team we are dedicated to delivering quality and knowing that you will be actively supporting an application forces you to focus on providing notifications and details of errors when things go wrong. This has also extended to creating tools to monitor the health and status of the application and administration tools to visualise processes so we can easily see what is happening at any time.

Continuous Deployment

With a steady stream of requirements, a small team, and little process we are able to complete stories and deploy them as soon as they are finished. There is no need to wait for the end of an iteration as you can start getting feedback instantly.

These are a few of the important areas that I believe have contributed to our team becoming so highly performing and are also the key areas by which we differ from other teams I have worked with. Some are seemingly at odds with conventional wisdom but they all embrace the principles of the agile manifesto. I would stress again however, context is important and we have stripped away process that can be useful in many situations. You should always weigh up the potential benefits against limitations and drawback of any process or tool as part of a continually improving agile team.

blog comments powered by Disqus


A blog by Michael Jones, a developer currently working at forward, whose interests include: web technologies; ruby; functional programming; design and making the perfect cup of filter coffee.

Subscribe by RSS