Good / Cheap / Fast: Which two?

Question

I have heard the phrase: "Good, cheap, and fast: pick two."

For programming projects is there usually a "best two?"

Answer 1

Good and fast !

Answer 2

I always strive to go with Good and Fast. Often what is delivered is Cheap and Fast, sadly.

I think the frequent mistake people make is to go with "cheap" without considering a total cost over the project life cycle, including support and maintenance. If initial bids included these extra items (which I suggest are far more costly for "cheap" projects than non-cheap projects) the cheap option often looks less appealing (and is often the most expensive in the long run).

Just some thoughts from my experience...

Answer 3

That is entirely dependent on your clients.

If they're willing to pay, good and fast is always the preference...

Answer 4

It really depends on the project. For startups which have a money constraint, cheap and fast are generally is the best approach. If you have unlimited money, obviously choosing fast and good is the best approach. It varies from situation to situation.

Answer 5

I prefer Good and Fast... The business always chooses Cheap and Fast

Answer 6

Personally, I think it usually depends on the nature of the project and quite possibly the clients. Cheap and good are usually for people with low budgets. Good and fast are for clients with a bigger budget and potentially could lead to more projects.

Answer 7

if you don't want to spend money good and cheap is better

Answer 8

It's just a simpler statement of budget vs time vs scope. Two are fixed, one is variable.

The problem is, they pretty much always want all 3...

Answer 9

It depends on the project and the available resources that the customer has. There's no single answer.

Answer 10

Good is subjective go for cheap and fast. At least that way if it's bad (which is the same as someone else's good) you can throw it away with minimum fuss.

Answer 11

Another way to look at this is that there are basically four variables that you can control to a greater or lesser extent.

• Quality
• Scope
• Resources
• Time

Of these four, generally you want to fix Quality high, though there are exceptions. Resources are best added beforehand and thus are also reasonably fixed unless your timeline is very long. The trade-off, then, is usually between Scope (what) and Time (how long). My preference is to reduce Scope and meet deadlines if what I can deliver still has value. Often this is in the context of a particular iteration and the dropped features will be added later, perhaps increasing the overall Time of the project.

In your pantheon, I suppose this would equate to Good and Fast.

Answer 12

Empirically, I'd say most projects tend to go with Cheap and Fast. The fraction of Good software I've seen in my life is vanishingly small...

Answer 13

The best 2 - good & fast

The reality - fast & cheap

Answer 14

Most engineers will tell you that they want to do good work. That's fairly natural. Almost nobody likes the idea of looking back over their life's work and seeing a ton of cheap crap they made. You'd like to be able to have a little pride in what you spend your life doing.

This isn't restricted to software. If you find yourself a good mechanic, someone who enjoys the work, they will always try to get you to fix things right. For example, they'll push for a $600 engine job on an old used car to fix a bunch of slow oil leaks that won't cost you anywhere near $600 in oil over its lifetime. I used to think they were all looking to bilk me, but that's not it at all. They just want to do the job right.

Understanding that our customers and non-engineer bosses look at us the same way we look at that auto mechanic is the beginning of wisdom.

Answer 15

My experience is that only ONE of them is actually possible

Answer 16

Open Source => Good & Cheap

Answer 17

Like everyone else, I would prefer good and fast.

But I think that's too simplistic. Picking cheap will eventually undercut the good in the long run. Sometimes, choosing fast can too, as innovation should involve a more higher degree of prototyping and testing.

Of course, each project has different conditions (and levels of complexity, innovation, and economies of scale), but generally I think that truly good really means you can't be too cheap or too fast.

Answer 18

A subjective, non-programming question that did not get closed. Who would have thought that was possible...

edit - dang, looks like I entered my post too soon...

Answer 19

There's a quality that's good enough, a speed that's fast enough, and a price that's cheap enough. If you can't get all three, it's not going to be enough, and you should stop and rethink your project.

Answer 20

Clients want everything, yesterday, for no cost.

It's finding a balance in each request that helps determine is this something I fight for (Good and Fast) or save them some money because it's not that important or they might not use it as much as they want (Good and Cheap).

The third option, Fast and Cheap, doesn't imply it won't be good to me thought. More like, we are implementing less to meet your budget and timeline and make sure we implement it well.

What about when there isn't an option?

In trying to pick 2 of Good, Fast or Cheap, I use a simple test:

1) How important is it? 2) How complicated is it? 3) How long will it take before you think you can do it faster?

Based on these answers, I try to fight for the following:

- Is it simple? Really? Fast and Cheap is probably good enough. Start with the approach of it will be faster and cheaper if we start with something simple and build it out how you need it, if you need it. Otherwise we will do all this work and have to change it anyways, using up that time anyways. This might be agile development in some ways.

- Is it complicated? Really? If it's so critical and necessary, are you sure you aren't over engineering?

- Can I deliver immediately in bite sizes? How is it that they make do now? Wouldn't even a simple solution that does a few core and critical things, make a big difference over how it's being done now? Then, it's likely better to do less, but do it well and cheap. My rule of thumb is to always start with small victories that have a larger impact than their effort and let them snowball and gain momentum into the big system. No one loves getting a system quicker than they wanted. So, you give it to them, a feature or three at a time. Just make sure your testing and signoff process is there.

Just some ideas, hope it is some food for thought.