This past Saturday I had an early morning coffee with a friend. He’s an entrepreneurial type – a big thinker who moves at a fast pace and is always thinking ahead.  One question he asked of me, “Are you playing checkers or chess?”.

The question was asked around business and career but I could not help but think of the implications to software.

In the agile software world we often use the mantra…”do the simplest thing that works”.  I have found that I cringe at the usage of that statement at certain points (when honest - even at my own usage at times upon later reflection).  Really, if we step back and honestly evaluate ourselves, how often do we really implement the simplest thing that works. My opinion is that it’s often used as an excuse to get get out of work - a “wild card” of sorts that’s pulled out when convenient.

With “the simplest thing that works”, developers associate the term YAGNI – You Ain’t Gonna Need It.  While very often true – you really don’t need that feature (studies have demonstrated and confirmed) – I see times where people confuse YAGNI and the agile principle of “the simplest thing that works”. What’s the difference?

Chess versus checkers my friend. Checkers is a pretty simple game with few rules and even fewer game pieces.  Chess however has several game pieces, each of which has their own movements and rules associated with them.  The types of discussions and strategies that exist around chess do not exist around checkers.  Put simply, chess is much more complex than checkers.  Checkers is really treated on a move-by-move basis whereas chess is far more strategic, where moves are setup far in advance of their execution.

When talking about “the simplest thing that works” we have to be careful to not be playing checkers.  Play chess instead.  Make a small, single move that moves you closer to some strategic end.  Like it or not, many waterfall processes are playing chess – trying to anticipate every outcome or piece of functionality and adjust/account for it. What the waterfall practitioner fails to see is the inevitable change.  Many agile adopters start playing checkers, making small move after small move, assuaging fears of downstream problems with the comfort that their doing the simplest thing that works.

Therefore, have a strategy, a end in mind, and then do the simplest thing that works that moves you closer to that end.  Note however that this may not always be the absolute simplest thing that works.