[InclinedPlane]

Spolsky is wrong.

Rewriting is a significant risk, and rewrites often fail because people don't appreciate that fact. But there are ways to rewrite successfully, and often doing so is the correct course of action.

A big problem with rewrites is that it puts a strain on development resources, and it's not possible to maintain both old and new code at the same time. Another big problem is prematurely committing to the rewrite, before it has proven itself. When the inevitable happens and schedules slip, defects arise, and features need to be cut this can prove disastrous for a rewrite that you've foolishly committed to in advance. Also, people often ignore the value of years of productive use which provides testing and validation of immense value.

If you have the resources often the best choice is to spin off a new project for a rewrite and have them compete in the open. With luck the rewrite could become mature enough to overtake the original (as has happened with many projects). Alternately, work in phases doing refactoring in steps, perhaps with new features behind feature flags.

Many people think that rewriting code is easier than green field development, in reality it's often more difficult. It takes a great deal of skill, and often luck, to manage a good rewrite.

[Pacabel]

A significant problem is that there are a lot of developers today who revere Spolsky as some sort of a god, and absolutely refuse to question or reconsider anything that he has written.

This trend is particularly bad with those who've gotten involved with software development since 2005 or so.

I chalk it up to a lack of experience with massive, multi-decade software projects. If all a developer has worked with are small, recently-written Ruby on Rails apps, for example, then I don't think they can appreciate situations where rewrites of some degree are the only viable option.

Hopefully this attitude regarding Spolsky's writing will change with time, as these people encounter the real-world situations where significant or total rewrites are basically the only possible option.

[InclinedPlane]

An even bigger problem, in my opinion, is the idea (usually only implicit) that any advice can apply to the entire panoply of software development. As though writing Flappy Bird and writing control software for the Falcon 9 weren't as different as banging together some shelving using plywood from home depot and machining custom components from exotic alloys using a lathe. An important part of maturing as a developer is learning to understand that different situations call for different techniques and being able to know what things are truly important with a given project and which aren't.

[wpietri]

A related problem, or maybe the same problem in a different outfit, is the notion that my personal experience is enough for me to opine on all software everywhere.

For me there's a useful sort of arrogance, the "I could code that in two weeks even if I don't know the language" kind of arrogance. I say useful, because that had gotten me to jump into projects that I never would have dared touch.

But the dangerous side of that arrogance is, "I know enough to say what what these other people are doing is stupid". Every time I learn a new sort of software or a new domain, I am reminded that it's much easier to make bold pronouncements from ignorance than from knowledge.