Version Control in Embedded Systems

[Paul E. Bennett]

In article <bev0hb$3ll$1$830fa79d@news.demon.co.uk>
steve@DELETEMEfivetrees.com "steve at fivetrees" writes:
"John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote in message news:cun5hvkb9dcihbgoadi0nap63e2j31sqb3@4ax.com... The Microsoft mantra, that all software has bugs, is an excellent mind-set for making bugs. If one assumes that bugs are undesirable and in fact a disgrace, coding can be designed to minimize errors first pass. I do that, because I like to lie in bed and nibble chocolate and review my code, and I hate to sweat over emulators and stuff in the lab. I agree 150%. However, as I think we've determined before, we appear to be in a minority. Never mind - the hack-and-debug majority make us look good ;).

Trouble is those that just sit and hack at code tend to introduce nearly
as many new bugs as they are eliminating old ones. Never mind that once
you have written and released buggy code you will probably never rid
yourself of it.
Although I do get tired sometimes of explaining to skeptical customers why and how bug-free code is a realistic objective, regardless of the degree of complexity. The "complex software must be buggy" is an all-pervading myth, and IMHO a rather sad admission of failure by our profession.

A well thought out system design will have eliminated 99% of all the
bugs in specification and design before you have even laid one line of
production code. It should also, despite complexity of the problem, be
simple enough to understand fully. This will assist in elimination of
the final 1% of bugs during the integration testing. Factory testing
and Commissioning testing can then be "REALLY" proving to the customer
that you have completed a system to his requirements.
More important, if you depend on testing to find bugs, you'll never find all of them. Very, very true. And poorly understood. Debugging is an asymptotic process - it may approach but never reaches zero bugs, as you say. Usually the point at which one declares debugging complete is a function of pressure and cost. Far from ideal. Far better to design from the outset for no bugs - as one does with hardware, esp. ASICs. Why do software people have such trouble with this concept?

I for one do not consider hiring "software only types". I always go
for those who have an aptitude in hardware topics as well (whether
electrical, mechanical or electronic). Note that on team projects
you have to have some balance in the team and the team must be able
to understand each others work in order to peer review it.

--
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[Robert Cowham]

peb@amleth.demon.co.uk ("Paul E. Bennett") wrote in
news:1058302551snz@amleth.demon.co.uk:
A well thought out system design will have eliminated 99% of all the bugs in specification and design before you have even laid one line of production code. It should also, despite complexity of the problem, be simple enough to understand fully. This will assist in elimination of the final 1% of bugs during the integration testing. Factory testing and Commissioning testing can then be "REALLY" proving to the customer that you have completed a system to his requirements.

The extreme programming guys would take issue with this in that until
you start delivering releases to the customers they tend to be very
unclear as to what the sepcifications should be. Their approach is to
have a development process that can cope with change, as that is a fact
of life.
More important, if you depend on testing to find bugs, you'll never find all of them. Very, very true. And poorly understood. Debugging is an asymptotic process - it may approach but never reaches zero bugs, as you say. Usually the point at which one declares debugging complete is a function of pressure and cost. Far from ideal. Far better to design from the outset for no bugs - as one does with hardware, esp. ASICs. Why do software people have such trouble with this concept?

It can all depend on what you are doing with software. I have a worked
on a number of systems where I have had to rely on third party
components (ranging from middleware to Microsoft Office), and indeed the
operating system and compilers. I have come across bugs in the
compilers, bugs in Office, etc, etc. These are nasty and my ability to
persuade Microsoft to fix things somewhat limited - I have to find the
bug, find what caused it, and then find workarounds...

Software these days tends to depend on a heap of other stuff around it.

--
Robert Cowham

[Jonathan Kirwan]

On Wed, 16 Jul 2003 09:54:52 -0700, John Larkin
<jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
On 16 Jul 2003 08:27:46 GMT, Robert Cowham <rc@vaccaperna.co.uk>wrote:peb@amleth.demon.co.uk ("Paul E. Bennett") wrote innews:1058302551snz@amleth.demon.co.uk: A well thought out system design will have eliminated 99% of all the bugs in specification and design before you have even laid one line of production code. It should also, despite complexity of the problem, be simple enough to understand fully. This will assist in elimination of the final 1% of bugs during the integration testing. Factory testing and Commissioning testing can then be "REALLY" proving to the customer that you have completed a system to his requirements.The extreme programming guys would take issue with this in that untilyou start delivering releases to the customers they tend to be veryunclear as to what the sepcifications should be. Their approach is tohave a development process that can cope with change, as that is a factof life.One of my best customers, a big scientific instrumentation company, isnotorious: they don't really think through what they want until wedeliver the first couple of units, and then all sorts of people wanderin and poke it and change everything. I delivered one really nicecontroller, fully in agreement with the tekkies on specs, andpresented the first unit at a meeting. A marketing biggie justhappened to enter the conference room, for an unrelated reason, andlooked at the box. "What's this switch for?" she asked. I said "Itselects which heater type the system has.""No," she said, "that's unacceptable. The controller must sense theheater type automatically." Then she left. Of course, nobody offeredus any more engineering money. I'm now up to rev J of the code on thisone (starting at A); zero bugs so far, but lots of changes.John

An excellent point, highlighted many, many times in my own
experience, as well. Few people really know what they want
before they get to touch and feel what they don't want.

There are a few wonderful customers who have been down the road
a few times and can provide both an excellent definition to
start and an excellent background of experience to draw from.
Some of those are even able and willing to pay for the job at
hand, too. If anyone has a magic formula for causing that
select set of customers to track you down and hire you, I'd love
to hear it. I know one when I see one, but they are as rare as
hen's teeth and I can't base a business on just that group.

But give someone something they don't want and they'll often
find out some one fact quickly and let you know. Fix that and
come back and they'll find yet another one that "slipped
through" the last time.

Knowing this up front and still managing to get the right thing
done in the end, on an acceptable schedule and cost, is some of
what keeps the work interesting.

Jon

[Paul E. Bennett]

In article <a30bhvkho80vv208llgmq1pj56csmigt1f@4ax.com>
jjlarkin@highSNIPlandTHIStechPLEASEnology.com "John Larkin" writes:
One of my best customers, a big scientific instrumentation company, is notorious: they don't really think through what they want until we deliver the first couple of units, and then all sorts of people wander in and poke it and change everything. I delivered one really nice controller, fully in agreement with the tekkies on specs, and presented the first unit at a meeting. A marketing biggie just happened to enter the conference room, for an unrelated reason, and looked at the box. "What's this switch for?" she asked. I said "It selects which heater type the system has." "No," she said, "that's unacceptable. The controller must sense the heater type automatically." Then she left. Of course, nobody offered us any more engineering money. I'm now up to rev J of the code on this one (starting at A); zero bugs so far, but lots of changes.

A prime example of the need to "fix the customer before fixing the
system". The above siuation is wholly avoidable with the right
approach. Remember System Design beigins by getting the spec right
for yourself and the customer.

I have related in this and other groups my use of prototypes (on PC
and in cardboard cut-outs) as aids in "spec-bashing sessions". It is
quite extraordinary when you get a roomful of execs and operators
pressing the imaginary buttons and making comments about what they
expect to see happen as a result. The sessions need to be highly
structured and a good moderator is absolutely vital. The result is
usually a pretty good preliminary requirements specification that
one can get ones teeth into and not bite much fresh air. Usually
we do it all again a few weeks later but this time reviewing the
spec very thoroughly and really stretching it hard. The second
meeting everyone has to prepare for properly.

As you develop the system you are going to continue to find the
odd problem in the requirements specification. It is vital to raise
a problem report on this with the client and ensure he responds to
it promptly. Be on your guard to ensure that feature drift does not
creep into the requirements without your noticing it (I know some
clients try to do this). If your teams are on the ball you should be
able to spot this specification drift easily enough. When you do quote
the cost of adding the feature to the client and give him the option
of changing the requiremenst and paying for it or to limit his needs
to the original.

However good you are at getting the spec right first time there are
many instances where a change must be implemented in a myriad of
documents. You need to control the changes in a very orderly manner.
Such changes may come from anywhere; testing; users of previous
systems; the client maintenance etc. Encourage the filling in of
problem reports (hint: only one problem per report as this eases
closure later). Have a sound process for dealing with problem reports
and ensure they are always under review (even the simply answered ones).
Always record all problem reports submitted and track them until each
problem is resolved (by a new version issue).

My simple system development process is partly described in the
flowchart on the HIDECS page of my website and in papers I have
presented to a couple of conferences. It is in fact the central
change management core of the process. There is another diagram
that deals with the range of documents required at each stage of
development. You are invited to look and download the papers
if you want to find out more.

--
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[Ken Lee]

On Wed, 16 Jul 2003 23:09:04 +0000 (UTC), peb@amleth.demon.co.uk
("Paul E. Bennett") wrote:
In article <a30bhvkho80vv208llgmq1pj56csmigt1f@4ax.com> jjlarkin@highSNIPlandTHIStechPLEASEnology.com "John Larkin" writes: One of my best customers, a big scientific instrumentation company, is notorious: they don't really think through what they want until we deliver the first couple of units, and then all sorts of people wander in and poke it and change everything. I delivered one really nice controller, fully in agreement with the tekkies on specs, and presented the first unit at a meeting. A marketing biggie just happened to enter the conference room, for an unrelated reason, and looked at the box. "What's this switch for?" she asked. I said "It selects which heater type the system has." "No," she said, "that's unacceptable. The controller must sense the heater type automatically." Then she left. Of course, nobody offered us any more engineering money. I'm now up to rev J of the code on this one (starting at A); zero bugs so far, but lots of changes.
A prime example of the need to "fix the customer before fixing thesystem". The above siuation is wholly avoidable with the rightapproach. Remember System Design beigins by getting the spec rightfor yourself and the customer.

All good stuff. Where I work we use the term "train" rather than
"fix". "Fix" has the implication that you want to kill someone ---
which on the other hand with System Specs, may be the case ;-)
I have related in this and other groups my use of prototypes (on PCand in cardboard cut-outs) as aids in "spec-bashing sessions". It isquite extraordinary when you get a roomful of execs and operatorspressing the imaginary buttons and making comments about what theyexpect to see happen as a result. The sessions need to be highlystructured and a good moderator is absolutely vital. The result isusually a pretty good preliminary requirements specification thatone can get ones teeth into and not bite much fresh air. Usuallywe do it all again a few weeks later but this time reviewing thespec very thoroughly and really stretching it hard. The secondmeeting everyone has to prepare for properly.

What's also useful from these sessions, are the use cases & scenarios
as they could be used in System Validation and provide a guide to
Software Verification.
As you develop the system you are going to continue to find theodd problem in the requirements specification. It is vital to raisea problem report on this with the client and ensure he responds toit promptly. Be on your guard to ensure that feature drift does notcreep into the requirements without your noticing it (I know someclients try to do this). If your teams are on the ball you should beable to spot this specification drift easily enough. When you do quotethe cost of adding the feature to the client and give him the optionof changing the requiremenst and paying for it or to limit his needsto the original.

Basically with new features (particularly when introduced in later
design) you have to play hardball with the customer and state changes
in terms of dollars ($$). Recording changes & problems provide good
metrics that can give one insight as to the cost of change, for future
projects.
However good you are at getting the spec right first time there aremany instances where a change must be implemented in a myriad ofdocuments.

It's often the case with projects that too much documentation is
produced or not the right documents, particularly if the product is to
be submitted to some regulatory body. Why too much? Typically for
products that go to regulatory bodies, engineers will tend to produce
a lot of "just-in-case" documents, may be because they haven't
received guidance as to what documents to produce. If the product is
to go for CE Mark or FDA (510K) submission, then the engineer should
be made aware of what documents are mandatory at the onset.
You need to control the changes in a very orderly manner.Such changes may come from anywhere; testing; users of previoussystems; the client maintenance etc. Encourage the filling in ofproblem reports (hint: only one problem per report as this easesclosure later). Have a sound process for dealing with problem reportsand ensure they are always under review (even the simply answered ones).Always record all problem reports submitted and track them until eachproblem is resolved (by a new version issue).

I would recommend an online tool to track problems & issues and make
it available to all team members (not just engineers). We use PVCS
Tracker and the use of it is outlined in our work instruction so that
everyone knows how it should be used.
My simple system development process is partly described in theflowchart on the HIDECS page of my website and in papers I havepresented to a couple of conferences. It is in fact the centralchange management core of the process. There is another diagramthat deals with the range of documents required at each stage ofdevelopment. You are invited to look and download the papersif you want to find out more.--********************************************************************Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..********************************************************************


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

[John Larkin]

On Wed, 16 Jul 2003 23:09:04 +0000 (UTC), peb@amleth.demon.co.uk
("Paul E. Bennett") wrote:
In article <a30bhvkho80vv208llgmq1pj56csmigt1f@4ax.com> jjlarkin@highSNIPlandTHIStechPLEASEnology.com "John Larkin" writes: One of my best customers, a big scientific instrumentation company, is notorious: they don't really think through what they want until we deliver the first couple of units, and then all sorts of people wander in and poke it and change everything. I delivered one really nice controller, fully in agreement with the tekkies on specs, and presented the first unit at a meeting. A marketing biggie just happened to enter the conference room, for an unrelated reason, and looked at the box. "What's this switch for?" she asked. I said "It selects which heater type the system has." "No," she said, "that's unacceptable. The controller must sense the heater type automatically." Then she left. Of course, nobody offered us any more engineering money. I'm now up to rev J of the code on this one (starting at A); zero bugs so far, but lots of changes.A prime example of the need to "fix the customer before fixing thesystem". The above siuation is wholly avoidable with the rightapproach.

Right: locking the conference room door.

John

[Koushik Banerjee]

"Yaakov" <H_shemisone@yahoo.com> wrote in message
news:2a2c56bb.0307160658.38e0ea69@posting.google.com...
: Robert Cowham <rc@vaccaperna.co.uk> wrote in message
news:<Xns93BA603507C0Ercvaccapernacouk@130.133.1.4>...
: > peb@amleth.demon.co.uk ("Paul E. Bennett") wrote in
: > news:1058302551snz@amleth.demon.co.uk:
:
:
: Yes, One should design for bug free hardware as well as software. I
: tell my programmers that I want them to make life hard for our test
: engineer. Let him spend hours until he scrounges up a bug instead of
: just a couple of minutes.
:

If the tester happens to find a bug just after he starts testing, I think
either the specs were not cleanly defined(or rather the test cases dont
match the spec) Or the programmer is really a BAD one. In such cases it is
better desirable to do away with that programmer and get someone else good
to re-write the code (NOT revamp or fix the code), because it is easier
writing something altogether new yourself, than to fix some shit of someone
else. And anyways if the developer left behind some obvious bugs, his coding
style would also be very bad and less readable to others, less maintainable
and blah-blahs..

: Yes, we should use the most cost effective trade-offs available. By
: some that will be rigorous code inspection, by others it will be a
: solid test-harness. Others will find a combination of the two.
:
: There is one issue that I didn't see addressed.
:
: If a bug is found don't deny it. Sounds trite but I've seen it happen.
: The engineer that I'm happiest with assumes the truth of a bug report,
: tries to reconstruct it in his development environment, and then asks
: the question "Is this isolated or is this found somewhere else in my
: work (read Hardware and/or Software)?" IMHO, quick patches are
: worthless, even if you have a zillion installations. You'll just have
: to make another one. If your lucky the tester will catch your new bug
: before it gets out the door.
:
: This question could and should also be applied to marketing decisions
: (read GUI design and feature sets)
:
: Another point that ties in to Version Control (that's how we started
: the thread :-} ).
: There must be communication between the Development and Test Groups.
: At the very least the Test Group (and actually the developer himself)
: should ask "Did you touch shared modules?" The answer to this question
: will define how extensive the regression test for introducing bugs to
: other features will be.
:
: Yaakov

[Koushik Banerjee]

"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message
news:ci7bhv8o4tcmvlaqs59gf513iag4qv4l7p@4ax.com...
: An excellent point, highlighted many, many times in my own
: experience, as well. Few people really know what they want
: before they get to touch and feel what they don't want.
:
: There are a few wonderful customers who have been down the road
: a few times and can provide both an excellent definition to
: start and an excellent background of experience to draw from.
: Some of those are even able and willing to pay for the job at
: hand, too. If anyone has a magic formula for causing that
: select set of customers to track you down and hire you, I'd love
: to hear it. I know one when I see one, but they are as rare as
: hen's teeth and I can't base a business on just that group.
:
: But give someone something they don't want and they'll often
: find out some one fact quickly and let you know. Fix that and
: come back and they'll find yet another one that "slipped
: through" the last time.
:
: Knowing this up front and still managing to get the right thing
: done in the end, on an acceptable schedule and cost, is some of
: what keeps the work interesting.
:
: Jon
:

It is right to get a customer "who knows what he wants" in software
industry, but it is not the case for hardware. It is very expensive, and the
customers _usually_ knows "what they want" in the hardware industry. Most
companies into hardware do their own design and manufacturing, and others
usually are already big and long-time players to know what would work with
their design. The difference with a software and hardware can be tested on
cost terms as:
Software (say a particular version) once written can be used/sold "n" number
of times with out any additional costs(barring packaging/shipping and other
such costs),
BUT
Hardware except the designing , the actual hardware needs to be produced "n"
number of times if you plan to sell it so many times (along with other costs
of packagin/shipping ...)

So fixing a software bug when released into the market/into production even
for embedded systems is easy , but for the hardware it is impossible since
you need to replace the whole stuff or maybe if possible write something new
in software to achieve the same functionailty , though not quite possible
always, and any function thru hardware is performance efficient than done in
software.

Koushik.

[Jonathan Kirwan]

On Wed, 30 Jul 2003 22:08:29 +0530, "Koushik Banerjee"
<koushik.banerjee@eds.com> wrote:
"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in messagenews:ci7bhv8o4tcmvlaqs59gf513iag4qv4l7p@4ax.com...: An excellent point, highlighted many, many times in my own: experience, as well. Few people really know what they want: before they get to touch and feel what they don't want.:: There are a few wonderful customers who have been down the road: a few times and can provide both an excellent definition to: start and an excellent background of experience to draw from.: Some of those are even able and willing to pay for the job at: hand, too. If anyone has a magic formula for causing that: select set of customers to track you down and hire you, I'd love: to hear it. I know one when I see one, but they are as rare as: hen's teeth and I can't base a business on just that group.:: But give someone something they don't want and they'll often: find out some one fact quickly and let you know. Fix that and: come back and they'll find yet another one that "slipped: through" the last time.:: Knowing this up front and still managing to get the right thing: done in the end, on an acceptable schedule and cost, is some of: what keeps the work interesting.:: Jon:It is right to get a customer "who knows what he wants" in softwareindustry,

It's rare to find them, though. So one cannot base their
software business on such customers unless one has a magic
formula here or a narrow enough market where this is often the
case. I think some of the same issues hound hardware, as well.
(In fact, I know some do, since I work in designing and building
scientific and commercial instrumentation and I see the same
issues come up in finding the _right_ system specifications.)
but it is not the case for hardware. It is very expensive, and thecustomers _usually_ knows "what they want" in the hardware industry.

Ah, you mean the opposite of what I thought you mean. In other
words, you mean that in hardware you *must* have a customer who
knows what they want?
Mostcompanies into hardware do their own design and manufacturing, and othersusually are already big and long-time players to know what would work withtheir design.

Plus, there is nature working for you. Nature/physics pretty
much is the same where ever you go in the world and problems
have a certain set of well known boundaries for their solutions.
Software has to deal with physics, too, of course (the embedded
work I do, for example), but facets can also often be more about
addressing human likes and dislikes, which are vastly more
fickle than nature. But then, so does hardware have to deal
with this (ease of use.)
The difference with a software and hardware can be tested oncost terms as:Software (say a particular version) once written can be used/sold "n" numberof times with out any additional costs(barring packaging/shipping and othersuch costs),BUTHardware except the designing , the actual hardware needs to be produced "n"number of times if you plan to sell it so many times (along with other costsof packagin/shipping ...)So fixing a software bug when released into the market/into production evenfor embedded systems is easy , but for the hardware it is impossible sinceyou need to replace the whole stuff or maybe if possible write something newin software to achieve the same functionailty , though not quite possiblealways, and any function thru hardware is performance efficient than done insoftware.

Indeed. Hardware is tangible.

I'm not sure exactly where you were going. I tend to understand
and agree with you about the details you've mentioned. So
perhaps all you wanted to do is highlight another aspect I'd
failed to address.

The only thing I take issue with, if at all, is if you are
saying that customers of hardware generally know what they want
and that you *can* rely on having such customers when you do
hardware design. If that is what you think or are arguing, then
I have to disagree. Hardware customers are not always (or
often, perhaps) all that knowledgeable about what they want.
[Some are trained over time to _want_ only what can actually be
made well!]

But the street of bankruptcy is littered with companies failing,
in part, because of building what their perceived customers
_told_ them they wanted. Failing to ask questions about what
they are willing to pay for or failing to understand who the
real customer (the one willing to actually pay) is and getting
their information from the wrong base... and so on.

It's wonderful, as always, when one's customers are all well
informed about their requirements, know what they need/want,
know what they are willing to pay and for what, and have the
where-with-all to actually pay a good price.

Still, I think many of the same problems exist in both domains,
as far as customers are concerned. There are differences, of
course. And you've painted some of those well.

Jon

[Pete Fenelon]

In comp.arch.embedded Robert Cowham <rc@vaccaperna.co.uk> wrote: I think it was "Peopleware" that first described those developers who are a net drain on a project, because the code they produce is bug ridden and takes more effort to correct than it would have for someone else to do in the first place. (Some developers are an order of magnitude more productive than others).

I've only ever worked with one such developer - unfortunately it wasn't
just his code that was problematic, it was his entire attitude to work.
If he got challenging work he regarded it as being an attempt to stretch
him past breaking point, if he got routine work he described it as an
attempt to 'de-skill' him...

pete
--
pete@fenelon.com "there's no room for enigmas in built-up areas" HMHB

[Koushik Banerjee]

"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message
news:v01givsqqj8vd77e4jmhii4nj57s91igc2@4ax.com...
:: >It is right to get a customer "who knows what he wants" in software
: >industry,
:
: It's rare to find them, though. So one cannot base their
: software business on such customers unless one has a magic
: formula here or a narrow enough market where this is often the
: case. I think some of the same issues hound hardware, as well.
: (In fact, I know some do, since I work in designing and building
: scientific and commercial instrumentation and I see the same
: issues come up in finding the _right_ system specifications.)
:
: >but it is not the case for hardware. It is very expensive, and the
: >customers _usually_ knows "what they want" in the hardware industry.
:
: Ah, you mean the opposite of what I thought you mean. In other
: words, you mean that in hardware you *must* have a customer who
: knows what they want?
:
: >Most
: >companies into hardware do their own design and manufacturing, and others
: >usually are already big and long-time players to know what would work
with
: >their design.
:
: Plus, there is nature working for you. Nature/physics pretty
: much is the same where ever you go in the world and problems
: have a certain set of well known boundaries for their solutions.
: Software has to deal with physics, too, of course (the embedded
: work I do, for example), but facets can also often be more about
: addressing human likes and dislikes, which are vastly more
: fickle than nature. But then, so does hardware have to deal
: with this (ease of use.)
:
: >The difference with a software and hardware can be tested on
: >cost terms as:
: >Software (say a particular version) once written can be used/sold "n"
number
: >of times with out any additional costs(barring packaging/shipping and
other
: >such costs),
: >BUT
: >Hardware except the designing , the actual hardware needs to be produced
"n"
: >number of times if you plan to sell it so many times (along with other
costs
: >of packagin/shipping ...)
: >
: >So fixing a software bug when released into the market/into production
even
: >for embedded systems is easy , but for the hardware it is impossible
since
: >you need to replace the whole stuff or maybe if possible write something
new
: >in software to achieve the same functionailty , though not quite possible
: >always, and any function thru hardware is performance efficient than done
in
: >software.
:
: Indeed. Hardware is tangible.
:
: I'm not sure exactly where you were going. I tend to understand
: and agree with you about the details you've mentioned. So
: perhaps all you wanted to do is highlight another aspect I'd
: failed to address.
:
: The only thing I take issue with, if at all, is if you are
: saying that customers of hardware generally know what they want
: and that you *can* rely on having such customers when you do
: hardware design. If that is what you think or are arguing, then
: I have to disagree. Hardware customers are not always (or
: often, perhaps) all that knowledgeable about what they want.
: [Some are trained over time to _want_ only what can actually be
: made well!]
:
: But the street of bankruptcy is littered with companies failing,
: in part, because of building what their perceived customers
: _told_ them they wanted. Failing to ask questions about what
: they are willing to pay for or failing to understand who the
: real customer (the one willing to actually pay) is and getting
: their information from the wrong base... and so on.
:
: It's wonderful, as always, when one's customers are all well
: informed about their requirements, know what they need/want,
: know what they are willing to pay and for what, and have the
: where-with-all to actually pay a good price.
:
: Still, I think many of the same problems exist in both domains,
: as far as customers are concerned. There are differences, of
: course. And you've painted some of those well.
:
: Jon
:
You are right in saying that the problem exists in both domain, but I feel
the problem exists more in software domain considering the knowledge base of
the software companies, customers and the engineers (I am not saying the h/w
engineers are better than s/w ones, but the number of new things done in h/w
is less than in s/w)and this contributes to the artifacts that are needed to
get a job done.
My belief is that a company investing in h/w is dollar ($$) rich first to
get all the right setup (say you need more than few computers and a garage
to start with, you need a dust-free environment, some special dress, h/w and
other stuff to get started), and after investing in all these, if they are
not sure about their customers and their requirements, it is pretty much a
ruin for the company. That is the company is likely to close down any day
because of lack of business. But in sofware, you can rent a few machines,
set up few tables in a garage, and get some hackers to start with. Once you
feel that you are getting good business , you can expand, or simply stop
paying the rent of the computers and garage, and you would be thrown out
with very little to lose. The investment pattern is very different.
But yes, hardware does get effected by software these days, say when the
e-crash took place in 2000, all the switch manufacturing companies took a
hit, since their customer was maily companies into e-commerce, and those
either cancelled or postponed their orders. Lucent, Cisco took hits that way
then.

And if you are talking of "usuability" case in hardware, I think the core
functionality is what drives a product, other than the look & feel factor.
And the core costs more than the UI factor, like how the front-panel looks
like in a DVD player or the box looks like can be different in different
regions, but most people would be more interested in what it can do (the
core part), which is the expensive part.

Well otherwise both of them are same in most ways. You are right about that.

Koushik.

[John Larkin]

On Thu, 31 Jul 2003 19:25:00 +0530, "Koushik Banerjee"
<koushik.banerjee@eds.com> wrote::You are right in saying that the problem exists in both domain, but I feelthe problem exists more in software domain considering the knowledge base ofthe software companies, customers and the engineers (I am not saying the h/wengineers are better than s/w ones, but the number of new things done in h/wis less than in s/w)and this contributes to the artifacts that are needed toget a job done.

Hardware design tends to have fewer (lots fewer!) bugs, but there may
be another explanation: hardware is generally parallel and
synchronous, while software is sequential within separate concurrent
threads, and essentially asynchronous. So hardware logic designers
have much better visibility and control over system states.

John

[steve at fivetrees]

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message news:qkciivcnhi5h8qhp0rjfbkgq1jtg2ig933@4ax.com... Hardware design tends to have fewer (lots fewer!) bugs, but there may be another explanation: hardware is generally parallel and synchronous, while software is sequential within separate concurrent threads, and essentially asynchronous. So hardware logic designers have much better visibility and control over system states.

.... Which is exactly why I design my code to be synchronous. And why I have
so few software problems.

I consider that designing hardware (esp. ASICs) taught me the most about
writing good software ;).

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com

[John Larkin]

On Thu, 31 Jul 2003 16:54:50 +0100, "steve at fivetrees"
<steve@DELETEMEfivetrees.com> wrote:
"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote inmessage news:qkciivcnhi5h8qhp0rjfbkgq1jtg2ig933@4ax.com... Hardware design tends to have fewer (lots fewer!) bugs, but there may be another explanation: hardware is generally parallel and synchronous, while software is sequential within separate concurrent threads, and essentially asynchronous. So hardware logic designers have much better visibility and control over system states.... Which is exactly why I design my code to be synchronous. And why I haveso few software problems.I consider that designing hardware (esp. ASICs) taught me the most aboutwriting good software ;).Stevehttp://www.sfdesign.co.ukhttp://www.fivetrees.com

Me too. I design embedded software the same way as I design logic: run
nice clean little state machines at a regular rate, run each to
completion every shot, and never assign resources dynamically. Fully
decode states. "Inter-task" communications is via variables shared
between state machines. No queues. No abstraction. No glamour. No
bugs.

I've written a few RTOSs, but I find lately that I really don't need
them. Luckily, I'm an engineer most of the time, so I view programming
as a mildly tedious task to be finished, not as a lifelong career. So
I just want to get it over the quickest, most reliable way, even if
that involves simplistic grunt work that wouldn't look good on a
resume.

John

[Gene S. Berkowitz]

In article <bgb742$n6net$1@ID-188659.news.uni-berlin.de>,
koushik.banerjee@eds.com says...
And if you are talking of "usuability" case in hardware, I think the core functionality is what drives a product, other than the look & feel factor. And the core costs more than the UI factor, like how the front-panel looks like in a DVD player or the box looks like can be different in different regions, but most people would be more interested in what it can do (the core part), which is the expensive part.

I think this is completely wrong, as regards consumer products.
Color displays sell better than monochrome.
Customers want the color of the box to match their other
components, which is why audio/video equipment is either
all silver or all black.

Selling consumer electronics is all about emotion, which is
why advertisements are written and illustrated in particular
ways.

MOST consumers don't know that there might be the identical
decoder in two DVD players, one selling for $100 and one for
$200. They will pay more for specific brands, particularly
if they owned that brand before, or because someone they know
has it. Other than that, price usually drives the decision.

And frankly, a good display, keypad, and case can cost several
times what the core electronics does. Chip vendors are in a
continuous race to the bottom, but that doesn't change the
price of metal vs. plastic for the box.

--Gene

[Eric Roesinger]

"Koushik Banerjee" <koushik.banerjee@eds.com> wrote in message
news:bg8sac$lreg0$1@ID-188659.news.uni-berlin.de... <cut> So fixing a software bug when released into the market/into production even for embedded systems is easy <cut>

C|N>K!

From what planet did you import this notion?

I take it you've never written firmware for mask-ROM, microcontrollers,
which are soldered directly onto the product PCB, to control cost? Or
code synthesized into a compacted ROM, within an ASIC?

Remind me not to hire you, for any projects with a half-million-dollar
NRE or initial parts purchase. In fact, I think I'll put you on the as-
sembly line, remanufacturing a few tens of thousands of product PCB's,
to replace MCU's for a code change. Be careful not to peel any traces!

Once out of prototyping, the cost of changing embedded software is oft-
en every bit as high as changing hardware--and sometimes worse. (After
all, changing the odd SMT component, or adding a little flat-wiring is
a bargain, compared to replacing an MCU).

--
egr

[Koushik Banerjee]

"Pete Fenelon" <pete@fenelon.com> wrote in message
news:vihn463qmdh16e@corp.supernews.com...
: In comp.arch.embedded Robert Cowham <rc@vaccaperna.co.uk> wrote:
: > I think it was "Peopleware" that first described those developers who
are a
: > net drain on a project, because the code they produce is bug ridden and
: > takes more effort to correct than it would have for someone else to do
in
: > the first place. (Some developers are an order of magnitude more
productive
: > than others).
:
: I've only ever worked with one such developer - unfortunately it wasn't
: just his code that was problematic, it was his entire attitude to work.
: If he got challenging work he regarded it as being an attempt to stretch
: him past breaking point, if he got routine work he described it as an
: attempt to 'de-skill' him...
:
: pete
: --
: pete@fenelon.com "there's no room for enigmas in built-up areas" HMHB
:
I guess then he was not looking for working altogether. People who have
excuses for every action of others (negatively) are better to be left off
to themselves. Though I have worked with quite a few of them, one in
particular was pretty annoying more because of his attitude towards
programming/learning and taking suggestions from others. His aptitude
towards computers was pretty low, which cannot be taught. He always
felt low on himself if others tried to correct him though he was just out
of college with a different background. But what I learnt/understood was
it was always better to leave such souls to themselves, they and you are
better off that way.

Koushik

[Koushik Banerjee]

"Eric Roesinger" <eric-welcomes-you-to-limbo@aerie-pr.com> wrote in message
news:3f2a92fb_4@newsfeed...
: "Koushik Banerjee" <koushik.banerjee@eds.com> wrote in message
: news:bg8sac$lreg0$1@ID-188659.news.uni-berlin.de...
: >
: > <cut>
: >
: > So fixing a software bug when released into the market/into production
: > even for embedded systems is easy <cut>
:
: C|N>K!
:
: From what planet did you import this notion?
:
: I take it you've never written firmware for mask-ROM, microcontrollers,
: which are soldered directly onto the product PCB, to control cost? Or
: code synthesized into a compacted ROM, within an ASIC?
:
: Remind me not to hire you, for any projects with a half-million-dollar
: NRE or initial parts purchase. In fact, I think I'll put you on the as-
: sembly line, remanufacturing a few tens of thousands of product PCB's,
: to replace MCU's for a code change. Be careful not to peel any traces!
:
: Once out of prototyping, the cost of changing embedded software is oft-
: en every bit as high as changing hardware--and sometimes worse. (After
: all, changing the odd SMT component, or adding a little flat-wiring is
: a bargain, compared to replacing an MCU).
:
: --
: egr
:
:
My statement was a relative one(though I had not mentioned that, but
can be judged from the statement which follows). So what I meant
that was (read relatively) easier to fix a bug in the software for
embedded system than it is to do it with hardware.
You are right that I have not written any firmware myself. My main
job is configuration management, but I have written code also. I have
worked for the european leader in CE, and that is how my idea on
embedded system comes from. It might be possible that they have better
process and technology working for them to get this done easily(they are
in the market for more than 100yrs). At least I am aware that if they
needed to fix a application bug in the DVD player, all that was
needed was to create a CD with the flash, which would then be
distributed to the dealers who would then place it in the tray of the
DVD player, which would self-program itself, (this process took less
than 5minutes). If that sound difficult, I know of no easier way even
in software industry itself. A high range DELL server takes more than
5minutes to boot with NT/2K OS, leave aside Unix style OS.

[Andrew Paule]

Eric:

don't be so hard on the guy - I've done the kind of things you describe
(high volume ASICs, mask ROMs, NIST traceable ATE), but if I were to
assign this task to someone, I would make sure that they know the
pitfalls -yes mask ROM and ASIC require thorough debug before they are
manufactured, but I would not throw this guy into a situation where he
is in charge of making this kind of a decision if he does not know about
it. Most of this comes from EXPERIENCE (if I had a buck for every
mistake I've ever made....), and because someone does not have enough
experience, don't label him/her like that. This is mentoring, required
in our field - and if you were to put someone in charge of something and
it failed - it's YOUR fault, not theirs - never throw someone in too
deep. If we forget to mentor people, we will be SOL when we are done
doing things.

Andrew

Eric Roesinger wrote:
"Koushik Banerjee" <koushik.banerjee@eds.com> wrote in messagenews:bg8sac$lreg0$1@ID-188659.news.uni-berlin.de...<cut>So fixing a software bug when released into the market/into productioneven for embedded systems is easy <cut>C|N>K!From what planet did you import this notion?I take it you've never written firmware for mask-ROM, microcontrollers,which are soldered directly onto the product PCB, to control cost? Orcode synthesized into a compacted ROM, within an ASIC?Remind me not to hire you, for any projects with a half-million-dollarNRE or initial parts purchase. In fact, I think I'll put you on the as-sembly line, remanufacturing a few tens of thousands of product PCB's,to replace MCU's for a code change. Be careful not to peel any traces!Once out of prototyping, the cost of changing embedded software is oft-en every bit as high as changing hardware--and sometimes worse. (Afterall, changing the odd SMT component, or adding a little flat-wiring isa bargain, compared to replacing an MCU).

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi, Koushik:

Koushik Banerjee escribió en comp.software.config-mgmt:

[...
] My statement was a relative one(though I had not mentioned that, but

And a very relative one, you can be sure.
can be judged from the statement which follows). So what I meant that was (read relatively) easier to fix a bug in the software for embedded system than it is to do it with hardware. You are right that I have not written any firmware myself. My main job is configuration management, but I have written code also. I have worked for the european leader in CE, and that is how my idea on embedded system comes from. It might be possible that they have better process and technology working for them to get this done easily(they are in the market for more than 100yrs). At least I am aware that if they

Philips, you mean...
needed to fix a application bug in the DVD player, all that was

DVD player? Philips for sure, then.
needed was to create a CD with the flash, which would then be distributed to the dealers who would then place it in the tray of the

Well, you can bet you're pretty lucky for sure. A DVD player is a player
after all, so there's an easy way to put the new software into the
hardware... though the player. Even your procedure is a very expensive
one, since most DVD player will end up at the local Philips official
representant and this action will be billed by the hour!!! Most other
embebbed software is not so lucky: where do you expect to place the
upgrading CD onto a microwave oven, or a TV set, for instance? They will
be returned to the mother mill, maybe in a different continent, and that
will be rrrrrreally expensive, don't you think so?
DVD player, which would self-program itself, (this process took less than 5minutes). If that sound difficult, I know of no easier way even in software industry itself. A high range DELL server takes more than 5minutes to boot with NT/2K OS, leave aside Unix style OS.

Well, I don't know of a single Dell which would take 5 minutes to warm up
the OS, less talking about barebones Unix (Both mininum i386 Solaris or
Linux boot up well under 20 seconds, and WinNT/2000 within a minute).

--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi again Koushik:

Koushik Banerjee escribió en comp.software.config-mgmt:
"steve at fivetrees" <steve@DELETEMEfivetrees.com> wrote in message news:bgc6l5$9g6$1$8302bc10@news.demon.co.uk... : "John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote in : message news:03hiiv4o68o38vf1s2epoi9kq5qt4plk8l@4ax.com...

[and a lot of uneeded text follows]

First of all, I would ask you NOT to answer after the text. Just leave what
is relevant for your answer and do it just where it do has any mean!
But if this is the case are we not wasting the language skills if you are not using the grammer. It would be liike saying you try to create the wheel each time you need a bicycle, and that too in the pre-historic style. Might be true that you being an engineer, programming is not the best part of your job, But I believe if it is interesting to you, it is better to learn it to be done the best possible way. It might

What Steve was telling you was that he had found his "best possible way" by
doing the way he was doing it: going to the point it was about the most
direct and simply way he could think about!
give you some sleepless nights, but you would save many more later since you know the cleaen and shortest way to write it. And if that was not enough, is it not a simple cause that the less lines of code you write, the less the chances of having bug. Every line of code you write

As it has already been answered to you, that isn't really true: there are
two famous "idioms" regarding programing that never will really be repeated
too enough: Do it as simply as possible (but not simpler); and do it the
most expectable way. Ten lines for a clear and expectable 'while-then'
loop will be less bug-prone than a "clever" 'for' oneliner for sure!
Someone named it "programming-on-jeans" versus the "too clever"
"programming-on-smoking" concept.
increases the likeliness of bug arising, which can decrease if modular or OOP approach is used. So if you happen to introduce a bug, the fix might be in a base class which would fix all related bugs in all the derived objects, rather than go and fix it individual places, more maintainability..and other advantages. But again it really depends on how many lines of code you write.

Again, that's what you're teached in school. When you affront a 4-6K lines
project (hardware or embebbed projects tend not to be too long) the
"formal" OO approach not only isn't too efficient (if you tend to be too
"formal" you cannot take advantages from the oddities of the hardware
you're managing) but it tends to be too buggy too (all your formalities,
being such a "little" project is overload -the percentage of API-related
code lines vs. "productive" code lines is too high, that can fit well
within your "the more code lines, the more bugs" theory).
--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[Eric Roesinger]

"Koushik Banerjee" <koushik.banerjee@eds.com> wrote in message
news:bggv8k$oipf7$1@ID-188659.news.uni-berlin.de... "steve at fivetrees" <steve@DELETEMEfivetrees.com> wrote in message news:bgc6l5$9g6$1$8302bc10@news.demon.co.uk... : "John Larkin" <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote in : message news:03hiiv4o68o38vf1s2epoi9kq5qt4plk8l@4ax.com... : > Me too. I design embedded software the same way as I design logic: run : > nice clean little state machines at a regular rate, run each to : > completion every shot, and never assign resources dynamically. Fully : > decode states. "Inter-task" communications is via variables shared : > between state machines. No queues. No abstraction. No glamour. No : > bugs. : : Mostly agreed. For anything non-trivial I tend to avoid sharing
variables, : though, and I embrace the principles of OO - i.e. I use access methods. : Which means I often have routines with one line (e.g. return( : some_variable);) for readonly access. Write access is similarly
controlled : and centralised. : : > I've written a few RTOSs, but I find lately that I really don't need : > them. Luckily, I'm an engineer most of the time, so I view programming : > as a mildly tedious task to be finished, not as a lifelong career. So : > I just want to get it over the quickest, most reliable way, even if : > that involves simplistic grunt work that wouldn't look good on a : > resume. : : Entirely agreed. That ol' KISS principle again. : But if this is the case are we not wasting the language skills if
you are not using the grammer. It would be liike saying you try to create
the wheel each time you need a bicycle, and that too in the pre-historic style. Might be true that you being an engineer, programming is not the best part of your job, But I believe if it is interesting to
you, it is better to learn it to be done the best possible way. It might give you some sleepless nights, but you would save many more later
since you know the cleaen and shortest way to write it.

Frankly, the only thing that is going to give *me* sleepless nights, it not
having complete control of what runs on the systems I design, and the faults
that can result. What looks simple and clean in an HLL may not be, in terms
of the code that actually runs, on the MCU.

Now, I will grant that there are benefits to compile-time checking over run-
time "defensive programming"--particularly for "access methods", which can
resolve to simple inline fetches; but understanding the system is far more
important than the programming language used to implement it.
And if that was not enough, is it not a simple cause that the less lines of code you write, the less the chances of having bug. Every line of code you write increases the likeliness of bug arising, which can decrease if modular
or OOP approach is used. So if you happen to introduce a bug, the fix might be in a base class which would fix all related bugs in all
the derived objects, rather than go and fix it individual places, more maintainability..and other advantages. But again it really depends on how many lines of code you write.

No, it depends on understanding the meaning (and in embedded work, often
the implementation) of the lines of code one writes. In many cases, it also
depends on the availability of tools.

[LJ]

Eric Roesinger wrote:
The vast majority (especially by distribution volume) of embedded systems do not share in this luxury of being field-updateable. One cannot, for example, perform a field update like this on most automotive engine controllers. To assume that a majority, or even a significant fraction of embedded applica- tions can be cheaply updated, *after release into production*, is not only so far from the truth as to be ludicrous, but, quite frankly, an unspeakably arrogant application of ignorance.

You're a dinosaur- make all your future products web appliance- access
the auto-junk via the cellcom-to-CAN- what the hell is this good for if
you can't update products on the fly.:-)

[bh]

John Larkin wrote:

[...]
I've written a few RTOSs, but I find lately that I really don't need them. Luckily, I'm an engineer most of the time, so I view programming as a mildly tedious task to be finished, not as a lifelong career. So

Do you mean you cease to be an engineer while coding? Hmm.
I just want to get it over the quickest, most reliable way, even if that involves simplistic grunt work that wouldn't look good on a resume.

I'm sure the people who worry about time-to-market love the rapid,
simple approach, especially if it works the first time.

Where I come from, products are enhanced for years through upgrades,
while the underlying hardware is mostly static.

John

BH

[Dwain Wilder]

Koushik Banerjee wrote: "Yaakov" <H_shemisone@yahoo.com> wrote in message news:2a2c56bb.0307160658.38e0ea69@posting.google.com... : Robert Cowham <rc@vaccaperna.co.uk> wrote in message news:<Xns93BA603507C0Ercvaccapernacouk@130.133.1.4>... : > peb@amleth.demon.co.uk ("Paul E. Bennett") wrote in : > news:1058302551snz@amleth.demon.co.uk: : : : Yes, One should design for bug free hardware as well as software. I : tell my programmers that I want them to make life hard for our test : engineer. Let him spend hours until he scrounges up a bug instead of : just a couple of minutes. : If the tester happens to find a bug just after he starts testing, I think either the specs were not cleanly defined(or rather the test cases dont match the spec) Or the programmer is really a BAD one. In such cases itis better desirable to do away with that programmer and get someone else good to re-write the code (NOT revamp or fix the code), because it is easier writing something altogether new yourself, than to fix some shit of someone else. And anyways if the developer left behind some obvious bugs, his coding style would also be very bad and less readable to others, less maintainable and blah-blahs..

It is tempting to take an easily found bug as a sign of programming
incompetence. But the programmer's ability to do system or integration testing
is often limited. The only thing the prorammer can always be charged withis
unit testing. I would think all of us on this newsgroup have seen bugs crop up
because of integration or system issues that weren't the fault of the programmer.

Dwain
: Yes, we should use the most cost effective trade-offs available. By : some that will be rigorous code inspection, by others it will be a : solid test-harness. Others will find a combination of the two. : : There is one issue that I didn't see addressed. : : If a bug is found don't deny it. Sounds trite but I've seen it happen. : The engineer that I'm happiest with assumes the truth of a bug report, : tries to reconstruct it in his development environment, and then asks : the question "Is this isolated or is this found somewhere else in my : work (read Hardware and/or Software)?" IMHO, quick patches are : worthless, even if you have a zillion installations. You'll just have : to make another one. If your lucky the tester will catch your new bug : before it gets out the door. : : This question could and should also be applied to marketing decisions : (read GUI design and feature sets) : : Another point that ties in to Version Control (that's how we started : the thread :-} ). : There must be communication between the Development and Test Groups. : At the very least the Test Group (and actually the developer himself) : should ask "Did you touch shared modules?" The answer to this question : will define how extensive the regression test for introducing bugs to : other features will be. : : Yaakov


--
Dwain Wilder
Bear Meadow Folk Instruments
http://www.bearmeadow.com
_______________________________
I arise in the morning torn between a desire to improve (or save) the world and
a desire to enjoy (or savor) the world. This makes it hard to plan the day.
—E. B. White

[steve at fivetrees]

"Fred Bloggs" <nospam@nospam.com> wrote in message
news:3F2D8A0E.2060107@nospam.com... Eric Roesinger wrote: The vast majority (especially by distribution volume) of embedded
systems do not share in this luxury of being field-updateable. One cannot, for example, perform a field update like this on most automotive engine controllers.
To assume that a majority, or even a significant fraction of embedded
applica- tions can be cheaply updated, *after release into production*, is not
only so far from the truth as to be ludicrous, but, quite frankly, an
unspeakably arrogant application of ignorance. You're a dinosaur- make all your future products web appliance- access the auto-junk via the cellcom-to-CAN- what the hell is this good for if you can't update products on the fly.:-)

If Eric is a dinosaur, so am I. While I'd *love* to make all my products
field-upgradeable, I'm often constrained by cost. When designing, in
particular, high-volume products, I have to balance my budget to the nearest
penny. Fairly often I have to make a choice as to where to put the upgrade
system:
- in the product (hardware costs incurred with every item)
- in the lab and/or distributor's workshop (hardware costs limited to
those that actually need them)

This decision is also based on knowledge of the likelihood/frequency of
upgrades. If the code is good quality, and the spec is stable, there is no
good reason to incur recurring hardware costs for the sake of insurance.

OTOH, I always try to ensure a code upgrade path that doesn't involve
soldering... but even that can be a tough call.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com

[Ken Lee]

On Mon, 04 Aug 2003 12:28:18 GMT, "me" <stevecase@aol.com> wrote:
perform a field update like this on most automotive engine controllers.To assume that a majority, or even a significant fraction of embeddedapplica- tions can be cheaply updated, *after release into production*, is not only so far from the truth as to be ludicrous, but, quite frankly, anunspeakably arrogant application of ignorance. - I see this guy Eric must still be in high school or ready for retirement

Not quite sure what your point is. Is Eric living in the past or is he
insightful?

My own opinion is that field upgrades are a "pain". It's not so much
as to the technical implementation that's the problem but more related
to the possible uses cases and company infrastructure that's the
killer.

If you're upgrading remotely, by modem say, one has to cater for all
possible scenarios of lost communications. You can restrict these use
cases by having only service centre upgrades, but in most cases for
low COGs products, it's cheaper to just replace the CPU board or even
provide the customer with a replacement unit.

The 3 main reasons why a embedded product would be field upgradeable
(in decending order of importance) are:

1. Marketing feature -- it certainly looks good on a brochure and
anyway your competitor has it. The customer perceives this as lower
maintenance cost as they've already conceded that the software is
likely to have bugs.
2. High risk development, so the software is likely to have bugs or
that the product has so much requirement creep that the software's
stability is questionable. Or that the development schedule was so
unrealistic, that some of the customer's requirements have to be done
in a 2nd revision of the software.
3. Future feature enhancement -- on its own is unlikely as it is
usually combined with Point 2. Typically these "features" were part of
the original requirements, but were omiited from the initial software
release due to schedule pressure (am I right!).

Here's a test which separates the men from the boys -- tell your
software team that they're about to develop a product of which at
least 50K units per year will be made AND the software will be going
to mask ROM and see how they react ;-)

If this type of product is new to the software team, then they will
need to up the ante on their Software Process, as this is a clear
example of "right first time" development.

Ken.

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

[Paul Hovnanian P.E.]

Dwain Wilder wrote:
[snip] It is tempting to take an easily found bug as a sign of programming incompetence. But the programmer's ability to do system or integration testing is often limited. The only thing the prorammer can always be charged with is unit testing. I would think all of us on this newsgroup have seen bugs crop up because of integration or system issues that weren't the fault of the programmer.

Yes. That's all the more reason to keep the software development as
closely coordinated with the hardware as possible in embedded systems.
Version control (and every other development discipline) needs to be
applied across the whole project, not just each piece separately.

--
Paul Hovnanian mailto:Paul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
Smoking is one of the leading causes of statistics.
-- Fletcher Knebel

[Paul Hovnanian P.E.]

bh wrote: John Larkin wrote: [...] I've written a few RTOSs, but I find lately that I really don't need them. Luckily, I'm an engineer most of the time, so I view programming as a mildly tedious task to be finished, not as a lifelong career. So Do you mean you cease to be an engineer while coding? Hmm. I just want to get it over the quickest, most reliable way, even if that involves simplistic grunt work that wouldn't look good on a resume. I'm sure the people who worry about time-to-market love the rapid, simple approach, especially if it works the first time. Where I come from, products are enhanced for years through upgrades, while the underlying hardware is mostly static.

Now try working in an environment where there are multiple hardware
versions in the field that need software updates from time to time. And
a customer base that can't always be trusted to match the h/w part
number with the s/w part number. This version control has to be
automatic.

--
Paul Hovnanian mailto:Paul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
Marching to a different kettle of fish.

[Michael A. Terrell]

Dwain Wilder wrote: It is tempting to take an easily found bug as a sign of programming incompetence. But the programmer's ability to do system or integration testing is often limited. The only thing the prorammer can always be charged with is unit testing. I would think all of us on this newsgroup have seen bugs crop up because of integration or system issues that weren't the fault of the programmer. Dwain

i had to repair a crappy test fixture a couple years ago. The
engineering tech that built it had sent it to the production floor with
over half the tests mis-programmed. He would be looking for the right
voltage, but the wrong polarity, and other obvious mistakes.

The test techs had a list of tests that were bad, and the fixture
missed a lot of defects. I replaced the worn out wiring harness and
fixed the software. I ran about 100 boards to verify that it worked
perfectly. That is, till someone in SMD assembly swapped some .01 µF
caps with resistors that fed one of the analog MUX inputs.

It was the first thing tested, and the boards passed, but when they
were installed in the equipment, they slowly charged, and caused a
severe DC offset problem. The test supervisor came to my bench waving a
board, claiming it had never been tested.

I set it up and ran the test for him, and it passed. He told me what
it was doing, so a quick look at the schematic, and another board
revealed the assembly errors. While he was ranting about defective
software, I copied the test to the end of the test. By repeating the
test I verified the initial test, and that there were no swapped parts.
I had it ready and running before he stopped long enough to catch his
breath. After he saw it was fixed, he just walked away shaking his
head.
--


Its August 5, 2003, so I'm 51 today!
Michael A. Terrell
Central Florida

[Michael A. Terrell]

"Paul Hovnanian P.E." wrote: bh wrote: John Larkin wrote: [...] I've written a few RTOSs, but I find lately that I really don't need them. Luckily, I'm an engineer most of the time, so I view programming as a mildly tedious task to be finished, not as a lifelong career. So Do you mean you cease to be an engineer while coding? Hmm. I just want to get it over the quickest, most reliable way, even if that involves simplistic grunt work that wouldn't look good on a resume. I'm sure the people who worry about time-to-market love the rapid, simple approach, especially if it works the first time. Where I come from, products are enhanced for years through upgrades, while the underlying hardware is mostly static. Now try working in an environment where there are multiple hardware versions in the field that need software updates from time to time. And a customer base that can't always be trusted to match the h/w part number with the s/w part number. This version control has to be automatic. -- Paul Hovnanian mailto:Paul@Hovnanian.com note to spammers: a Washington State resident ------------------------------------------------------------------ Marching to a different kettle of fish.

Even worse. A customer has different version of a device, with
feature dependent software on different boards, and the idiot swaps
cards around, and ships a unit in for service. Not only do you need the
software logs, you need to verify the serial number of ever circuit
board BEFORE you start repairs or upgrades. Or, they have you upgrade
one unit, and try to copy the software to other units, built at
different times, with different rev numbers on the boards, and screw up
a million dollars worth of equipment, and you catch hell for their
stupidity.

--


Its August 5, 2003, so I'm 51 today!
Michael A. Terrell
Central Florida

[Koushik Banerjee]

"Dwain Wilder" <dwain@bearmeadow.com> wrote in message
news:3F2E530F.6080203@bearmeadow.com...


Koushik Banerjee wrote: "Yaakov" <H_shemisone@yahoo.com> wrote in message news:2a2c56bb.0307160658.38e0ea69@posting.google.com... : Robert Cowham <rc@vaccaperna.co.uk> wrote in message news:<Xns93BA603507C0Ercvaccapernacouk@130.133.1.4>... : > peb@amleth.demon.co.uk ("Paul E. Bennett") wrote in : > news:1058302551snz@amleth.demon.co.uk: : : : Yes, One should design for bug free hardware as well as software. I : tell my programmers that I want them to make life hard for our test : engineer. Let him spend hours until he scrounges up a bug instead of : just a couple of minutes. : If the tester happens to find a bug just after he starts testing, I think either the specs were not cleanly defined(or rather the test cases dont match the spec) Or the programmer is really a BAD one. In such cases it is better desirable to do away with that programmer and get someone else good to re-write the code (NOT revamp or fix the code), because it is easier writing something altogether new yourself, than to fix some shit of
someone else. And anyways if the developer left behind some obvious bugs, his
coding style would also be very bad and less readable to others, less
maintainable and blah-blahs..

It is tempting to take an easily found bug as a sign of programming
incompetence. But the programmer's ability to do system or integration
testing
is often limited. The only thing the prorammer can always be charged with is
unit testing. I would think all of us on this newsgroup have seen bugs crop
up
because of integration or system issues that weren't the fault of the
programmer.

Dwain

But who handles the integration ? I suppose it is someone from the
development group. And to end it there is a integration testing, where we
are supposed to test what would be typical integration issues. I understand
that there would be still some which could miss this, but the idea is to
have them at minimum. I cannot comment much on the hardware perspective, but
in software, a domain expert would know what cases need to be tested out of
the system test cases to catch bug in this phase.

Koushik.

[Koushik Banerjee]

Jesus,

"Jesús M. NAVARRO" <jesus_navarro@undominio.net> wrote in message
news:orcuv-r9t.ln1@mithrandir.intranet...
: Hi, Koushik:
:
:
: > needed was to create a CD with the flash, which would then be
: > distributed to the dealers who would then place it in the tray of
the
:
: Well, you can bet you're pretty lucky for sure. A DVD player is a player
: after all, so there's an easy way to put the new software into the
: hardware... though the player. Even your procedure is a very expensive
: one, since most DVD player will end up at the local Philips official
: representant and this action will be billed by the hour!!! Most other
: embebbed software is not so lucky: where do you expect to place the
: upgrading CD onto a microwave oven, or a TV set, for instance? They will
: be returned to the mother mill, maybe in a different continent, and that
: will be rrrrrreally expensive, don't you think so?
:
Most embedded systems today I understand have their method of field updates.
I mentioned CD containing the flash software was one way of doing it. There
also was a mechanism using connectors, which could be plugged into the
EEPROM, by which you could burn the flash memory with the new software, This
feature works for all systems which work on flash memory, that is the TV
system has this feature, your mobile phone has this feature (you can look
for some dots inside your mobile phone, which are used to upgrade software.
CD is a cheaper way of doing it, considering no expenses, but for the
connector stuff, you need the hardware to be present with the dealer. That
is the difference.
Yes, I understand it is not possible for PCBs or few other systems like
those, but I do not agree that it is not possible for all systems. And true
costs can be a factor but considering the cost of throwing away the whole
product versus the cost to make the product functional again - I do not
feel one needs to think a lot on that.

Koushik

[steve at fivetrees]

"Koushik Banerjee" <koushik.banerjee@eds.com> wrote in message
news:bgqc24$r8re1$1@ID-188659.news.uni-berlin.de... You are right, everyone has his or her style of programming. But what is important is to have a knowledge of the system (domain expertise), and making best use of the language.

I disagree - "making best use of the language" is not a factor. Writing
reliable code often involves using a *subset* of the language. This is
especially true of C++, which is poorly suited to embedded work and has many
constructs that simply have no place in embedded work.
So if ones tries to program in C in OOP way, it would be inefficient, and in C++ in a C ways would be inefficient.

Again I disagree. I write object-oriented C (and assembler) all the time.
Design is separate from coding - except with languages like C++ where the
distinction is blurred. (Is this a good thing? Discuss ;).)

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com

[steve at fivetrees]

"Koushik Banerjee" <koushik.banerjee@eds.com> wrote in message
news:bgqqtb$rito8$1@ID-188659.news.uni-berlin.de... Yes, I understand it is not possible for PCBs or few other systems like those, but I do not agree that it is not possible for all systems. And
true costs can be a factor but considering the cost of throwing away the whole product versus the cost to make the product functional again - I do not feel one needs to think a lot on that.

I repeat that field-upgrading is *not* always appropriate for embedded
products. (See my earlier post.)

In many cases a better use of available cash is to get the code right in the
first place. A bug that renders a product non-functional should never be
shipped - period. Field-upgradability should *never* be an excuse for sloppy
work.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com

[John Larkin]

On Wed, 6 Aug 2003 12:54:47 +0530, "Koushik Banerjee"
<koushik.banerjee@eds.com> wrote:
But who handles the integration ? I suppose it is someone from thedevelopment group. And to end it there is a integration testing, where weare supposed to test what would be typical integration issues. I understandthat there would be still some which could miss this, but the idea is tohave them at minimum. I cannot comment much on the hardware perspective, butin software, a domain expert would know what cases need to be tested out ofthe system test cases to catch bug in this phase.Koushik.

The optimum development team size is one.

John

[David Gillon]

John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in message
news:fl42jvkso19ksapntjdi86ogcagv984utg@4ax.com...
The optimum development team size is one.

For a project requiring several man-millenia of effort?

By no means all embedded software efforts are of low enough complexity to be
handled by a single person. Nor are the various aerospace, transportation,
nuclear or medical regulatory agencies likely to be sympathetic to the
argument that you can provide an IVV capability or guarantee QA
independence/oversight with a team of one.

[Paul E. Bennett]

> On Wed, 6 Aug 2003 12:54:47 +0530, "Koushik Banerjee" <koushik.banerjee@eds.com> wrote:But who handles the integration ? I suppose it is someone from thedevelopment group. And to end it there is a integration testing, where weare supposed to test what would be typical integration issues. I understandthat there would be still some which could miss this, but the idea is tohave them at minimum. I cannot comment much on the hardware perspective, butin software, a domain expert would know what cases need to be tested out ofthe system test cases to catch bug in this phase.Koushik. The optimum development team size is one.

There are problems in having a team that small. There is no-one to
check for the silly errors we are all prone to make (keyboard error
entry rate is often quoted as 3% - naturally not all those errors
make it through to shipping). Think of surgical teams. A multiple
discipline mix of about 5 to 7 people who are able to check each
others work in mini-review sessions (whatever that work might
entail). The mix of disciplines needs to (at least loosely) match
the requirements of the project. You may need more than one team if
the project is rather large (each huge project should be arranged
as a collection of smaller projects).

--
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi, Paul:

Paul E. Bennett escribió en comp.software.config-mgmt:
In article <fl42jvkso19ksapntjdi86ogcagv984utg@4ax.com> jjlarkin@highlandSNIPtechTHISnologyPLEASE.com "John Larkin" writes: On Wed, 6 Aug 2003 12:54:47 +0530, "Koushik Banerjee" <koushik.banerjee@eds.com> wrote:But who handles the integration ? I suppose it is someone from thedevelopment group. And to end it there is a integration testing, wherewe are supposed to test what would be typical integration issues. Iunderstand that there would be still some which could miss this, but theidea is to have them at minimum. I cannot comment much on the hardwareperspective, but in software, a domain expert would know what cases needto be tested out of the system test cases to catch bug in this phase.Koushik. The optimum development team size is one. There are problems in having a team that small. There is no-one to check for the silly errors we are all prone to make (keyboard error entry rate is often quoted as 3% - naturally not all those errors

Yes, there is: it's call "the compiler".
make it through to shipping). Think of surgical teams. A multiple discipline mix of about 5 to 7 people who are able to check each others work in mini-review sessions (whatever that work might entail). The mix of disciplines needs to (at least loosely) match the requirements of the project. You may need more than one team if the project is rather large (each huge project should be arranged as a collection of smaller projects).

The surgeon approach works because:
1/ They are working in a very narrow place (so communication problems are
minimized)
2/ They are working on a very repetitive and specialized manner, so
surprises and "conflicts" go to a minimum (the chances of the anaesthesist
jumping for the scalpel crying "me! me! I'll open his belly!" are quite
reduced)

I bet that's not the usual environment for a development team (and yes, it
has been tried to mimic the advantages of the surgical teams into the
programming field: the XP two programmers per PC and trying to specialize
the members of the team and the project tasks so overlap is minimum has
been tried with varied success).
--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[Ken Lee]

On Fri, 08 Aug 2003 04:08:05 +0200,
=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?= <jesus_navarro@undominio.net>
wrote:
Hi, Paul:Paul E. Bennett escribió en comp.software.config-mgmt: In article <fl42jvkso19ksapntjdi86ogcagv984utg@4ax.com> jjlarkin@highlandSNIPtechTHISnologyPLEASE.com "John Larkin" writes: On Wed, 6 Aug 2003 12:54:47 +0530, "Koushik Banerjee" <koushik.banerjee@eds.com> wrote: > >But who handles the integration ? I suppose it is someone from the >development group. And to end it there is a integration testing, where >we are supposed to test what would be typical integration issues. I >understand that there would be still some which could miss this, but the >idea is to have them at minimum. I cannot comment much on the hardware >perspective, but in software, a domain expert would know what cases need >to be tested out of the system test cases to catch bug in this phase. > >Koushik. > The optimum development team size is one. There are problems in having a team that small. There is no-one to check for the silly errors we are all prone to make (keyboard error entry rate is often quoted as 3% - naturally not all those errorsYes, there is: it's call "the compiler".

It depends what one's definition of an error or bug is. Some
developers regard non compliance to the Coding Standard as an error.
How about ill-formed conditional statements or uninitialised pointers
-- these may pass the compiler (certainly not a good Lint) and are a
source of potential bugs. Of course, there's the ageless screwing up
of the logic (because the office girl that you've got a crush on, just
bent down to pick up a pencil and so you got distracted), which would
pass the compiler checks but probably (hopefully) fail in one's unit
testing.
make it through to shipping). Think of surgical teams. A multiple discipline mix of about 5 to 7 people who are able to check each others work in mini-review sessions (whatever that work might entail). The mix of disciplines needs to (at least loosely) match the requirements of the project. You may need more than one team if the project is rather large (each huge project should be arranged as a collection of smaller projects).The surgeon approach works because:1/ They are working in a very narrow place (so communication problems areminimized)2/ They are working on a very repetitive and specialized manner, sosurprises and "conflicts" go to a minimum (the chances of the anaesthesistjumping for the scalpel crying "me! me! I'll open his belly!" are quitereduced)I bet that's not the usual environment for a development team (and yes, ithas been tried to mimic the advantages of the surgical teams into theprogramming field: the XP two programmers per PC and trying to specializethe members of the team and the project tasks so overlap is minimum hasbeen tried with varied success).

All I can say is that Software Development Teams of more than 1
person, are a reality. The performance of the team will rely on team
management. Also it relies on team members -- it's unwise to place a
sole maverick with xenophobic behaviour into a team environment -- you
need team players for it to work.

Ken.
--SALUD,Jesús***jesus_navarro@undominio.net***


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

[Chris Hills]

In article <3F2D8A0E.2060107@nospam.com>, Fred Bloggs
<nospam@nospam.com> writesYou're a dinosaur- make all your future products web appliance- accessthe auto-junk via the cellcom-to-CAN- what the hell is this good for ifyou can't update products on the fly.:-)

There are many systems that must not have an update capability.
Yesterday (Thursday 7th August 2003) I was asked to specify an OTP part
because for security reasons it must NOT be field upgradeable. This is
for a state of the art system (for next seasons F1 cars) And yes it will
be on a CAN network.

There are many systems such as control systems for safety related
equipment, security equipment etc that do not want any way of upgrading
the code because the code shipped MUST be as certified.

Changes are not permitted. In fact many have to use a specified version
of the compiler.

As for "web accessible" some of the development areas I visit are not
permitted web access (for safety and security) let alone their projects.
Besides many of the projects don't have room for web access. I assume
you mean Internet access. A small but important distinction.

Not a dinosaur just working in more professionals area than you are.


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

[Robert Cowham]

=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?= <jesus_navarro@undominio.net>
wrote in news:kku901-s6e.ln1@mithrandir.intranet:
Hi, Ken: Ken Lee escribió en comp.software.config-mgmt: On Wed, 06 Aug 2003 07:38:17 -0700, John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote: [...]The optimum development team size is one. I would have thought that the optimum team size is dependant on the scope of the project in hand. It's a balance of team management overhead & delivery date. Possibly you meant to say that "one" is a preferable team size. Also having a team of one, leaves the deliverable quality aspects to just a single person -- which may not be a good idea. Having one's code constantly (informally) inspected by a peer is good practice to exposing errors, either in coding or design. Also an indicator of whether one has written good code, is whether a peer (of comparable technical skills) can readily understand it.
That being said, of course the "single developer team" is not always possible (though desireable as an optimum): if a software development project objetively needs 20.000 man/hours, you can wait about 10 years for the project to be finished or you will be forced to use a bigger team (and then you will need to cope with the managerial problems that a "team of more than one" arises).

There's a good link in the book "Lean Software Development" - (see
http://www.poppendieck.com). Refers to Jim Johnson, Chairman of the
Standish Group telling the story of how Florida and Minnesota each
developed its Statewide Automated Child Welfare Information System
(SACWIS). Florida started in 1990, original estimate 8 years and $32m.
In 2002, Florida had spent $170m and estimate was 2005 for $230m.
Minnesota began in 1999, and completed in 2000 at a cost of $1.1m.
Minnesota kept to standardized infrastructure, minimized requirements
and had 8 capable people....

--
Robert Cowham

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi, Chris:

Chris Hills escribió en comp.software.config-mgmt:
In article <69db01-o1e.ln1@mithrandir.intranet>, Jesús M. NAVARRO <jesus_navarro@undominio.net> writes> The optimum development team size is one. There are problems in having a team that small. There is no-one to check for the silly errors we are all prone to make (keyboard error entry rate is often quoted as 3% - naturally not all those errorsYes, there is: it's call "the compiler". The compiler is not an error checker... it is a translator. As long as the syntax is legal. The first level of checking is Lint. PC-Lint in my case. This is a common mistake amongst new and inexperienced programmers that the compiler is an error checker. In fact Denis Ritche said that Lint was invented to pick up the highly dubious but syntactically correct miss uses of C. I will dig out the exact quote and URL later today.

OK. I wouldn't try to be "academic". I was just arguing the assertion
"There is no-one to check for the silly errors we are all prone to make
(keyboard error entry rate is often quoted as 3% - naturally not all those
errors make it through to shipping)." If "keyboard error-related" it will
produce non-compilable code (in such a high percentage that the chances for
a misstyping that produces sintactically right still semantically wrong
code are simply neglectable... at least for any compilable language, which
I think was an automatic implicity given my, somewhat ironic phrase).

Anyway, change "the compiler" with the "lint checker" if you want to. My
assertion is still true: for silly mistakes and mainly because they're
silly there're automatic tools that will do the work. The subtle errors
are the ones that need more *human* eyeballs to be catched.
--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi, Ken:

Ken Lee escribió en comp.software.config-mgmt:
On Fri, 08 Aug 2003 04:08:05 +0200, =?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?= <jesus_navarro@undominio.net> wrote:Hi, Paul:Paul E. Bennett escribió en comp.software.config-mgmt: In article <fl42jvkso19ksapntjdi86ogcagv984utg@4ax.com> jjlarkin@highlandSNIPtechTHISnologyPLEASE.com "John Larkin" writes:

[...]
There are problems in having a team that small. There is no-one to check for the silly errors we are all prone to make (keyboard error entry rate is often quoted as 3% - naturally not all those errorsYes, there is: it's call "the compiler". It depends what one's definition of an error or bug is.

You're right, but I was not talking about "bugs" in general but specifically
about "silly bugs like keyboard mistyping".
The surgeon approach works because:1/ They are working in a very narrow place (so communication problems areminimized)2/ They are working on a very repetitive and specialized manner, sosurprises and "conflicts" go to a minimum (the chances of the anaesthesistjumping for the scalpel crying "me! me! I'll open his belly!" are quitereduced)I bet that's not the usual environment for a development team (and yes, ithas been tried to mimic the advantages of the surgical teams into theprogramming field: the XP two programmers per PC and trying to specializethe members of the team and the project tasks so overlap is minimum hasbeen tried with varied success). All I can say is that Software Development Teams of more than 1 person, are a reality. The performance of the team will rely on team management. Also it relies on team members -- it's unwise to place a sole maverick with xenophobic behaviour into a team environment -- you need team players for it to work.

Anybody will argue the truth that there are development teams of more than
one development (even more a "development team of just one developer" is
more a joke than anything else"). What I was saying is that *one* is the
optimum size for a "development team" but, since usually you really can't
have a development team that short, you will need extra-work (that is
called "management") to compensate for the problems any "development team
of more that one" arises. You yourself have arosen one of them: you have
to trash away "lonestar programmers" because they fit badly within a larger
than one people team while they could do a good (even a brilliant) job if
the team size was exactly one.
--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi, Robert:

Robert Cowham escribió en comp.software.config-mgmt:
=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?= <jesus_navarro@undominio.net> wrote in news:kku901-s6e.ln1@mithrandir.intranet:

[...]
That being said, of course the "single developer team" is not always possible (though desireable as an optimum): if a software development project objetively needs 20.000 man/hours, you can wait about 10 years for the project to be finished or you will be forced to use a bigger team (and then you will need to cope with the managerial problems that a "team of more than one" arises). There's a good link in the book "Lean Software Development" - (see http://www.poppendieck.com). Refers to Jim Johnson, Chairman of the Standish Group telling the story of how Florida and Minnesota each developed its Statewide Automated Child Welfare Information System (SACWIS). Florida started in 1990, original estimate 8 years and $32m. In 2002, Florida had spent $170m and estimate was 2005 for $230m. Minnesota began in 1999, and completed in 2000 at a cost of $1.1m. Minnesota kept to standardized infrastructure, minimized requirements and had 8 capable people....

I really don't know what exactly your point is here, but I see it as a
consolidation of my position: given a fixed "table of requirements" the
shorter the team (given all other circumnstances stay the same), the most
probably you will end up with good results. Once your development team
grows over one member you face managerial problems you will have to cope
with. Then again, the shorter the team (even over the "one member
optimum") the easier the managerial problems will be so the more probable
you will end up with positive results.
--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi again, Ken:

Ken Lee escribió en comp.software.config-mgmt:

[...]
It's a common knowledge that the lower the development team the best theresults will be, being one of the most important tasks for mid-managementsplit big project/problems into short enough "chunks" so they can bedeployed by just one developer or a short team of them. This is true and correct and I couldn't agree more, but we shouldn't conclude that the optimum size is one. That's all I was commenting on in my previous post.

Well, of course we're talking almost about angels' sex (or at least more
about wording and semantics, since we seem to already have the same opinion
but for some wordings) here but still, I stand in my position: from the
fact that most of the SCM/CM tools/procedures (not all, as I previously
said in the heat of the moment, since repeteability and acountability are
really very important too and have nothing to do with the group size) just
"try" to overcome problems that arise *only* when the team size grows over
1 member, one can conclude that a "single developer team" is an optimum...
or a sweet utopia if you think it is better said this way.
--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[Robert Cowham]

=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?= <jesus_navarro@undominio.net> wrote
in news:torc01-fuj.ln1@mithrandir.intranet:
I really don't know what exactly your point is here, but I see it as a consolidation of my position: given a fixed "table of requirements" the shorter the team (given all other circumnstances stay the same), the most probably you will end up with good results. Once your development team grows over one member you face managerial problems you will have to cope with. Then again, the shorter the team (even over the "one member optimum") the easier the managerial problems will be so the more probable you will end up with positive results.

Well I wouldn't go so far as to say 1 member is optimal (in all cases), but
I was supporting your position!

--
Robert Cowham

[Robert Cowham]

=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?= <jesus_navarro@undominio.net>
wrote in news:e5sc01-pak.ln1@mithrandir.intranet:
This is true and correct and I couldn't agree more, but we shouldn't conclude that the optimum size is one. That's all I was commenting on in my previous post. Well, of course we're talking almost about angels' sex (or at least more about wording and semantics, since we seem to already have the same opinion but for some wordings) here but still, I stand in my position: from the fact that most of the SCM/CM tools/procedures (not all, as I previously said in the heat of the moment, since repeteability and acountability are really very important too and have nothing to do with the group size) just "try" to overcome problems that arise *only* when the team size grows over 1 member, one can conclude that a "single developer team" is an optimum... or a sweet utopia if you think it is better said this way.

The XP guys would probably disagree - 2 gives better results than 1....

--
Robert Cowham

[=?ISO-8859-15?Q?Jes=FAs_M=2E_NAVARRO?=]

Hi, Robert:

Robert Cowham escribió en comp.software.config-mgmt:

[...]
The XP guys would probably disagree - 2 gives better results than 1....

Wouldn't say so. I'd say XP stays that 2 gives better results than 1+1:
*Given* that your team is already larger than 1, pairing programmers gives
(suppousedly) better results than letting them alone. But ask yourself
why:
1/ Because pairing them you're nearer to the "grid state" I talked about in
a previous message
2/ The pairings are not static but change over time, thus further
facilitating intercommunication and knowledge about other parts of the code
and about the minds of the members of the team.

Again, if the team was made of 1 from the beginning, you wouldn't need the
XP approach at all!

(Still, they're probably right regarding the more eyeballs, the easier not
to overlook something, so well... it migth be true that a team of 2 *at the
same PC* can be more productive without higher managerial burden... Not my
experience, anyway: I've done paired creative productions -not computer
programs, and while working in pairs can be more productive from the
creativeness point of view if the pair is mediocre, big egos tend to stay
in the way when the members of the pair are good and really creative.
Maybe the technical part of the computer programming can make a difference,
I really don't know).
--
SALUD,
Jesús
***
jesus_navarro@undominio.net
***

[Dwain Wilder]

Koushik Banerjee wrote: "Dwain Wilder" <dwain@bearmeadow.com> wrote in message news:3F2E530F.6080203@bearmeadow.com... Koushik Banerjee wrote: "Yaakov" <H_shemisone@yahoo.com> wrote in messagenews:2a2c56bb.0307160658.38e0ea69@posting.google.com...: Robert Cowham <rc@vaccaperna.co.uk> wrote in messagenews:<Xns93BA603507C0Ercvaccapernacouk@130.133.1.4>...: > peb@amleth.demon.co.uk ("Paul E. Bennett") wrote in: > news:1058302551snz@amleth.demon.co.uk:::: Yes, One should design for bug free hardware as well as software. I: tell my programmers that I want them to make life hard for our test: engineer. Let him spend hours until he scrounges up a bug instead of: just a couple of minutes.:If the tester happens to find a bug just after he starts testing, I thinkeither the specs were not cleanly defined(or rather the test cases dontmatch the spec) Or the programmer is really a BAD one. In such cases itisbetter desirable to do away with that programmer and get someone else goodto re-write the code (NOT revamp or fix the code), because it is easierwriting something altogether new yourself, than to fix some shit of someone else. And anyways if the developer left behind some obvious bugs, his coding style would also be very bad and less readable to others, less maintainable and blah-blahs.. It is tempting to take an easily found bug as a sign of programming incompetence. But the programmer's ability to do system or integration testing is often limited. The only thing the prorammer can always be charged with is unit testing. I would think all of us on this newsgroup have seen bugs crop up because of integration or system issues that weren't the fault of the programmer. Dwain But who handles the integration ? I suppose it is someone from the development group. And to end it there is a integration testing, where we are supposed to test what would be typical integration issues. I understand that there would be still some which could miss this, but the idea is to have them at minimum. I cannot comment much on the hardware perspective, but in software, a domain expert would know what cases need to be tested out of the system test cases to catch bug in this phase. Koushik.

To be sure, Koushik, a developer does the integration testing. My point was that
one can't simply blame a programmer when his/her work is going to integrate with
other system components. There may be integration or system level issues beyond
his knowledge. He/she may well do the integration test and have to fix a problem
in code he/she created or changed. But that does not necessarily imply that he
or she should have fixed the problem at unit test if the problem arose becausse
of integration or system issues. Does that make my point clearer?

Dwain



--
Dwain Wilder
Bear Meadow Folk Instruments
http://www.bearmeadow.com
_______________________________
Hypocrisy is the homage vice pays to virtue.
—François de La Rochefoucauld