iansrobinson.com

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.

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.

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.

I’m currently trying to use Linq to SQL to model and persist some very simple domain objects. Not having used Linq to SQL before, I’m muddling through, but have quickly run up against a couple of things that have me puzzled:

• Entity classes require a public default constructor
• There’s no support for user-defined value types

My ignorance? Limitations in the framework? You tell me.

Default Public Constructors for Entity Classes

I’m attributing my entity (domain) classes with TableAttribute, and their members with ColumnAttribute. TableAttribute maps a class to a table in the database; ColumnAttribute maps its members to the table’s columns.

To ensure that an object behaves as a good citizen from the moment it’s instantiated, I prefer to set up its state in its constructor. To further guarantee an object can’t be created in an ill-formed state, I tend not to include a default, parameterless constructor for such classes.

Now unless I’m mistaken, I can’t define a Linq to SQL entity class that lacks a public default constructor:

System.InvalidOperationException: The type 'xxx' must declare a default (parameterless) constructor in order to be constructed during mapping.

Nor can I use a private parameterless constructor:

System.MissingMethodException: No parameterless constructor defined for this object.

I can make my members private, so that only Linq can call the setters during object initialisation, which is great; but I can’t make the constructor private or otherwise accessible only to Linq. Seemingly a small issue, but it means that some objects could end up being created in an invalid state.

No Support for User-Defined Value Types

As far as I’m aware, Linq to SQL doesn’t support user-defined value types. Value types are types that lack identity, much as an integer doesn’t have any identity: this 3 is as good as that 3. Value types serve as attributes of entities - which do possess identity. In a database, value types are often stored in the table of the entity that owns them; in an object model, they’re usually surfaced as a dependent object of the parent class they help describe.

To illustrate what I mean by value type, imagine we are modelling a Picture with Description, Border Thickness and Border Style attributes. We might store the Picture in the database like this:

- but represent it in code like this:

Here the Border class constitutes a user-defined value type.

One of the things I want to do with one of my domain objects is store a hash of a string member (a Uri in this instance) with that object’s corresponding database record. I can then index the hash, and lookup records based on the hash rather than a long (500) nvarchar value (which in any case can’t be indexed because it exceeds 900 bytes).

The hashing algorithm isn’t a concern of the entity class that exposes the hash value, so I’ve encapsulated the algorithm in a separate class, effectively making it a user-defined value object:

public class UriHash
{
    private readonly int value;

    public UriHash(string uri)
    {
        value = uri.GetHashCode();
    }

    public UriHash(int value)
    {
        this.value = value;
    }

    public int Value
    {
        get { return value; }
    }
}

As you can see, I’m simply calling GetHashCode() on the relevant string member, but it may be that in the near future I’ll want to change this to use, say, an MD5 hash. When (if) that happens, I’ll have to make changes in several places: in the database schema (int to nvarchar), and in any code that gets or sets an int value. What I’m keen to do, even from the outset, is maintain my encapsulation of the hashing algorithm, but at the same time keep to a minimum the number of places where knowledge of the hash type (int versus string/nvarchar) is baked into the code.

Because Linq to SQL doesn’t currently support user-defined value types, my entity class exposes the hash as a plain old int, as follows:

[Table(Name = "MonitorableResource")]
public class MonitorableResource
{
    // Constructors omitted

    private UriHash uriHash;

    [Column(DbType = "Int NOT NULL", CanBeNull = false)]
    internal int UriHash
    {
        private set { uriHash = new UriHash(value); }
        get
        {
            if (uriHash == null)
            {
                uriHash = new UriHash(Uri);
            }
            return uriHash.Value;
        }
    }

    [Column(DbType = "NVarChar(500) NOT NULL", CanBeNull = false)]
    public string Uri { get; private set; }

    // Other code omitted
}

The problem here is that whilst the hashing algorithm is nicely encapsulated in the UriHash class, the hash type (an int in this instance) is smeared all over the code. The database schema knows it’s an int, and so does the UriHash class. That’s fine: there’s a one-to-one mapping between the OO and the relational worlds. But on top of that, MonitorableResource knows that the type is an int, and that its UriHash member maps to the UriHash column in the database. That’s one place too many for my liking.

Ideally I’d like to expose the MonitorableResource’s UriHash member as a UriHash, and push the ColumnAttribute mapping onto the UriHash type’s Value member - something like this (note, this code isn’t valid Linq to SQL):

[Table(Name = "MonitorableResource")]
public class MonitorableResource
{
    // Constructors omitted

    private UriHash uriHash;

    [ValueObject]
    internal UriHash UriHash
    {
        private set { uriHash = value; }
        get
        {
            if (uriHash == null)
            {
                uriHash = new UriHash(Uri);
            }
            return uriHash;
        }
    }

    [Column(DbType = "NVarChar(500) NOT NULL", CanBeNull = false)]
    public string Uri { get; private set; }

    // Other code omitted
}

public class UriHash
{
    public UriHash() {}

    public UriHash(string uri)
    {
        Value = uri.GetHashCode();
    }

    public UriHash(int value)
    {
        Value = value;
    }

    [Column(Name = "UriHash", DbType = "NVarChar(500) NOT NULL", CanBeNull = false)]
    public int Value { get; set; }
}

Interestingly, the forthcoming Entity Framework does support value objects, which it calls Complex Type Objects. NHibernate, of course, has long supported custom value types.

You’d be forgiven for thinking I’ve got nothing else to talk about…

In preparation for the launch of the ThoughtWorks Anthology, each of the authors recorded a short podcast in which they discuss their essay. Mine is online now. It’s four minutes tops - the perfect aural companion as you huddle outside with a cigarette.

If you like that, you might like this: a couple of years ago, Martin Fowler and I did an interview with Microsoft’s Ron Jacobs on the Evolution of Architecture. As per usual, I’m a one-note band…