Thursday, August 7, 2008

Use and renewal

In one of Tagore's dance dramas, the diva asks her cronies to renew her with new jewelry. How much renewal she had by such means, and what she did with such renewal, is what the dance and the drama is all about, and I will not divulge it here. But those of us, like the diva, who are obliged to recognize the decay of flesh, crave at one point or the other for renewal. Trees have at least the ritual of renewal. Once a year old leaves shed, and new ones shine. We alas, have no such facility -- the ritual of renewal, or renewal itself.

Decay comes with age, with use, with wear and tear, and tears. These come with living. In every mechanical system -- or systems with at least some mechanical parts, like the human body -- parts will wear, mostly the moving ones. But in software, there are no moving parts. So what wears a software system down, what wearies it?

This question has been asked and answered many times. Most fascinatingly, each time the question has been a little different, and the answer commensurately so. Thus it is no more one question with one answer. The decay of software comes with use, as new and newer functionality is stacked on an unsuspecting initial design. It is hoped that the underlying plasticity of software will be equal to anything. But what is unique about the use of software that warrants such wanton expectations? What is that which sets apart the use of software from the use of say a car, or bridge? We take a car or a bridge as given, love it or hate it, or become indifferent to it, and move on to another car, or another bridge (if we are in a car). But with software we are ever so tantalizingly close to what is, and what we want it to be. For software, the die is never cast. Frequently software never dies, one system merely reincarnates to another. Like our lives, there is always change. Change like the diva's new jewels, has the power to renew. Or thus the diva budgeted.

Ruminations on renewal apart, a key challenge of software engineering is to know what to do about changing requirements, or at least know what it does to a software system, take it as given, and live life from there.