Agilists love a good catch phrase. You Aren’t Gonna Need it (YAGNI), Do the Simplest Thing that Could Possibly Work, and Pain Driven Development are three of them. In fact these three are different ways to say the same thing.

All three phrases are about addressing a technical problem the team might face in the future. Immature teams will immediately attempt to solve the potential problem and thus add complexity to their product. More mature teams take a slower, more considered view.

In fact Agile teams should go through these stages when considering a potential problem/solution:

1. Remember “YAGNI” i.e. point out the team don’t have a problem now, hence don’t need that solution now, so probably won’t need it in the future either.
2. Wait until you feel some pain before accepting the problem is real.
3. Once you feel the pain then do the simplest thing possible to solve the problem.
4. Then wait until you feel more pain before trying anything else in that space.

That considered process is Pain Driven Development.

Pain driven development is an iterative approach to development. Becoming aware of significant pain causes the team to revisit the solution and remove that pain. They iterate on the solution. By limiting the solution of each iteration, by doing the simplest thing that could possibly work, means the team can deliver the highest value they can at the time but also acknowledge they may have iterate again at a latter date.

YAGNI

One of the Principles behind the Agile Manifesto is:

Simplicity–the art of maximizing the amount
of work not done–is essential.

The phrase You Aren’t Gonna Need It (YAGNI) comes from Extreme programming community and is a reminder to apply the Simplicity principle. Maximising the amount of work not done. If you don’t need the functionality in question to address immediate user needs there is a good chance you won’t need it in the future, so don’t do the work. And building less is a key element of software project success.

Ignoring the Simplicity principle means the developers are gold plating. That is bad because the software becomes more complex, harder to enhance and harder to maintain. All of which adds cost and time. Ironically it makes the life of the developers harder, not easier. At the extreme is causes the project to fail.

It is good for a technical team to challenge itself with YAGNI when considering technical solutions. But YAGNI can also be used to challenge the business. Particularly if the product owner stated their preferred solution not the actual problem. The team should push back when the product owner shoves a solution at them and YAGNI is part of that push back. YAGNI can be part of the discussion even if the product owner is talking about real features. If it is obvious to the team that nobody will use a proposed feature then YAGNI is a reasonable response.

Feel the Pain

Mark Needham describes Pain Driven Development as “making decisions at the last responsible moment by encouraging our team to ‘feel the pain’ before introducing any constraint in our application”. He points out that the team has to have a feedback mechanism to ensure they are aware of the pain before it goes too far.

Feedback can be quite informal. The team just notices the problem. Perhaps the somebody mentions at the stand up “Hey guys, that screen is sooo slow”. That is pain. Pain for the tester having to test it, pain for the product owner having to sell it into the business and ultimately pain for the user when trying to use the screen.

A more formal approach to feedback is to run a Technical Debt Retrospective with the team. During this type of retrospective the team can create a Technical Debt Effort/Pain Wall. Nice name but really it is just one of those management charts with four quadrants. Each Technical Debt user story is placed on the chart depending on two dimensions:

• The relative effort that the team would have to spend in order to pay this debt.
• Pain is the direct impact on productivity that this debt causes.

The highest return is when you are experiencing high pain and can fix it with low effort. Anything with low pain and high effort is not worth it. Other combinations are marginal.

The Simplest Thing that Could Possibly Work

Ward Cunningham, one of the XP crew, recommends doing The Simplest Thing that Could Possibly Work when designing and architecting systems.

Why? YAGNI!

Acknowledgements

Thanks to the Ruby community for shouting “YAGNI” until I got the concept.

And thanks to Pedro Santos for introducing me to the term “Pain Driven Development”.