Friday Jul 11, 2008

Nostalgia and a lesson

Recently, I happened to stumble upon my old old home page. This was
created 10 or more years ago. In it, I had a list of software I like.
Finding how the list changed over time was an educating experience.

My original list:
- Linux
- Emacs
- Tcl/Tk
- Windowmaker

My current list:
- Emacs
- Windowmaker
- GNU (to a certain extend)

Emacs, no  uncertainties there.  Number one.  Learned more
about it, wrote more for it and converted a few unbelievers.
Switched to Gnus meanwhile and I spend horrendous amounts of
time there.

Windowmaker, tried xfce  and gnome and kde. After a little
while everything else started getting in the way. Got half
way to writing couple of applets. Windowmaker on Solaris
applet menagerie isn't anything to write home about.

GNU, even though not an absolute must, not having some of
the things  would cause  pain in the wrong place. Having
switched to Solaris, and spending the rest of my time in
Windows, means, other than for things like Gimp, I really
don't need most of it.

Linux, not in  the preferred list anymore.  The last happy
experience I had was installing DSL in a no good laptop and
finding the laptop come alive. Nothing against and nothing
for. As I mentioned, spending all my Unix time on Solaris is
a big reason. Still, I don't find anything driving me back
to Linux. Using it at home for example.

Tcl/Tk, absolutely  not in the  list. I can't for my life
think why it was in the list in the first place. I remember
being impressed with expect, but that is no excuse. I use
multixterm regularly but that is about it for Tcl.

Trying to explain the above to myself...

A few months back, me and a colleague were trying to burn a
DVD. He had just got his MacBook. The legendary usability of
Mac was put to test. After a futile 10 minutes with the Mac,
a few seconds with google put us right. It wasn't even worth
the question "How do I ..." after we found how to do it. The
lesson learned was, usability is as much about how much you
use it, as it is about how well it is designed.

Tuesday Mar 18, 2008

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.




« April 2014