Archive for June, 2008

The Simplest Thing That Could Possibly Work

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

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.

Atom   RSS 2.0   Email

Stories, Capabilities, Services and Contracts

June 25th, 2008  |  Published in Agile, Behaviour-Driven Development, Consumer-Driven Contracts, SOA by Ian Robinson

Today I want to introduce a bare-bones model to help guide the creation of business, architectural and technology artefacts in an agile and iterative manner over the course of an SOA initiative:

  • Stories – in the form of Behaviour-Driven Development exemplars – describe goals and desired outcomes;
  • Capabilities encapsulate the resources and abilities an organisation needs to satisfy those goals;
  • Services host capabilities;
  • Contracts – particularly consumer-driven contracts – assert the interactions between services.

We iterate over this model many times in the course of an engagement, emphasising different parts as we go. We concentrate on organisation-level stories and capabilities when establishing an organisation-wide context, then project-level stories, capabilities and services whilst planning projects and delivery streams, and then release- and iteration-level artefacts during specific instances of delivery.

Such an approach represents a “thin-slice” way to:

  • establish context, business goals and consensus amongst stakeholders;
  • create a long-term vision that joins up the business, architectural and technology views of an SOA initiative;
  • describe and challenge an organisation’s goals and the benefits attached to those goals;
  • describe the capabilities needed to meet those goals;
  • identify the quality-of-service expectations the business has of those capabilities;
  • identify services and assign capabilities to services;
  • describe and test the externally visible interactions between services;
  • identify, plan and develop slices of service functionality that deliver business benefits early and often.

Atom   RSS 2.0   Email

Rediscovering Business Benefits

June 5th, 2008  |  Published in Agile, Behaviour-Driven Development by Ian Robinson

Outcomes and the business value that we’re seeking to release in pursuing those outcomes all too often get passed over in favour of a morass of implementation trivia.

Desired business outcomes frame the delivery of application functionality, or more generally, service capabilities: they motivate software development. The outcome-driven bias of agile practices is reflected in the user story: in the Role-Feature-Benefit story sequence (see Dan North’s What‘s in a story for a description of these parts, and more recently Elizabeth Keogh’s RIP As a… I want… So that… for a compelling reformulation of the story format).

Sadly, many instances of stories try and get by without capturing outcomes and benefits. As one of the commentators on Elizabeth’s post notes: “the ‘so that’s’ are always the hardest thing to write in a story and are the first thing to be omitted.”

I see a lot of stories that neglect Role-Feature-Benefit in favour of the much easier Role-How-Feature. That is: as a <role> I want <something doing this way> so that <I can do this/this happens>:

As a user I want to export results so that I can share them with colleagues

Well, thanks for telling me how to do my job, and not telling me anything about what motivates yours.

Have we specified an outcome here? Not really. What we do have is a misplaced feature masquerading as an outcome, and a pre-emptive description of how to implement that feature. We’ve shuffled the desired outcome, the goal that motivates this feature, off the table. And by pre-emptively specifying an implementation, we’ve limited the opportunity for choosing between several implementation strategies – lo-fi, hi-fi – come implementation time.

When I spot stories like this, I try to “force” the issue of outcomes and benefits by performing a “shift left” on the story parts. Role stays the same, Feature shifts left, and squeezes How out. This leaves: as a <role> I want <to do this/this to happen> so that <??????>:

As a user I want share results with colleagues so that…

Now we’ve got a role, and a feature, and can start asking “why?” regarding the benefit:

As a user I want share results with colleagues so we can make an informed group decision about recent performance

Identifying the benefit allows us to turn the effort dial up and down. You need to do this, urgently? How about this workaround? Estimate: zip.

Atom   RSS 2.0   Email