I was going to go rant on a bit about all the folks who think perl 6 and/or parrot is going to fail miserably, but I think I won't. Most of them don't know what they're talking about, and many of the rest are obnoxiously snide just because, well, they're obnoxiously snide. At this point those folks can just go jump, I don't much care. (And for all the snide python folks, well, I shall have to make sure I have a nice, hires image of Guido getting pied when it happens. And it will)
Instead I think I'll go on about one of the few points people do have about the plan as it stands--the complete throwing out and rewriting of the perl 5 core. The big thing thrown at us is "Rewrites always fail" and that we should refactor parts of the core instead. Well, we're not doing that for a number of reasons, and while I ought to explain them I'll do it elsewhere.
Instead, I want to tackle the "complete rewrites always fail" meme that seems to be out there, because it's just not true.
The problem is that most large software projects fail. Period. Start a big project--heck, any project--and odds are you'll never finish. The larger the project the less likely success is. It's not an intrinsic property of large projects so much as an intrinsic property of the way we manage large projects, but things in rewrite tend to be big, so it crops up. The odds of a big project dodging the bullet once are poor, and twice is really poor, though a rewrite has a slightly better chance of getting pulled off since the people involved did it once. If you figure the chance of a large project succeeding are (1/X), the chances of a large rewritten project succeeding are (1/X2) more or less. Since rewrites are often larger undertakings than the original the odds are a touch worse that a project will survive two full development rounds, though that may be offset a bit by the fact that the organizers probably have at least a bit of the skills needed to get a large project to completion.
Sometimes the "Second System Syndrome" stuff gets thrown in the mix, and this is a valid thing to be worried about. Fred Brooks talks about it in The Mythical Man-Month, a great book about large project management. (One of a number of project management and project design books I have that I sometimes pull out and read) Basically the second system someone designs is the one likely to fail through overreaching, as you try to do all the stuff you couldn't in the first system but haven't yet failed at so you don't know they're infeasable.
If you realize all this, though--that the Second System Syndrome is real, and that project management that avoids the pitfalls gets you a higher chance of success--a rewrite is often in a position to succeed better than a brand new project. You've got people familiar with the original code base and functionality, and you know much better what you want to do and not do with a design, both of which can help doing the rewrite.
More than anything else, especially with a volunteer project, you need to sit on the folks who are bitten by (or are perpetually reveling in) Second System problems, but that just means that your lead designers and project managers have to keep things from getting out of control.
Writing a large system a second time isn't easy, by any means, but doing it a second time is far from the kiss of death that you'd think it was.
Posted by Dan at February 28, 2003 06:25 PM | TrackBack (0)