Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Wednesday August 06, 2008
12:43 AM

Smalltalkers Still Get it Right

[ #37109 ]

Next time someone considers rewriting an app into (insert currently fashionable language here), ask yourself whether a three year long timeout will serve anyone's interests.

James Robertson, The Wages of Pointless Rewrites

Three years to migrate a working application from mod_perl to PHP and (reportedly) Erlang? I could write my own virtual machine from scratch if funded full-time for three years. (Yes, I'm aware of certain ironies about rewriting a virtual machine over the period of seven years and counting, but I can count our paying customers on zero hands.)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I was in a discussion over lunch one day at OSCON this year over the same issue. "Would you rewrite something from language x to y?" The issues have little to do with x or y, they are all business based (or should be).

    What can't you do with x that the business needs that you could do with y? Can you not find developers/support for x? What would it cost to train developers vs. rebuilding? Not to mention the arguments for sticking with tested code versus all the newly bugified code you'll generate over the
  • I'd gladly take a three year timeout to rewrite the steaming pile of garbage known as TIRKS [wikipedia.org]. It's an ancient, slow, expensive, horribly licensed 3270 app that's a major pain to interface with, but survives largely due to historical reasons.

    However, rumor has it people (internally) have tried and failed to replace it in the past. Also, it's an internal facing app, so perhaps there's more slack there.

  • Hi, chromatic. I work on Delicious, and I've been with the site since before Yahoo! bought it.

    Delicious was not merely migrated. It was redesigned and rewritten from the database up. Several months of development were spent in design and QA (we were in limited beta since September [delicious.com]). The additional forethought and care were warranted since a lot of people rely on us every day.

    Delicious was originally designed for a relatively small number of people. It has been extended, patched, optimized, sharded

    • Why did you throw away everything, though? You could have fixed the architecture without changing languages.
      • Why did you throw away everything, though? You could have fixed the architecture without changing languages.

        Oh, sure. Everything is just a Simple Matter Of Programming. :)

        PHP on the front end was an administrative requirement. Switching the front end to PHP did not unduly extend our development time. I'm free to tell you this because our founder has already said as much in the surprisingly balanced reddit thread in response to James' article [reddit.com].

        We considered simply bolting a PHP front end onto the original site, but it was not practical. The original user interface was tightly coupled to the site's business

    • The languages we chose are the right tools for their respective jobs.

      I don't know your particular constraints, and I'm happy to accept that, but a three year rewrite with an eleven month beta period seems troubled -- unless that was the schedule from the beginning. I very much look forward to a retrospective.