Home > Archive > Extreme Programming > January 2005 > Just a Software Problem
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Just a Software Problem
|
|
| Isaac Gouy 2004-11-17, 3:58 pm |
| "The most important things the shuttle group does -- carefully
planning the software in advance, writing no code until the design is
complete, making no changes without supporting blueprints, keeping a
completely accurate record of the code -- are not expensive. The
process isn't even rocket science. Its standard practice in almost
every engineering discipline except software engineering."
http://www.fastcompany.com/online/06/writestuff.html
Y'all love this kind of article ;-)
| |
| Laurent Bossavit 2004-11-17, 3:58 pm |
| Isaac,
> Y'all love this kind of article ;-)
This caught my eye:
It's strictly an 8-to-5 kind of place -- there are late nights, but
they're the exception. The programmers are intense, but low-key.
This too:
For one thing, 12 of the 22 people in the room are women, many of them
senior managers or senior technical staff.
And this as well:
What's going on here is the kind of nuts-and-bolts work that defines
the drive for group perfection -- a drive that is aggressively
intolerant of ego-driven hotshots. In the shuttle group's culture,
there are no superstar programmers. The whole approach to developing
software is intentionally designed not to rely on any particular
person.
And, I'm sorry but I just have to go on, this:
"We never let anything go," says Patti Thornton, a senior manager. "We
do just the opposite: we let everything bother us."
I'm more than willing to be lectured on about XP and its shortcomings by
anyone who actually works that way. If she happens to have any interest
in lecturing, which I somehow doubt. :)
Laurent
| |
| stedetro@yahoo.com 2004-11-17, 3:58 pm |
| Life and death software .... the one place XP might not make it!
The thing that struck me was the believe that the code was "ERROR
FREE."
How do you truly know software is error free? Is there something
scientific that they use to determine this?
Stede
| |
| John Roth 2004-11-17, 8:56 pm |
|
<stedetro@yahoo.com> wrote in message
news:1100720352.299121.227400@c13g2000cwb.googlegroups.com...
> Life and death software .... the one place XP might not make it!
>
> The thing that struck me was the believe that the code was "ERROR
> FREE."
>
> How do you truly know software is error free? Is there something
> scientific that they use to determine this?
Look up Assured Quality. That's a series of techniques
that is used to measure the defect density remaining in
the code.
One of the techniques is defect injection: you deliberately
inject defects and then see how many of them your chosen
defect detection and removal technique finds. In XP, that
would be the combination of unit and acceptance tests.
In other methodologies, that would be a combination of
classical testing and code inspections.
John Roth
>
> Stede
>
| |
| Stede Troisi 2004-11-18, 8:57 am |
| Thanks John. I will look up Assured Quality. I am shocked. I didn't know you
could really determine the number of bugs. This is  !
Thanks again,
Stede
"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:10pnjg3ogn4t204@news.supernews.com...
>
> <stedetro@yahoo.com> wrote in message
> news:1100720352.299121.227400@c13g2000cwb.googlegroups.com...
>
> Look up Assured Quality. That's a series of techniques
> that is used to measure the defect density remaining in
> the code.
>
> One of the techniques is defect injection: you deliberately
> inject defects and then see how many of them your chosen
> defect detection and removal technique finds. In XP, that
> would be the combination of unit and acceptance tests.
> In other methodologies, that would be a combination of
> classical testing and code inspections.
>
> John Roth
>
| |
| Jeff Grigg 2004-11-19, 3:56 am |
| igouy@yahoo.com (Isaac Gouy) wrote...
> "The most important things the shuttle group does -- carefully
> planning the software in advance, writing no code until the design is
> complete, making no changes without supporting blueprints, keeping a
> completely accurate record of the code -- are not expensive. [...]"
>
> http://www.fastcompany.com/online/06/writestuff.html
Hmmm...
(1) Their approach strikes me as something like the Clean Room
approach.
http://www.c2.com/cgi/wiki?CleanRoomMethodology
(2) RE: "not expensive"...
"[...], a change that involves just 1.5% of the program, or 6,366
lines of code. The specs for that one change run 2,500 pages, a volume
thicker than a phone book. The specs for the current program fill 30
volumes and run 40,000 pages."
Hmmm...
2,500 of painstakingly reviewed specs for 6,366 lines of code.
"thicker than a phone book" is how they describe it.
"30 volumes and run 40,000 pages."
Someone had to pay to write, review, correct, polish, verify, etc on
those 40,000 pages of painstakingly detailed and specific specs. That
doesn't come for free.
So I remain somewhat skeptical of the offhand "not expensive" comment.
For that application, the expense is probably worth it. But to
describe it as "not expensive" or to imply that all business projects
should take the same approach don't seem to be well-supported
propositions.
| |
| Jeff Grigg 2004-11-19, 3:56 am |
| igouy@yahoo.com (Isaac Gouy) wrote...
> "[...] -- are not expensive. [...]"
> http://www.fastcompany.com/online/06/writestuff.html
A "P.S." on the cost issue:
"[...] the groups $35 million per year budget is a trivial slice of
the NASA pie, but on a dollars-per-line basis, it makes the group
among the nation's most expensive software organizations."
| |
| Robert C. Martin 2004-11-23, 8:56 pm |
| On 17 Nov 2004 10:07:46 -0800, igouy@yahoo.com (Isaac Gouy) wrote:
>"The most important things the shuttle group does -- carefully
>planning the software in advance, writing no code until the design is
>complete, making no changes without supporting blueprints, keeping a
>completely accurate record of the code -- are not expensive. The
>process isn't even rocket science. Its standard practice in almost
>every engineering discipline except software engineering."
In iterations that are six w s long.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
| Robert C. Martin 2004-11-23, 8:56 pm |
| On 17 Nov 2004 11:39:12 -0800, "stedetro@yahoo.com"
<stedetro@yahoo.com> wrote:
>Life and death software .... the one place XP might not make it!
I'd rather fly on a plane whose software was done the XP way.
The shuttle is an interesting case. They were mandated to use the
2167 (waterfall) process, and refused. Instead they used an iterative
approach, building the software in 6 w long iterations.
An XP project typically uses one-two w iterations. Those
iterations start with an *intense* effort to nail down the
requirements in hideous detail by expressing them as automated
acceptance tests. The requirements within the iteration are frozen
for the duration of the iteration. The code is tested and tested and
tested again. The design is debated and refined throughout.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
| igouy@yahoo.com 2005-01-18, 3:56 am |
| > In iterations that are six ws long.
What's the source for that factoid?
| |
| Isaac Gouy 2005-01-18, 3:56 am |
| Robert C. Martin wrote:
> The shuttle is an interesting case. They were mandated to use
> the 2167 (waterfall) process, and refused. Instead they used an
> iterative approach, building the software in 6 w long iterations.
Do you intend to say development took place in 6-w time-boxes?
The article "They Write the Right Stuff" is dated Dec 1996/Jan 1997.
Maybe the comments on DoD 2167 (wasn't 2167 replaced in 1996?) refer to
the early years of software development for the Shuttle?
| |
| Isaac Gouy 2005-01-21, 3:59 am |
| Robert C. Martin wrote:
> The shuttle is an interesting case. They were mandated to use the
> 2167 (waterfall) process, and refused. Instead they used an
> iterative approach, building the software in 6 w long iterations.
I've been unable to confirm these "facts".
Could there have been some confusion reading Craig Larman's "Agile and
Iterative Development: A Manager's Guide"?
>From page 84,
"The Shuttle project exhibited classic IID practices: timeboxed
iterations in the eight-w range, feedback driven refinement of
specifications, and so forth."
and from page 85, this is *not* about the Shuttle project
"Another early story... the project was ostensibly meant to fit within
DoD single pass waterfall standards, with testing and integration in
the last phase."
| |
|
|
|
|
| Robert C. Martin 2005-01-24, 3:56 am |
| On 21 Jan 2005 10:17:06 -0800, "Isaac Gouy" <igouy@yahoo.com> wrote:
>
>
>And where does this factoid come from:
>"They were mandated to use the 2167 (waterfall) process, and refused."
Sorry, that's from my own understanding that 2167 was mandated for any
government project. If I remember correctly, any government project
had to use 2167, or make a case for why it couldn't/shouldn't be used.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
| Isaac Gouy 2005-01-24, 3:57 am |
| > Sorry, that's from my own understanding that 2167 was mandated for
any
> government project. If I remember correctly, any government project
> had to use 2167, or make a case for why it couldn't/shouldn't be
used.
My ignorance of 2167 is fairly complete.
afaict DOD-STD-2167 was released in June 1985, and DOD-STD-2167A was
cancelled in 1994.
The article "They Write the Right Stuff" is dated Dec 1996/Jan 1997,
and seems to be a description contemporaneous software development for
the shuttle.
afaict work on the shuttle software began back in 1975, and the
specific remarks made in Craig Larman's book (and in "Iterative and
Incremental Development: A Brief History"
http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf) about PASS
iterations averaging around 8 ws are for the period 1977-1980.
afaict DoD 2167 didn't exist in 1980
> The shuttle is an interesting case. They were mandated to use the
> 2167 (waterfall) process, and refused. Instead they used an iterative
> approach, building the software in 6 w long iterations.
My understanding from these comments was that DOD-STD-2167 was mandated
for the shuttle project; DOD-STD-2167 was actively rejected, and
instead of using DOD-STD-2167 software was developed in 6 w long
iterations.
Now it seems like the comments were perhaps based on assumption rather
than fact?
| |
| Robert C. Martin 2005-01-24, 8:56 pm |
| On 23 Jan 2005 23:24:01 -0800, "Isaac Gouy" <igouy@yahoo.com> wrote:
>any
>used.
>
>My ignorance of 2167 is fairly complete.
>afaict DOD-STD-2167 was released in June 1985, and DOD-STD-2167A was
>cancelled in 1994.
>
>The article "They Write the Right Stuff" is dated Dec 1996/Jan 1997,
>and seems to be a description contemporaneous software development for
>the shuttle.
>
>afaict work on the shuttle software began back in 1975, and the
>specific remarks made in Craig Larman's book (and in "Iterative and
>Incremental Development: A Brief History"
>http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf) about PASS
>iterations averaging around 8 ws are for the period 1977-1980.
>
>afaict DoD 2167 didn't exist in 1980
>
>
>
>My understanding from these comments was that DOD-STD-2167 was mandated
>for the shuttle project; DOD-STD-2167 was actively rejected, and
>instead of using DOD-STD-2167 software was developed in 6 w long
>iterations.
>
>Now it seems like the comments were perhaps based on assumption rather
>than fact?
<deep_inhale>
The comments were based on the snippet from Craig's book. I
mistakenly typed 6 ws instead of 8 ws, and I assumed that 2167
was mandated because of the use of the term "ideal" software process
which I took to mean 2167 because "figure 3" shows a phased waterfall
approach.
<exhale_whew!>
So, I'll rephrase my original statement from:
http://groups-beta.google.com/group...b46fa0b4351889d
On 17 Nov 2004 11:39:12 -0800, "stede...@yahoo.com"
<stede...@yahoo.com> wrote:
>Life and death software .... the one place XP might not make it!
I'd rather fly on a plane whose software was done the XP way.
The shuttle is an interesting case. They considered using the
waterfall process, but rejected it. Instead they used an iterative
approach, building the software in 8 w long iterations.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
| |
| Isaac Gouy 2005-01-25, 8:56 am |
| > <deep_inhale>
> The comments were based on the snippet from Craig's book. I
> mistakenly typed 6 ws instead of 8 ws, and I assumed that 2167
> was mandated because of the use of the term "ideal" software process
> which I took to mean 2167 because "figure 3" shows a phased waterfall
> approach.
> <exhale_whew!>
Thank you! I'm pleased we've sorted that out :-)
Seems like they wrote Figure 3 but meant Figure 2:
"the detailed definition of all requirements could not be completed in
time to support a proven software design, implementation, and
verification development cycle (Figure 2) due to the ongoing vehicle
engineering analysis work."
page 915, Madden and Rone
-snip-
> The shuttle is an interesting case. They considered using the
> waterfall process, but rejected it. Instead they used an iterative
> approach, building the software in 8 w long iterations.
Exactly 8 ws, or 30-odd different lengths which over 3 years
average-out to around 8 ws :-)
The shuttle really is an interesting case-study. As we might expect,
there's a lot more to the 30 year project than can be shown in a couple
of paragraphs of Mr Larman's book.
I've been unable to learn about the development of the ALT software in
1975 & 1976 (ALT was Space Shuttle Approach and Landings Tests
http://en.wikipedia.org/wiki/Space_Shuttle_Enterprise). The ALT
software formed the architectural basis for STS-1 (STS-1 was
http://en.wikipedia.org/wiki/Space_Shuttle_Columbia).
The 1980 articles on STS-1
1.5MB http://klabs.org/DEI/Processor/shuttle/madden_rone.pdf
5MB
http://klabs.org/DEI/Processor/shut...uter_system.pdf
1.2MB http://klabs.org/DEI/Processor/shuttle/p926-carlow.pdf
"Journey to a mature software process" discusses the changes in
development process that have taken place in the Space Shuttle Onboard
Software project from the '70s to the '90s.
IBM Systems Journal 33(1) 1994
1.7MB http://www.research.ibm.com/journal/sj/331/billings.pdf
Quoting from these rich articles is inevitably partial and selective,
this is from the 1994 conclusions: "Houston demonstrated that
disciplined use of program management, team inspections, independent
testing, incremental development, requirements management, and
measurement programs, result in predictable product quality delivered
on time and within budget." p60
| |
| Isaac Gouy 2005-01-26, 3:58 am |
| -snip-
> So I remain somewhat skeptical of the offhand "not expensive"
comment.
>
> For that application, the expense is probably worth it. But to
> describe it as "not expensive" or to imply that all business projects
> should take the same approach don't seem to be well-supported
> propositions.
Agreed.
"It is estimated that the cost of a single line of mission-critical
code at the level of ultra-high reliability required has reached $350.
Lines of code that are non-mission critical cost about $35 each...
the Project would not change the architecture of the process were they
to begin building non-human rated software with lower reliability
requirements. The cost of such a process would decline because the
amount of verification activity would be reduced."
p14, A Case History of the Space Shuttle Onboard Systems Project, 1994
http://www.sematech.org/docubase/document/2551atr.pdf
|
|
|
|
|
8 w