Iced up Cirrus crashes

"Matt Barrow" wrote in message
...

"Colin W Kingsbury" wrote in message
ink.net...



And the long range costs of software done haphazzardly is...what?


Much cheaper products and faster evolution in terms of features. Perhaps the
most famed software development outfit in the business (in terms of quality)
is the Lockmar group that built and maintains the guidance control program
on the Space Shuttle. They know of a small number (5 IIRC) bugs that cannot
be fixed without causing worse problems elsewhere.

Among other things, the computer this program runs on has not changed much
in 20 years- it is basically comparable to an Apple II in terms of
processing power. Second, five or so years ago they did a little accounting
and figured that over the years, the system had cost about $35,000 per line
of code. Now, Windows XP is up into the tens of millions of code by itself,
and MS Office is perhaps twice again as large. Do the math and you see we're
talking numbers into the hundreds of billions. So perfection (or as close to
it as is possible) would cost something like the size of the budget deficit.

While individual users have very little power over a company like MSFT, they
do in fact listen to their big enterprise customers like say Bank of America
who buy licenses tens of thousands at a time. For years, quality was not an
issue because the cost of failures (system crashes) was relatively low. But
this is starting to change because of awareness about security issues, among
other things. A large number of the security flaws that exist in Windows are
symptomatic of slapdash engineering. A virus that takes ten thousand
desktops down costs the BofA probably millions of dollars. So now these CIOs
are telling MSFT that they need to get their act together.

-cwk.

I must politely disagree. And this is very much off topic to this N/G.

I have worked on very large projects (including a tracking system for
NASA). When QA is part of the planning process (that is, a group is
responsible for validation, certification and regression testing),
things are done a bit differently.

When automation is used to test the system being built, testing and the
results come back very quickly. Debugging done by the developers is
more efficient than when it is expected of the support people. The cost
of debugged lines of code drops.

One other thing about software development - high level language coding
vs. assembly language ("machine language") coding. The development
costs are quite high for assembly language, particularly when they have
to work right the first time. But when that development can be done in
high-level languages that have been debugged, cost of development drops
when compared to "machine language" development.

So when software development is controlled and driven by the marketing
arm of a company, too often you get buggy code that has not been
correctly documented. [I've worked under those conditions too.]

Regards,
Steve.T
PP ASEL/Instrument

"Steve.T" wrote in message
ups.com...
I must politely disagree. And this is very much off topic to this N/G.

Since when has that stopped anyone?

So when software development is controlled and driven by the marketing
arm of a company, too often you get buggy code that has not been
correctly documented. [I've worked under those conditions too.]


Well, you'll sooner have cats and dogs living together than marketing and
engineering getting along. I've lived on both sides of the aisle and as a
now general manager I can say unequivocally that software development
*should* be driven by marketing. If they are doing their job right, they
understand what will sell and that is the point.

Looking at this from a product management standpoint, it is all about how
much priority you assign to building quality versus building other aspects
of the product. There is no free lunch: quality costs time. It may pay
itself back over the long run but companies often live and die financially
in the short one, so choices must be made. I have worked at two companies
that over-engineered their products and died as a result.

The real failure here is that consumers have no good way to get a handle on
the quality of products they're considering buying. This is especially acute
with typical business systems that are not mass-marketed. There is no JD
Power/Consumer Reports survey for software like there are for new cars. So
even if a customer says, "I'm willing to pay 10% more for a 5% improvement
in quality," there's no way for them to find out who is in fact better.
Vendors therefore have little incentive to do better than anyone else. New
features on the other hand will logically be prioritized over quality
improvements in many cases because while no customer will pay 10% more for a
quality improvement that can't be measured, they will pay 15% more for a
catchy feature that is quite obvious. We can argue the details but the
purpose of a business is in the end to make a product customers are willing
to pay for. Traditionally quality has not been rewarded by the market.

As an economist, I see this as a classic market failure known as the
"prisoner's dilemma." Because of the lack of information (difficulty of
measuring relative quality objectively), the market fails to provide
higher-quality options even though customers clearly want them. This
coincidentally is the branch of game theory that won John Nash (the subject
of "A Beautiful Mind") his Nobel some years back.

-cwk.