Software's evil

Tim Wescott wrote:
> 
> It's possible to improve the development process of software so it 
> doesn't suffer from these evils.  Unfortunately, the improvements have to 
> have support of nearly everyone in the whole organization, and certainly 
> majority support at every layer.  This means that any manager in the 
> chain from the developer up to the Big Boss can cut the whole thing off 
> at the knees by choosing to believe an optimist who promises a shorter 
> schedule.
> 
> I've seen big complex projects work, but I've seen it far less often than 
> I've seen them fail.  And I've seen them fail due to individual failures 
> at just about any level.

True enough.

Sometimes, however, it takes a hero to make a project work
but not before he has had the nerve to send away all the
nuisance ;)

Not Really Me wrote:
>>
>>
> My thought is that the first step is to improve the specification process. 
> When was the last time you got a software specification that was actually 
> complete and didn't require revisions?
> 
> Customer/Marketeer:  It should have a two line ascii display.
> 
> Engineer:  What should it say on this display?
> 
> C/M: You know, a menu of something?  How long to you think it will take?
> 
> Apologies for over simplistic example, but we've all been there.

We have a saying for that: they asked us to make
a product that could say "papa-maman" (mum and dad)

Lanarcam wrote:
> Ed Prochak wrote :

>> problem complexity
>> Some problems are now being automated which may be unsolvable.

>> I don't know when a breakthrough will come, but I don't think we have
>> seen it yet. And it may not come as a singular event. We may muddle
>> thru and improve our processes, our solutions, and our tools in
>> varying steps.
> 
> I tend to agree with all of that, but somehow, they managed to
> build a "complex" rocket in 1969 which involved communications
> among many teams and at a time when tools were scarce.
> Applying systems building techniques would certainly help.

It seems to me that the computing used on in the Apollo
program was pretty primitive in terms of complexity,
performing more of a calculator role than any other.
A marvel of complexity to be sure, but more of a
mechanical marvel than any other. I think the crew
provided much of the processing and IPC :)

-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1

Vladimir Vassilevsky wrote:
> 
> 
> Pertti Kellom�ki wrote:
> 
> 
>> But the properties one really wants to
>> verify are much more abstract, such as "does this piece of software
>> land my plane safely?".
> 
> It is enough if this piece of software lands the plane safely in 99.999% 
> of cases. There is no point for the further improvement if the insurance 
> premiums and the other possible losses are already lower then the cost 
> of the development and testing.

Indeed.  One of my friends was the lead engineer
for the first automatic teller machine.  One of
the design goals was that it would dispense cash
with the same or better accuracy as a human teller,
not perfection...

>> It's possible to improve the development process of software so it 
>> doesn't suffer from these evils.  Unfortunately, the improvements have to 
>> have support of nearly everyone in the whole organization, and certainly 
>> majority support at every layer.  This means that any manager in the 
>> chain from the developer up to the Big Boss can cut the whole thing off 
>> at the knees by choosing to believe an optimist who promises a shorter 
>> schedule.
>>
>> I've seen big complex projects work, but I've seen it far less often than 
>> I've seen them fail.  And I've seen them fail due to individual failures 
>> at just about any level.
>
> True enough.


Yes, organizational top to bottom agreement that adherence to a  good SW dev 
process is a prerequisite for success.

> Sometimes, however, it takes a hero to make a project work
> but not before he has had the nerve to send away all the
> nuisance ;)

If I understand this point, you're saying the hero is advocating for the 
good SW dev process AND he has the sway or power in the organization to make 
it happen.  Those who advocate but don't have the sway (like me) are walking 
a fine line between "We need it but nobody's listening" and "I tried, I 
failed, I'm done".  I've drifted from the former to the latter in my growing 
but software-primitive group, of which is composed of mostly EEs MEs and 
physicists.  I'm not proud of that either :(

(BTW, great thread, close to my heart)

JJS

On Mar 27, 10:59=A0am, Chris H <ch...@phaedsys.org> wrote:

> In the real world it all comes down to money. Insurance premiums and
> liability.

If this was true, the phrase "I drive a Pinto" wouldn't get a laugh.
The _real_ bottom line is risk. Insurance is one way of managing risk,
but nobody carries a policy that will cover the complete loss of a
business.

Remember the de Havilland Comet? Remember how difficult it was to get
people to board them even once the bugs were fixed?

On Mar 27, 6:42 am, Lanarcam <lanarc...@yahoo.fr> wrote:

> I think this is only part of the problem. A microcontroller
> is a complex design and generally without bugs.

Yeah, right...

Hopefully most of the bugs were found and corrected or at least noted
before the silicon got to you,
but the history of known bugs suggests that they are not that
uncommon.

I remember reading errata that I found particularly cheeky, the way it
was written was that it did not implicate the silicon for the failure
of a certain mode of operation, it implicated the documentation for
suggesting that the particular mode existed!

And unfortunately, it was that mode that made the chip attractive in
the first place.

John Speth wrote:
> 
>> Sometimes, however, it takes a hero to make a project work
>> but not before he has had the nerve to send away all the
>> nuisance ;)
> 
> If I understand this point, you're saying the hero is advocating for the 
> good SW dev process AND he has the sway or power in the organization to make 
> it happen. 

I meant that sometimes you have to tell managers that they are
a bunch of ineffective nuisance, (you just don't say it
exactly like that), and that if they don't let you manage
effectively the project they are in for *the* disaster.

> Those who advocate but don't have the sway (like me) are walking 
> a fine line between "We need it but nobody's listening" and "I tried, I 
> failed, I'm done".  I've drifted from the former to the latter in my growing 
> but software-primitive group, of which is composed of mostly EEs MEs and 
> physicists.  I'm not proud of that either :(
> 

larwe wrote:
> Chris H <ch...@phaedsys.org> wrote:
> 
>> In the real world it all comes down to money. Insurance premiums and
>> liability.
> 
> If this was true, the phrase "I drive a Pinto" wouldn't get a laugh.
> The _real_ bottom line is risk. Insurance is one way of managing risk,
> but nobody carries a policy that will cover the complete loss of a
> business.
> 
> Remember the de Havilland Comet? Remember how difficult it was to get
> people to board them even once the bugs were fixed?

However they are still flying, I believe (or were very recently). 
They just don't do passenger traffic; they became cargo devices. 
Their eventual record was very good.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

Not Really Me wrote:

> My thought is that the first step is to improve the specification
> process. When was the last time you got a software specification that
> was actually complete and didn't require revisions?

I have seen both ends of the specification problem.

At the scant end, a specification that left it to the engineer (me) to
extract by extensive Q&A exactly what was wanted.

At the enormously complete specification end, it was so complete that all
the referenced standards and legislature managed to contradict each
other so much that a working solution was impossible to achieve. This
specification was reduced from a 900 page document to a mere 35 pages of
specification that was entirely adequate following a short Q&A with the
client.

You are right, though, in recognising that starting off with a decent
specification that has had conflicting requirements resolved, is
logically correct and consistent and well structured, will help the
progress of a project. Doing more of the thinking (Systems Engineering)
work up front saves an enormous amount of time in integration, testing
and maintenance.



-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************