The Skeptical Methodologist

Software, Rants and Management

Breakthrough Driven Development

Conveyor Belt Development

We all know the conveyor belt model of software development doesn’t work. Requirements don’t go in one end of the machine to be transformed into working software in a step by step fashion. This is the usual argument against most process – we’re not quite sure how we write software, so there’s no step by step process to do it right.

Still, we find ourselves moving back to the conveyor belt in one way or another. We measure effort in weeks, or SLOC or code points. We ask for status in terms of a certain percent “of the way there”.

Some argue that the only reason we do this is because pointy-haired-bosses refuse to give up on the dream of conveyor belt software, and stubbornly demand that development bend to their will and make their jobs easier.

I now believe this is false. The reason why people turn back to the conveyor belt isn’t because they believe it – it’s because they have nothing else.

We’ve taken our Luddite hammers to the conveyor belt and screamed “there is something more here!” when talking about software. “It’s not so easily captured in your charts and figures” we argue. But when we have to turn back to the practicalities of working with many other teams – those of which do have conveyor belts that work just fine – we have no new machine to replace our broken belts with.

And so the belts are mended, and the machines turned back on.

And we dance around the point – our pointy haired bosses says “I get it, I get it, it’s not so easy as to say that you’re 50% done. But I have to tell my pointy haired boss something. Is 50% okay?”

The more naive amongst us expect our overseers to gird their loins and go swinging into battle with their own overseers arguing against the metrics and belts and charts altogether.

They expect this, and then send their overseer into battle without any weapons.

To really destroy the belt, we have to offer up a replacement. And here is mine.

The Die is Cast

Software development is a stochastic process. Think of it like a game of D&D. The Dungeon Master tells you to defeat this enemy, you have to roll 16 or higher on a D20. That’s 16, 17, 18, 19 or 20 on a 20 sided die, giving you a 5/20 or 25% chance of victory.

Every day we come in and sit at our dev boxes, analyzing our designs and debugging our programs, we’re rolling a die. Will this be the day? Will we have a breakthrough today?

So much of software, from design to debugging as mentioned above, is pure random chance. There’s no process to assuredly find a bug, and there’s no process to assure a good design. Instead, we must try many hypotheses when finding a bug. We must try many designs in trying to find a good design. With each one, we get a certain chance of success.

This ends up looking deceivingly like the conveyor belt in some ways but is distinctly different in others.

The Belt and the Die

First, let’s say we estimate 20 days for a project. The conveyor belt model says after one day, we’ll be 1/20th complete, while on day 19, we’ll be 19/20ths complete. This, we know, is false.

Under the rolling a die model, a 20-day estimate is the same as saying we need to roll a 20 on a 20 sided die. Given 20 days, we can almost guarantee success. So the estimate looks the same. But look what happens on each day.

On the first day, we have a 1/20th chance of succeeding. On the second day, we have a 1/20th chance of succeeding. On the 19th day, we have a 1/20th chance of succeeding!

With the conveyor belt model, each day gets us closer to our goal. Under the D&D model, each day is just another chance to win. We can have early lucky breakthroughs, but we can also have projects that go on and on as the die stubbornly refuses to obey our wishes.

Is all work using the D20 in software? No. Clearly breaking down projects into milestones allows us to take some conveyor belt approaches – first we need to open the portcullis (roll a 6 or higher on a D20), then we need to sneak into the castle (roll an 18 or higher on a D20), then we need to defeat the dragon (roll a 12 or higher on a D20).

With these breakdowns, we can say that someone fighting the dragon does seem in certain ways ‘closer’ than someone still outside the castle gates. But it’s not in the same way that a car with a paint job, interior work and wheels is ‘closer’ to being finished than a just a frame. There’s still some chance that the guy outside of the gates gets lucky and defeats the dragon before the guy at the dragon.

It’s less likely than our dragon fighter finishing first, but not impossible.

Summing Up

Creating a design is rolling a die. It has a chance of being good, and a chance of being bad. Hard projects tend to have more chances of failure than easy projects. But breaking through abounds. Each project can be measured in some minimum number of breakthroughs it needs to succeed, and those chances of success can be easily turned into estimates. But in a breakthrough driven development model, having put 20 days into a 20-day project means nothing. It’s no closer to success than when it started. It’s still most likely 20 days away.


February 7, 2017 Posted by | Uncategorized | Leave a comment