Re^3: Nobody Expects the Agile Imposition (Part VI): Architecture

[mr_mischief]

My intent was not to start an argument over semantics nor over anything else. I merely intended to clarify where I think some imprecision and unnecessary disagreement has entered the thread. If we keep using words we define differently as a basis, then we at least need to know how those words are being used by each party. Otherwise we'll talk past one another and nobody really knows where we would agree and disagree no matter how civil or friendly the discussion.

I also think it helps to remember that intentions toward a project can change over time. What one thinks will be a straightforward rewrite from the beginning can change in focus and gain features before the rewrite is done (or even really started). The new design can be a totally different sort of beast from the old, but since it's still in the same lineage the distinction is blurred. In fact, I suspect that the svn folks intended to rewrite CVS but looking back would only loosely use that term for what they finally did. I think Larry would say Perl 5 is a rewrite of Perl 4 from the point of view of both the language and the perl tool. I would probably say that, anyway. I think he intended originally for Perl 6 to be a rewrite of some sort, but the language is the only thing being rewritten IMO. I think Rakudo and Parrot are definitely not rewrites of perl 5.6 or 5.8 although the language implemented is still in the Perl family. How Larry actually does view things of course would be for Larry to say no matter what I think he might say.

[eyepopslikeamosquito]

What one thinks will be a straightforward rewrite from the beginning can change in focus and gain features before the rewrite is done.

Yes, I suspect this happens rather a lot. I once inherited an "unmaintainable" build system written as a huge DOS .BAT script. Well, it was unmaintainable to me, because I didn't know .BAT very well and, frankly, didn't want to. My strong opinion, expressed in Unix shell versus Perl, is that you should not write non-trivial systems in .BAT (or Unix shell). Luckily, it was only a few thousand lines long and I was able to "rewrite" it in Perl fairly painlessly. Because the original design and interface was so bad, I "improved" it as I went, so my "rewrite" ended up a fair bit different to the original. Naturally, I didn't write it as a monolithic script, but as a number of modules along with a small script mainline. Now you and BrowserUk may claim I didn't rewrite it, I wrote a new build system. Fair enough, but I prefer not to argue about that any more. :) The important strategic question is: should I have "rewritten" it in Perl or improved it by changing the existing .BAT script? From my (biased) point of view, the "rewrite" was a raging success because we were able to extend this system many times over the years (often by adding new modules) and I feel the cost of the rewrite was got back many times over by improved robustness and performance, along with much easier maintenance over a period of many years.

Of course, rewriting small systems is easy. Suppose this system has now grown to 100,000+ lines of Perl and the person who takes it over dislikes Perl, claims it is a tangled mess, and decides it would be more "maintainable" to rewrite it in Ruby or Python. Is that a wise decision? Though I would normally argue against that, others have been known to argue for it (BTW, as far as I'm aware, sanity prevailed and Bugzilla is still written in Perl).

Whether it makes sense to rewrite depends on many factors: how large the system is; how ambitiously you want to extend it; how clean is its code; and how skillful are the rewriters. I make the last point because unfortunately I've seen a number of over-confident programmers over the years complain loudly about a crappy old system, boldy rewrite it ... then end up with a crappier system than the original! In my experience, the quality of the developers doing the rewrite is crucial: a creaky old legacy system written by first-rate developers is likely to be better than a shiny new one rewritten by mediocre developers. As Joel Spolsky cautions when you rewrite: "there is absolutely no reason to believe that you are going to do a better job".