(1) You actually do meet a developer from time to time who fetishizes complexity. More frequently, you'll find developers and managers who'll fight any attempt to reduce surplus complexity.
(2) I don't think the root cause of crappy software is the cost of quality. Quoth Phil Crosby, quality is free, it's the screw-ups that are expensive.
Nobody has suggested that the federal and state Obamacare sites failed because too little was spent on them. The way it was done, state by state, made the experience a laboratory of software development.
It was certainly possible to make an Obamacare site that works. New York had a rough first week, but at the beginning of Week 2 I had no trouble signing my mother-in-law up. Some states never processed a single application online.
The trouble wasn't that "quality is expensive" but more incompetence in management, procurement, etc.
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."
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.
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.
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.
(2) I don't think the root cause of crappy software is the cost of quality. Quoth Phil Crosby, quality is free, it's the screw-ups that are expensive.
Nobody has suggested that the federal and state Obamacare sites failed because too little was spent on them. The way it was done, state by state, made the experience a laboratory of software development.
It was certainly possible to make an Obamacare site that works. New York had a rough first week, but at the beginning of Week 2 I had no trouble signing my mother-in-law up. Some states never processed a single application online.
The trouble wasn't that "quality is expensive" but more incompetence in management, procurement, etc.