Where is the constraint in software development?

I just had a thought about the relationship between software development and the Theory of Constraints. It probably isn’t a new thought, although itĀ seems to differ from some of the analyses I’ve seen elsewhere. Also, I probably won’t be able to express it in any coherent way; but here goes…

Continue reading


geekup nottingham

Tomorrow evening (Nov 1st, 2010) I’ll be speaking at GeekUp Nottingham, reprising my flow session from this year’s AgileNorth conference. And at some point in the evening I’ll be giving away a signed copy of my book Refactoring in Ruby.

If I show slides tomorrow, it’ll be the set I showed at AgileNorth, plus a couple I’ve added just in case there’s no flipchart.

Looking forward to a great night, and to fascinating discussion as always.

rocks into gold

My very talented friend Clarke Ching has self-published his second novel Rocks into Gold (his first, Rolling Rocks Downhill, is due out later this year).

Rocks into Gold is a “parable for software developers who want to survive — and then thrive — through the Credit Crunch”. If you’re a subscriber to this blog you’ll probably know the book’s main message already; but read it anyway, because you probably also know someone who’s project, or job, or organisation, might just benefit from Clarke’s excellent re-telling — buy them a copy.

Inherent simplicity

This week I’ve been doing a lot of reading around Goldratt’s latest big idea: inherent simplicity. The premise is that any complex system (Goldratt typically considers companies here) always has an “inherent simplicity”. Once found, this simple model of the complex organism can be used to reason about it and create breakthrough analyses of, say, the route to exponential growth in profits.

The more I read, the more I realised that this idea has formed the basis of much of my career. Having a PhD in mathematics, I have always looked for — and enjoyed looking for — the elegant and simple solution at the heart of any problem. And in my work life I’ve applied the same aesthetic to solving business problems. Here’s a neat example from a consulting gig in the 1990’s…

A group of us (designers, developers, business analysts) had been tasked with re-engineering an old suite of applications used by a parcel delivery firm. The idea was to replace a bunch of disparate applications with a single, distributed enterprise solution, and at the same time evolve from “parcel tracking” to “parcel management” (whatever that means). We had a 200-page spec describing the business rules for parcel management, and it was unbelievably complex. A parcel might have a barcode, or a hand-written label, or no legible markings at all. It might be waiting to be loaded on a van to its final destination, or waiting to be sorted at the hub, or in the wrong place entirely. If it was in the wrong place, it may have been labelled correctly or incorrectly, legibly or illegibly. And so on. We were becoming bogged down in the detail, and everywhere we looked there was more. The object model for the new application was looking like spaghetti, and the mess got larger each day.


So one day, frustrated by the complexity, I took a break from facilitating the analysis sessions and took the problem home; peace and quiet. And I found the system’s inherent simplicity: Look at everything from the parcel’s point of view. Where I’ve been doesn’t matter; whether I’m in the right or wrong place now doesn’t matter. All that matters is where I should go next. And for each parcel, that’s unique. Given any parcel located anywhere in the system, there’s a “best” route to its destination, and therefore a single next place to which it should be moved. The means of transport (hand, van, plane, forklift, …) is also unimportant at this level. All of the business rules lived inside Parcel.get_next_location(), and everything else was implementation detail.


It took the other members of the analysis team a couple of days to grasp this simplicity and peel away the layers of complexity. And then the project was canned, so this elegant solution was never implemented.

Anyroadup, you get the idea…

downstream testing implies a policy constraint

As usual, it takes me multiple attempts to figure out what I really want to say, and how to express myself. Here’s a bit more discussion of what I believe is implied by downstream testing:

The very fact that downstream testing occurs, and is heavily consuming resources, means that management haven’t understood that such activity is waste. (If management had understand that, then they would re-organise the process and put the testing up front — prevention of defects, instead of detection.) No amount of tinkering with analysis or development will alter that management perception, and therefore the process will always be wasteful and low in quality. So the constraint to progress is management’s belief that downstream testing has value.