On Tue, 16 May 2000, Jeffry Smith wrote:
>> In the software engineering field, the design *is* the product.
>
> NO!! I've overseen software development. The code is NOT, repeat,
> NOT, the design. The design is the functional description of what the
> CODE does / will do.
*sigh* I knew this would happen.
What we, in the software engineering field, call "design", other engineering
fields call "specification". The deliverable product of software engineering
most closeness approximates what "regular" engineers call designs. I wrote
that message and made those statements in the context of engineering in
general. Please adjust your scope and re-parse. ;-)
In the field of software engineering, yes, design is a separate step from
implementation. That isn't what I'm talking about.
> Why is it highly coupling? Because we build it that way. It DOESN'T
> HAVE TO BE BUILT THAT WAY!!!! IF you follow the Unix philosophy, and
> good OO practice, you don't build it that way.
They *help*, but they do not make the problem go away. Computer software
still exhibits a level of coupling unheard of in any other field. You can't
tell me you haven't seen this yourself.
>> With software, all too often, anything more complex then a
>> push-button needs to be designed from scratch.
>
> see above. We don't have to keep doing this.
I agree (and thought I made clear; guess I was wrong) that things can be
done better. But we still find ourselves doing things over and over and over
and over again. I think there are a lot of reasons why this is the case.
Some are technical, some are political. Here are a few of my theories:
One is immature techniques and tools. We are still inventing the techniques
(object-oriented design, for example) and tools (CASE packages, IDEs, etc.)
that other fields have had for years. Many (most?) engineering fields are
basically applied physics. The Newtonian world we live in hasn't changed in
10,000 years of human civilization. That is a lot of time to figure out how
to build a house. We haven't had nearly as long to figure out how to build
software.
The above will be solved, in time. But what about these:
When you build a system with a high incidence of code reuse, you also create
a large dependency tree. A bug in, say, printf(), effects an *awful* lot of
programs. So, while reusing code, you introduce single points of failure.
Which way do you go?
The speed at which computer hardware technology advances in is another
problem. Computing power doubles every eighteen months, or so Moore's Law
tells us. That is unheard of in other fields. However, the state of the art
in software engineering seems to advance at a more "normal" pace. The
hardware guys are developing new things faster then the humans who have to
program them can keep up.
Flaws are not always readily apparent in software. If you've got a
structural element in a wing that needs to support 10,000 pounds, you put a
five ton weight on it and see what happens. Bugs in software, however, can
lie undetected for *decades*, even if the code is in plain sight, simply
because the bug is only triggered by a particular combination of things that
hasn't occurred yet. A bad executable looks just like a good one.
Then there is the fact that each software program has the potential to be
totally different from the last. This is very significant. While the
technologies used to implement them have changed quite a bit over the years,
the general design of an airplane hasn't changed much since it was invented.
(Here I'm using "design" and "implement" in this CS senses). But a word
processor is very different from a spread sheet, and nothing at all like a web
server. Sure, you can re-use shared components to do things like sort strings
or buffer I/O, but there is a high level of uniqueness to each problem being
solved. Combine this with the fact that, very often, all involved don't
*really* understand the requirements until after they've tried implementing
the system, and you've got a problem that doesn't exist in many other fields.
I am not so sure these problems will be solved easily.
Then we have the political problems, of which I'll list just a few:
Managers who don't understand the separate requirements specification,
design, implementation, and testing stages required to write good software.
Managers who don't understand what good software is, period.
Requirements that change after you enter the design phase. We're all guilty
of this. Software is such an intangible thing that we subconsciously seem to
think we can get away with this. We can't.
Software development schedules that are driven by release dates. You cannot
hurry quality. Software is done when it's ready; before then, you're
releasing a buggy product, pure and simple.
I could go on and on. Heck, I already have.
>> Of course, with your traditional, closed-source software business, that
>> won't happen. Again I stress: The design *is* the product. Boeing can
>> give away their designs because they make jets. A software company makes
>> designs.
>
> Actually, you also get the product (for a fee, because it's made of
> material).
Are you talking about distribution media and printed manuals? Those are not
software products. They're equipment. The software product is the ones and
zeros encoded on the media. The cost to "manufacture" a copy of that binary
data is effectively zero.
> What you really pay Boeing for is their expertise in building solutions to
> your problem (moving cargo long distances, through the air).
And the software industry argues that you're paying them for their expertise
in building solutions to your computer problems.
> You could build aircraft yourself (believe it or not, they teach it in
> school, you can get all the blueprints).
Right. And how many companies have the facilities to build a 747? :-)
> BTW: You can, if you want, tear that Boeing jet into a bazillion
> piece & put it back together. Try doing that with proprietary
> software.
I suspect tearing a Boeing jet apart and putting it back together would be
about as easy as attacking your average closed-source product with a
disassembler and other reverse-engineering tools. :-)
>> The service segment remains, of course, but selling services is not the
>> same as selling a product.
>
> Which is what Boeing, Ford, GM, AirBus, et al are really selling.
Well, to some extent, although the manufacturing and material costs of a 747
are nothing to shake a stick at.
> ps: I like the sig.
Thank you. :-)
--
Ben Scott <[EMAIL PROTECTED]>
| "Knowledge is always of value, and the value is never predictable. What |
| will come of it, we cannot know." -- Larry Niven |
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
