[wahB4vai]

Organizations get what you reward.

Tech Debt is rewarded.

Doing something for the first time, almost by definition, means one does not really know what one is doing and is going to do it somewhat wrong.

Hiring less skilled labor (cheap coder camps for example) to implement buzzword bingo solutions gets you into a place where all the software contains large chunks of it's substance coming from people doing it for the first time... and not 100% right.

As we never go back to fix the tech debt we end up building stills for the borked and less than great. When that structure topples over we start over with a new bingo sheet listing the hot new technologies that will fix our problems this time round for sure.

I'd think that a good fraction of the current language expansion is that the older languages are too complex and filled with broken. Green fields allow one to reimplement printf, feel great about it, and get rewarded as a luminary in the smaller pond.

.....

oh... and well the cynic in me would argue planed obsolescence at the gross level. No one buys the new stuff unless there's new stuff.

[hyperpallium]

Software engineering reinvents everything every decade or so. People were complaining about it 20 years ago - I suspect they have from the beginning. Not only new languages, also new hardware and new platforms in general. Moore's law seemed to be the driver, but the constant growth means constant new people... unlike scientific paradigms, we needn't wait for old practitioners to die.

BTW is "stills" a typo for something? (shims?)

[krylon]

> Doing something for the first time, almost by definition, means one does not really know what one is doing and is going to do it somewhat wrong.

The Mythical Man-Month has a chapter on this titled "Prepare to throw one away". Brooks argues, that the program/OS/whatever you build the first time around should be considered a prototype. Then you reflect on what problems you encountered, what went well, and so on and use those insights to guide you when start over.

It seems like such an obvious idea, but Brooks wrote that almost 50 years ago, and it seems like only very few people listened. Primarily, I guess, because much software is already written under highly optimistic schedules - telling management and/or customers that you want to throw the thing out and start over is not going to make you popular.

[coldcode]

That do it twice idea originally came from Royce's famous article in 1970 which lead people to claim he invented Waterfall (due to the diagram he started with). Reflecting on practices from leading teams in the 60's was that do the project once to learn everything, and then do it again and ship the second one. Worth reading.

[randallsquared]

On the other hand, we have the Second System Effect, about the dangers of throwing away the first version of Thing in favor of "Thing Done RIGHT This Time".

[moron4hire]

What's also obvious is practically no manager is going to go for that.