Binu Jose Philip's Weblog

How to kill software

This is yet another rantish blog entry. Too many of them recently. Well..

Why some software dies while some survive? I have convinced myself
quality, usability and applicability has nothing to do with it. I use
Emacs, you may use vi or notepad or brief. brief? brief from underware
Inc. No longer out there. Notepad? alive, even my 2 year old has
accidentally launched it while "exploring". Windowmaker, dying. I
always come back to it because it gives me functionality I need and
nothing more unless I ask. You would have your own examples. I am not
talking about open software alone. TruCluster. I work on Solaris
Cluster and couldn't help hearing tales about how good it was - going
going. OS/2 - gone, Windows - very much around, eh?

Bad management. From inside Sun I have seen some wonderful products
die a horrible and prolonged death because of internal politics. I
have seen that happen outside Sun too. The usual reason - even a
failed new project helps in increased visibility. Old wonderful
products just bring in money, not promotions. Usually new projects
cannot happen unless an existing something is killed. Wait for an
ambitious enough person with sufficient lack of understanding to come
along and you can see the death of a fine piece of software. That will
not be a long wait usually.

Laziness and lack of neurons. It is highly unlikely that the same
person(s) who conceived and coded the first cut will continue to work
on some software for ever. Lisp, vi and Emacs anyone? The new person(s)
working on it have to be motivated and maybe *better* skilled than the
author(s). It takes skill to understand a piece of software well
enough to play it. More than that, it takes dedication and hard-work
to stick with it long enough to start understanding it well enough.

Lack of courage. The simple belief "if it breaks I will fix it" is
very hard to come by. Tweaks and blobs and nudges are all well and
good. I worked for sustaining for 5.5 years. The written and unwritten
law there is "lesser lines changed better the fix". That works only to
a certain extent. Every once in a while you have to rip out huge gobs
of code and replace it with something better, more elegant, more
scale-able more tuned to the present designs. Software must change to
survive. If you want proof, read this blog entry by Charles Suresh
(BTW, he was my mentor when I joined sustaining).

One last reason, lack of vision. If the software is conceived with a
limited scope it is guaranteed not to survive long. Over reaching and
over engineering all aside, when you are talking about surviving 20 or
30 years or more, the initial idea has to be grand enough and solid
enough to survive and kick butts of new kids on the block for all that
time. Take Emacs. Survives and kicks butt.

The above is not halfway to a complete list. Still, all said and done,
it hurts when a perfectly fine piece of software you like, is put on
the chopping block for any or some of the above reasons and you have
to watch it die.

Posted at 04:14AM Mar 19, 2008 by binujp in verbal diarrhea  |