[jroseattle]

I was expecting this slidedeck to be a bit more focused on defying Spolsky, and whether or not that was a good decision.

FWIW, I've never bought into Spolsky's vision that re-writing code is poor strategy. Steve Jobs never thought twice about ripping something apart and starting over. If anything, code re-write can be an advantageous position -- you often have a greater understanding of the problems you're intending to solve. When well-executed, it can take the form of heavy refactoring, even when switching languages/platforms.

[LockeWatts]

I'm not really sure why Steve Jobs is your model for code design.

[widdershins]

Because he oversaw the creation of 3 of the most successful operating systems of all time? I know he didn't design them, but he was involved in managing the projects. Just playing devil's advocate.

[zerr]

Well, it doesn't mean he evaluated at the code level and decided that rewriting is better than refactoring...

[jroseattle]

Apple has/had a history of re-writing code over the years. The first iPods and their iterations were code re-writes, IIRC. Many of the onboard applications were completely re-written for the iPad.

[Daishiman]

Rewriting for new hardware is totally different from rewriting business logic. In the first case there are sometimes no other choices left.

Also, the code that usually goes into hardware microcode and firmwares is much more tightly coupled.

[grey-area]

Steve Jobs never thought twice about ripping something apart and starting over. If anything, code re-write can be an advantageous position -- you often have a greater understanding of the problems you're intending to solve.

It's interesting that you take Jobs (and by extension Apple) as an example here, as many new projects from them which might appear to be complete rewrites from the outside are in fact heavily derivative or dependent on other projects. iOS for example is an incremental revision of OS X, removing some of the UI layer and replacing it, but leaving almost all of the underlying OS intact, using the same dev language any many of the same APIs - it is by no means a clean-room rewrite. OS X itself was heavily based on NextStep, which of course was based on Mach/BSD, so none of these 'new' platforms started from a clean slate like BeOS for example, and the same tends to happen with APIs, though sometimes these have been rewritten (Quicktime comes to mind, and arguably UIKit is a significant rewrite of AppKit, though the two still exist in parallel just now).

Sometimes rewriting is the best solution, but it does tend to take a lot longer than expected, doesn't always leave you with a satisfactory replacement, and ends in failure more often than it ends in success, particularly on very large projects or ones with fuzzy scope. I think Spolsky was talking about projects on the level of Netscape and Excel, where a rewrite would be a significant challenge very likely to fail or be delayed so long that it falls short of its initial goals. The smaller the project, the more viable a rewrite becomes, and sometimes it is the best option if the existing product is not delivering and is difficult to extend/support.

[macspoofing]

>I've never bought into Spolsky's vision that re-writing code is poor strategy.

I think it's something that's true in general but false in some specific cases. Rewriting involves spending enormous time and resources to at best standstill, and at worst move backwards ( chances are your re-written product will be poorer in features, and initially buggier than your old, stable, battle-tested version). For smaller companies, it is a death knell.

[jroseattle]

Yes, very true. Although I'd like to add some context.

> Rewriting involves spending enormous time and resources to at best standstill, and at worst move backwards ( chances are your re-written product will be poorer in features, and initially buggier than your old, stable, battle-tested version).

There is plenty of evidence that this has happened in many places and with many companies. A very real scenario that's played out before.

I'd say those scenarios were not well-executed. If the outcome of a re-write is "standstill", the re-write is pointless. There is no justification for proceeding with it.

However, if "standstill" equates only to user-facing features, chances are the re-write is to address critical issues elsewhere (I get the impression that was the situation with the OP.) In that case, "standstill" doesn't apply. It's simply a matter of deciding whether or not the effort and risk justifies the reward.

To my main point, Spolsky's hard-line essentially says re-building your application from scratch is bad strategy. I think it is short-sighted to draw that line. I prefer to exercise judgment and draw on the resources at my disposal for the given situation. I presume many others do as well.

[macspoofing]

>Spolsky's hard-line essentially says re-building your application from scratch is bad strategy.

I don't think Spolsky's position is as "hard-line" as you think it is. I always took it as a very very strong "rule-of-thumb". Every time a rewrite is proposed, it should sound warning bells in all stakeholder. And we're talking about a clean-room rewrite, and not a sub-module rewrite. Spolsky has no problem with rewriting and re-architecturing sub-pieces of an application.

Twitter is a great example of Spolky's philosophy. They had a big architectural and technology problem with Ruby and RoR, but they didn't do a clean-room rewrite with Java. Instead they tackled one sub-component at a time, and now they have something that rocks, but still allowed them to keep the time/code investment they made originally. Just as well, it allowed them to incrementally 'upgrade' their service.

[gnaffle]

I think the big danger Spolsky warns about is the "stop working on the old code and spend a year doing a complete rewrite". Many very smart people have underestimated the risks in doing that and the time it will take, while overestimating the benefits.

A smarter approach is to rewrite parts of the code. Apple has done that with many apps (and even iOS is OSX with a new UI/API on top). Linux has had many patch-by-patch rewrites as well. With a webapp, a "complete rewrite" still might leave most of the heavy lifting to the web framework, and you might be able to keep most of your HTML, CSS and JS.

I think the well-executed rewrites usually include launching an entirely new product while still supporting the old one. Adobe did this with InDesign (replacing PageMaker), Apple did this with OSX (the initial releases included OS9) and Microsoft did it with NT while keeping Windows 9X around.

[yuhong]

Yea, the WaSP was in 1998 petitioning Netscape to cancel Mariner, and unfortunately they caved.

[yuhong]

My personal favorite is the MS OS/2 2.0 fiasco, where the project was abandoned by MS after the first SDK was already sent to developers: http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-...