The Iron Stool

In classic project management parlance , every project is a combination of money, scope and time.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/10/the-iron-stool.html

you can have it: fast, cheap, good. pick two.

I like the fast, cheap, good analogy. It just seems to work out that way.

I can sure relate, several libraries I’ve been required to use for various projects were obviously stool.

Fast (Time), Cheap (Money), Good (Quality)
That puts resources and functionality into the Money category, but that’s not as intuitive or flexible as the “stool” analogy. Could we call it a “pyramid” in casual discussions since “tetrahedron” might leave people staring blankly and “stool” just diverts the listener into comedy? Of course, the pyramids in Egypt are pentahedrons so that might be confusing too…we still need to work on our analogies…

The source of the contradiction is that it only makes sense to discuss trading off optimizations if you’re already on the Pareto optimality frontier of the system, which, in English, means that you really are at the point where you can not have more of X without giving up some Y.

In the real world, people often like to jump straight to talking about tradeoffs without first figuring out whether they’ve actually reached the point that they need to make tradeoffs. I think the most common example I see in a non-programming context is the discussion about the allegded tradeoff between security and freedom. We only have to tradeoff if we have already intelligently implemented our security system, but in the real world, there are many ways, even some very easy ones, that we could make ourselves safer and harden our society without affecting our freedoms at all.

In the programming world, it is true that you will eventually reach the point where you must trade off time for resources, but if you’ve got actual waste in the system, the better thing to do (at least in theory) is to attack the waste directly. By eliminating that waste, you can have your cake and eat it.

On the flip side, it is important to realize that eventually you will have effectively eliminated that waste (you can only get to 100% efficiency in theory), and if you start eliminating waste it’s important to realize that you’re not really cheating the need to trade off, you’re merely climbing out of the hole you were in. When you’re done claiming the low-hanging fruit, it’s important not to get annoyed with your programmers/managers that they get to the point where they have to make tradeoffs. Getting away without tradeoffs only worked because your previous system was pathological. (Given how rarely people seem to reach this point this is a mostly theoretical concern, but it’s worth pointing out.)

It’s still a triangle.
The length of the sides correspond to the three factors.
The area of the triangle represents quality.

(Although I’ve seen diagrams showing quality as the area of a circle inscribed in the triangle, but that’s harder to explain)

Budget: more $$ = longer side.
Resources: more resources = longer side.
Time: more time = longer side.

Nice analogy Jeff (ans Susan). It simply identifies that this is a problem in three dimensions. However, I agree that the term stool does divert the reader to comedy.

So in the spirit of comedy…

http://en.wikipedia.org/wiki/Bristol_scale

I tend to group quality and functionality as one and split resources to budget and man power. But the argument follows would be similar.

I thought it’s a question has been discussing for 30 years since Brooks’s Mythical Man-Month, which argues that em"man and month are not interchangable"/em, and do not forget the diminishing mirginal productivity: adding one production factor alone continuously eventually degrades the whole stuff. I think the same holds for the man-quality, quality-budget or budget-time pairs, so the analogy of stool or
pyramid can’t be correct… you have to expect in software development that spending a lot in a prolonged timeline with a team of 1000 developers can still give you a mess.

I think the premise is slightly flawed:

  1. Here’s what we’re going to do
  2. Here’s how much time we have to do it
  3. Here’s how much money we can spend doing it.

Should be:

  1. Here’s what the user wants
  2. Here’s how long it will take
  3. If we only do this much instead of all of it, you will save X dollars and Y time.
  4. When you (the user) get some more money and time, we will build more of it.
  5. Functionality is in proportion to how much time and money the user has.
  6. If you monkey with the equation in (5), you get less quality.
  7. If you make us do stupid things (like test something before it’s finished), everything known to man suffers.

And here, I thought you were talking about eating too much cheese or something :slight_smile:

Ha! I was thinking the same thing Craig.

I like the stool analogy. With quality being where you put your own seat. That’s how it usually feels later when it comes to maintaining the thing.

I’d read somewhere back that there were four vairables (as stated above), but one can only control three…at the cost of the fourth. The idea has stuck with me, and as a developer (who escaped the evils of mgmt) I subversivley promote quality.

Why subversivley?

Ask an internal/external customer about quality, and they say they want it…but they don’t want to pay for it. When deadlines loom and budgets are blown, quality is all to frequently the first casualty.

Maybe it is because it is so dificult to meassure? Maybe because even the definition alone is difficult to state?

Its more like:

  1. Heres what actually needs to be done
  2. Heres what the client asks for (generally #1)
  3. Heres what my boss promised the client (#2)
  4. Heres the time until the client needs it.
  5. Heres the time frame they say they need it in (#4)
  6. Heres the time frame my boss promises it in (#5)

And so on… Until I am at work late into the night trying futilely to meet an impossible deadline for software that isn’t up to par because I am either hyped up on 4 cups of coffee or half asleep doing it, when it isn’t needed for months…

/rant

Could we call it a “pyramid” in casual discussions since “tetrahedron” might leave people staring blankly and “stool” just diverts the listener into comedy?

I wanted the title to be intriguing but not pure comedy. I don’t like to do this, but I took the liberty of removing a few comments that were off topic. I suppose it’s my own fault…

The interesting thing about the stool is that it recognizes that, in software development, quality is separate from the main spec…which is where we go wrong.

The issue with software is that it’s incredibly difficult to quantify “Quality”. But you can certainly count how many people you have, how many days you have to do something, and the amount of money you’re allocated. That’s why quality takes a beating when you’re pinned down on the other three resources. On a manufacturing assembly line, sure. For example: how do you quantify the quality difference between an iPod and a Taiwanese knockoff? It’s partly hardware design, but also software…

I would not call the third facet of the triange “Functionality” - it would be “Quality”, of which functionality is a subset of.

The stool analogy is poor because it suggests that Time, Resource, and Functionality must be equal to give a quality product.

I can see the desire to separate functionality and quality, but I’ve never seen the triangle analogy break down when they were combined.

Matt V wrote “The area of the triangle represents quality.”

No, you can have a small scope (just a small amount of functionality to implement) with small budget, and it can still be good.

The way the stool works, they have to be equal, or quality literally falls over and slips :slight_smile: I.e. if you have a big scope (lots of functionality) and no budget.

However, we also have the Mythical Man Month problem with iron triangle’s “money” (resources) side.

Oops, sorry, in my second sentence, s/and no budget./and no time.