Software Engineering is not a hoax... (was Re: Any research putting c above ada?)

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <5lsjb3$bqc@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

  > I would go as far as saying that ``software engineering'' is a hoax.

    Huh?

  > Developing a correct program is much more akin to theorem proving than
  > engineering activity...

    Ah, programming is not software engineering.  Software engineering
is all that other stuff which successful projects do that results in
projects being successful.

    We had an interesting case a few weeks ago here.  A project
manager wanted to know if switching from X to Y at this point in the
project made sense.  (X and Y here are irrelevant to the discussion.)
He ended up talking to five people who really are software engineers.

    The first person gave him a lot of advice that basically amounted
to do NOTHING to change the specifications for build one, but start a
small scoping activity to make sure that all functions of the current
system are scheduled for build two, and anything else that can be
moved to build three, is.  Then once build two is complete come back
and discuss X vs. Y.

    The project manager thought that this was good advice, but didn't
really answer his X vs. Y question, so he called someone else.  Got
the same answer.  Tried a third person, got the same answer, called
me.  I went over to his office, looked at his schedule charts, and
gave the same answer.  At this point he was suspecting a conspiracy,
because the answers were almost identical and didn't address his
question.  I suggested a fifth person who had been in meetings all
morning, but was familar with the project.   The project manager used
his speaker phone and after asking a few questions got basically this
reply:

    "The thing you have to understand is that even asking the design
team to look at this at this point will cause at least a three month
slip, and you can't afford that, because you are tied to the (system
Z) deployment schedule.  In fact, it is not clear that build three
will be ready by then in any case, so you should make sure that any
functionality provided by the current system is provided in build two.
If it looks like build two will meet your current schedule, then you
can evaluate this question in that context."

    PM: "But is this BETTER in the long run?  That is what I want to
know."

    In chorus: "Trying to answer that now will kill the project."

    All of this had NOTHING to do with actual programming, but
everything to do with software engineering.  Software engineering is
all about knowing the difference between want and need, and keeping
the focus on meeting requirements, whether they relate to cost,
schedule, maintainability, or even to actual product functionality.
The usual stock in trade of the software engineer is managing
complexity, because we know that the project staff can only deal with
so much at a time, and any attempt to exceed that real world limit can
result in disaster.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...