4 ms·

I think it's important to distinguish up-front cost versus long-term cost. In more than just this discussion. For example: plenty of people in the Bay Area wo

I think it's important to distinguish up-front cost versus long-term cost. In more than just this discussion. For example: plenty of people in the Bay Area would, long-term, find it cost-advantageous to own rather than rent -- if they could get together a 20% down payment. But they can't. So it's kind of irrelevant whether they'd save money long term. The same principle can apply to software. Sure, you'd save money long-term if you adhered to extremely high quality standards. But you wouldn't release this month -- and you need to release this month for your company to stay afloat. Figuring out when the short term cost is worth the long term savings is a great deal of the art of software product strategy. And I don't think we should just categorically sweep all such decisions -- even all such wrong decisions -- into the catch-all of "incompetence."

PaulHoule 12y ago
That's the language of failure. Technical debt strangles many products before they even get to market. The status quo of software development is that management won't face the facts of what software will cost so they chronically underestimate what an efficient software development effort would cost by a factor of two or three. Instead of laying out a realistic plan that will succeed, they embark on a hopeful plan that will certainly NOT succeed, and you end up with a 2/3 chance of failure and, if there is success, it costs a lot more than efficient development. Screwing around leads to going in circles, not delivering a product in the next month. If software managers focused on compressing the standard deviation of the schedule they'd come very close to least cost development, because screwing up is incredibly expensive.
- aetherson 12y ago
  Could we admit some nuance here? When we want to stigmatize people who plan too heavily for the future, we call it "overengineering." When we want to stigmatize people who plan not enough for the future, we do whatever you're doing above. The line between those two failure modes is relatively narrow and not at all obvious. There aren't simple heuristics that will infallibly put us onto the line, and acting like this is all black and white doesn't help anyone.
  - dllthomas 12y ago
    Even "line" is probably an oversimplification. Some projects probably have a large region, some a narrow line, and some might non-obviously have no such path.

PaulHoule 12y ago

That's the language of failure. Technical debt strangles many products before they even get to market. The status quo of software development is that management won't face the facts of what software will cost so they chronically underestimate what an efficient software development effort would cost by a factor of two or three. Instead of laying out a realistic plan that will succeed, they embark on a hopeful plan that will certainly NOT succeed, and you end up with a 2/3 chance of failure and, if there is success, it costs a lot more than efficient development. Screwing around leads to going in circles, not delivering a product in the next month. If software managers focused on compressing the standard deviation of the schedule they'd come very close to least cost development, because screwing up is incredibly expensive.

aetherson 12y ago
Could we admit some nuance here? When we want to stigmatize people who plan too heavily for the future, we call it "overengineering." When we want to stigmatize people who plan not enough for the future, we do whatever you're doing above. The line between those two failure modes is relatively narrow and not at all obvious. There aren't simple heuristics that will infallibly put us onto the line, and acting like this is all black and white doesn't help anyone.
- dllthomas 12y ago
  Even "line" is probably an oversimplification. Some projects probably have a large region, some a narrow line, and some might non-obviously have no such path.