The Simplest Thing That Could Possibly Work

June 26th, 2008  |  Published in Agile by Ian Robinson  |  1 Comment

Jay Fields has written a nice post about “The Simplest Thing That Could Possibly Work.”

I worked very briefly with Ward Cunningham a few years ago. After hearing Ward use a curiously inflected version of this phrase, I asked him about it. We discussed “the simplest thing that could possible work,” what it meant to us, and how we might use it to guide our day-to-day development activities:

“The simplest thing that could possibly work”

This is the prescriptive approach. It passes an almost aesthetic judgment on the desired “final” state of an application: whatever will, in retrospect, prove to have been the simplest way of solving the problem at hand – do that now!

There’s something overly thrifty about this use of the phrase. It ignores the fact that noise, waste and redundancy form an ineluctable condition of possibility for producing something meaningful and useful – no matter how much we might want to trim all excess from what we do. Too often, it’s an appeal to no authority whatsoever; an attempt to bring an abrupt end to the conversation; the agilista’s last resort.

“The simplest thing that could possibly work”

This says more about the process than the final result. It’s an investigative tactic, an exploratory strategy, a way to get you somewhere:

“We don’t know enough about this yet to propose a great solution, so what’s the very next little thing, the simplest thing, that we could do that might just move us forward, or might just give us enough information to work out how to move forward again. Let’s do it. If it doesn’t give us any more information, or leads us down a blind alley – well, what have we lost? Not much, an hour at most.”

Said against a background of asserted behaviour, a safety net of unit tests and continuous integration, this is the pragmatist’s “just enough” (but the politician’s death knell; U-turn as a failure of leadership).

A Duty of Care

The conscientious developer is always working out what’s important today, what to do now, next. But it’s not all for the now; there’s a counter-force, another imperative, which we must reconcile with the demand for “the simplest thing.” We might call this force our duty of care to the overall lifetime of a system.

“The simplest thing that could possible work” has nothing useful to say about our duty of care to the overall lifetime of system. The “simplest” variant is too simplistic, too absolute: it determines our duty purely in terms of a rigid adherence to the simplest thing we might do now. The “possibly” variant has no pretensions to determining our duty: it’s a key to the immediate future only.

Martin Fowler’s “Who Needs an Architect?” does have something to say about our duty of care, however. Casting that article in the terms I’ve established here, I’d say that “architecture” is the term we might apply to those collaborative activities that seek to balance our desire to do “the simplest thing that could possibly work” with our duty of care to the overall lifetime of a system. We do architecture when take up the challenge of mediating these two forces.

My duty of care has been pricked recently by such things as auto generated proxies, naive point-to-point connections, implementations that allow schemas and technology choices to bleed across the application landscape, dogmatic adherence to architectural purity, insufficient separation of message representations from internal domain representations – the list goes on. These things aren’t wrong in and of themselves, but set in a particular context, evaluated against possible lifetime of a particular system, they beg to be interrogated. I suspect the signatories to the “ADO .NET Entity Framework Vote of No Confidence” have been similarly provoked by their duty of care.

Jay’s anecdote quite nicely stages the tensions between our need to do the next important thing now and our duty of care to the overall lifetime of a system. Both the full-blown pattern implementation of the feature being discussed and the more minimal solution Jay’s team have currently settled on exhibit a desire to do “just enough” for the now – but in a way that doesn’t foreclose the future. Resolution here was achieved not by pre-emptively invoking the prescriptive “simplest,” but by collaboration, pairing, discussion; by attending to the process, exercising group judgement, working up insight and feedback; by trusting in a cautious thread of discovery. Architecture, as Martin says, as social construct.

1 Comment  |  Atom   RSS 2.0   Email


  1. The Punch Barrel / The Simplest Thing That Could Possibly Work says:

    June 26th, 2008 at 12:31 pm (#)

    […] Another commentary on the same article from Ian Robinson can be found at The Simplest Thing That Could Possibly Work :: […]