Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Good, Cheap, Fast: pick 2

3 views
Skip to first unread message

David Alex Lamb

unread,
Dec 22, 1997, 3:00:00 AM12/22/97
to

In article <349929...@tagsys.com>,
Ladislav Bashtarz <ladi...@tagsys.com> wrote:
>
>i tell my clients that they can have it;
>
>1) cheap
>2) fast
>3) supporting their business

I first heard this as:
Good, Cheap, Fast: pick any 2
Does anybody know the origin of this phrase?

I can see how one can do (Cheap, Fast, not Good) since it seems possible from
complaints in this newsgroup that this is the dominant paradigm. How do you
manage the other two?
- (Fast, Good, not Cheap) Maybe hire the right number of very good (very
expensive) people, with the right infrastructure support?
- (Good, Cheap, not Fast) This one I'm really puzzled about
--
http://www.qucis.queensu.ca/home/dalamb/

Scott P. Duncan

unread,
Dec 22, 1997, 3:00:00 AM12/22/97
to

David Alex Lamb wrote:
>
> I can see how one can do (Cheap, Fast, not Good) since it seems
> possible from complaints in this newsgroup that this is the
> dominant paradigm.

Actually, if one believes the many stories about customer complaints
regarding software, the paradigm would seem to be (not Cheap, not
Fast, not so good)! Most places I worked would say that customers
think software projects cost too much, take too long, and fail to
deliver what was needed/expected/promised.

> - (Fast, Good, not Cheap) Maybe hire the right number of very
> good (very expensive) people, with the right infrastructure
> support?

Basically, I think this would characterize it or hire a larger
number of good but less expensive people. (For some, "fast" may
be that the project comes in on time.)

> - (Good, Cheap, not Fast) This one I'm really puzzled about

Hire a smaller team than one might expect for the job, reducing
cost factors that way and give them longer to work on it. The
smaller team takes longer but has better communication, often
less internal rework.

Eric G Roesinger

unread,
Dec 23, 1997, 3:00:00 AM12/23/97
to

dal...@qucis.queensu.ca (David Alex Lamb) wrote in <67mjct$b...@knot.queensu.ca>:

> In article <349929...@tagsys.com>,
> Ladislav Bashtarz <ladi...@tagsys.com> wrote:
> >
> >i tell my clients that they can have it;
> >
> >1) cheap
> >2) fast
> >3) supporting their business
>
> I first heard this as:
> Good, Cheap, Fast: pick any 2
> Does anybody know the origin of this phrase?
>
> I can see how one can do (Cheap, Fast, not Good) since it seems possible from
> complaints in this newsgroup that this is the dominant paradigm. How do you
> manage the other two?
> - (Fast, Good, not Cheap) Maybe hire the right number of very good (very
> expensive) people, with the right infrastructure support?
> - (Good, Cheap, not Fast) This one I'm really puzzled about

Simple, if you want it to be good and need it to be cheap, don't expect
it to be fast: it won't be!

Regards,

--
Eric G. Roesinger, SW Engr. : I'm speaking for myself, not my employer!
RF Comm. Product Development : -----------------------------------------
Audio & Communications Dept. : Practice, is no different than : Mt.27.:.
Thomson Consumer Electronics : theory in practice, in theory. : 45-54 :

Bill Bolton

unread,
Dec 23, 1997, 3:00:00 AM12/23/97
to

On 22 Dec 1997 20:43:09 GMT, dal...@qucis.queensu.ca (David Alex Lamb)
wrote:

>I first heard this as:
> Good, Cheap, Fast: pick any 2
>Does anybody know the origin of this phrase?

I believe it originated in the printing industry.

Cheers,

Bill

Bill Bolton billb...@acslink.net.au
Sydney, Australia

Jeffrey C. Dege

unread,
Dec 23, 1997, 3:00:00 AM12/23/97
to

On 22 Dec 1997 20:43:09 GMT, David Alex Lamb <dal...@qucis.queensu.ca> wrote:
>
>I can see how one can do (Cheap, Fast, not Good) since it seems possible from
>complaints in this newsgroup that this is the dominant paradigm. How do you
>manage the other two?
> - (Fast, Good, not Cheap) Maybe hire the right number of very good (very
> expensive) people, with the right infrastructure support?
> - (Good, Cheap, not Fast) This one I'm really puzzled about

Look at Putnam and Myers "Measures for Excellence" (Yourdon Press 1992).
Their data finds a strong negative correlation between development effort
and schedule. Modest increases in schedule can dramatically reduce total
cost of development. They also identify a maximum manpower buildup rate
that for any given organization is nearly constant. Their conclusion
is that for any given project and organization, there is a given fixed
minumum development time, which is also the most expensive.

For an example system of 60 kloc, the minimum development time might be
13 months, with a total effort of 78 manmonths and a peak staffing of 9.
The same project could be accomplished in 14 months, with a total effort
of 51 manmonths, and a peak staffing of 5, or in 15 months, with an
effort of 38 manmonths and a peack staffing of 4.

Of course, as I do with most software estimating researches, I think
he's reading more accuracy into his numbers than are really there,
but the core ideas, there is a minimum time beyond which schedule
_CANNOT_ be squeezed, and that there are significant productivity
efficiencies that can be gained by planning for a more relaxed
schedule, are both basically true.

--
.sig under construction


Dave Vance

unread,
Dec 23, 1997, 3:00:00 AM12/23/97
to

The way I've usually seen this represented is as a triangle with
"quality", "cost", and "schedule" at the points (or "Good", "Fast", and
"Cheap", take your pick). Any project is somewhere inside the triangle;
with the points representing the best possible for that requirement.
Moving closer to any side or any point moves you farther from others.
So, you can:

- get an amazing amount of quality from a long and expensive project,

- Increase quality and shorten schedule by spending more,

- Get something useless to market very quickly and cheaply, etc, etc.

This is a useful tool, by the way, not a biblical edict. You don't
ALWAYS have to spend more to increase quality and shorten schedule, for
instance. But it DOES describe the way things usually work, and I find
the triangle useful when trying to get a customer to prioritize their
requirements (as in, "which 2 of the 3 are most important to you?").
And when you're trying to get out of a hole, you can usually move
towards two of the points at the expense of the other.

- Dave -


David Alex Lamb wrote:
>
> In article <349929...@tagsys.com>,
> Ladislav Bashtarz <ladi...@tagsys.com> wrote:
> >
> >i tell my clients that they can have it;
> >
> >1) cheap
> >2) fast
> >3) supporting their business
>

> I first heard this as:
> Good, Cheap, Fast: pick any 2
> Does anybody know the origin of this phrase?
>

> I can see how one can do (Cheap, Fast, not Good) since it seems possible from
> complaints in this newsgroup that this is the dominant paradigm. How do you
> manage the other two?
> - (Fast, Good, not Cheap) Maybe hire the right number of very good (very
> expensive) people, with the right infrastructure support?
> - (Good, Cheap, not Fast) This one I'm really puzzled about

> --
> http://www.qucis.queensu.ca/home/dalamb/

Dave Vance

unread,
Dec 23, 1997, 3:00:00 AM12/23/97
to

Jeffrey C. Dege wrote:
>
> Look at Putnam and Myers "Measures for Excellence" (Yourdon Press 1992).
> Their data finds a strong negative correlation between development effort
> and schedule. Modest increases in schedule can dramatically reduce total
> cost of development. They also identify a maximum manpower buildup rate
> that for any given organization is nearly constant. Their conclusion
> is that for any given project and organization, there is a given fixed
> minumum development time, which is also the most expensive.
>

I would agree with you up to a point; your example assumes wildly
varying productivity for the 3 schedules, but you might not have
intended it to be taken literally :-)! My experience has been that it's
an inverted bell curve for cost, with the left side of the bell being
flatter than the right. In other words, there's an optimum cheapest
schedule that's longer than the minimum. As you shorten the schedule
towards the minimum, cost goes up, but not dramatically. As you
increase the schedule from the optimum, cost also goes up; more
dramatically, in my experience, because you're keeping infrastructure
and support around longer for the project.

The other problem is often people are re-assessing schedule in the
middle of a project, when they already have a certain staffing level.
From that point any increase in schedule ALMOST ALWAYS increases cost,
even if only because it takes some non-trivial time and effort to allow
the people you don't need anymore time to move to another project!

It's one person's experience; note I haven't seen any studies along
these lines!

- Dave -

George X. Kambic

unread,
Dec 23, 1997, 3:00:00 AM12/23/97
to

David Alex Lamb wrote:
>
> In article <349929...@tagsys.com>,
> Ladislav Bashtarz <ladi...@tagsys.com> wrote:
> >
> >i tell my clients that they can have it;
> >
> >1) cheap
> >2) fast
> >3) supporting their business
>
> I first heard this as:
> Good, Cheap, Fast: pick any 2
> Does anybody know the origin of this phrase?
>
> I can see how one can do (Cheap, Fast, not Good) since it seems possible from
> complaints in this newsgroup that this is the dominant paradigm. How do you
> manage the other two?
> - (Fast, Good, not Cheap) Maybe hire the right number of very good (very
> expensive) people, with the right infrastructure support?
> - (Good, Cheap, not Fast) This one I'm really puzzled about
> --
> http://www.qucis.queensu.ca/home/dalamb/

Well, I remember using it around our company in 1976 or so. I
don't know the origin, but would bet it is in some project
management book somewhere.

Billy Chambless

unread,
Dec 23, 1997, 3:00:00 AM12/23/97
to

In article <67mjct$b...@knot.queensu.ca>, dal...@qucis.queensu.ca (David Alex Lamb) writes:

|> I first heard this as:
|> Good, Cheap, Fast: pick any 2
|> Does anybody know the origin of this phrase?

|> I can see how one can do (Cheap, Fast, not Good) since it seems possible from
|> complaints in this newsgroup that this is the dominant paradigm. How do you
|> manage the other two?

|> - (Fast, Good, not Cheap) Maybe hire the right number of very good (very
|> expensive) people, with the right infrastructure support?

Or more than the "right" number of really good people. As the number of
devlopers passes the optimal number, there is a productivity increase,
but it's diminished, due to communication overhead.

|> - (Good, Cheap, not Fast) This one I'm really puzzled about

Imagine a single truly brilliant programmer slaving away. Eventually,
the product will ship, and be of high quality. But it will take a
while.

Jeffrey C. Dege

unread,
Dec 24, 1997, 3:00:00 AM12/24/97
to

On Tue, 23 Dec 1997 09:58:24 -0600, Dave Vance <dva...@vnet.ibm.com> wrote:
>Jeffrey C. Dege wrote:
>>
>> Look at Putnam and Myers "Measures for Excellence" (Yourdon Press 1992).
>> Their data finds a strong negative correlation between development effort
>> and schedule. Modest increases in schedule can dramatically reduce total
>> cost of development. They also identify a maximum manpower buildup rate
>> that for any given organization is nearly constant. Their conclusion
>> is that for any given project and organization, there is a given fixed
>> minumum development time, which is also the most expensive.
>
> I would agree with you up to a point; your example assumes wildly
>varying productivity for the 3 schedules, but you might not have
>intended it to be taken literally :-)! My experience has been that it's
>an inverted bell curve for cost, with the left side of the bell being
>flatter than the right. In other words, there's an optimum cheapest
>schedule that's longer than the minimum. As you shorten the schedule
>towards the minimum, cost goes up, but not dramatically. As you
>increase the schedule from the optimum, cost also goes up; more
>dramatically, in my experience, because you're keeping infrastructure
>and support around longer for the project.

His observation is that projects that planned for longer than minimum
development time were noticably cheaper than projects that planned
for the minimum development time. A longer time for the same amount
of work means fewer programmers, hence less communications cost,
less training costs, fewer development and testing machines, reduced
office support overhead, etc. Beyond that, lack of schedule pressure
means that the developers can identify common substructure, resulting
in more reuse and a more cohesive architecture.

Of course, this assumes an actual project plan. Unplanned projects
can have no meaningful prediction of cost. If the whole of the
plan is for the programmers to work until its done, with no
real definition of just what done is, it may never get done,
and costs can be very high then.

--
.sig under construction


Karl E Wiegers

unread,
Dec 30, 1997, 3:00:00 AM12/30/97
to

In article <349FD9...@vnet.ibm.com>,

Dave Vance <dva...@vnet.ibm.com> wrote:
>The way I've usually seen this represented is as a triangle with
>"quality", "cost", and "schedule" at the points (or "Good", "Fast", and
>"Cheap", take your pick). Any project is somewhere inside the triangle;
>with the points representing the best possible for that requirement.
>Moving closer to any side or any point moves you farther from others.

I struggled for a long time to figure out how to represent these kinds of
tradeoffs. In my book, "Creating a Software Engineering Culture," I describe
an approach involving 5 dimensions of a SW project: cost, features, quality,
schedule, and staff. On any project, each of these dimensions can be a
constraint (fixed value, no latitude), a driver (prime objective of the
project), or a degree of freedom (project manager has some degree of
latitude to trade those dimensions off against each other to accomplish
the driver within the constraints). They can't all be drivers or constraints!

I use a Kiviat diagram as a simple, qualitative way to represent how
much flexibility the project manager has in each dimension, to make the
project succeed. This is just a tool for having important conversations
about what the key project objectives are, and what the project manager
can stretch, bend, and trade off to achieve those objectives.

--
Karl Wiegers kwie...@kodak.com
Eastman Kodak Company phone: (716) 781-9152
343 State Street fax: (716) 724-7434
Rochester, NY 14650-0546
Opinions expressed here are almost certainly unique to me.
--

Scott P. Duncan

unread,
Jan 2, 1998, 3:00:00 AM1/2/98
to

Karl E Wiegers wrote:
>
> In my book, "Creating a Software Engineering Culture,"

Anyone read this (besides myself)? I've had the chance to hear
Karl speak twice about the ideas in the book as well: '97 SEPG
in San Jose and the ASQ 7th Int'l Conf. on S/W Quality in Mont-
gomery (AL).

Billy Chambless

unread,
Jan 2, 1998, 3:00:00 AM1/2/98
to

In article <34ACE0...@mindspring.com>, "Scott P. Duncan" <soft...@mindspring.com> writes:
|> Karl E Wiegers wrote:
|> >
|> > In my book, "Creating a Software Engineering Culture,"
|>
|> Anyone read this (besides myself)? I've had the chance to hear
|> Karl speak twice about the ideas in the book as well: '97 SEPG

Yes; I think it's a great book. Lots of useful insights in t.ti.

0 new messages