[MUD-Dev] Re: Why did it take years?

J C Lawrence claw at under.engr.sgi.com
Wed Oct 28 15:26:15 New Zealand Daylight Time 1998

On Tue, 27 Oct 1998 19:21:44 -0600 
Cynbe ru Taren<cynbe at muq.org> wrote:

> For me, at least, it depends a lot on the task.  I once did 20,000
> lines in 2-3 days by dint of writing about 900 lines of Perl to
> autogenerate them.  (Brute-forcing the Marching Cubes algorithm
> for extracting a surface from volume MRI data by compiling
> special-case functions for all cases.  Result ran limited only by
> memory bandwidth...)

There's another parameter (not that the software development process 
is terribly on topic): original verus additional code. 

Comparitively its much easier to write X thousand lines from scratch
and have a working system than it is to write the same number of LOC
against an existent code base and to have it work similarly well.

> For now, I'm living on lentils scraping up the last of our down
> payment (closing in a week -- http://sandystone.com/house.html for
> a pic of our glorious view and rundown new dump :) 

Please don't talk to me about buying houses.  We are still trying
to.  Our lawyers are still fighting and there are no winners (nor
likely to be anything but bankrupt survivors at this rate).

> so the old dual-CPU PentiumPro box I built for Muq will have to do
> for now.  RAM's cheap enough that I put 256Meg in it, which should
> avoid displaying the current inefficiency of diskbased operation
> too obviously at first...


A dual Celeron 300A performs pretty nicely and can be had, decently
dressed for under US$1K.  (I've toyed with the idea of making and
selling these babies).

>> Here's what I usually like to do at the start of a big project:
>> Make a list of things that are really, really, really important -
>> things the project just won't work at all without.  Those should
>> be done first.  Make a second list of things that are really,
>> really important - things that without which, the project will
>> suck.  These will be done next, although some of them may remain
>> undone with the product ships.  Finally, make a third list of
>> things which are really important - things that would add a whole
>> lot to the project, and which would be really cool.  You will
>> never do any of these things.

> I think anyone who has been through a major software development
> team effort will recognize the truth of that!

There's a scale in there.  There's also a question of engineering
process and control.  

A whole lot of Irix (eg the 4Dwm desktop manager (note: not the
windowmanager, but the Indigo Magic bits) and many of its little
clever bits, the finder, etc) came about because some engineer went
out and did something that he thought was "cool" (or often merely
helpful) and slipped it into the production code.  That said, a
whole LOT (millions of dollars a year of LOT) of SGI computers were
sold specifically because of such "cool" items.  This could never
happen at sites with heavier engineering processes, controls and
standards.  There is a very good and simple reason taht HP-UX is a
generally stable, predictable, and ever so boring OS.  They have
very good, enforced, and controlled engineering processes.  HP also
doesn't sell very many boxes on their "cool" factor.

<<And yes, the loss of "cool" at SGI in many ways has contributed to
their current hard times>>

Translation: Ferarri's don't just sell because they're fast.  They
also sell for the "cool genetalia waving factor", and given their
ongoing maintenance expenses, a whole lot of "cool" went in instead
of many "gotta have this or it will suck" factors.  (There is no
jealousy here just because I get passed by at least 5 Ferrari's on
my commute to work, or because the guy up the hill from me has a
Lamborghini, two Ferarri's, a Lotus and a DeLorean...)

J C Lawrence                               Internet: claw at kanga.nu
(Contractor)                              Internet: coder at kanga.nu
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

More information about the MUD-Dev mailing list