Two sides of the same fence?

In my daily reading these two articles came fairly close together, and I have a strong feeling they are describing exactly the same project. *

From one side of the fence: A total rewrite: costly, time-consuming, but worth it?

“Our CMS was developed using Active Server Pages, and consisted of around 80,000 lines of VBScript code.”

“as we continued to develop the rest of the framework, we saw that it took a lot longer than anticipated”

From the other side: The Homegrown CMS

“If one were to create a list of adjectives to describe this monstrosity, “stable,” “reliable,” and “accurate” would be strikingly absent.”

“…nearly 200 tables (mostly imported from Microsoft Access) and not a single stored procedure. Boolean-type values were represented as a CHAR(5) field, holding possible values of ‘true’, ‘false’, or NULL…

“There were also no indexes. Nor any primary key columns… For inserts, an ID was assigned via in-line SQL by requesting the Max(ID) field of any particular table and adding 1.”

My point of view: this sounds like a good counter-example to the (very good, but general) advice offered by Joel Spolsky: don’t rewrite from scratch.

* EDIT: Vidar Langberget has advised that these are not the same project, proving that I’m not such a great prognosticator 😐

ORA-01481 Invalid number format model
Another way to learn something new every day

Comments

  1. Spolsky’s point is actually a commercial/managerial one: Never rewrite a ‘product’ from scratch, as it will be a different ‘product’ and inherently annoy everyone dependent on abusing original_product in ways the developers could never predict.

    Now, if there’s a reason to want a different product, that’s cool, but to draw from recent examples:

    If Apple had discontinued the Mac and declared the iPhonePadOS as the “new hotness” “rewrite from scratch” (which they pretend it is) Mac OS XI…

    If Microsoft had discontinued the Win9x horrorshow with NT before the “merging” into the sufficiently-bug-compatible XP…

    … existing users would’ve been very unhappy, because they’d feel “lied to” — Original_Thing 2.0 is nothing like Original_Thing 1.0. And if you’re going to start from scratch, it’s better to hand marketing (and the world) New_Thing than force everyone to get used to Original_Thing referring to two otherwise ‘unrelated’ things. Then, even if you have to kill Original_Thing because it’s a horrible unmaintainable/broken/unprofitable mess, you aren’t breaking the linguistic contract where a name should refer to a single ‘thing’.

    This gains you the efficiency of not playing mind games with yourself/your developers/your [customers|consumers|end_users], and also communicates your intentions more effectively. If New_Thing is a good enough idea, it should be able to stand under its own name, and if it’s a sufficiently good replacement for Original_Thing, it should be able to obsolete it and supplant it without anyone having to pretend it’s Original_Thing.

    [Some companies manage to break this rule, but it’s rare – and more often it’s a case of offering Product and Product++ (see: Mac OS, Mac “OS X”) in the exact sense of C and C++, rather than calling C++ “C 3.0”.]

    • Jeffrey Kemp
      26 May 2010 - 1:57 pm

      Hi Peon,

      Thanks for your comments.

      Certainly, the more transparent a company is about its product direction, the better life is for its customers. This is one thing I appreciate about Oracle – e.g. I still remember years ago the world saying “Oracle Forms is dead” – meanwhile, Oracle is still updating and enhancing the product.

      Yes, creating “New_Thing” as a new product instead of just “Original_Thing v2” is certainly a preferable strategy when the product undergoes significant change.

      Whether a company decides to rebrand their “version 2” as a new product or not, however, the point still applies to the development context, in my opinion. I’m not even aware whether the CMS under discussion remained backwards compatible after the rewrite – for all I know, there might have been relatively little impact on their existing customers (there likely was, but I don’t know that).

      It’s not really about marketing or management – the primary takeaway from Spolsky is that there is almost always some value in the old code, so deciding to throw it all away is effectively wasting all that precious developer blood, sweat and tears. Blood sweat and tears that were expended on not only making the product work for those who “abuse the original product”, but also for making it work correctly/reliably in all kinds of unpredictable scenarios.

      The counter argument is that if the original code is *really* bad, i.e. an unmaintainable hodgepodge with little intrinsic value, then the cost/benefit ratio may very well swing in favour of a rewrite. As Langberget said, however, this still comes at a high cost.

  2. Vidar Langberget
    27 May 2010 - 12:43 am

    I’m the author of the blog post titled ” A total rewrite: costly, time-consuming, but worth it?”. I just wanted to point out that the two stories are not talking about the same project.

    While we has some fundamental problems with our architecture, it wasn’t badly developed like the one described at The Daily WTF.

    Vidar

    • Jeffrey Kemp
      27 May 2010 - 7:00 am

      Hi Vidar,

      Looks like my wild speculation was way off. Thanks for clearing that up!

      For my part, I still agree that a rewrite was the best decision to make, based on the factors you describe in your article.

      Thanks

  3. “The counter argument is that if the original code is *really* bad, i.e. an unmaintainable hodgepodge with little intrinsic value, then the cost/benefit ratio may very well swing in favour of a rewrite.”

    Got picked up in
    http://securosis.com/blog/code-re-engineering/

Leave a Reply

Your email address will not be published / Required fields are marked *