On refactoring… — BarTab 2.0 is on its way

May 10, 2010

In the excellent Coders at Work book, Doug Crockford advises programmers to rewrite their stuff every six months or so. He says rewrite, but I don’t think he actually means that. Developers love rewriting stuff and most of the time it’s absolutely pointless — I know, I’ve been there.

I think what he means is refactoring. Basically streamlining the good parts and getting rid of cruft. In an ideal world, refactoring can be done in small, atomic steps. It should create no or few incompatibilities. And most crucially, it shouldn’t in any way affect the product’s shipping date.

This past week I have given BarTab this treatment. Since its creation in late January, it has grown organically. After a few months of fixing bugs, adding features, releasing early and often, and observing it “in the wild,” it was time to step back and clean it up. And boy did it need cleaning up.

My precondition for this refactoring was that I wouldn’t add any new features. Nada. Zip. Even though it would’ve been very tempting at various stages. I did manage to fix a few lingering bugs, though. In the end I turned over almost every line of code, some even twice. It was a deeply satisfying experience, and I’m glad I stuck by my no-new-features rule. It wasn’t an ideal refactoring in the sense that it was completely backwards compatible. The old API was horrible, it is now much more symmetric and free of horrible puns.

So BarTab 2.0 (available now as beta) is leaner, meaner, less invasive (no eval() hacks!) and more compatible with other Firefox add-ons. In a lot of ways it’s the BarTab that I should always have written. But you know as well as I do, that’s not how it works. Very few people write perfect code the first time round.

To me, BarTab is the perfect example of why Release Early and Often and the occasional Refactoring works extremely well for small, self-contained pieces of code such as a library, plug-in or extension. It isn’t by far the first time I’ve done things this way, but it’s certainly turned out very nicely this time.

5 Responses to “On refactoring… — BarTab 2.0 is on its way”

  1. bruce wayne Says:

    Hi Philipp,

    vielen Dank für dein addon Bartab, es ist das sinnvollste und derzeit genialste Addon, das wo gibt😉

    Ich würde mir sehr wünschen, das diese funktion demnächst als standart in FF integriert wird. Kann man das irgendwo beantragen?🙂

  2. Martijn Faassen Says:

    Am I right that you seem to be implying that the whole Zope 3 project was a waste of time? I’d argue the Zope Toolkit that resulted from it was hardly a pointless effort. Did you really mean to imply your involvement or the project were pointless? If so, I beg to disagree: it’s doing both yourself and the project a disservice.

    The Zope Toolkit is a codebase that’s been used by many in a variety of settings in production for years. Moreover, its successes and failures provided for much, very much, learning.

    A lot of mistakes, big and small, were made along the way, of course. I’d think that’s a claim that can be made by many a software project, and Zope’s definitely one of them.

    So, thanks for all the help, and please don’t feel ashamed of your previous work. It wasn’t pointless to many of us, even though if I knew in advance where things would lead us, I’d have done a lot of things differently. But learning is part of life.

    • philikon Says:

      Martijn, no worries, I’m glad I was part of Zope. Of course the rewrite wasn’t completely pointless, but I think it was self-indulgent for the most part. Indeed, that’s probably the better word.

      I’m glad for the Zope Toolkit, but in all likelihood a rewrite wasn’t the only way to get it. Of course that’s one of the lessons I was able to learn over the past few years and I’m grateful I was given the opportunity. That still doesn’t mean I can’t be critical of what we did.

  3. Martijn Faassen Says:

    I’m totally critical of what we did; we should’ve done it a lot more incrementally, for instance. And not to try to rebuild the ZMI. And we still have too much magic. And some of it is ravioli code, which is also bad to manage. But criticism isn’t the same as rejection.

    Speaking about your current occupation (congrats by the way!), Mozilla’s another example of a total rewrite. It took forever, looked on the edge of failure a bunch of times, but then turned into a success. And most likely left a lot of code around that suffers from early decisions that still needs to be worked with today. Some parallels with the Zope project, though it’s entirely different in other ways, and of course the ZTK won’t ever have the success of Mozilla (it doesn’t need to have).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: