[MUD-Dev] Re: Why did it take years?
Adam Wiggins
adam at angel.com
Wed Oct 28 17:14:21 CET 1998
On Wed, 28 Oct 1998, J C Lawrence wrote:
> 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...)
Absolutely. I've actually worked both sides of this issue before.
In my earliest jobs, I worked with 9-to-5 software engineers. People
that took CSE in college because they heard it was a good field,
learned everything they needed to know, and then got clockpuncher jobs
writing straightforward code. With *them*, you have to work hard to
get them to try doing anything not completely ordinary. eg: the first
real 9 to 5 job I had was for a company that made some medical account
software for small doctor's offices called Medisoft. Medisoft was a
giant kludge of code, most of which was BASIC which was translated to
C by a basic-to-C converter. Every single menu, window, and help
screen was special cased. Myself and one other programmer there started
arguing that there should be a toolkit for generating the apps (there
were numerous variations - the Lite version, the Pro version, the
Dentist version, the Optomotrist version...) with some good core functionality,
and then all the windows and help screens and whatnot could just be read
from text files or simple scripts. They didn't like this idea much;
and of course, the idea that we ditch the BASIC code and convert the
whole thing to C++ was met with scoffing laughter.
However - at every game company I've worked for, the attitude is the
reverse. Most everyone is there because they want to work on stuff
that's "cool" and "neat", things that have never been done before. Just
keeping the ambition in check can be a full time job.
And there's no worse offender, as a group, than mud-dev. The
ambition and groundbreaking ideas availible here is like nothing I've ever
seen. Naturally, I think this is great - it's why I'm here. But now
that there are folks talking about collaberating on a real project, I take
a slightly different attitude. Cool stuff is important, but you need
to figure out the few major groundbreaking things you're going to focus on,
and leave all the rest as utilitarian and unexciting as possible.
That's why I'm playing the pessimist; I know that no matter what anyone
says, the amount of ambition and optimism in this particular group will
always far outweigh any practicality. But I thought I'd try to at least
tip the scales the other way, at least just a little bit. I've seen
quite enough ambitious projects created by truly talented people become
burried under its own weight.
Adam W.
More information about the mud-dev-archive
mailing list