[prog] State of software engineering profession

Jimen Ching jching at flex.com
Sat Apr 12 21:18:38 EST 2003

On Sat, 12 Apr 2003, Robert J. Hansen wrote:
>The first generation of programming languages--FORTRAN, COBOL
>and C--weren't designed for crossplatform portability.

I'm not sure why you keep coming back to crossplatform portability.  This
is one instance of the problem, but not the premise.

>> profession.  This is not the point, my 'real' point is that we seem to
>> accept _excuses_ for every problem we have.
>If we were accepting excuses, would we really be investing so much
>(economically and intellectually) in solving the portability problem?

Finally, something relevant to my point.  Good.  Perhaps you did
understand after all.  ;-)

Though portability is not the only problem, let's use it as an example.
Exactly what economic and intellectual investment are you refering to?
Inventing yet another language, is not a solution to the portability
problem.  If the processor manufacturers standardize on a single
instruction set architecture, we wouldn't have any portability problems at
all.  A VM is just a software path to this solution, and as a result, it
incurs a performance penalty.  What we need is a hardware path.

Also, standardising on an ISA could still allow each chip vendor to
differentiate themselves.  They could design processors with different
clock rates, heat dissipation, power consumption, etc.  There are many
parameters that go into designing a processor.  AMD and Intel have been
designing chips with the same ISA for many years, and both are succesfull

This is THE solution to the portability problem.  The fact that we refuse
to accept it is part of the point I've been trying to make.  Of course,
again, portability is just one problem.  It isn't even the biggest
problem, in my opinion.

>> P.S.  I don't accept the idea that software applications are broken
>> because the industry is not mature enough.  It is broken because of poor
>> design, poor implementation, or poor testing, or all three.
>The fact we don't have any good, commonly-held best practices for design,
>implementation and testing is evidence that the field's immature.

I think we have to agree to disagree here.  By the way, when I say 'poor
design', I didn't mean there isn't 'good design' concepts.  I mean the
designers are, well, low quality.

>We're still at the level of "skilled artisans putting together
>automobiles one at a time", not the software assembly line.  There's been
>a _lot_ of effort at creating software assembly lines, but so far they've
>all failed.  That doesn't mean we, as practitioners in the field, are
>failures.  That just means we've got a hell of a long way to go.

Cars aren't designed on an assembly line.  I don't see why the design
process of software needs to be different from the design of everything
else.  A software application is a system, just like products in every
other industry.  And there are a few 'visionaries' that design software
like everything else.  It's just that our industry doesn't do it that way.

There are many code generation tools, which bring us closer to an
assembly-line methodology.  But you're right, we're not there yet.  But
there are best-practices that are accepted universally, i.e. peer review.
I haven't heard of any development process that says peer review is a bad
idea.  How often does the industry perform peer reviews of design and
implementation?  Matter of fact, the software industry goes out of its way
to make peer review difficult--by not releasing source code.  Peer review
is just one example of best-practices.  There are many others that other
industries use.  Best-practices are almost always universal.

Testing can be done on an assembly line for cars as well as for software.
An assembly line is just automation.  You can automate testing today with
existing tools.  Many companies do it and a few are actually succeeding.

I am beginning to see an explanation for the point I was trying to make.
Which was an observation on the software industry about how it is so
willing to accept the poor state of the profession.  Robert, if your
reasoning is a representation of the industry in general, then I can see
how we got here and how we are stuck here.  But this might pose a
difficult problem.  If I'm having this much trouble just trying to
describe the situation, imagine the effort in selling the solution to the
industry as a whole.

This has been an interesting intellectual excercise.  Thank you.

Jimen Ching (WH6BRR)      jching at flex.com     wh6brr at uhm.ampr.org

More information about the Programming mailing list