Simple Isnt Easy

In ExtremeProgramming, we DoTheSimplestThingThatCouldPossiblyWork. We say YouArentGonnaNeedIt, which reminds us to build to our current need, not to some foreseen future requirement.

We were talking today, in response to the discussion on NanoIncrements, about how hard it is to do simplicity.

IsaacAsimov wrote a time-travel story in which the agents who edited the past tried to find the MinimumNecessaryChange?, the simplest change to the past that brings about the future you want. (Larger changes had undesirable side effects: the idea was to minimize these.)

When we DoTheSimplestThingThatCouldPossiblyWork, we observe that our more-experienced developers choose simpler initial implementations than the less-experienced ones. This happens, I'm guessing, because they know the system better, therefore worry less about "what if", and because they have more experience with refactoring.

When we live by these rules for a while, we build up great confidence in our ability always to improve the system just enough to get the new function we need, and we observe that the simplicity of the system always serves us, never hurts us.

That said, it's important to remember that we take the simplest idea and implement it in the simplest final code. Our practice is not to leave junk in the system. When we do this it works fine; when we let ourselves get lax, we get in trouble.

See TimeToMakeItShort

If you think simple is easy, learn many chess games of Capablanca, since they all are so simple, then try to replicate his style.

CategorySimplification