DanNorth.net

This question came up at the recent Expo-C conference, when presenter Michael Stal talked about designing services to be “as simple as possible but no simpler”. Kent Beck advises us to do “the simplest thing that could possibly work”, but this is often mistaken for “the first thing I could possibly think of” or even “the only thing I know” (also known as the Golden Hammer antipattern).

We picked up the topic as an open space session later that day. I took the position that you should only ever focus on the specific case in hand, and then only generalize if you meet another similar case. Erik Meijer, the reknowned language guru and thoroughly nice guy, took the opposing stance that you should abstract the general solution and then implement it locally. He pointed out that this was an approach with centuries of mathematical tradition behind it and is a fundamental tenet of modern functional programming¹. This developed into a good-natured but heated stand-off. I just couldn’t see the value of building a fancy general solution on the client’s money, when there was lots more important work to do and limited time. He couldn’t understand why you wouldn’t take the effort to make something as flexible as possible for the end user, especially if you were designing something like a programmers’ toolset or language. On the scale of specific to general – or concrete to abstract – we were at opposite ends, with a seemingly intractable chasm between us. He was simply wrong, and so, of course, was I.

If you are working on an agile project, you can confidently take the “simplistic” approach of only solving for today, safe in the knowledge that you can easily change the code tomorrow, or next week, as you learn more. If you are designing something that involves publishing an API – of which designing a programming language can be considered an extreme example – then your decisions can have a far-reaching impact².

This led us to the notion of a Change Event Horizon, which is the amount of time before you can undo the effect of a decision. For a programming language the change event horizon is huge. It can take years to repair a bogus language decision, and involve complex processes such as deprecation. For an internally-deployed enterprise app you are only as far away as your next release date.

So now we had a working definition of “too simple”. It can be defined as any decision that doesn’t consider the scale of the change event horizon. As an agile developer, one of my objectives is to create as small a change event horizon as I can, through the medium of continuous integration, automated testing and regular user feedback. Erik doesn’t have that luxury – he has to predict what his users will want, and use much blunter instruments such as beta programmes and focus groups. Add to that the myriad unpredictable things people do once you release a language – who would have predicted that Ruby would become the DSL host language of choice, or that VB would ever become cool³ – and you can quickly see that Erik lives in a far more complex world than me. No wonder then that he looks to the general, abstract case whenever he encounters a new situation. And I can rest easy knowing that my tiny change event horizon means I can change the world with the next release.

NLP talks about “in time” vs “through time”. Being in time means living in the moment, and not worrying about the future. Being through time means seeing the wider context, and carefully considering the implications of any action. Of course most people are a healthy mix of both of these. I am notoriously in time, which might explain why the immediacy of feedback on an agile project appeals to me – I simply don’t have the attention span for anything longer!

¹ Erik is also the father of Haskell

² Thanks are due to Niclas Nilsson for taking the role of translator/peacemaker for us to reach that realisation.

³ Take a look at some of the up-coming language features in VB9 if you don’t believe me.

Adopting agile practices is a step-change for many senior managers and business sponsors. Don’t underestimate the importance of getting them onside early in an engagement, and making it “safe” for them to explore and adopt agile practices. We want to provide our sponsors with timely, accurate information they can use to make effective decisions about the steering of a project. An agile project provides exactly the data to do just this, but we have to ensure that the people receiving it can interpret and make use of it easily and effectively.

For the team on the ground, agile adoption is a shift in thinking from large chunks of activity to smaller, iterative, highly-collaborative working. This shift can take place quite quickly. With a small, motivated team and a high enough proportion of agile “enablers” in the team (about 50/50 seems to work best), a new team can pick up “proper” TDD, pairing, continuous integration, story writing, etc. in a matter of a few weeks.

The business sponsors, on the other hand, have a rather different journey. They are used to seeing Gantt charts showing percentage completion of development activities, and—shame on us—they are used to project managers being, well, at best conservative with the truth. In our defence, we say things like: they don’t need to know the day-to-day dynamics of the delivery cycle. If we are slipping slightly, let’s just gloss over it—we don’t want to go worrying anyone. And anyway, no-one likes their project to be “amber”, do they?