Software Development And The Sunk Cost Fallacy
skorks.com
skorks.com
...we (developers) will often stick with a technology/library choice through thick and thin long past the time we should have abandoned it and found something that fits our needs better. There are always, good reasons to justify all this, but what it comes down to in the end is self-delusion – the sunk cost fallacy at work.
In software you're always balancing risk. If you have some working software, but it has some flaws that doesn't mean you should abandon it. If you are to rewrite it's likely that you can fix the known flaws, but what new flaws will you introduce? How much will it cost? It's hardly a fallacy, it's just a question of prudence in the face of the unknown.
I also have some beef with the javascript bits:
But, all the browsers already support it (well, kinda, none in quite the same way) and there are all the frameworks that make everything much better.
The core language is remarkably consistent. It's only the DOM that has glaring inconsistencies.
In the meantime it makes a lot more sense and is infact much easier, to put millions of developers through daily pain, rather than phasing out JavaScript in favour of something better (anything would probably do)
Um no, Javascript is one of the most powerful languages ever to hit the mainstream. It's warts are pretty nasty, but given the picture of Douglas Crockford's book, I would expect the author to have a greater appreciation for the elegance of The Good Parts.
It is never too late to remove a technology or library if it was clearly the wrong choice.
Wishful thinking. Of course it can be too late. If we take the JS argument at face value then that's the perfect example. A standard like Javascript can not be engineered. These things happen organically overtime by circumstance. If someone makes a push to replace Javascript the most likely outcome is throwing away time and money. In fact, the tech landscape is littered with things that are too late to change.
I've yet to see a project where throwing out the old software because of its flaws saved effort. Of course, that's partly due to not having had any projects where I was inheriting software written by competent developers in the first place, but the management can't tell the difference.
Every single time that I've seen that argument used as a basis for selecting the refactor approach, it's ended up being a death march because we had to re-write nearly the entire thing anyway. And when we were done, we STILL had a tangled mess of tightly-coupled components that didn't quite work.
It's exceedingly rare in software to find a situation where abandoning the old software is a mistake.
With any luck, I'll find one of those projects some day. But I doubt it, since the trend I've seen is that software quality is decreasing, and more and more components are tightly coupled together because the developers are too rushed and/or burned out to realize it.
If you ask me, the article isn't worded strongly enough.
In fact, it describes the government contracting industry almost perfectly. The entire industry is based on using the sun cost fallacy to reward failure, because in government contracting the LAST thing you want to do is finish a project early and under budget. If you do, you get a smaller budget on the next project.
So, while much of the effort that's gone into JS over the years could be considered sunk cost, it's probably not YOUR sunk cost, (so you aren't irrationally motivated), and JS itself is a bright, growing ecosystem.
What keeps JS in the lead now has nothing to do with sunk cost, but it's early success and the network effect. It's well known, has lots of apps written for it, and is ubiquitous. It's successful because it's successful and continues to be.