▲ 50 points
back
10 comments
It's hard to completely tell from the article, but this almost sounds like they built a new product, not really a rewrite. The new product subsumed the old system, but really could be described as a different product (in the way that Word is not just a refactored version of Notepad). Nevertheless, great read.
One thing to also note is that Fred Brooks has stated that his "Throw one away" idea was wrong. He now says, "I would now recommend this for bad teams only. Now, I suggest you make schedules on previous experience of your team. My new approach: INCREMENTAL SE, i.e. build a small functionally limited but working system and then expand it."
It isn't clear from the article whether the new system is in production and the old system has been thrown away. Those are the two most important questions.
If the company is maintaining the old system to support existing users, that's a bad sign for the rewrite. If there is a separate team for the old system, that's a really bad sign for the rewrite (not to mention for the company).
Doing this is harder than it sounds. Technical success may be a necessary condition but it isn't a sufficient one.
The old system has been entirely decommissioned, and the team works entirely on the new system now.
How long was the transition period? A single day? What size userbase was migrated (if you can say)?
Also, thanks for writing this up - lots of good writing as usual. Having gone through a rewrite recently, and being asked to consult on another, you've identified a lot of good issues for me to revisit.
Since this was a rewrite of a system that just consumed the output of the CMS, the migration was not awful. One day, we just started exporting the new data format and using the new system to create apps. Users continued to use the same CMS to build their applications -- the CMS was the target of many improvements, but didn't get replaced wholesale. Thus the rollout of the new system wasn't really impacted by the number of users of the CMS. Though the Dojo/PhoneGap system in reality exists pretty independently from the CMS, you might think of it as the presentation layer of the CMS, so this rewrite really targeted a (significant) piece of a larger system.
nice - sounds like just about the best case scenario for a rewrite, excepting a total scrap and start over of the whole company :)
This is the part of a rewrite that scares the crap out of me. When you have thousands of users across hundreds of big clients, with millions of existing records and a decade of history, making a big switch in one go seems impossible.
Interesting read; not a lot of universal truths about re-writing. Which is actually a good thing because there are none. The decision to re-write is highly dependent on the context in which it is being made.
For example, a large legacy application in operation for over a decade with a huge volume of customer data is completely different monster from a smart phone app. Re-writing it in another language is a pain in the ass and if you're really, really successful nobody will notice the effort you put in. It won't make you any money or friends.
Still, there are times when it's just necessary. Even large legacy applications can be replaced given the right parameters. You can write an interface layer to the old code and extend it in a new language. Write an exhaustive amount of unit tests and acceptance tests against the legacy wrapper API and slowly replace the legacy code behind it with new code that is better written, faster, and more reliable (or what have you).
I think the most salient point of this article is to know what you're re-writing. Good acceptance tests and functional tests will help A LOT in making this decision.
I wonder exactly how old the "old" codebase was at the time of the rewrite? It seems like it couldn't have been too old, with PhoneGap and Moustache playing a prominent part in the original system.
"I pored over our existing code, seeing the word node on what felt like every other line. As an experiment, I changed that word node to baseObj in a few high-level files, and suddenly a whole world of solutions opened up to me — the name of a thing had limiting my thinking."
Really? Wow. :-)