Shopping List

This will be about shopping and why creating software isn’t like a shopping list, or at least it shouldn’t be.

At my house, the groceries arrive on Thursday, usually in the morning - Sainsbury’s home delivery has become a part of our life. But before they arrive, my esteemed spouse meticulously plans a few days in advance, detailing what, when, how, and how much the family will be feasting on. A meaty dinner here, a vegetarian dish there, and something sweet for another time… In this case, the plan for the upcoming weekend is brilliant: Moroccan Lamb Stew…

Then comes Thursday morning and… you probably know the drill… the SMS arrives with information about substitutes or shortages: suddenly, the eggs are out, the fine red wine is replaced with some swill, the leeks are swapped for celery (I have no idea how one could confuse those - or maybe it’s no mistake), or there’s no lamb so we’ll get refund…

So, no Moroccan Lamb Stew! The weekend plans are completely ruined… We wouldn’t dare risk creating a ‘Frankenstew’ without the lamb… The plan had to change, a reshuffling of meals, and so on.

Alright, what does this have to do with software development? More than you might think. Let’s start by considering which other industry you associate with the software development process. In the majority of cases, you’ll get answers that compare this process to the construction industry: land measurements, foundations, basement, ground floor, first floor, etc., and finally the finishing touches…

Well, completely wrong!!! Allow me to quote from the brilliant book “Pragmatic Programmer”:

Well, software doesn’t quite work that way. Rather than construction, software is more like gardening - it is more organic than concrete. You plant many things in a garden according to an initial plan and conditions. Some thrive, others are destined to end up as compost. You may move plantings relative to each other to take advantage of the interplay of light and shadow, wind and rain. Overgrown plants get split or pruned, and colors that clash may get moved to more aesthetically pleasing locations. You pull weeds, and you fertilize plantings that are in need of some extra help. You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, the layout) as needed.

The metaphor of the garden is beautiful, isn’t it?

I’ve actually never seen successful software creation by thinking of it in terms of building construction. Sure, attempts have been made, and I’ve often been part of such processes myself, and it’s true that business people love this kind of thinking - only, it never really matched reality - because at the development level, there was always the garden.

So, since we’re talking about “building construction,” then we have our shopping list:

The list usually goes on forever, is often as long and winding as the journey from London to Birmingham. What seems to be the natural process in such a case? Well, of course… We follow the list, do one thing, then the next, from top to bottom - why not? :-) So, we work on the ingredients, each one separately, assuming that once combined (in the future, if there is any future), they will create something beautiful for us.

However, following this path, we quickly notice that the subsequent elements are interconnected, they depend on each other, or should be considered as such. It is impossible or impractical to consider them entirely separately. And when considered in isolation, they will make their interconnectedness known at the end of the road - combined together, they absolutely will not create anything beautiful. You can always argue that the problem might arise due to the wrong order, but please, feel free to rearrange the order as you wish…

The problem I see lies entirely elsewhere. We want to prepare a specific dish, call it what you want: deliver value to the user, a feature, a user story. That is, to prepare SOMETHING using ingredients from our list, just a few or many, in various proportions, but SOMETHING that isn’t just an ingredient from the list itself.

So, let say, we have our dish with the very unpretentious name: “User System Login,” for which we need the following ingredients:

So prepare only as much ingredients as we need for a given dish, no less and no more. And like a delivery from Sainsbury’s - because something might not arrive, or something completely different than what we planned might show up, working with fewer ingredients allows us to more comfortably and safely find a solution.

Alright, enough with the metaphors; of course, this is absolutely nothing new - the concept of FDD (Feature-driven development) was established in the late 90s. To this, you can also add the fantastic User Story Mapping - I recommend the book by Jeff Patton with the same title.

Ahh, and remember, don’t go overboard with the spices. ;-)