This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: Walking Backwards For Christmas
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
The Walking bit sort-of-kinda derives from the present rumblings about fuel prices. I'm lucky; I have to drive to the office and back maybe once per week; granted, that's a 90 mile trip each way, but most of the rest of the time the car stays in the driveway. It's summer, so walking The Daughter to school of a morning is actually a nice way to start the day. All in all, my ecological footprint, at least in terms of petrol, is tending towards the minimal.
The last lot of UK fuel protests (around four years ago, in case you're in the US and missed it all) brought the place to a standstill, coincidentally just as I was starting the job-before-this-one, leaving me with a new car but no way to get any fuel to put in it. I managed to drive it home from the car dealer on the fumes that remained in the tank, but when the protesters crawled home and the fuel flowed again I had to roll the damn thing downhill into the village to fill it up. Now I hear those same rumblings again from people whose view of fairness and the role of the market are somewhat different than mine, but now I have broadband and a job that can be done from home and by phone. Colour me insulated.
The Backwards bit is because on my journey here to the office this morning (up at 5:30am, so trust me, there's time to think) I was pondering some interesting comments on Zope 3 that someone made, anonymously. I have no real problem with anyone's decision to rewrite, refactor and generally re-the-hell out of any code they get their hands on. It is only after we have written something that we truly understand how it ought to have been written, and if Open Source is about anything, psychologically, it's satisfying one's own personal urges, whether they be for recognition, kudos or something to automate those tedious backup jobs that get in the way of your Quake.
But there are other consequences to be faced when one yields, trembling with anticipation, to the temptations of the Rewriting Demons.
Firstly, there's the subtle, hidden urge to DoItBetter. Now that you've written System A, you know how it should have been done, how it all should have been structured and precisely where you went wrong. But a rewrite is not enough; you also know what else you should have added. This time, you think, not only will it be faster and not have that nasty little workaround with the global variables and all, but it will also slice, dice and make curly fries. Thus are the seeds of destruction sown; you can either rewrite, or you can extend. Attempting to do the two at once is dangerous at best. At the very least, put up a safety net and wear goggles.
The second issue, and the more interesting to me at any rate, is that of backwards compatibility. Let me lay my motivational cards out on the metaphorical table here; I like backwards compatibility. I strive for it. A new version of a system that requires me to munge, reprocess or redo any of its inputs, scripts or command files feels plain wrong, inelegant and wanting. If it affects other users as well, I feel a sense of failure. I got it bad, baby. But it's not that difficult a thing to manage, either. Extending methods so that they deal with new parameters yet will still work as they used to. Maintaining old interfaces on objects whilst adding new ones. Devising extendible syntaxes for configuration files. The phrase "the system will ignore any keywords that it does not recognise" appears in most of the specification document I've churned out over the last couple of weeks. It's all designed to grow.
But not, as far as my failing old eyes can see, with Zope 3. There the imps of rewriting seem to have found willing hosts; for good and laudable reasons. Zope has evolved in the Darwinian world of web systems to fit the niche it has found, spreading out and expanding like a sponge to fill the irregularly shaped hole in the world that was just waiting for a Python-based, object oriented web development platform. Evolution brings with it the inevitable internal tangles of retrofitting and adaptation; Zope has its own appendix and wisdom teeth left over from earlier incarnations. There are good reasons for a rewrite.
But Zope is like Forth, or SmallTalk, in that the development environment and the code built using it become one, inseparable. Like the barnacles that encrust a limpet, they stick together and are not easily prised apart. And the blending of the two is reflected in the developers themselves; the nature of Zope is that expertise is gained by digging into the system and accreting knowledge, some of which is about the basic Zope, much of which is about the way in which an individual or an organisation uses it. If Zope 3 fails to provide a bridge for those who have investments in Zope 2, whether in working sites or experience, then its market is restricted to those who feel like trying a brand new Zope with all the risks inherent. The leap to upgrade would have to be well worth it to balance the risk. The phrase "there will be many conversion scripts" sounds less like a road ahead than the Bridge of Khazad-Dhum, over which the Balrog cannot pass.
By contrast, consider MySQL. With each version come incremental improvements (some values of "incremental" are more incremental than others). Each slips in under the blanket of a working system, replacing the older version painlessly. More or less; there are exceptions to everything, but at least that is the intent.
Someone once asked Dave Cutler to rewrite VMS. He wrote Windows NT. Enough said.
Previous Topic
