silk and spinach

A couple of weeks ago Clarke Ching interviewed me as part of his Everyday Agile initiative. The discussion describes what happened when one of my clients, Codeweavers, invited me to participate in kicking off a new project. You can download the MP3 directly from here.

Warning: The sound quality and levels are very poor, because my headset had packed up. So we’ll probably be re-recording it (or something similar) soon.

In the meantime I’m interested to hear from you if you’ve done the same kind of exercise, and how it turned out.

Wordle seems to be cropping up in a lot of blogs right now, so I thought I’d give it a try on my delicious bookmarks:

I think that sums up my interests quite well. But then, I guess that’s inevitable…

A mailing list recently reminded me of the so-called “Peter principle”, which avers rather sarcastically that in terms of careers, everyone rises to the level of his incompetence. While I was trying to figure out whether this makes any sense, I realised that there’s a huge assumption built into the principle: Good is up.

Somehow, furtherance of one’s career is mapped to “higher”. Is that because most organisations are viewed hierarchically, or is it why most organisations are hierachical? Which came first, I wonder — the shape of our organisations, or the metaphors we use to describe them? We use phrases such as “at the top of the tree”, “top brass”, “a long way to fall”, “social climber”, “high flyer” — all of which reinforce the metaphor that success is “up” and lack of success is “down”. Little wonder that so few organisations escape from this and use non-hierarchical structures.

So the Peter principle says that, as our careers evolve, we climb the corporate ladder until we reach a level that’s too high for our abilities. Again, making the assumption that there’s some kind of linear mapping between “height” in the hierarchy and “ability”. Presumably this is the ability to be “high up” and to have more people and things “under” you? Which also seems to assume that all other kinds of ability are useless or irrelevant. In which case, I think the Peter principle is correct: people tend not to be given more of the kind of work they have shown they are not good at. And in a hierarchical organisation, that means people will stop rising when they get too high.

Sad, though ,that multi-dimensional, multi-talented people can be categorised in such a one-dimensional way.

Clarke asked me to explain my earlier throw-away remark that YAGNI forms part of the EXPLOIT step in moving the bottleneck away from development, so here goes…

YAGNI (You Aren’t Gonna Need It) is an exhortation from the early days of XP. It has been discussed and misunderstood a great deal, so I’m not going to get into the finesses of meaning here. For our purposes, it reminds the developer not to work on features or generalisations that may be needed, telling him instead to focus his present efforts on delivering only what he knows is the current requirement. (In the interests of brevity, I’ll refer below to YAGNI only in terms of added behaviour, and I’ll use the word “feature” for any fragment of any kind of behaviour; all other forms of YAGNI are assumed.)

(In my practice I use a similarly attention-grabbing soundbite. Whenever I see a developer do something “because it may be needed in the future” I accuse him of crystal ball gazing. I remind the whole team that it can be risky and dangerous to get your balls out, and that seems to help the message stick. Other times there’s an embarrassed silence.)

Writing crystal ball code has three effects: In the present moment, it means that the developer is spending current time investing in one of many possible futures; in the period from now until that possible future, it means that there is code in the system that doesn’t need to be there; and when the future arrives, it may look different than that which the developer predicted.

First, then, crystal ball code uses up current development time. This is bad when development is the bottleneck and when batch sizes are relatively small and when development order has been defined in terms of business value and when feature cycle time is a KPI. The time spent developing a crystal ball feature will delay the current batch and all batches upto the imagined future. There is a tiny chance that development of that future batch will be faster (see below), but all interim ROI (for example) will be reduced by the delay introduced right now.

Second, the crystal ball code represents inventory, and it has a carrying cost. This code, which may never be required by the end user, must always build, integrate and pass all tests; if ever it doesn’t, time must be spent fixing it. Furthermore, a larger codebase will always require more time and effort to understand and navigate (think of having to drive around piles of inventory in order to fetch anything or the lean practice of 5S). Even if the guess turns out to be correct, the additional carrying cost of this inventory will slow down the development of all batches of features between now and the imagined future.

Third, the developer’s guess may be just plain wrong. Either the imagined “requirement” is never requested, or it is requested and by that time the codebase is radically different from what it is now. The developer may have to spend time removing the feature (for instance if it would confuse or endanger the user) or completely re-design it to make it match how reality turned out. It is assumed that the “wow, that’s exactly what we needed” outcome is sufficiently unlikely that the costs of the other outcomes dominate.

So YAGNI is based on a few core assumptions:

• The product is to be built incrementally in batches of features
• Each increment should be potentially shippable in terms of quality and cohesiveness
• It is hard to predict what features will be requested in later batches
• It is hard to predict what future code may look like
• Development is the bottleneck
• Speed of development is crucial
• The present value of current features is higher than the future value of future features

Under these conditions, YAGNI is part of the EXPLOIT step because it helps to maximise the amount of current development effort going into delivering current value.

Sketchy information is beginning to emerge about a new half-day AgileNorth event that’s scheduled for a Saturday around the end of April. It will be free to attend, it will be hosted at the University of Central Lancashire in Preston, UK, and it will feature sessions on “agile methods”.

If it turns out to be on April 26th, perhaps one or more of the attendees could turn up to the naked agilists event that evening and describe the highlights…?

Chad Fowler has just launched Slick or Slack, a website where we can all review and compare code snippets for the Quality that has no name. Great idea — I’m hooked already!

The date of the next NakedAgilists virtual conference has been set for Saturday April 26th 2008, at 8pm GMT. Previous events have been packed with great sessions and debate, so add this event to your calendar now to avoid disappointment!

As always, the conference will consist of a small number of 5- or 10-minute sessions, each followed by a 5-minute discussion among all attendees. Contact me if you have a session idea you would like to present (or join our mailing list and get some feedback on your idea there).

I’ll post more information about the event as it makes itself known to me…

This week Wayne Allen is starting an experiment: one of his teams is going to drop the “traditional” agile approach of iterations and velocity, in favour of a kanban-style pull system with capped work in progress. The team will do no estimation, and the only metric for the department will be the average number of days required for a story to make it through the whole process.

I hope Wayne will keep us informed on the experiment’s progress and results, because I believe this is the kind of practical research that the agile world desperately needs right now. I suspect this kind of move could only be made in an organisation that has built up a deep reservior of trust in agile (and in Wayne); I wonder what other pre-requisites ar enecessary for kanban development to be acceptable (not to mention successful). I’m particularly interested the reactions of those who want to know what features are coming in which release at what date: Will they have less visibility of progress and planning information than before? Will they get nervous as a result? Or will they adapt their behaviour to the new throughput metric?

Hats off the Wayne and colleagues for trying this, and for anouncing the experiment publicly.

I’m about to TDD a Ruby class whose behaviour will involve the use of random numbers. I expect the algorithms within the class to evolve as I implement new stories, so I don’t want to design and build a testing mechanism that will be brittle when those changes occur. But before I can write the next example, I need to figure out how to control the random numbers needed by the code under test. Off the top of my head I can think of four options:

1. One way would be to set a fixed seed just before each test and then simply let the random algorithm do its thing. But for each new behaviour I would need to guess the appropriate seed, which is likely to be time-consuming. Furthermore, the relationship between each magic seed and the specific behaviour tested is likely to be obscure, possibly requiring comments to document it for the future reader. And finally, if the algorithm later evolves in such a way as to consume random numbers in a different order or quantity, the seed may turn out to be inappropriate, leading to broken tests or, worse, tests that pass but which no longer test the planned behaviour.
2. Alternatively I could redefine Kernel::rand — but that could potentially interfere with stuff I don’t know about elsewhere in the object space.
3. Within the class under test I could self-encapsulate the call to Kernel::rand, and then override the encapsulating method in a subclass for the tests. But then I’m not testing the class itself.
4. Finally, I could parameterize the class, passing to it an object that generates random numbers for it. This option appears to give me complete control, without being too brittle or trampling on anyone else in the object space.

So I’ll go with option 4. Right now, though, I’m not sure what interface the randomizer object should provide to the calling class. Looking ahead, I expect I’ll most likely want to select a random item from an array, which means selecting a random integer in the range 0...(array.length). And for this next example all I’ll need is a couple of different randomizers that return 0 or 1 on every request, so I’ll simply pass in a proc:

obj.randomize_using { |ceil| 0 }

And if ever I need to provide a specific sequence of varying random numbers, I can do it like this:

rands = [1, 0, 2]
obj.randomize_using { |ceil| rands.shift || 0 }

Later that same day…

The class I’m developing has evolved quite a lot and split into three. And suddenly, with the most recent change, three of the tests have begun failing. A little investigation reveals that the code is now consuming a random number when it didn’t need to in the past, and so some of my randomizer procs now provide inappropriate values. It turns out that two of the failing examples actually boil down to being a single test of a piece that has now been refactored out into another class; by refactoring the tests to match I can remove the dependency on random numbers altogether. And the last broken test is fixed by providing a randomizer that respects the ceiling passed to it (not an unreasonable request):

obj.randomize_using { |ceil| [2, ceil-1].min }

This works, and I get no more surprises during the session.

Over on the Beautiful Code blog, Michael Feathers has written about loving C:

“I remember flipping through the Kernighan and Ritchie book decades ago, trying to pick up the language. I remember a lot of frustration, but I also remember a lot of satisfaction. C has its quirks, but in retrospect, they are a lot less mysterious than the quirks of many other languages. They don’t require deep reasoning. The behavior of a construct is either defined or it isn’t…”

There’s a discussion going on in the post’s comments too, mostly between proponents of C versus C++.

The thing I value most about C is its simplicity. As simple as possible, and no simpler. I feel that pretty much everything that came out of the Ritchie / Thompson / Kernighan / McIlroy group has that same quality — a deep deep cleanliness. C++ has none of that, in my opinion. It was designed specifically as a hybrid, an attempt to bring the features of one “desirable” language into the space of a different language. The cracks show, and have been made worse and worse over time. The fact that C pretty much stopped evolving very early on is perhaps a factor that helps keep it young and fresh. It does one job and does it well, and has no pretensions to be all things to all men.

There’s a trend in British politics (I’m sure the other major democracies must have it too) in which our political parties seem to be playing catch-up all the time. Instead of saying “this group stands for X”, and then dying out when X is no longer popular or relevant, they say “this group stands for being popular”, acquiring new policies and values simply in order to remain “current”. C++ seems a bit like that to me, and Java too. Everything but the kitchen sink gets thrown in, instead of simply admitting that some problems might just be better solved using a different language. C didn’t do that (much), and has remained clean and simple as a result. I’m not ashamed to say that I love it too.

(I fear that Ruby may be taking its first steps down the “kitchen sink” road…)