3 ms·

I wasn't defining "broken" as "the engineers find it distasteful". I was defining it as "broken". I agree with this: > 6 months to deliver 2 applications that

I wasn't defining "broken" as "the engineers find it distasteful". I was defining it as "broken". I agree with this: > 6 months to deliver 2 applications that each work 80% often provides more business value than 6 months to provide one application that works 100%. Though this is a question of product management prioritisation, not engineering practice. "It's faster to not write tests" depends entirely on a definition of completion that ignores the cost of repairing defects and coping with faults and failures in production.

BoiledCabbage 7y ago
> I wasn't defining "broken" as "the engineers find it distasteful". I was defining it as "broken". If a piece of software literally will not launch period, then it is broken. If it can do pretty much anything more than that, then it "works to some degree", and just has some number of scenarios that are broken. And my point is that if it has 80% of scenarios that work and 20% of scenarios that are completely functionally broken (ie do not work at all for the customer) that still provides business value. That's the point I'm making. It's not ideal, but in the real world half broken software is immensely valuable. > Software that's broken in preventable ways doesn't solve business problems, it just creates new ones. So software that is broken in preventable ways, absolutely does solve business problems. And just about the entire software industry is proof of this.