🚀 go-pugleaf

In article <11347@boulder.Colorado.EDU> scotth@boulder.Colorado.EDU (Scott Henninger) writes:
>|   Also, regarding the hardware analogy, it does not draw a direct
>|   correspondence between computer software and computer hardware;
>|   rather, it draws an analogy to the extensive catalogs of ICs, 
>|   resistors, capacitors, etc. used by electrical engineers to build
>|   all kinds of application-specific products.
>
>Again, this assumes that the components can be used without modification.  This
>is not the norm with software, but is with hardware.  Also, we must keep in mind
>that resistors and capacitors implement one kind of machine.  For software, we
>must find the equivalents of resistors and capacitors for each domain we write
>software for.
>
>|   It seeks to diminish the "art form" mindset, replacing it with "engineering
>|   discipline".  
>
>To claim that this is true is to claim that all the world's domains can be
>reduced to engineering principles.  While it's a worthy goal, I'm not so sure
>that it can be done.
>
>I would like to hear other opinions.  Anyone out there?
>-- Scott
>   scotth@boulder.colorado.edu

I think I'm probably jumping in way over my head here, but I'll hazard a very
naive opinion... :-).

It would seem to me that the hardware analogy is actually rather appropriate.
But before anyone goes and rants all over me, think about how many engineers
we have out there.  Obviously, "engineering" is still an art too.  Namely, it
is the art of examinging a body of solutions to previous problems and trying
to find one or more solutions which can be adapted to solve the current
problem.  I don't see any way to claim that this isn't still an art, since
we would have replaced all those engineers with computers if it weren't an
art.

This makes me believe that there will always be a certain art to software
development.  I would never claim that engineers are not in some sense of the
word artists.  In this respect, software component development seems to have
two major fronts:

1) coming up with better techniques for identifying commonality between problems
(and therefore their solutions).  This is perhaps as much a "way of thinking"
task as it is an infrastructure development task.  Not to say that there isn't
a *lot* of infrastructure that we can develop.  Quite the contrary, I would
agree with previous statments that software component technologies are rather
embryonic (lots of room for fortunes to be made.... :-).

2) Convince the world (through case studies) that reuse can save them time and
dollars.  This is the only thing that will convince the "suits" that this
wonderful infrastructure is worth paying for and worth the cost of retraining
their people to use.

If this is all very obvious to everyone, sorry...

Thanks,
--------------------------------------------------------------------------------
Brian R. Gilstrap    ...!{ {killer,bellcore}!texbell, uunet }!swbatl!uucibg
One Bell Center      +----------------------------------------------------------
Rm 17-G-4            | "Winnie-the-Pooh read the two notices very carefully,
St. Louis, MO 63101  | first from left to right, and afterwards, in case he had
(314) 235-3929       | missed some of it, from right to left."   -- A. A. Milne
--------------------------------------------------------------------------------
Disclaimer:
Me, speak for my company?  You must be joking.  I'm just speaking my mind.