If you have not watched Rich Hickey’s talk on Hammock Driven Development you should do so now. I’ll wait right here whilst you do. Great talk wasn’t it?

Although delivered ten years ago, many of the problems Rich describes I still encounter today so in this post I will discuss the key points from the talk and how they can help you deliver the changes that your users actually need.

Analysis and Design

Conduct proper Analysis and Design. Rich mentions that this might feel so 90’s but as he points out, this isn’t just a process to be followed and there is no need to become a UML astronaut. Instead he distills Analysis and Design down to two things. Identify the problem we are trying to solve and assessing our proposed solution to whether or not it solves that problem.

A brilliant synopsis.

Many of the projects I have been part of could have been saved a lot of heartache if better Analysis and Design had been undertaken. Everyone on the team should have a clear understanding of the problem and why it needs to be solved. Equally the team should have confidence in the solution being implemented. The solution was not the first idea that popped into someones head but had been carefully selected, compared against others, trades offs made and it had been subjected to a rigorous peer review.

Solve problems

We should be solving problems. We should not be building features. Features specified by users are really not good ideas. You need to dig into what problem they have and find what is the best solution to it. Then you can reconcile your solution with what they have asked for.

I have concatenated several of Rich’s quotes here. The message is clear. Don’t start building features that have been specified by users. You will waste time solving the wrong problem(s)

Practice Problem solving

If you are going to be spending the majority of your day solving problems it is a worthwhile investment to get better at it. Aside from recommending the book How to Solve it by George Polya. Rich also discusses the useful process of writing it down in a format such as:

I am solving this problem, this is the problem.

Rich describes a situation where poor problem solving has been applied. “We have this problem, I think we need a NoSQL Database.” There is a chasm between the problem and the solution so when you hear something similar it should start to ring alarm bells.

He also mentions that it is a good idea to seek out related problems and see how they were solved. What worked and probably more importantly what didn’t. Finding a related problem is going to save you time compared to starting from scratch.

Rich’s final tip is again to write your understanding of the problem down. In doing so I have noticed whenever I write a solution to a problem down gaps in my understanding magically appear.

Be discerning

Not everything is awesome.

This is a step that applies to every stage of software development and yet is so often overlooked.

Find problems in your solutions. What trade offs are implicitly or explicitly being made by the choices you make?

Start small, start now

There are no silver bullets in software development but I believe applying these principles will improve you and your teams ability to deliver solutions that solve your users problems.

It’s a fact that you will need support from Management before implementing these principles. It may help to start by solving problems using some of the methods discussed in Rich’s talk and in this post. When improvements are seen or even better measured it will become an easier sell on implementing bigger changes such as how Analysis and Design is undertaken.

Let me know how you get on.