4 ms·

> At the time, software development was suffering from a mistaken belief: that building things fast and building things well were fundamentally opposed. I thin

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

namdnay 7y ago
Sometimes I’m not sure you can have just good and fast, however much money you throw at it. Some things just take time to work through.
koonsolo 7y ago
Developers are your biggest cost, so I never understood why fast and cheap would be opposed to each other. And if you buy off the shelve, most of the time it's both faster and cheaper than building it yourself. 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.
- EdSharkey 7y ago
  We have to peg quality with rigorous testing or else cost (time spent) will be variable upwards to infinity (due to accumulation of untenable technical debt). 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.
- OrangeMango 7y ago
  > Developers are your biggest cost 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.
  - koonsolo 7y ago
    I 100% agree with you. I have this in my head like this: a developer with a low rate might be very expensive, and a developer with a high rate might be very cheap. Organization is definitely a big factor. But when I said developers are your biggest cost, this is from an accounting point of view.
riazrizvi 7y ago
Note to self: Remember whenever you think "Good,fast,cheap; pick 2", it frames your choices as either "produce something not-good" or "produce something and take your time or hire lots of people". You are again regressing to your ivory-tower-inventor tendency, you spend too long perfecting and the perfecting gets worse and worse. Instead it's "fast+cheap, fast+cheap, fast+cheap" to minimize the time between customer-hypothesis and customer-trial. You do that until you achieve "good enough". This is the surest and most economical way to achieve "good". This is agile.
- MattGaiser 7y ago
  > until you achieve "good enough". 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 :).
  - analyst74 7y ago
    This is the way.
- Tade0 7y ago
  > Instead it's "fast+cheap, fast+cheap, fast+cheap" I've seen this before. After the second iteration it becomes neither fast nor cheap.
  - joejerryronnie 7y ago
    A colleague once had a paper taped to the outside wall of their cubicle which read “Why do we never have time to build it right, but we always have time to build it over again?” Management was not a huge fan of this piece of paper.

namdnay 7y ago

Sometimes I’m not sure you can have just good and fast, however much money you throw at it. Some things just take time to work through.

koonsolo 7y ago

Developers are your biggest cost, so I never understood why fast and cheap would be opposed to each other. And if you buy off the shelve, most of the time it's both faster and cheaper than building it yourself. 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.

EdSharkey 7y ago
We have to peg quality with rigorous testing or else cost (time spent) will be variable upwards to infinity (due to accumulation of untenable technical debt). 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.
OrangeMango 7y ago
> Developers are your biggest cost 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.
- koonsolo 7y ago
  I 100% agree with you. I have this in my head like this: a developer with a low rate might be very expensive, and a developer with a high rate might be very cheap. Organization is definitely a big factor. But when I said developers are your biggest cost, this is from an accounting point of view.

riazrizvi 7y ago

Note to self: Remember whenever you think "Good,fast,cheap; pick 2", it frames your choices as either "produce something not-good" or "produce something and take your time or hire lots of people". You are again regressing to your ivory-tower-inventor tendency, you spend too long perfecting and the perfecting gets worse and worse. Instead it's "fast+cheap, fast+cheap, fast+cheap" to minimize the time between customer-hypothesis and customer-trial. You do that until you achieve "good enough". This is the surest and most economical way to achieve "good". This is agile.

MattGaiser 7y ago
> until you achieve "good enough". 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 :).
- analyst74 7y ago
  This is the way.
Tade0 7y ago
> Instead it's "fast+cheap, fast+cheap, fast+cheap" I've seen this before. After the second iteration it becomes neither fast nor cheap.
- joejerryronnie 7y ago
  A colleague once had a paper taped to the outside wall of their cubicle which read “Why do we never have time to build it right, but we always have time to build it over again?” Management was not a huge fan of this piece of paper.