[Software ]

Matt Graham danceswithcrows@usa.net
12 Mar 2001 16:44:17 EST


Edward Glowacki <glowack2@msu.edu> wrote:
> Software sucks.

If anyone on this list has not heard Three Dead Trolls In A Baggie's "Every OS
Sucks", go download it.

> Second is that professionals can't code either. (By professionals,
> I'm referring to "has graduated college with a CSE/CPS/equivalent
> degree.).  [snip]  
> because we don't have a development
> cycle, we just write-once-and-throw-away our code here.  I could
> rant on this a while longer, but I think what I've already said
> will suffice.

Yep.  Time pressures prevent even pros from fixing old bugs since they're too
busy implementing new features.  If it compiles, ship it.

> Third is that users don't seem to give a shit that their software
> sucks.  Even I, who seems to know better, have been trained to use
> shotty software and "just deal with" the crashes.

...who the users gonna call?  Microsoft?  Shyaa right.  If the users have
contracted with a dev firm that's produced a piece of custom software, then
the users could possibly call up the developers and report the latest bugs. 
Then the developers could fix things.  This doesn't work unless the dev firm
is small.  Big firms have effective phone firewalls to prevent the developers
from getting deluged with "stupid user tricks".  This is both good and bad. 
See next paragraph.
 
> Fifth is that software is written by geeks for geeks.  Very few
> products (be it an OS, a piece of software, a web site, whatever)
> are designed with any significant user testing, other than testing
> on other geeks.  You end up using stuff that's cryptic and has
> plenty of "cool stuff" instead of stuff that's easy to use and has
> the stuff you need.

Testing gets shafted in the real world.  They want "whitebox testers", people
who can not only test software, but go into the code and find out what's going
wrong and make small changes to fix small bugs, which means the developers
don't have to fiddle with small things.  These whitebox testers are,
naturally, pseudo-programmers and at least partial geeks.  Maintaining a "user
mindset" is bloody difficult when you know par tof what's going on.  "Blackbox
testing", which doesn't require geeks at all, is out of favor because it's
more expensive and slower.  (Speaking from personal experience?  Who, me?)

> Seventh is that users don't give any feedback.  How many times have
> you personally written to a software author and said, "Hey, when
> I do this and this, your program produces funny output."?  I've
> done it a few times, but not enough.  I've more often suggested
> enhancements or ways to do things differently to make them work
> better, but even then, I could have done more.

Point 7.5:
Users are STUPID.  Most users are *incapable* of providing good feedback, or
any feedback at all.  Case:  I was working on a project about 1.5 years ago,
when a (l)user sent out an e-mail to everyone using the program.  COmplete
text was, "i need someone to do X for me by thursday.  oh yeah the program
ain't working."  After giving this luser the 3rd degree, I found out that the
program had generated the following error:
"Your home dir. is 100% full.  Please delete something, or you will be unable
to use the program.  Also, other programs like Pine will complain that your
home is 100% full.  Please tell the programmer that this has happened."

He didn't have 2 brain cells to rub together and report this error, let alone
do what it advised him to do.  As a result, I spent 2 hours chasing wild
geese.  This is not an isolated instance; the users at my current job are just
as bad, they're on the opposite side of the world, and they speak English as a
second language (if that.)

> Ninth is legacy software. 

Ah yes, and we all know how well BeOS did with their idea of scrapping all the
old crap.  (It irritates me when "old code" is called "legacy".  Euphemisms
everywhere.  Now, it seems that "legacy code" is turning into "heritage code".
 I'm going to have a proactive issue with this and morph it into an action
item.)

> Tenth is documentation.

I refer you to the Dilbert cartoon where Tina exclaims, "How can I write
documentation for a product that doesn't exist yet?"

> Eleventh is lack of vision.  Or more precisely, lack of
> a plan containing the intermediate steps between where
> one is at and the vision, which itself rests on the X axis 
> at infinity.  

There is a vision for the projects I'm currently working on.  Actually several
visions.  The lead programmer's vision, which is currently locked up in his
skull, the marketing department's vision, which mutates unpredictably
depending on which client he's talked to recently, and the dev team's vision,
which is multipartite and mutates depending on how much beer they've had. 
Very little of this is written down anywhere, and if it were, it'd be out of
date in 3 days.

The problem is time.  Never enough time to do it right, always enough time to
do it over.  See _The Mythical Man-Month_ for more coherent thoughts on that. 
Ack.  I need to get back to work.  Good rant.




-- 
Matt G / Dances With Crows
There is no Darkness in Eternity
But only Light too dim for us to see

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1