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.

Saturday, March 29, 2008

Software metrics? Oh! You mean lines of code.

With due deference, I beg to differ. Lines of code (LOC) was once the software metric, is now merely a software metric. One among many other software metrics that are being continually conceived, created, and enhanced as software engineering grapples with deepening complexity. There was a time when the biggest challenge with writing code was to make it run, just as the earliest buildings humans built were good if they stood. You could count bricks and measure up such buildings. But then we learnt to build structures like the Taj Mahal. Just as it would be facile to try and measure the Taj by the weight of its marble, software systems of today are intricate interactions of components that are way beyond the ken of code count. Not only are the components larger than their lines of code, the interaction is larger than the component count. Simple intuitive metrics – unrelated to LOC – can give us insights into how design happens, and how responsibilities can be delegated (equitably, one hopes!) to components. I look forward to lively discussions on this and other topics at a forthcoming conference.