Solving problems backwards

Tom Breur

8 October 2017

Writing software is hard enough, as it is. Attempting to solve particularly difficult problems can be downright vexing. “Try the simplest possible solution that might work” is one of the good old XP maxims that I am often reminded of. For me, there are (at least…) two elements in there:

1.     begin with a simple solution;

2.     try (!) to get a solution to work

With regards to #1, you can always elaborate on your initial design, make it nicer, etc. For example, if you can get your approach to work with a flat file but feel you need a data base for it, add the data base later. Start off with a flat file, and see if your plan comes to fruition.

For #2, I am reminded of “Gerstenfeld’s Law of Trying” (see: J Scott Armstrong, p. 19-20, 1978):

Q: “Daddy, fix my bike for me.”

A: “I don’t know anything about bikes.”

Q: “Daddy, please fix my bike.”

A: “I don’t know how to fix your bike.”
Q: “Daddy, please fix my bike.”

A: “I don’t know how to fix your bike.”
PAUSE

Q: “But, Daddy, you can try, can’t you?”

ANOTHER PAUSE

A: “Yes, I suppose I can can try.”

“And you know,” said my friend Gerstenfeld later, “I did fix that bike.”

Instead of thinking through your idea, “just do it” – it can be surprising how much, and the kinds of things you might discover from merely trying.

There is no path to success without implementation. And when the rubber meets the road, there are often unexpected, unforeseen bumps in the road. Navigate those sooner, rather than later. “Fail fast” isn’t about failing, I would argue, but rather about trying. That way you can future proof your approach to as wide a variety of unexpected conditions as possible. And when it later turns out you missed some challenging conditions? Then at least you had something in production, and gave yourself the best possible odds of learning from exposure to reality…