Projects With A Body Count

Someone asked me recently, “What is extreme programming?”.

My first reaction was a slight chuckle as the image which flashed across my mind was of a project I worked on back in the mid-90′s.

At that time I was working for a small software company in London which was developing a product for use in various large city institutions. The people I worked with were some of the most motivated individuals I have come across in my time with a real hunger to succeed and many a time individuals went above and beyond the call of duty. The particular incident which made me laugh was of myself and a colleague leaving the office at around 6:00am. On our way out of the main door, the CEO was walking in:

“Morning lads. Nice to see you in early!” he said.

“We’re off home.” we replied to his surprise.

We’d been up all night trying to fix the main product so that it would be in a fit state for our CTO to demonstrate to a client that day. Death of WaterfallAfter finishing at around 4:00am and being a distance from home we were so knackered that we slept on the sofas in the reception area. Once the tubes had started running again we headed for home.

With the power of hindsight and experience it is obvious now why we ended up in that situation. Essentially it boiled down to terrible communication and even worse visibility of the quality of the product. Projects were typically based on the Waterfall methodology and I can’t remember any kind of automated testing. Day in, day out, we the technical team responded to the demands of ever vociferous clients with the end result being code meltdown.

Another example of “extreme programming” came when a major client simply refused to hang up on a conference call until the software we were building was working on their site. They were so frustrated with lack of delivery and broken promises that all trust had practically evaporated. Something like seven or eight hours after the call started they finally hung up.

So why does it happen?

There are a multitude of reasons people give but I like to think it boils down to this:

If you don’t know exactly what your software does at every given moment and you don’t know how much effort it took to build it then your delivery of future functionality will fail due to either a planning or technical meltdown.

The night we slept in reception we had no idea what the product did as a whole. We just knew that it probably did enough to get through the demo. After about 20 hours straight programming with next to zero testing or formal delivery I’d say the odds were pretty high we’d broken a few things along the way. Similarly, the poor guys coding like caffeine addicted nerds during an eight hour telephone marathon almost certainly didn’t deliver a product that was up to scratch. Both were examples of the death throes of a project which had died from a massive overdose of untamed complexity.

Fast forward ten years or so and enter some new development methodologies: Agile, and Extreme Programming.

The first time I had a real “Eureka!” moment was working for a large insurance company in Australia. I’d never heard of Agile before but on day one, there I was standing up in the morning telling people what I’d done yesterday, what I planned to do today and whether anything was hindering me. I thought it was just a nice way to get to know everyone.

Agile? You bet. On time and on budget.

As the weeks passed though, I began to see what was happening. People arrived at 8:30am and went home at 5:00pm. Code was being continuously developed, checked-in, peer reviewed using online tools and tested. DAILY. The project manager was always around telling us what was going on and informing us what was the next priority. This went on for about eight or nine months then the team was slowly scaled down as work neared completion and finally, with great fanfare, the project went live.

On time and on budget.

It was only a while later when I realised I had changed to. Software can be delivered and it doesn’t have to be hell. I was energised again and wanted to do more.

The last project I worked on was a whopper. Several hundred technical staff building from scratch a global entertainment platform. The core databases held hundreds of millions of records using over 20 terabytes of storage. There were somewhere in the region of 20 complex REST services powering mobile, browser and desktop applications and the message transaction rate can only be described as substantial.

The first version of the platform went live in nine months and was rolled out globally to many countries in less than eighteen months.

Agile? You bet. It was one of the best examples of Scrum I’ve ever heard of and I certainly was proud to be a part of it. People buzzed. They were proud of what they were doing and strove to make it better. Everyone from senior managers to junior developers played their part and their energy and enthusiasm abounded because the great gathering storm clouds of unmanaged complexity never formed.

In the worst project he ever worked on, two people actually died.

Business owners managed their backlogs well. Technical teams worked religiously to two week sprints always using test driven development, always with a retrospectives. We communicated and had huge white boards which let all and sundry know how we were progressing. One of the nicest parts was when, inevitably, development teams felt they were being pushed to deliver too much and pushed back to the business with a “no”. The business accepted this and re-prioritised. Over time a trusting relationship developed which meant everyone could get on with their job.

Thinking back to those crazy days in London I remember a conversation I had with a colleague in the pub one night. He talked about the worst project he ever worked on where two people actually died. One had a heart attack, the other in an accident.

I can’t say Waterfall was to blame for that. But you can’t entirely rule it out either.