Len Yabloko wrote: (01)
> I don't think you appreciate both: the intellectual challenge
> and practical implications of this discussion. (02)
I'm sure I don't. (03)
> To call something an engineering does not make it so. (04)
Agree. The same goes for "theory" and "science", I might add. (05)
> Before Industrial Revolution people were building and making things
> for the most practical reasons and in the most practical way they
> could imagine at the time. That does not qualify it as engineering.
> That was craftsmanship like carpenter, smith etc.
>
> Engineering results in consistent scalable production, (06)
If by "consistent, scalable production", you mean there is a set of
established methods and practices that are known to work in most problem
spaces (of a given kind), I can agree. (07)
> which so called "knowledge engineering" does not. (08)
Well, OK. At present that is true. We haven't yet established a set of
reliable methods and practices. But we are trying to find them. And we
probably don't have enough observations to be used as a basis. (In
fact, many of the best observations we have are from data modeling.) (09)
> And it will not until it applies theories. (010)
I would point out that some magnificent buildings were built by persons
with experience and methods without benefit of accepted theories.
We call the builders of the pyramids and of the temple in Jerusalem
"masons", rather than "civil engineers", I suppose. But a
number of reputable publications have referred to DaVinci as a "military
and civil engineer". And the Romans surely did "military engineering",
by all accounts. And shatter-resistant windshields were designed in the
1950s, but the supporting mathematics for the structural analysis was
developed in the 1960s. And the operations research methods of the
1960s also proved that the logistical planning for the 1948 Berlin
airlift was 94% of optimal. (011)
To put it plainly, I don't think the experimental evidence supports
Len's hypothesis. (012)
"Consistent scalable production" is not dependent on having theories, it
is dependent on having established methods and practices, supported by
observations at least, and theories at best. (013)
I would not accept the idea that "civil engineering" first began with
Eiffel and Roebling, just because they were actually applying physical
theory to the problem of structural design. But that _was_ the time
when civil engineering moved from an observation basis to a theory basis. (014)
> One of theories is "Model Theory" which you so casually attached
> to "model of knowledge". This is another example of pseudo-engineering.
> In fact data modeling is only an engineering discipline withing a
> particular well axiomatized relational model with all available
> mathematical and technical tools. (015)
And otherwise it is simply a technical trade? OK, then I'm a tradesman. (016)
I have an analysis approach, a design approach, correctness principles
and quality principles, and validation methods, but these are based on
the collective experience and observation of a community. Yes, we lack
a mathematical theory for comprehending what business people mean by
what they say. But just as Caesar's engineers knew how to get an army
across the Rhine, we do know how to get a business's data into a
manageable, reliable repository that supports its applications. And
doing that takes analysis and design and development and verification
and testing. That is why we call ourselves "engineers". (017)
BTW, we don't so much lack theories. The problem is in figuring out how
to apply them. And that might mean there are no useful theories yet. (018)
> Likewise software engineering is only engineering within well
> developed calculus translated into true programing languages - (019)
Well, I agree that "software engineering", as currently practiced by
most software engineers, isn't engineering. But the above is not
helpful. It only encourages the nonsense of "computer science" and
"automated software design". (020)
Software engineering is about the design of a machine, a system, and you
can no more completely characterize the behavior of a software machine
than you can a complex mechanical device. You can completely
characterize the behavior of small parts and you can approximate the
system behavior with analytical models and simulations and empirical
measurements, in both cases. The difference is that mechanical
engineers do; and "software engineers" could, but don't. (021)
There is no calculus for programs and there is no calculus for engine
designs. There are methods for evaluating engine designs, and there are
methods for evaluating software designs. (022)
But "computer science" uses semantics and logic, relational algebra,
numerical methods, mathematical programming, and simple machine theory,
which seems to me to be a fairly strong theoretical basis -- it just
ain't physics. And it isn't yet clear how it provides more than a basis
for methods for solving specific kinds of sub-problems. (023)
And no engineering discipline has a theory, or even a clear and accepted
discipline for "systems engineering" -- breaking the real problem down
into solvable parts and rebuilding a functional whole from the part
solutions. There is coming to be an established practice for that, but
it is very recent. 30 years ago, it was a "black art", and the
expertise was hidden inside the companies that built big systems --
ships, aircraft, automobiles -- because it was part of the corporate
business advantage. But software engineers have been forced to solve
similar problems for over 20 years, and most of what was called
"software engineering" in the literature was about dealing with "systems
engineering" problems. (024)
> all other "creativity" in software industry has not yet reached
> the level of engineering, despite considerable wealth created,
> which is not a proof of soundness (at least to me). (025)
Engineering is about applying theory, knowledge, observations,
principles and method. I agree that the software industry as a whole
has not yet reached the level of "engineering", but IMO, the problem is
the failure to abide by established principles and the failure to
practice method. (026)
We don't teach "computer scientists" to be engineers; and we the
employers don't require them to be. We treat them like artisans and
they behave like artisans. But the first step in fixing this is to
teach them engineering discipline and enforce it in the workplace.
Unlike Len, I think emphasizing "theory" muddles that message. (027)
-Ed (028)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (029)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (030)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (031)
|