🚀 go-pugleaf

In article <slrn5uf92j.ci1.zebee@zipper.zip.com.au>,
Zebee Johnstone <zebee@zipper.zip.com.au> wrote:
>On 5 Aug 1997 15:23:45 GMT, Ben Neil Gerdemann <gerdemb@rice.edu> wrote:
>>I think the problem this software developers are constantly under pressure
>>to get their software out as fast as possible. Writing tight small code is
>>not a priority, and until hardware speeds stop increasing so fast it won't
>>be. Sigh. 
>
>I don't think that's the full story.
>
>Code on things like C64s, PDPs etc was mostly assembler.  Hard to write,
>but very fast.
>
>These days it's all written in C, easier to write, portable, but
>slow.
>
>C programmers are easier to find and cheaper than assembler programmers.
>
>Ccode is portable, assembler isn't - so while assembler was fine if
>you have oe OS and one chip to code for, these days, use
>C.
>
>Way back when, I knew a guy who wrote a radar training simulator
>for the RAAF. It ran in 640K on a TI PC clone (cos at that stage
>the TI box had the best graphics). It was in assembler and
>performed as well as the huge thing they'd been using that
>took a room and 5 men.
>
>It was retired a few years ago for something swisher, on an SGI
>I believe.  Needs a fast CPU, and scads of RAM, but it didn't need
>a hotshot assembler man.
>
>Zebee

Well, to say that in order to have a fast program, one has to code
it in assembly language, it's like to say that in order to run fast,
one has to wear a pair of Nike (put in your favorate brand here) snickers.

I always believe that the leg power of the runner has more to do
with speed than the snickers do.

Bad softwares certainly have something to do with tight release
schedule. But that also has to do with a bunch of other factors,
like the designer/programmer ability, the attitude of the manager
towards innovation (lots of managers manage on a if-it-ain't-broken-
don't-fix-it basis), the budget, the resources the company is willing
to put in, etc. I am a software developer myself, and I know
what that means.

As an example, I was once brought in to a project to work on
the system robustness of a buggy system. After the analysis,
I proposed to the manager to change radically the code, if not
redesign the whole system. For a safe change (no redesign), I
can reduce the code by half and double the speed (and that was
a conservative estimate). 

The manager's response was: "Don't change anything, the system is
already out there for field trial. If anything happens, we want
to be able to trace the problem with the existing code. Put that
for the next release."

The company has 4 releases each year, and each field trial period
last two months. So the change is being postponed release after
release, and all the problems never got fixed.

Other problems are related to programmers' training. Nowaday,
anyone who can code (not necessarily well) can concider him/herself
a programmer. Other fields of engineering require very strict
training/education, but not "software engineering" (the right
term would be "software craftmanship"). 

The order of priority in software development industry is this:

  - Make it work
  - Make it right
  - Make it fast 
  - Make it small

You can imagine the result if the last two priorities never get
the "processor time" :)

ciao

Xiaopong