Because the high level business model remains the same. Seeking perpetually increasing short term profitability instead of long term sustainability. Carrot on a stick.

This is such a popular misconception amongst the nerd set. Perhaps because there's a great us v. them narrative implicit in it. I suspect what initially birthed it was a basic misapprehension common to people who have great faith in their own intelligence and opinions - that of needing to ascribe stupidity to people who don't seem to share viewpoints.

I won't bother citing because it's literally overwhelming, but it's pretty clear that there are many companies producing software with the long-term view in mind, and I bet every single one of them is subject to schedule issues.

I've certainly been on teams with long-term thinking embedded in the process and spent time explaining delays, which is of course merely an anecdote, but rather suggestive of things not being as black and white as you'd like to present them.

edit: minor wording cleanups

'such a popular misconception amongst the nerd set'

Um, maybe its just been the places I've worked at, but I've been repeatedly told "we should ship software rather than get everything perfect".

I agree, at the same time, most if not all of the problems I've encountered (including ones I've built for myself) have been because of this impatience.

This describes pretty much every type of project ever. Not saying everything lags 100% of the time but most significant projects miss initial schedules. Software has some unique characteristics to be sure, but it's not atypical. (And things like large construction projects tend to be even worse.)

> ... for the technological progresses ...

You've answered it yourself :-) It's not a technical problem, it's a social issue.

Feature creep, over optimistic estimates, business needs changing, and misunderstanding the requirements would be at the top of my list.

No-one's willing to take the huge amount of time it takes to design a software system and accurately estimate how long it will take to build it.

They're happy to pretend good estimates are possible without that, though, and complain endlessly about how bad estimates always are.

It's a self fulfilling prophecy. It's because this is not possible, since often software is a never ending journey. Today's requirements are not tomorrow's requirements. If only we could freeze time.

Application creation (programming, design) are creative processes. If you want a brick wall, you sum up the materials, job size, and labor. Not so with software.

And I'm really glad that it is.

At the end of day that's precisely the joy of this field. Else it's just a job.

I once had a mentor who was fond of saying "Git doesn't solve human problems", in reference to git-conflicts while explaining the system to less technical team members.

Technological advancements have, to this point, had fairly limited effect on mitigating error in human input.

Most of it is not a technology problem. Most of it is a human problem. Humans are not as good as we think we are at communicating in precise details with others.

a) Estimates are made when the least information is available.

b) Developers are bad at estimating the unknown unknowns that will bite them.

c) Padding estimates is somehow seen as a bad thing, probably due to...

d) Business pressures that incentivize everyone to quote the earliest possible date something could be ready, rather than the date it will most likely be ready.

I really think d) is the most significant one here. It's pretty visible if you look at the problem structure. In a competitive environment, the first one to give a solution wins, at least initially. Since it's easy to hide bugs and unfinished features for the release, the ones who skip proper design will ship faster and thus win and preserve on the market. "Good solution today is better than perfect one tomorrow" turns into "worst solution that's still acceptable today is better than decent enough solution tomorrow".