Software's evil

Lanarcam wrote:

> An extract from "Embedded systems dictionary" by Jack Ganssle and Michael
> Barr:
> 
> "Unfortunately, as hardware design more and more resembles
> software development, the hardware inherits all of software's evils:
> late delivery, bugs and misinterpreted specs."

[...]

> Is it be possible to improve the development process
> of harware blocks so that they don't suffer from these evils
> and would it be possible to apply these techniques to
> software? Is it a problem of costs only?

Yes, this is mainly a problem of resources. I put it this way: to be 
done perfectly, just about every complex project requires 3 times more 
time and effort then it is allowed to be allocated for that.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Vladimir Vassilevsky wrote:
> 
>> Is it be possible to improve the development process
>> of harware blocks so that they don't suffer from these evils
>> and would it be possible to apply these techniques to
>> software? Is it a problem of costs only?
> 
> Yes, this is mainly a problem of resources. I put it this way: to be 
> done perfectly, just about every complex project requires 3 times more 
> time and effort then it is allowed to be allocated for that.

In other words, how to balance costs and potential
prejudices or simply short term costs and long term
costs.

Lanarcam wrote:


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

LOL

Since the times of i286, all of the microcontrollers are laden with 
bugs. Look into the silicon errata sheets.

Only the simple designs mass produced for many years can be relatively 
bug free.

> If a design
> is complex, you can decompose it into manageable units
> with well specified interfaces.

Every textbook says that.

> This requires time and
> rigour and is not compatible with tight schedules and
> scarce resources.

Consequently, there is no economical demand for the things to be 
perfect; good enough is good enough.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Pertti Kellom=E4ki 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=20
of the development and testing.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Mar 27, 4:19 am, "Lanarcam" <lanarc...@yahoo.fr> wrote:
> An extract from "Embedded systems dictionary" by Jack Ganssle and Michael
> Barr:
>
> "Unfortunately, as hardware design more and more resembles
> software development, the hardware inherits all of software's evils:
> late delivery, bugs and misinterpreted specs."
>
> If that is the case, the problem of software doesn't lie in
> the instrinsic properties of software components but
> in the development process.
>
> Hardware blocks developed as parts of FPGAs
> have the same functional characteristics as discrete equivalent
> hardware parts. If they suffer from software evil's, this is
> only due to the development process.
>
> Is it be possible to improve the development process
> of harware blocks so that they don't suffer from these evils
> and would it be possible to apply these techniques to
> software? Is it a problem of costs only?

There are multiple "evils" in development:
schedules
just note how frequently cell phone models come out nowadays

requirements
as systems can do more, customers expect the next generation to do
even more

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

problem size
Or tyranny of the numbers: processors may double in speed but problem
size may be growing faster , e.g graphics processing where doubling
the resolution quadruples the data size.  So any problem with a larger
than O(n) solution algorithm suffers.

These don't even touch the development issues:
just communicating between developers changes as project scale up:
single developer -> small team -> large team -> multiple large teams
More complex problems with some development tools essentially the same
as 30years ago

So it is not the development process alone. Managers need to know that
all these factors (and more) influence the process.

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.
   Ed

Ed Prochak wrote :
> 
> There are multiple "evils" in development:
> schedules
> just note how frequently cell phone models come out nowadays
> 
> requirements
> as systems can do more, customers expect the next generation to do
> even more
> 
> problem complexity
> Some problems are now being automated which may be unsolvable.
> 
> problem size
> Or tyranny of the numbers: processors may double in speed but problem
> size may be growing faster , e.g graphics processing where doubling
> the resolution quadruples the data size.  So any problem with a larger
> than O(n) solution algorithm suffers.
> 
> These don't even touch the development issues:
> just communicating between developers changes as project scale up:
> single developer -> small team -> large team -> multiple large teams
> More complex problems with some development tools essentially the same
> as 30years ago
> 
> So it is not the development process alone. Managers need to know that
> all these factors (and more) influence the process.
> 
> 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.

In message <K4OGj.22730$0o7.17567@newssvr13.news.prodigy.net>, Vladimir 
Vassilevsky <antispam_bogus@hotmail.com> writes
>
>
>Pertti Kellom&#4294967295;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.
>
>Vladimir Vassilevsky
>DSP and Mixed Signal Design Consultant
>http://www.abvolt.com
>


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


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Thu, 27 Mar 2008 10:19:23 +0100, Lanarcam wrote:

> An extract from "Embedded systems dictionary" by Jack Ganssle and
> Michael Barr:
> 
> "Unfortunately, as hardware design more and more resembles software
> development, the hardware inherits all of software's evils: late
> delivery, bugs and misinterpreted specs."
> 
> If that is the case, the problem of software doesn't lie in the
> instrinsic properties of software components but in the development
> process.
> 
> Hardware blocks developed as parts of FPGAs have the same functional
> characteristics as discrete equivalent hardware parts. If they suffer
> from software evil's, this is only due to the development process.
> 
> Is it be possible to improve the development process of harware blocks
> so that they don't suffer from these evils and would it be possible to
> apply these techniques to software? Is it a problem of costs only?

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.

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

"Lanarcam" <lanarcam1@yahoo.fr> wrote in message 
news:47eb669c$0$12012$426a74cc@news.free.fr...
> An extract from "Embedded systems dictionary" by Jack Ganssle and Michael
> Barr:
>
> "Unfortunately, as hardware design more and more resembles
> software development, the hardware inherits all of software's evils:
> late delivery, bugs and misinterpreted specs."
>
> If that is the case, the problem of software doesn't lie in
> the instrinsic properties of software components but
> in the development process.
>
> Hardware blocks developed as parts of FPGAs
> have the same functional characteristics as discrete equivalent
> hardware parts. If they suffer from software evil's, this is
> only due to the development process.
>
> Is it be possible to improve the development process
> of harware blocks so that they don't suffer from these evils
> and would it be possible to apply these techniques to
> software? Is it a problem of costs only?
>
>
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.

Scott

On 2008-03-27, Chris H <chris@phaedsys.org> wrote:
>
> In the real world it all comes down to money. Insurance premiums and 
> liability.

True, but it pays not to be too cynical about the calculation.
Obviously there are the difficulties of valuing damage to reputations
and other 'soft' issues.  

IANAL, but my understanding is that if it can be shown in court
that you were aware of a substantial risk, but opted not to moderate
that risk on the basis that it would simply be cheaper to settle
any cases that arose as a consequence, there is a real possibilty
of an exemplary damages award.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org