Version Control in Embedded Systems

[Stephen Baynes.]

"Yaakov" <H_shemisone@yahoo.com> wrote in message
news:2a2c56bb.0307020321.16e28a83@posting.google.com... Are people using formal Version Control systems for embedded applications? If you're using something other than a nightly backup to the network server, I'd like to know what it is. Might want to formalize something where I work


You mean is anyone not using formal version control systems for embeded
systems?
As embeded systems are usually difficult to upgrade to a new version - the
quality levels needed require one to use some sort of formal version control
(and configuration control).

We use Telelogic Synergy.

--
Stephen Baynes CEng MBCS
DTG-S&S, Philips Semiconductors Southampton
Tel +44 23 80316431

[Paul E. Bennett]

In article <2a2c56bb.0307020321.16e28a83@posting.google.com>
H_shemisone@yahoo.com "Yaakov" writes:
Are people using formal Version Control systems for embedded applications? If you're using something other than a nightly backup to the network server, I'd like to know what it is. Might want to formalize something where I work

Having viewed some of the answers you have already received on this
topic I will chip in and mention a commercial package. This is
actually a combination of two packages, one for the version management
side of the task, the other for the change management side.

MKS Source Integrity - RCS based version management
MKS Track Integrity - Change management database/logger.
(see http://www.mks.com/)

Both of these products working together implement the flowchart of
process management that is featured on my website and automates the
four forms and one register aspect of that process.

Of course, you only need a commercial package like the MKS products
if you have a largish team of people working on the project. I am
sure that the freely available tools will do some of the work of
the above packages. In small teams it is even possible to do the
job manually. However, run version and change management you must.

As someone else has aleady indicated, the use of a version control
system is not just for embedded source code. Version control should
be an integral part of the development process and cover all aspects
of design and manufacture.

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

[steve at fivetrees]

""Paul E. Bennett"" <peb@amleth.demon.co.uk> wrote in message
news:1057355321snz@amleth.demon.co.uk... Having viewed some of the answers you have already received on this topic I will chip in and mention a commercial package.

Point taken, Paul, but did it need to be in triplicate?

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

[Paul E. Bennett]

In article <be5322$fhc$1$8302bc10@news.demon.co.uk>
steve@DELETEMEfivetrees.com "steve at fivetrees" writes:
""Paul E. Bennett"" <peb@amleth.demon.co.uk> wrote in message news:1057355321snz@amleth.demon.co.uk... Having viewed some of the answers you have already received on this topic I will chip in and mention a commercial package. Point taken, Paul, but did it need to be in triplicate?

Sorry about that. The item didn't seem to have left my machine at all
hence reposting it. I hadn't seen it appear in the newsgroup at all
despite the multiple posting.

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

[steve at fivetrees]

""Paul E. Bennett"" <peb@amleth.demon.co.uk> wrote in message
news:1057479091snz@amleth.demon.co.uk... Sorry about that. The item didn't seem to have left my machine at all hence reposting it. I hadn't seen it appear in the newsgroup at all despite the multiple posting.

No problem. I misread it as being an ad posted 3 times - mea culpa ;).

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

[Paul E. Bennett]

In article <beaaos$rln$1$8300dec7@news.demon.co.uk>
steve@DELETEMEfivetrees.com "steve at fivetrees" writes:
""Paul E. Bennett"" <peb@amleth.demon.co.uk> wrote in message news:1057479091snz@amleth.demon.co.uk... Sorry about that. The item didn't seem to have left my machine at all hence reposting it. I hadn't seen it appear in the newsgroup at all despite the multiple posting. No problem. I misread it as being an ad posted 3 times - mea culpa ;).

Apparently a change at Demon meant that multi-line newsgroup lists
weren't being processed properly.

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

[steve at fivetrees]

""Paul E. Bennett"" <peb@amleth.demon.co.uk> wrote in message
news:1057777940snz@amleth.demon.co.uk... Apparently a change at Demon meant that multi-line newsgroup lists weren't being processed properly.

Bizarre.
see http://www.feabhas.com for details. <<

Heh. Give my regards to Niall ;). I still have some examples of OO-C to give
him...

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

[Robert Cowham]

John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
news:cf8cgv06bf3fe1te3d9cq2s6pctr4hcl9a@4ax.com:
On Fri, 4 Jul 2003 13:23:21 +0100, "Stephen Baynes."<stephen.baynes@soton.sc.philips.com> wrote:"Yaakov" <H_shemisone@yahoo.com> wrote in messagenews:2a2c56bb.0307020321.16e28a83@posting.google.com... Are people using formal Version Control systems for embedded applications? If you're using something other than a nightly backup to the network server, I'd like to know what it is. Might want to formalize something where I workYou mean is anyone not using formal version control systems forembeded systems? I'm not. I program in assembly, generally have one source file, work in DOS mode, and use one batch file to build an entire project. I can archive a typical project, including all tools *and the operating system* on one floppy.

Even when working on a small script on my own, the ability to save versions
every few minutes if appropriate with a comment to say what was working,
what I'm about to do, just makes everything go much better. I can back out
changes, and delete sections (rather than just comment out) knowing that I
can get them back if needed.

I can't really imagine not using VC for anything.... They exist for DOS too
and can be just as easy to use.

--
Robert Cowham

[John Larkin]

On 11 Jul 2003 11:02:25 GMT, Robert Cowham <rc@vaccaperna.co.uk>
wrote:
John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote innews:cf8cgv06bf3fe1te3d9cq2s6pctr4hcl9a@4ax.com: On Fri, 4 Jul 2003 13:23:21 +0100, "Stephen Baynes."<stephen.baynes@soton.sc.philips.com> wrote:"Yaakov" <H_shemisone@yahoo.com> wrote in messagenews:2a2c56bb.0307020321.16e28a83@posting.google.com...> Are people using formal Version Control systems for embedded> applications? If you're using something other than a nightly backup> to the network server, I'd like to know what it is. Might want to> formalize something where I workYou mean is anyone not using formal version control systems forembeded systems? I'm not. I program in assembly, generally have one source file, work in DOS mode, and use one batch file to build an entire project. I can archive a typical project, including all tools *and the operating system* on one floppy.Even when working on a small script on my own, the ability to save versionsevery few minutes if appropriate with a comment to say what was working,what I'm about to do, just makes everything go much better. I can back outchanges, and delete sections (rather than just comment out) knowing that Ican get them back if needed.I can't really imagine not using VC for anything.... They exist for DOS tooand can be just as easy to use.


Well, different strokes. I can't imagine doing a separate backup every
few minutes, or what I would do with the resulting, say, 1500 backup
files that I'd generate during a 2-week-long embedded programming
project. I guess I'm old-fashioned: I think about the problem, write
the code, test it, release it, and I'm done.

My experience working with programs and organizations big and small is
that the fancier the tools, the worse the code.

John

[Jerry Lusa]

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message news:5oktgv8lti3itoeoojqiqammc3ssfdm609@4ax.com... On 11 Jul 2003 11:02:25 GMT, Robert Cowham <rc@vaccaperna.co.uk> wrote:John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote innews:cf8cgv06bf3fe1te3d9cq2s6pctr4hcl9a@4ax.com: On Fri, 4 Jul 2003 13:23:21 +0100, "Stephen Baynes."<stephen.baynes@soton.sc.philips.com> wrote:>"Yaakov" <H_shemisone@yahoo.com> wrote in message>news:2a2c56bb.0307020321.16e28a83@posting.google.com...>> Are people using formal Version Control systems for embedded>> applications? If you're using something other than a nightly backup>> to the network server, I'd like to know what it is. Might want to>> formalize something where I work>>>You mean is anyone not using formal version control systems for>embeded systems? I'm not. I program in assembly, generally have one source file, work in DOS mode, and use one batch file to build an entire project. I can archive a typical project, including all tools *and the operating system* on one floppy.Even when working on a small script on my own, the ability to save
versionsevery few minutes if appropriate with a comment to say what was working,what I'm about to do, just makes everything go much better. I can back
outchanges, and delete sections (rather than just comment out) knowing that
Ican get them back if needed.I can't really imagine not using VC for anything.... They exist for DOS
tooand can be just as easy to use. Well, different strokes. I can't imagine doing a separate backup every few minutes, or what I would do with the resulting, say, 1500 backup files that I'd generate during a 2-week-long embedded programming project. I guess I'm old-fashioned: I think about the problem, write the code, test it, release it, and I'm done. My experience working with programs and organizations big and small is that the fancier the tools, the worse the code.

That sounds funny, but my impression is the same.

I think the point of versions/backup/comment is to keep track of design
decisions and be able to backtrack when one is later proven incorrect. 1500
backup files isn't the case with a decent source control system. It is just
1500
"deltas" which consist of maybe 50-500 characters each representing the
changes in the source for the new functionality which you detail in the
comment
you filed when you made the backup. You may even consolidate deltas over
version differences you don't want to keep track of, but it doesn't really
save much, just paper when printing out your version history.

Rufus









-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

[Paul E. Bennett]

In article <bekrcp$1nv$1$8300dec7@news.demon.co.uk>
steve@DELETEMEfivetrees.com "steve at fivetrees" writes:
""Paul E. Bennett"" <peb@amleth.demon.co.uk> wrote in message news:1057777940snz@amleth.demon.co.uk... Apparently a change at Demon meant that multi-line newsgroup lists weren't being processed properly. Bizarre. see http://www.feabhas.com for details. << Heh. Give my regards to Niall ;). I still have some examples of OO-C to give him...

When I get to speak to him again. Our paths haven't crossed for a
while.

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

[Grant Edwards]

In article <8qXPa.30651$hY1.8848084@news4.srv.hcvlny.cv.net>, me wrote:
When I was building commercial products, software control document control was a "a waste of time" even if we should have been using it.

Wow. Must be nice to be perfect. To never make a mistake. To
have an unlimited memory with inifinite accuracy.

What's it feel like to be god. Could you perhaps do something
about the weather in the midwest? It's been a bit too hot
lately.

--
Grant Edwards grante Yow! .. I think I'd
at better go back to my DESK
visi.com and toy with a few common
MISAPPREHENSIONS...

[Chris Hills]

In article <3f10568d$0$184$a1866201@newsreader.visi.com>, Grant Edwards
<grante@visi.com> writesIn article <8qXPa.30651$hY1.8848084@news4.srv.hcvlny.cv.net>, me wrote: When I was building commercial products, software control document control was a "a waste of time" even if we should have been using it.Wow. Must be nice to be perfect. To never make a mistake. Tohave an unlimited memory with inifinite accuracy.What's it feel like to be god. Could you perhaps do somethingabout the weather in the midwest? It's been a bit too hotlately.


Perhaps you should have read the whole post before replying?

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

[me]

> Wow. Must be nice to be perfect. To never make a mistake. To have an unlimited memory with inifinite accuracy.

Mooron, is that what I said?
What's it feel like to be god. Could you perhaps do something about the weather in the midwest? It's been a bit too hot lately.

Perhapes you should move off your farm and go someplace where software is
not used for porn.

-- Grant Edwards grante Yow! .. I think I'd at better go back to my
DESK visi.com and toy with a few
common MISAPPREHENSIONS...

[me]

Thanks Chris, they don't read very well in Minnesota.
Perhaps you should have read the whole post before replying? /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Robert Cowham]

> Mooron...

Do they have a lot of intellectually challenged cows where you live ;+)

--
Robert Cowham

[Don Pearce]

On 14 Jul 2003 11:05:42 GMT, Robert Cowham <rc@vaccaperna.co.uk>
wrote:
Mooron...Do they have a lot of intellectually challenged cows where you live ;+)--Robert Cowham

As opposed to your locality, where the cows clearly have a regrettable
tendency to overacting. Either that or the pigs have been genetically
engineered to produce beef-flavoured bacon.

d

_____________________________

http://www.pearce.uk.com

[Dwain Wilder]

Maybe "Mooron" is the elementary particle of cattle.

Robert Cowham wrote:Mooron... Do they have a lot of intellectually challenged cows where you live ;+)


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

[Lewin A.R.W. Edwards]

> Perhapes you should move off your farm and go someplace where software is not used for porn.

Hmm... if you can point out such a place on a map, I've got standing
purchase orders from several right-wing cultists for houses in such an
area...

[John Larkin]

On 12 Jul 2003 18:42:22 GMT, Grant Edwards <grante@visi.com> wrote:
In article <8qXPa.30651$hY1.8848084@news4.srv.hcvlny.cv.net>, me wrote: When I was building commercial products, software control document control was a "a waste of time" even if we should have been using it.Wow. Must be nice to be perfect. To never make a mistake.

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. More important, if you depend on testing to find bugs, you'll
never find all of them.
To have an unlimited memory with inifinite accuracy.

Comments perform that function.


John

[Dwain Wilder]

John Larkin wrote: On 12 Jul 2003 18:42:22 GMT, Grant Edwards <grante@visi.com> wrote: In article <8qXPa.30651$hY1.8848084@news4.srv.hcvlny.cv.net>, me wrote:When I was building commercial products, software control document controlwas a "a waste of time" even if we should have been using it.Wow. Must be nice to be perfect. To never make a mistake. 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. More important, if you depend on testing to find bugs, you'll never find all of them.

Now here's a guy with a work ethic I can understand! I even think what you have
to say has the ring of profundity: if one has so many bugs that one can'tfix
them through simple insight into the code, they have already infiltrated the
product to such a degree that you can no longer cure them. You can only rinse
them, a process that removes a more or less constant ratio of them (and leaves a
ratio of them). I've worked on more than a few such projects. Once this happens
you can forget about getting the code squeaky clean.

I like the bit about troubleshooting while nibbling chocolate in bed, too!
To have an unlimited memory with inifinite accuracy. Comments perform that function. John


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

[RP Henry]

"steve at fivetrees" <steve@DELETEMEfivetrees.com> wrote in message
news:bev0hb$3ll$1$830fa79d@news.demon.co.uk... 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 ALWAYS design for no bugs. But I wouldn't be so rash as to say that the
result is always bug-free.

[John Larkin]

On Mon, 14 Jul 2003 12:47:36 -0700, "RP Henry" <richard.p.henry@saic
dot com> wrote:I ALWAYS design for no bugs. But I wouldn't be so rash as to say that theresult is always bug-free.

But is is, absolutely literally, the thought that counts.

John

[Kevin Kramb]

"steve at fivetrees" <steve@DELETEMEfivetrees.com> wrote in message
news:bev0hb$3ll$1$830fa79d@news.demon.co.uk... "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 ;). 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. 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'm curious (honestly). Other than your mindset, what do you do differently
than
the "hack-and-debug" majority. John suggested thorough code reviews.
Anything else?

Do you actually test your software? If so do you find bugs during testing?

Is it your experience that hardware designs are normally right the first
time?

How complex are your software designs relative to your hardware designs?

-- Kevin

[John Larkin]

On Mon, 14 Jul 2003 23:00:27 -0400, "Kevin Kramb"
<kekramb.invalid@ra.rockwell.com.invalid> wrote:Is it your experience that hardware designs are normally right the firsttime?


It's interesting to compare. If I design a PC board full of parts, and
anything's wrong, I have to write an ECO to manufacturing to kluge the
board, and that's a very public admission of error. If it's too
serious or ugly to kluge, we have to roll the PCB rev - lots of work -
re-release the drawings, wait for new boards, build the next
iteration, etc. Again, very public and very expensive. So most
hardware works the first time, because the economic and social
pressures punish sloppy work.

Software, on the other hand, can be patched forever without traces
peeling off, and the entire process is pretty much done in private. So
software, even short routines, are seldom right the first, or even the
second, time. Interestingly, FPGA designs often tend to be like
software, sloppy and buggy on the first pass, at least by some people.
Anybody who designed a hard ASIC this way would be unemployed pronto.

Debugging just tells you about where in your code to look for
blunders, at which time you read the code, smack yourself in the head,
say "of course", and fix it. So why not do that *before* you test the
code?

John

[Kelly Hall]

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message news:f2t6hvocugmvoq4kgfhbsh189o3gb5idee@4ax.com... It's interesting to compare. If I design a PC board full of parts, and anything's wrong, I have to write an ECO to manufacturing to kluge the board, and that's a very public admission of error.
Software, on the other hand, can be patched forever without traces peeling off, and the entire process is pretty much done in private. So software, even short routines, are seldom right the first, or even the second, time.

Interesting. I've worked in both the hardware and software camps, and at
most of the software jobs we had even more elaborate release procedures for
software than for hardware. ECOs required in both cases, but the hardware
release process didn't usually include releasing modified test plans and
test reports, as well as updated design documents (use cases, specs,
whatnot, marketing and sales signoffs, etc). Of course, I've worked in
software environments where whatever we installed on the master server was
what the customer got, and there wasn't even any source code control
system - just nightly backups of the server.

After trying it a variety of ways, I prefer a strong ECO process with the
QA-maintained document control library for released documents, and both
user-level (ie, just for me and my private use) and group-level (ie, for
everyone on the team) source code control systems. But when it comes down
to it, I'll do whatever the customer wants. If he doesn't care, then I do
it my way ;)
Debugging just tells you about where in your code to look for blunders, at which time you read the code, smack yourself in the head, say "of course", and fix it. So why not do that *before* you test the code?

It all depends how you work and how your project runs. If your
specifications are rigid, you can do a lot of analysis and design checking
up front and save debug time in the long term. If your project is a
never-ending series of "we like this but not that and can it also do this
other thing?" it gets harder to maintain design discipline nd analysis. I'm
a big fan of writing self-tests and test stubs in all of my classes now so
that by the time I start integrating things I've already got a high level of
confidence that my components actually work. "Baby Steps" is my work
mantra.

Kelly

[steve at fivetrees]

"Kevin Kramb" <kekramb.invalid@ra.rockwell.com.invalid> wrote in message
news:vh6riee2db494e@corp.supernews.com... I'm curious (honestly). Other than your mindset, what do you do
differently than the "hack-and-debug" majority. John suggested thorough code reviews. Anything else?

"Mindset" is probably the key thing. Other elements include:
- Planning: I design before I code.
- Defensive design: I use a variety of techniques to ensure robustness,
and insensitivity (and hyper-sensitivity) to change.
- Synchronism: I use all the same techniques I learned doing ASIC design
to ensure synchronism i.e. positive data handover.
- Maintainability & readability: if I can't read the code at a glance, I
consider it broken.
Do you actually test your software? If so do you find bugs during
testing?

Of course ;). But the bugs I find tend to be glaring and easy to find. I
almost never introduce, or indeed need to find, subtle bugs. I emphasise
that my testing tends to be code verification, rather than active debugging.
Is it your experience that hardware designs are normally right the first time?

Mine tend to be - I've had right-first-time design drummed into me, and with
hard ASIC design, you tend not to get a second chance. This presupposes that
the spec was correct, of course ;).
How complex are your software designs relative to your hardware designs?

I get asked this a lot, and I understand why - but my response is always the
same: I break complex things down until they're a collection of simple
no-brainers ;). An example: I did a revision of a rack-based product
involving up to 70-odd intercommunicating processors, in 4 classes, designed
in C and hand-compiled in assembler - with no debug tools at all. All I
could do was turn the system on and see if it worked. Apart from one typo
which positively yelled at me, it did indeed work first time. The product
has since been extensively field-tested (the '98 World Cup TV coverage
depended in part on it working correctly); no bugs were reported or have
surfaced since.

Complexity isn't the issue. I've seen poorly-designed 2-page programs.
Perhaps the most constructive thing one could do to ensure bugfree design is
to take the debug tools away ;).

So what's special about me? Nothing. I just hate debugging. As another
poster said, there will always be bugs that debugging won't find *unless
they're designed out*.

With apologies for thread drift and soapboxing...

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

[steve at fivetrees]

"Ken Lee" <postmaster@noname.com> wrote in message
news:3f13b3b3.8415500@News.CIS.DFN.DE... Also I like to clarify something that's gnawing at me -- debugging is not formal testing. Debugging is a process by which a software engineer employs to determine why his/her code doesn't work. This process usually occurs due to the fact that the developer has erred in translating the design into code. Your customer is really more concerned about the testing that has been performed on the code. Testing is planned activity that follows a pre-determined protocol. It demonstrates the developer's confidence in what he/she has produced by highlighting areas of criticality in the code & then exposing them to vigorous test vectors.

I agree completely. One further point: I can plan (i.e. allow time) for
verification; but I can't plan for debugging. Therefore I prefer the former
;).
So when the customer says "How do I know that the software works!?" Do you say: 1) Trust me - I'm a good programmer or 2) No problem -- here's my Test Plan & Test Report. And I can show you my Test Protocols if you're interested.

I've done both ;). Also, as a consultant, I guarantee my work - if any bugs
do show up, I will fix them - whatever it takes - at no cost to the
customer.

I *much* prefer the formal approach - deliverable/demonstrable test
harnesses that get maintained along with the code, and a structured
bottom-up code walkthrough. However, I've had to learn to "wing it"
sometimes - see my earlier post re software testing with no debug equipment.
As a consequence, and as a survival strategy, I've wound up making my code
as clean and as clear as I can from the start, and actively avoiding bugs
while coding. I don't actually recommend this no-safety-net approach - but
sometimes I've had to perform the impossible in ridiculously short
timeframes knowing that I wouldn't get a second chance.

Clarity and maintainability are now probably my two most important
buzzwords. They're the same thing, really.

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

[Stephen Baynes.]

"John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
message news:f2t6hvocugmvoq4kgfhbsh189o3gb5idee@4ax.com... On Mon, 14 Jul 2003 23:00:27 -0400, "Kevin Kramb" <kekramb.invalid@ra.rockwell.com.invalid> wrote:Is it your experience that hardware designs are normally right the firsttime? It's interesting to compare. If I design a PC board full of parts, and anything's wrong, I have to write an ECO to manufacturing to kluge the board, and that's a very public admission of error. If it's too serious or ugly to kluge, we have to roll the PCB rev - lots of work - re-release the drawings, wait for new boards, build the next iteration, etc. Again, very public and very expensive. So most hardware works the first time, because the economic and social pressures punish sloppy work. Software, on the other hand, can be patched forever without traces peeling off, and the entire process is pretty much done in private. So software, even short routines, are seldom right the first, or even the second, time. Interestingly, FPGA designs often tend to be like software, sloppy and buggy on the first pass, at least by some people. Anybody who designed a hard ASIC this way would be unemployed pronto.

Most ICs seem to take at least a couple of expensive tries to get right and
many take more than that. It may vary between ASICs and full custom designs.

Ever considered how to apply a software patch to a few million TVs? Once it
really goes out you are not going to patch it unless it is something very
serious.

--
Stephen Baynes CEng MBCS
DTG-S&S, Philips Semiconductors Southampton
Tel +44 23 80316431

[Paul Hovnanian P.E.]

Ken Lee wrote:
[snip] Hardware engineers approach development better than Software Engineers because of many factors. Some are: 1. They usually deal with tried and proven components. Most of the issues of verification are to do with interfaces. 2. The test criteria are more tangible or identifiable and so test protocols that provide requirements coverage are more readily able to be formulated. Software engineers are often bogged down by the scope of the test coverage. Limiting the scope of the testing is one way that bugs sneak through. There are financial considerations in test coverage & schedule. 3. There is this approach by the Hardware Engineer to get it "right the first time" because the iteration from design, implementation, test & product takes so long, that another iteration could be too costly.

I'll agree with the above, but there is another factor at work here.
In most cases, hardware engineers have a better understanding of the
overall system requirements. This also extends to those of us who do
embedded s/w development, where there is very tight coupling between
the s/w development and the overall product development.

I've worked in everything from the embedded world to business systems
s/w. The most significant factor affecting the success (or failure) of
the software is whether those that do the analysis, design and testing
understand the domain for which they are developing.

Tools and formal practices are good, but they will fail to produce a
quality product if the developers don't understand the problem to be
solved. Unfortunately, there is a trend in some industries to separate
system, hardware and software development, sometimes separated by many
time zones.


--
Paul Hovnanian mailto:Paul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
Aleph-null bottles of beer on the wall
Aleph-null bottles of beer,
You take one down
and pass it around
Aleph-null bottles of beer on the wall

[Ken Lee]

On Tue, 15 Jul 2003 10:07:08 -0700, "Paul Hovnanian P.E."
<Paul@Hovnanian.com> wrote:
Ken Lee wrote:[snip] Hardware engineers approach development better than Software Engineers because of many factors. Some are: 1. They usually deal with tried and proven components. Most of the issues of verification are to do with interfaces. 2. The test criteria are more tangible or identifiable and so test protocols that provide requirements coverage are more readily able to be formulated. Software engineers are often bogged down by the scope of the test coverage. Limiting the scope of the testing is one way that bugs sneak through. There are financial considerations in test coverage & schedule. 3. There is this approach by the Hardware Engineer to get it "right the first time" because the iteration from design, implementation, test & product takes so long, that another iteration could be too costly.I'll agree with the above, but there is another factor at work here.In most cases, hardware engineers have a better understanding of theoverall system requirements. This also extends to those of us who doembedded s/w development, where there is very tight coupling betweenthe s/w development and the overall product development.
I've worked in everything from the embedded world to business systemss/w. The most significant factor affecting the success (or failure) ofthe software is whether those that do the analysis, design and testingunderstand the domain for which they are developing.Tools and formal practices are good, but they will fail to produce aquality product if the developers don't understand the problem to besolved. Unfortunately, there is a trend in some industries to separatesystem, hardware and software development, sometimes separated by manytime zones.

This is validation -- that is checking whether the proposed solution
is appropriate. There are analysis tools available that help the
engineer address this, but I think you're correct in asserting that
this is a poorly travelled area.

Business is driven by economics and the Capitalism of the Western
World calls for businesses to seek a competitive edge. That's why US
companies employ Indian programmers or have their goods manufactured
in China. Typically a business must view itself as global rather than
provincial, because an outside company could come in and quickly
acquire a reasonable market share. Obviously to capitalise on global
resources & skills, a company needs to acquire the organisational
skills, but it can be done and in fact (as you have pointed out) many
companies are doing it.

I actually see the separation of hardware & software development as a
good thing, mainly because systems are becoming so complex that
finding people who have the right skillset in both hardware & software
is becoming very difficult. Also "software" today is no longer about
"cutting code" which only really consumes about 5% to 10% of
engineering effort. It's about producing a deliverable that will make
the customer happy. So most of the effort goes into analysis, design
and testing. To do this properly you basically need a trained Software
Engineer rather than a hardware engineer who's a weekend programmer
;-)

Ken.
--Paul Hovnanian mailto:Paul@Hovnanian.comnote to spammers: a Washington State resident------------------------------------------------------------------Aleph-null bottles of beer on the wallAleph-null bottles of beer, You take one down and pass it aroundAleph-null bottles of beer on the wall


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

[Paul E. Bennett]

In article <vh6riee2db494e@corp.supernews.com>
kekramb.invalid@ra.rockwell.com.invalid "Kevin Kramb" writes:

[%X]
I'm curious (honestly). Other than your mindset, what do you do differently than the "hack-and-debug" majority. John suggested thorough code reviews. Anything else?

Yes. Very thorough review of the original requirements specification
and contract details in the first place. Until the original specification
is as right as it can be it is pointless designing any part of the
system. From that point it is just a matter of factoring the design so
that you end up with a clearly defined functional modularity and thus
removing the apparent complexity of system by improving your understanding.
Do you actually test your software? If so do you find bugs during testing?

Absolutely yes. Probably more than most. Each individual routine is
tested as soon as it is written (one of the beautiful things about
working with Forth is the lack of need for coding test stubs). That
way if the code does not fulfil the criteria of the requirements it
is easily modified, retested and improved before it is submitted for
inclusion in the intergated product (Edit Code->Compile->Test->Edit
Code->Compile->Test.......).
Is it your experience that hardware designs are normally right the first time?

Mostly yes. Usually when the design problems have been very thoroughly
understood and the solution becomes very apparent. It is usually better
to think a little longer rather than go through making several versions
of the PCB or chip (costs too much money that way).
How complex are your software designs relative to your hardware designs?

Mine range from equal to the software doing very highly complex things.
However, I never feel that my software is, itself, highly complex.

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

[Rob Judd]

Stephen Baynes. wrote: "John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in message news:f2t6hvocugmvoq4kgfhbsh189o3gb5idee@4ax.com... On Mon, 14 Jul 2003 23:00:27 -0400, "Kevin Kramb" <kekramb.invalid@ra.rockwell.com.invalid> wrote:Is it your experience that hardware designs are normally right the firsttime? It's interesting to compare. If I design a PC board full of parts, and anything's wrong, I have to write an ECO to manufacturing to kluge the board, and that's a very public admission of error. If it's too serious or ugly to kluge, we have to roll the PCB rev - lots of work - re-release the drawings, wait for new boards, build the next iteration, etc. Again, very public and very expensive. So most hardware works the first time, because the economic and social pressures punish sloppy work. Software, on the other hand, can be patched forever without traces peeling off, and the entire process is pretty much done in private. So software, even short routines, are seldom right the first, or even the second, time. Interestingly, FPGA designs often tend to be like software, sloppy and buggy on the first pass, at least by some people. Anybody who designed a hard ASIC this way would be unemployed pronto. Most ICs seem to take at least a couple of expensive tries to get right and many take more than that. It may vary between ASICs and full custom designs. Ever considered how to apply a software patch to a few million TVs? Once it really goes out you are not going to patch it unless it is something very serious.

It does happen though. The first software version for the new Teac DVB-T
STB recently released in Australia sucked so badly that users demanded
an upgrade, and got it. You couldn't skip unused channels, and settings
didn't save correctly.

Rob

[Ken Lee]

On Tue, 15 Jul 2003 19:59:16 -0700, "Paul Hovnanian P.E."
<Paul@Hovnanian.com> wrote:
Ken Lee wrote: On Tue, 15 Jul 2003 10:07:08 -0700, "Paul Hovnanian P.E." <Paul@Hovnanian.com> wrote:
<snip>I've worked in everything from the embedded world to business systemss/w. The most significant factor affecting the success (or failure) ofthe software is whether those that do the analysis, design and testingunderstand the domain for which they are developing.Tools and formal practices are good, but they will fail to produce aquality product if the developers don't understand the problem to besolved. Unfortunately, there is a trend in some industries to separatesystem, hardware and software development, sometimes separated by manytime zones. This is validation -- that is checking whether the proposed solution is appropriate. There are analysis tools available that help the engineer address this, but I think you're correct in asserting that this is a poorly travelled area.Validation, particularly automated validation, works best at the codelevel. If the requirements are messed up, that happens back inanalysis. Tools are still pretty weak at this point.

When I say "validation", I actually did mean validation and not
verification. The process you describe is one of verification. In
recent years the use of the term "validation" has become synonymous
with that of "verification" -- even the FDA has done this. However by
definition, validation is not verification.
Business is driven by economics and the Capitalism of the Western World calls for businesses to seek a competitive edge. That's why US companies employ Indian programmers or have their goods manufactured in China. Typically a business must view itself as global rather than provincial, because an outside company could come in and quickly acquire a reasonable market share. Obviously to capitalise on global resources & skills, a company needs to acquire the organisational skills, but it can be done and in fact (as you have pointed out) many companies are doing it. I actually see the separation of hardware & software development as a good thing, mainly because systems are becoming so complex that finding people who have the right skillset in both hardware & software is becoming very difficult. Also "software" today is no longer about "cutting code" which only really consumes about 5% to 10% of engineering effort. It's about producing a deliverable that will make the customer happy. So most of the effort goes into analysis, design and testing. To do this properly you basically need a trained Software Engineer rather than a hardware engineer who's a weekend programmerYou're assuming that the analysis only starts after thehardware/softwarefunctional allocation is done. In practice (particularly with embeddedsystems) most of the requirements collection and analysis is done longbefore the system architecture is established. This is the systemsengineering.

Not at all -- I'm assuming that there is a Systems Engineering phase.
Also I'll dispute that "in practice" that these requirements are NOT
"done long before the system architecture is established". Why do I
say that -- well Systems Engineering is not done in a lock-up in
isolation. For a good System Spec to be produced it involves the
collaboration of all stakeholders. The Systems Engineer acts as the
mediator of the Domain Experts. He/she looks at the marketing
requirements and with the inputs from the hardware, mechanical &
software representatives (etc) produces a System Spec which would have
a manageable development risk. What do the engineers do during this
time? Well they're not sitting at their desks twiddling their thumbs
or playing solitaire. They may be:
o ringing up vendors for parts & availability
o preparing & running prototypes
o researching development tools
o compiling a list of prospective micros to use
o preparing pseudo Bills of Materials for costing

I do agree that a good System Spec should be produced before "real"
development starts.

It should be noted that engineers are lazy sods (me included). To
mitigate against development risk, they typically adopt a modus
operandi or pattern of behaviour that has this tendency. This
includes:
o Adopting tried & proven methods
o Utilising domain experts
o Using mature architectures
o Using mature components
o Utilising a previous projects artefacts such as documents & code
o Working within a reasonable comfort zone, that is, working with
equipment that you know how to use, working with people you know, etc.

Now reading this you may think that engineers are pretty boring people
(ever been to a party with one ;-) ), but obviously they do venture
out and try new things. The point I'm getting to here, that is, it may
be that the new project is similar to the previous one. This is the
case for a company that is producing a limited product range. So the
System Spec for the new product may be reasonably predictable.

Contractors are probably the laziest sods of all ;-) --- have you
ever notice how they re-use aspects of their previous projects.
However this usually isn't reflected in their invoice. (For the
record, I have been a contractor :-) )
Once this is done, the hardware and software specialists go to work. Theproblem here is that with advances in tools like UML (and a few moreadvanced,proprietary ones), software design is being automated much more rapidlythanhardware design. Shipping the s/w requirements out will be pointlesswhen itsjust a matter of feeding them into a box and out pops the code.

The above is great for "design" and I'm all for it, but the analysis
of say, the Software system, still has to be done by an entity with a
brain. Sure there are analysis tools which help greatly. I've used
iLogix's Rhapsody and can appreciate the benefits of such technology.

Ken.
Paul Hovnanian mailto:Paul@Hovnanian.comnote to spammers: a Washington State resident------------------------------------------------------------------Fast wine, loose cars, old women.


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

[Koushik Banerjee]

"Rob Judd" <judd@ob-wan.com> wrote in message
news:3F14DE78.CD211404@ob-wan.com...
: Stephen Baynes. wrote:
: >
: > "John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
: > message news:f2t6hvocugmvoq4kgfhbsh189o3gb5idee@4ax.com...
: > > On Mon, 14 Jul 2003 23:00:27 -0400, "Kevin Kramb"
: > > <kekramb.invalid@ra.rockwell.com.invalid> wrote:
: > > >
: > > >Is it your experience that hardware designs are normally right the
first
: > > >time?
: > >
: > >
: > > It's interesting to compare. If I design a PC board full of parts, and
: > > anything's wrong, I have to write an ECO to manufacturing to kluge the
: > > board, and that's a very public admission of error. If it's too
: > > serious or ugly to kluge, we have to roll the PCB rev - lots of work -
: > > re-release the drawings, wait for new boards, build the next
: > > iteration, etc. Again, very public and very expensive. So most
: > > hardware works the first time, because the economic and social
: > > pressures punish sloppy work.
: > >
: > > Software, on the other hand, can be patched forever without traces
: > > peeling off, and the entire process is pretty much done in private. So
: > > software, even short routines, are seldom right the first, or even the
: > > second, time. Interestingly, FPGA designs often tend to be like
: > > software, sloppy and buggy on the first pass, at least by some people.
: > > Anybody who designed a hard ASIC this way would be unemployed pronto.
: >
: > Most ICs seem to take at least a couple of expensive tries to get right
and
: > many take more than that. It may vary between ASICs and full custom
designs.
: >
: > Ever considered how to apply a software patch to a few million TVs? Once
it
: > really goes out you are not going to patch it unless it is something
very
: > serious.
:
: It does happen though. The first software version for the new Teac DVB-T
: STB recently released in Australia sucked so badly that users demanded
: an upgrade, and got it. You couldn't skip unused channels, and settings
: didn't save correctly.
:
: Rob

Hardware *bugs* are always more costly upfront because of the loss of
material(say boards and other inputs) than software. Few years back Philips
(one of my previous employer) had to move the DVD player out of the
AsiaPacific market because it wouldnot play pirated VCDs, reason :
developers coded only to the specification, which did not include the
pirated format, but there were competetive products playing, so we needed to
do the same to stay in the market. No one to blame but at the end Customer
rules.

[Andrew Paule]

Koushik:

yes, many embedded systems can be designed to be easily field
upgradable - you just need a fixed bootstrap routing and enough
hardware that works to communicate. FPGA's may be easily fixed in the
same manner, if one loads them from a piece that can be field upgradable
- i.e. - load the thing from flash via a micro, and your VCS can be
implemented in all of your software. ASIC and mask ROM people come from
a different world, because the mask charges are outrageous, and you
can't fix burned silicon in the field, but for volume production, it's
the only way to go.

Andrew

Koushik Banerjee wrote:
"Rob Judd" <judd@ob-wan.com> wrote in messagenews:3F14DE78.CD211404@ob-wan.com...: Stephen Baynes. wrote:: >: > "John Larkin" <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in: > message news:f2t6hvocugmvoq4kgfhbsh189o3gb5idee@4ax.com...: > > On Mon, 14 Jul 2003 23:00:27 -0400, "Kevin Kramb": > > <kekramb.invalid@ra.rockwell.com.invalid> wrote:: > > >: > > >Is it your experience that hardware designs are normally right thefirst: > > >time?: > >: > >: > > It's interesting to compare. If I design a PC board full of parts, and: > > anything's wrong, I have to write an ECO to manufacturing to kluge the: > > board, and that's a very public admission of error. If it's too: > > serious or ugly to kluge, we have to roll the PCB rev - lots of work -: > > re-release the drawings, wait for new boards, build the next: > > iteration, etc. Again, very public and very expensive. So most: > > hardware works the first time, because the economic and social: > > pressures punish sloppy work.: > >: > > Software, on the other hand, can be patched forever without traces: > > peeling off, and the entire process is pretty much done in private. So: > > software, even short routines, are seldom right the first, or even the: > > second, time. Interestingly, FPGA designs often tend to be like: > > software, sloppy and buggy on the first pass, at least by some people.: > > Anybody who designed a hard ASIC this way would be unemployed pronto.: >: > Most ICs seem to take at least a couple of expensive tries to get rightand: > many take more than that. It may vary between ASICs and full customdesigns.: >: > Ever considered how to apply a software patch to a few million TVs? Onceit: > really goes out you are not going to patch it unless it is somethingvery: > serious.:: It does happen though. The first software version for the new Teac DVB-T: STB recently released in Australia sucked so badly that users demanded: an upgrade, and got it. You couldn't skip unused channels, and settings: didn't save correctly.:: RobHardware *bugs* are always more costly upfront because of the loss ofmaterial(say boards and other inputs) than software. Few years back Philips(one of my previous employer) had to move the DVD player out of theAsiaPacific market because it wouldnot play pirated VCDs, reason :developers coded only to the specification, which did not include thepirated format, but there were competetive products playing, so we needed todo the same to stay in the market. No one to blame but at the end Customerrules.

[Marc Randolph]

"Stephen Baynes." <stephen.baynes@soton.sc.philips.com> wrote in message news:<3f13e7ce$0$11378$4d4eb98e@read-nat.news.uk.uu.net>... Most ICs seem to take at least a couple of expensive tries to get right and many take more than that. It may vary between ASICs and full custom designs.

A good verification team would eliminate the "couple of expensive
tries to get it right." Our ASIC group has put out three ASICs that
were first pass successes.

Of course, we're talking about pretty big designs for non-consumer
products - so development time is on the order of many quarters (4 or
5), not months as Philips would be doing. But that still doesn't
excuse a good verification team.

Marc

[Kenneth Porter]

John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in
news:f2t6hvocugmvoq4kgfhbsh189o3gb5idee@4ax.com:
Software, on the other hand, can be patched forever without traces peeling off, and the entire process is pretty much done in private.

Open Source has the virtue of not being done in private. Real authors leave
their name on their work, for better or for worse. They participate in the
support groups for their work, and their email is public.

Imagine if the creator of "Clippy" (the Office paperclip character) were so
exposed! ;)

--
Kenneth Porter
http://www.sewingwitch.com/ken/

[Paul Hovnanian P.E.]

Kenneth Porter wrote: John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote in news:f2t6hvocugmvoq4kgfhbsh189o3gb5idee@4ax.com: Software, on the other hand, can be patched forever without traces peeling off, and the entire process is pretty much done in private. Open Source has the virtue of not being done in private. Real authors leave their name on their work, for better or for worse. They participate in the support groups for their work, and their email is public. Imagine if the creator of "Clippy" (the Office paperclip character) were so exposed! ;)

Or worse yet, MS Bob!

--
Paul Hovnanian mailto:Paul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
If your only tool is a hammer then every problem looks like a thumb.

[John Larkin]

On Mon, 04 Aug 2003 23:10:06 GMT, Kenneth Porter
<ken.blacklist@sewingwitch.com> wrote:
John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> wrote innews:f2t6hvocugmvoq4kgfhbsh189o3gb5idee@4ax.com: Software, on the other hand, can be patched forever without traces peeling off, and the entire process is pretty much done in private.Open Source has the virtue of not being done in private. Real authors leavetheir name on their work, for better or for worse. They participate in thesupport groups for their work, and their email is public.

Extreme Programming is done, in one version, by pairs of programmers.
Again, better code gets done whan it's done in public. It's
interesting that a 2:1 increase in manpower is justified by the better
quality.
Imagine if the creator of "Clippy" (the Office paperclip character) were soexposed! ;)

Is lynching legal in Washington State?

John

whose wife thinks Clippy is "adorable."

[Hans-Bernhard Broeker]

In comp.arch.embedded John Larkin <jjlarkin@highsniplandthistechpleasenology.com> wrote:
[...]
Extreme Programming is done, in one version, by pairs of programmers. Again, better code gets done whan it's done in public. It's interesting that a 2:1 increase in manpower is justified by the better quality.

I don't think you're getting that thing about the manpower increase
right. Just because "Extreme Programming" has two people working
together, at the same screen, all the time, doesn't imply one of those
two would have been unemployed otherwise. The key to XP is not how
many people work on the code, but how they *do* that work.

It's more like this: XP uses half as many development machines
compared to other methods, because two team members always share one
box, at all times. I.e. it's not a 2:1 increase in manpower; if at
all, it's a 2:1 *decrease* in machine power.

The only real drawback is that you can't use the typical cubicle
office space pattern easily --- XP teams need more space per cubicle,
and they'll be talking all the time, so you need better sound
isolation between cubicles. In other words: you need actual offices,
not cubicles.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.