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 :-)

Ha! I was thinking the same thing Craig.

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 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.

The whole triangle/stool thing is a bit weak. The triangle is trying to say "there are three variables, time resources and functionality, and a relationship linking them". I.e., there's a solution surface, in a 3D space, and the project can go anywhere on that solution surface but not off it. The stool brings in quality as a fourth variable, so you then have a 4D space with a solution hypersurface.

The point is, the triangle drawing can't show you the solution surface (it's one dimension short for showing that) and the stool can't show you the hypersurface (still one short). The pictures don't let you see the answer which is very disappointing. Worse, the simple drawings for non-mathematical folk encourage one to guess that the solution (hyper-)surface is a simple shape. It's not for most projects; it's full of warps and folds and loops.

BTW, for non-software work, isn't quality treated as part of functionality? Quantifiable quality, that is: MTTF, out-of-spec widgets per 1000, etc.; "fitness for purpose".

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.

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?

> 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 :) 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.

I'm with J. Michael Palermo IV in saying that functionality and quality are related, but I would say that quality is a subset of functionality. Features (functionality) really exist only if they are used, and they're used only when they don't suck.

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>

Great topic - I wrote an article about this a while back (http://www.basilv.com/psd/blog/2006/understanding-project-schedules), and have a java applet that provides a visualization of the 4 variables (http://www.basilv.com/psd/software-files/launchManagementDiamond.html).

I agree that it is possible to 'make your stool more malleable', to use your analogy - i.e. to for example improve your quality without increasing the time required. For many projects and especially for the project managers, however, I feel they are trying to irrationally shorten all the legs of the stool/pyramid, so for those I'd prefer to send the message that the stool is made of iron. Only once you have come to understand and accept that can you move beyond the iron to more malleable substances.

You're wrong. Quality is free; often quality is cheaper than free because it saves wasted time and rework. Think win/win.

To me, the center of software engineering is developing designs and practices that improve quality and lower cost at the same time. Unfortunately the software industry is focused on the 1950's "quality = testing" model... Only the most advanced shops have caught up with the 1980's ISO movement thinking.

To take an example, the other day I was finishing a web application that somebody else started. There were two controlled vocabulary terms that appeared in dropdown lists, and a rather nice editor that administrators could use to edit the list. Or rather, two copies of a rather nice list editor that were each hard coded to edit a particular variable.

I had to add a third, and maybe a fourth controlled vocabulary term. I could have "cut and pasted" one of the list editors, doing a "search and replace" for three parameters that the list depended on, and specialized it for the new controlled vocabulary terms.

Instead, I turned it into a class which took those three parameters as arguments. It took a while to replace the first dropdown, a little less time to replace the second dropdown... And just five minutes to add the third. The next day I heard from the client and understood the client needed something different, and it took less than ten minutes to make it right.

And now I've got a nice dropdown editor class I can drop into my next project -- that will save me both development and testing time, because I know that particular module is low in defects.

Bad quality costs a lot in development time. The other day I spent an hour and a half doing a job which should have take five minutes. It turned out that the database drivers were wonky, some of my subroutines were wonky, and some of the subroutines written by the last programmer were wonky. Perhaps I "should" have used an existing subroutine, but that subroutine had an error-prone interface that I didn't agree with. That left me having to duplicate some logic that I didn't want to duplicate. The database drivers didn't report errors correctly, so it took me forever to figure out what was wrong with my SQL. Here, bad quality == wasted developer time. The client may never see these hidden defects, but they make me miserable.

Of course, the scope for reuse depends on what you do. The most exciting development in the Software Engineering is Software Product Lines -- probably the first real "silver bullet" that lowers cost and time-to-market while increasing functionality and quality.

The idea of SPL is that a programming shop can develop assets and practices to create a "software factory" that can rapidly turn out products that are a variation on a theme. You get the flexibility of custom software, with the cost and profitability benefits of mass market software.

Win/Win thinking benefits everyone. It saves money for clients, makes your business more profitable, and sets your programmers free to do creative work rather than continuous rework.

I maintain that quality is a feature, not a separate dimension. "Quality", in this case, refers to Testing, Training, and Documentation - all of which are often "features" that get cut from the list to make the Schedule.

http://www.cazh1.com/blogger/thoughts/2006/10/iron-triangle-quality-is-feature-that.shtml

My boss had a triangle analogy as well, but his was:
1. Stuff works
2. Customer is happy
3. On time/budget
His thing was that it was relatively easy to get 2 out of 3, but difficult to get all 3.

product, cost and time is adequate to describe it. don't need 4.

product = features, quality, service, hardware, software etc.
cost = money, effort, resource (human, hardware, software) etc
time = dates, schedule, milestones etc

quality is just a characteristic of the product.

I think a good way to look at it is:

c = cost
s = speed
q = quality

c = s + q

Graphed in 3D this function is a plane.