The Project Management Triangle "fast-cheap-good (pick two, you can't have all three)" is something I've never agreed with.

How would you promise to build something good & cheap?
Doing it slowly will not really make it cheaper. The cost is usually development hours. If it takes 40 hours to make a good product - doing it 2 hours per day isn't going to make it cheaper.

Slower doesn't make it cheaper, but faster does make it more expensive. Cheap and good doesn't mean it will be done slowly, it means it won't be done fast. Just as fast and good means it won't be cheap, and fast and cheap means it won't be good.

fast + good = expensive, you need to hire a lot of skilled people to make this happen

fast + cheap = bad, you need to hire a lot of people, but you wont be able to pay the good ones. This may end up requiring further investment later on to make it better

cheap + good = slow, you hire only a few skilled people, so it will take them longer because you can only pay a few of those at that level, but the result will be a stable product with better design choices. This could be preferable to doing it fast + cheap because the product shouldn't need much further investment

either way, the triangle mostly exists as a simple estimation tool to show clients that saying "I want it fast, good and cheap" is nonsense. Think of it rather as a rule of thumb rather than some sort of mathematical law of management

@NotJeckel this is exactly what I'm arguing against

"cheap + good = slow, you hire only a
few skilled people, so it will take them
longer because you can only pay a few
of those at that level, but the result will
be a stable product with better design
choices."

In which way is that cheap?

@NotJeckel "Slower doesn't make it cheaper, but
faster does make it more expensive."

the idea the model presents is it that speed is the only trade off you would need to make it good & cheap.

Or are you're saying "cheap" doesn't exist in this model - there are only two options a) normal average price b) expensive

@Hazarth 'the triangle mostly exists as
a simple estimation tool to show clients
that saying "I want it fast, good and
cheap" is nonsense.'

Yes but when the second sentence is "So you can't have all 3 but you can have 2 - that's not nonsense"

That just makes me go 😰 "It's STILL nonsense - can't be tricking clients into thinking really good product can be done for cheap just by changing time constraints..."

@jiraTicket Not choosing fast doesn't mean the developers will do things slower than normal, it just means they won't do it faster than normal.

Don't overthink the semantics, it's just a rule of thumb, not a logical model with sharply defined terminology. If you understand that time, cost, and quality are interconnected and affect each other, then you get what it's trying to say.

Don't tell the managers, but software development indeed is a lot like making babies - you can't just get two devs and expect it to get done in half the time.

So yes, for most projects, you can't actually pick fast because team sizes don't scale and projects are often pretty hard to divide into pieces that actually fit together when done by different teams.
It gets a bit better with larger projects where extensive interface design between parts is feasible.

On top of that, dev salery is a pretty bad predictor for code quality.
Low speed also doesn't predict good quality - but high speed pretty much guarantees truckloads of bugs and low maintainability.

The triangle is just to give them peace of mind. They always choose cheap and still expect quality anyways. So at least they don't feel the need to check on progress every hour...

@Oktokolo I agree. Fred Brooks said 'What one programmer can do in one month, two programmers can do in two months. 😆

It's easy to split isolated tasks but increasing speed for a single task beyond one full time dev is hard.

@NotJeckel I get the rough idea and yeah I might be nitpicking but just feel like ranting about how this concept could sound more convincing with some tweaks.

I guess part of the problem with this is wording it as "fast - cheap - good"

rather than "speed - cost - quality".

I'd have fewer problems saying "You can prioritise quality and cost" rather than "good and cheap".

Cause that leaves room for changing it from "cheap" to "not super expensive"

Easy. Cheap doesn't refer to the cost in dev hours (abstract). It refers to actual money being paid (concrete).

@nitnip Yeah but what are the other main costs apart from dev hours? Hardware costs? - They are usually only relevant for entire new projects - not individual features.

And how would you reduce these costs just because you could slow down on the deadline?

At my first job as a software dev I was paid 2.5 (2013) euros per hour and my friend that was a good wage back then. Peers envied me :)

This is cheap part