> At the time, software development was suffering from a mistaken belief: that building things fast and building things well were fundamentally opposed.
I thing “good, fast, cheap; pick 2” is still generally valid.
I thing “good, fast, cheap; pick 2” is still generally valid.
Or until the ever-growing pile of garbage that agile produces gets too tall and tips over. Then you throw away the codebase and start again :).
I've seen this before. After the second iteration it becomes neither fast nor cheap.
Management was not a huge fan of this piece of paper.
So I always felt that fast and cheap go hand in hand.
I think the triangle is:
- features
- quality
- cost (=both price & time)
Edit: I forgot to mention that you cannot just throw more engineers at a problem to make it go faster. There is such a thing as an optimal team size.
Another edit (sorry it's Friday evening here;)): The faster you can get it done, the cheaper it will be.
Therefore, if cost must be pegged due to limited time/funds and quality must be pegged due to existential risk then quantity/richness of features must float and be flexible.
All good product owners will learn this truth eventually.
This is unlikely to be true. Bad decisions are your biggest cost.
An employee has a "return multiplier" - for every dollar you spend on them, what is the return to the business? Sometimes it is high. If so, the developer is very cheap. Sometimes is it low, or negative. If so, the developer is expensive.
Why would it be high or low? Part of that is developer skill, but mostly it is how well your organization runs itself and makes decisions.
Organization is definitely a big factor.
But when I said developers are your biggest cost, this is from an accounting point of view.