[lug] software engineering
nate at natetech.com
Mon Nov 13 13:46:03 MST 2006
bgiles at coyotesong.com wrote:
> The heart of engineering is making an informed, economic decision on the
> most cost-effective use of resources. That means knowing when to invest a
> lot of effort into design and implementation validation... and knowing
> when not to. It's perfectly reasonable to say that something isn't worth
> investing a lot of effort.
How many engineers even know how much the product they work on sells
for? I guarantee a building engineer knows the rough costs of every
material and various flavors of labor used in his or her end-product,
and how to make sure the contracts are right so that the customer will
pay for the appropriate things. But in software engineering, I don't
see many companies involving any but a very select few (usually already
in management) engineers in the COST process.
Since we're talking about Linux and then maybe commercially purchased
software... How do you find out just HOW MUCH testing was accomplished
on your software before you received it, as the CUSTOMER?
That's my thinking line here. How do customers find out?
If I buy a building, I get the blueprints, the engineer's sign offs and
dates, I get a LOT of information about how that building was built, to
what standards, etc. I get another sign off from a professional
engineer at a government agency that the building meets current
standards, and most importantly...
If that building does fall down, I have a lot of documentation of who's
PERSONALLY involved with their NAME on the thing.
Shouldn't software engineers be that liable (and probably also
compensated better at the high-end of their skill levels)?
Doctors, Lawyers, other Engineering disciplines, Architects, they all
have HUGE levels of PERSONAL liability (and motivation!) on the things
they work on. Somehow Software "engineering" has managed to not have
that. You don't see many software engineers contemplating taking out
personal liability insurance to cover them in case their employer
subrogates against them.
I think software engineering's relative anonymity probably hurts the
overall quality of the output. If your name and a signature that you
claim it does everything it's supposed to, had to be on it when it
shipped, would you ship it yet?
If someone buys a multi-hundred-thousand dollar software package to
handle some huge portion of their business -- they get nothing but a
disc and the thing still might be so difficult to integrate that they
have to hire an army of consultants. Especially egregious in this
regard, are any software packages labeled "Enterprise".
(In most cases, all that label really means is that you're going to have
to hire a crew the size of the Star Trek Enterprise to install,
integrate, operate and maintain it. And that the sales guy who sold it
to you just started receiving juicy commission checks for the rest of
his natural born life.)
It's also more likely they'll get told "that's a trade secret", if they
ask for more detail of how the software was actually built, even after
the purchase is completed and maybe even with an NDA in place.
The more expensive the software is, the more likely you can't get any
information about it at all.
Open-source gets someone the code, but that's not enough -- it doesn't
get them the design, the architecture, and the philosophy of the
Architect and Engineer working together. A completely different
talented team of people who "build software" could review it for you,
but you just paid someone to do that when they built it in the first
place. They still owe you information about how they built it, but
you'll never see it.
> The key point is -informed decision-. How many of our decisions are
> properly documented? You wouldn't want to do this with a 5-line perl
> script to monitor disk usage, but how many of us could successfully
> convince our boss to invest a few hours every week in documenting the
> basis for our decisions? (N.B., not designs or implementations, but the
> decisions we made plus a brief justification.)
Sure would be interesting.
> I think that's the biggest problem with software today. Not that it's
> released "too early", that it's released without really thinking things
> through. Different people and group makes their own "best" decisions but
> they aren't always playing to the same goals -- that gives you
> inconsistencies and flakiness. You would never see a civil engineering
> project that deliberately built a six-lane road up to a two-lane bridge.
Agreed! Great example! :-)
More information about the LUG