Back To The Old Version example essay topic

The Problem: Rewrite Mania I have been noticing a certain trend in software toward rewriting successful tools and standards. It seems that programmers always have the urge to make things better, which is perfectly understandable - after all, this is the primary trait of the engineer's mind (although I also think that artistic creativity also enters in the mix). Why should things stay static? Surely progress is good, and if we just stayed in the same place, using the same versions of tools without improvement, then things would deteriorate and generally get pretty boring. That's all very true, but what I am seeing is that in many cases we have tools which truly are 'good enough' for what they are designed to do - TCP / IP allows us to build giant, interconnected networks, Apache lets us build flexible web servers, Perl lets us write incomprehensibly obfuscated code (! )... well, point being, these things work. Really, outstandingly well.

They are 'good enough', and moreover they are used everywhere. So all's well and good, right? Well, not exactly. The programmers add little bits and pieces here and there, fix lots of bugs, and over time the code starts to look distinctly messy - and with the insights gained from this 'first version' of the application (I don't mean V 1.0, but rather the overall code base) the developers start to think about how it could be 'done right'. You know, now they know how they should have done it. Fired with new zeal and enthusiasm, the developers embark on a grand rewrite project, which will throw out all the old, stale, horrible, nasty untidy code, and construct reams of brand new, clean, designed, and, uh, buggy, incompatible, untested code.

Oh well, it " ll be worth it... right? So the new version will break some things that worked with the old version - the benefits from the changes far outweigh a loss of backward compatibility. In their minds, the developers are more focused on the cool aspects of the new version than they are on the fact that in the real world, millions of people are still using the old version. Eventually, then, the new version comes out, to grand fanfare. And a few people download it, try it... and it doesn't quite work. This is perfectly normal, these things need time.

So all the people who are running large production systems with the old version just back off for a while until the new version has been tested properly by, uh, someone else. Thing is, nobody wants to use their own production system to test the new version, particularly when the new version is incompatible with the old version and requires con fig changes which would be a pain to change back to the old version when the new version breaks! So what do we end up with? Two versions. The old one (which everyone uses) and the new one (which some people use, but is acknowledged to be not as reliable as the old one). Perhaps over time the new version becomes dominant, perhaps not... the more different it is from the old one (and the more things that it breaks), the longer it will take.

People have existing systems that work just fine with the old version, and unless they are forced to, there is simply no reason to upgrade. This is particularly true for Open Source software, because since there are so many people using the older version, it will inevitably be maintained by someone. There will be bug fixes and security updates, even when all the 'new' development work is officially happening on the new version. With closed proprietary software, it's different - companies like Microsoft have much more power to effectively force people to upgrade, no matter how much pain it causes. But regardless of all that, I am left wondering what this all gets us. Is it really the best way?

If software works and is used by lots and lots of people quite successfully, then why abandon all the hard work that went into the old code base, which inevitably includes many, many code fixes, optimizations, and other small bells and whistles that make life better for the user. The older version may not be perfect, but it does the job - and, in some cases, there just doesn't seem to be a good reason to upgrade. New versions mean new bugs and new problems - it's a never ending cycle. And, in truth, aren't we reaching a kind of plateau in software development? Are we really doing anything all that different today than what we were doing ten years ago?

Or even 20 years ago? When I learned C++ back in 1989, people were writing the same sorts of programs they are writing now, just with different API's. Are the users really doing anything all that different? Word processing is word processing, after all, as is email and web browsing. Anyway, here are a few examples of this trend that sprang to mind once I started pondering the subject...

-Neil Gun ton January 15th 2004.