Extreme Programming - shine a light on LAMPS

Author

shine a light on LAMPS

Isaac Gouy

2005-01-27, 8:57 pm

LAMPS 'A four-year 200 person-year effort involving millions of lines
of code, it was evolutionarily delivered in 45 timeboxed iterations
(one month per iteration). This is the earliest project example I found
where the length of iteration was in the range commonly recommended by
today's IID methods...
It is described by the noted 1970s thought leader Harlan Mills in
"Principles of Software Engineering" IBM Systems Journal Vol 19(4)
1980.'

pages 83-84, Craig Larman, "Agile and Iterative Development: A
Manager's
Guide" and similar comments in "Iterative and Incremental Development:
A Brief History" http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf

Happily, the IBM Systems Journal is available online, here's the index
page:
http://domino.research.ibm.com/tchj...xpand=26.4#26.4

Unhappily, all that Harlan Mills writes about LAMPS is:
"LAMPS software was a four-year project of over 200 person-years of
effort, developing over three million and integrating over seven
million words of program and data for eight different processors
distributed between a helicopter and a ship, in 45 incremental
deliveries. Every one of those deliveries was on time and under
budget." p415

Harlan Mills *never* mentions "timeboxed iterations (one month per
iteration)" in the cited article.

Can anyone shine a light on why Mr Larman added this information?
(Maybe Mr Larman had another source which wasn't cited?)

John Roth

2005-01-28, 3:57 am

"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:1106868643.035674.9200@c13g2000cwb.googlegroups.com...
> LAMPS 'A four-year 200 person-year effort involving millions of lines
> of code, it was evolutionarily delivered in 45 timeboxed iterations
> (one month per iteration). This is the earliest project example I found
> where the length of iteration was in the range commonly recommended by
> today's IID methods...
> It is described by the noted 1970s thought leader Harlan Mills in
> "Principles of Software Engineering" IBM Systems Journal Vol 19(4)
> 1980.'
>
> pages 83-84, Craig Larman, "Agile and Iterative Development: A
> Manager's
> Guide" and similar comments in "Iterative and Incremental Development:
> A Brief History" http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf
>
>
> Happily, the IBM Systems Journal is available online, here's the index
> page:
> http://domino.research.ibm.com/tchj...xpand=26.4#26.4
>
> Unhappily, all that Harlan Mills writes about LAMPS is:
> "LAMPS software was a four-year project of over 200 person-years of
> effort, developing over three million and integrating over seven
> million words of program and data for eight different processors
> distributed between a helicopter and a ship, in 45 incremental
> deliveries. Every one of those deliveries was on time and under
> budget." p415
>
> Harlan Mills *never* mentions "timeboxed iterations (one month per
> iteration)" in the cited article.
>
> Can anyone shine a light on why Mr Larman added this information?
> (Maybe Mr Larman had another source which wasn't cited?)

Four years is 48 months; i.e. the average iteration is somewhat over
a month. Given that 45 scheduled deliveries in a four year project
at that time is unusual enough to be jaw-dropping astonishing,
I don't find the notion that they were planned as one month
time boxes at all unlikely. On the other hand, I can very easily
see overlapping development of components so that the notion
of time boxes wouldn't apply across the entire project.

Another source would be helpful.

John Roth
>

Phlip

2005-01-28, 3:57 am

Isaac Gouy wrote:

> Happily, the IBM Systems Journal is available online, here's the index
> page:
>
http://domino.research.ibm.com/tchj...xpand=26.4#26.4
>
> Unhappily, all that Harlan Mills writes about LAMPS is:
> "LAMPS software was a four-year project of over 200 person-years of
> effort, developing over three million and integrating over seven
> million words of program and data for eight different processors
> distributed between a helicopter and a ship, in 45 incremental
> deliveries. Every one of those deliveries was on time and under
> budget." p415
>
> Harlan Mills *never* mentions "timeboxed iterations (one month per
> iteration)" in the cited article.

OH MY GAWD, Isaac you're RIGHT!

Strict XP/Scrum/IID etc says we have to get all the iterations EXACTLY THE
SAME LENGTH (or the metrics don't work).

But the LAMPS project could have used UNEQUAL iteration lengths!! They could
have followed calendar months, introducing extra days and such into each
iteration to match the "thirty days has November April June and No Wonder"
fudge factor! They could have simply delivered whenever they finished a
batch of features, and the "45 deliveries" over "four years" could simply be
the total of ALL KINDS of iteration lengths!!!

My FAITH in Larman's book, and in fact all of the incremental and iterative
software engineering movement(s) has been SHAKEN!!!

(Besides, I thought the entire Linux apache MySQL Perl Server architecture
was created over many, many more years, engineers and iterations...)

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

Isaac Gouy

2005-01-28, 3:57 am

> Four years is 48 months; i.e. the average iteration is somewhat over
> a month. Given that 45 scheduled deliveries in a four year project
> at that time is unusual enough to be jaw-dropping astonishing,
> I don't find the notion that they were planned as one month
> time boxes at all unlikely. On the other hand, I can very easily
> see overlapping development of components so that the notion
> of time boxes wouldn't apply across the entire project.
>
> Another source would be helpful.

Of course! The 17 incremental deliveries for STS-1 over a 31 month
period became 'timeboxed iterations in the eight-w

range", I should
have realized Mr Larman might have made that assumption again.

Overlapping concurrent development, with regular deliveries; or 36
months before the first delivery then drip, drip, drip; or ... ;(or
development in one-month timeboxes).
Yes, a source would be preferable to guesswork.

Laurent Bossavit

2005-01-28, 8:57 am

Isaac,

> Harlan Mills *never* mentions "timeboxed iterations (one month per
> iteration)" in the cited article.
> Can anyone shine a light on why Mr Larman added this information?
> (Maybe Mr Larman had another source which wasn't cited?)

The LAMPS project is apparently discussed (secondary source) in Tom
Gilb's 1988 "Principles of Software Engineering Management", p. 104; I
don't own the book myself, someone who does might be able to check what
language Gilb uses.

Laurent

Laurent Bossavit

2005-01-28, 8:57 am

Isaac,

> Of course! The 17 incremental deliveries for STS-1 over a 31 month
> period became 'timeboxed iterations in the eight-w

range", I should
> have realized Mr Larman might have made that assumption again.

I would be prudent with the hypothesis that Larman was careless in
inferring whether a given project was using timeboxed, constant-length
iterations vs. some other model; an earlier paragraph of the "History of
Iterative" article states:

"Yet, some varying and common traits are noted, such as differences in
the lifecycle details. For example, the length of iterations, and
whether or not they were timeboxed."

Of the TRW project, for instance, Larman notes: "The iterations were not
strictly timeboxed, and there was significant up-front specifications
work."

In "Evo: The Evolutionary Programs Managers Handbook", Gilb refers to
the LAMPS project and notes "cycles were about monthly for 4 years".
Maybe that's where Larman got constant length of one month for LAMPS.

Unlike Larman, Gilb is clear on the difference between iterative
*delivery* and iterative *development*, and cites LAMPS as an example of
the former.

Perhaps Larman is deducing "timeboxed" from "Every one of those
deliveries was on time". Isn't that what "timeboxed" means ? :)

Laurent

Isaac Gouy

2005-01-28, 8:57 am

> The LAMPS project is apparently discussed (secondary source) in Tom
> Gilb's 1988 "Principles of Software Engineering Management", p. 104;

"In IBM Systems Journal (No. 4, 1980) Harlan Mills, IBM's chief
software guru, reports extensive experiences with evolutionary
delivery. His model is closer to what we are recommending in this book,
although it lacks many of the same elements thas SDC lacked. It does
seem to work on the basis of some sort of handover to users.
Here are some quotations which characterize the IBM Federal Systems
Division experience:
'Management has learned to expect on-time, within-budget deliveries.
'LAMPS... a 4-year... 200 person-years' (project was delivered) 'in 45
incremental deliveries. Every one of those deliveries was on time and
under budget.'"

Isaac Gouy

2005-01-28, 3:59 pm

> I would be prudent with the hypothesis that Larman was careless in
> inferring whether a given project was using timeboxed,
> constant-length iterations vs. some other model
-snip-

True, sorry, my frustration is showing.

Figure 7.10 (Principles of Software Engineering Management, p105) on
the page opposite the tiny LAMPS extract, is redrawn from another of
"The management of software engineering" articles Part 5, R.E.Quinnan)
- the figure description begins: "The IBM FSD evolutionary cycle. Every
month the status of the cost and schedule is measured..."

In the original, there's no text with the "Design-to-cost" figure, this
is from the main text:
"Expenditures are not merely projected on a month-by-month basis; they
are related to specific work components and completion dates." p472 IBM
Syst J 19(4) 1980

"Design is an iterative process in which each design level is a
refinement of the previous level. At each stage, design and cost
alternatives are examined. Those that best satisfy the project
objectives are prepared for review and selection by the project
sponsor. If no alternative fits the cost target, several courses of
action are available. The most common one is to go back to the
designers and ask for a less costly, and perhaps less attractive,
design. If the target has been missed by a large amount - and cost is
critical - redesign may not produce an answer. In this case, the
sponsor has to consider giving up some of the planned capability of the
system. Otherwise, he has to recognise that the capability cannot be
acquired without increasing the cost target. The design process is
followed until the program design for a specific software increment has
been completed. From that point, development of each increment can
proceed concurrently with the program design of the others.

When the development and test of an increment is complete, an estimate
to complete the remaining increments is computed. The algorithms used
in this computation should reflect the various actual productivity
rates experienced in developing and testing previous increments." p474
http://www.research.ibm.com/journal.../ibmsj1904G.pdf

Isaac Gouy

2005-01-28, 3:59 pm

Isaac Gouy wrote:
over[color=darkred]
>
> Of course! The 17 incremental deliveries for STS-1 over a 31 month
> period became 'timeboxed iterations in the eight-w

range", I
should
> have realized Mr Larman might have made that assumption again.
>
> Overlapping concurrent development, with regular deliveries; or 36
> months before the first delivery then drip, drip, drip; or ... ;(or
> development in one-month timeboxes).
> Yes, a source would be preferable to guesswork.

To be absolutely clear: I don't know why the text refers to "timeboxed
iterations (one month per iteration)", so all I can do is guesswork.

Laurent Bossavit

2005-01-28, 3:59 pm

X-Newsreader: MicroPlanet Gravity v2.50
Lines: 17
Organization: Noos
NNTP-Posting-Date: 28 Jan 2005 13:39:20 GMT
NNTP-Posting-Host: 212.198.118.69
X-Trace: 1106919560 news.noos.fr 18648 212.198.118.69
X-Complaints-To: abuse@noos.fr
Xref: number1.nntp.dca.giganews.com comp.software.extreme-programming:32546

Isaac,

You know one thing that keeps bothering me with these flow diagrams
describing project lifecycles - not one of them ever features a terminal
box labeled "Cancel the project".

> When the development and test of an increment is complete, an estimate
> to complete the remaining increments is computed. The algorithms used
> in this computation should reflect the various actual productivity
> rates experienced in developing and testing previous increments." p474
> http://www.research.ibm.com/journal.../ibmsj1904G.pdf

Nothing new under the sun, eh ? :)

Have we shone enough light on LAMPS ?

Laurent

Isaac Gouy

2005-01-28, 8:57 pm

> You know one thing that keeps bothering me with these flow diagrams
> describing project lifecycles - not one of them ever features a
> terminal box labeled "Cancel the project".

Wouldn't that be "Modify Capability Description" to remove all planned
capabilites in this and following increments. :-)

What do we know in practice about Agile project cancellation?

>
> Nothing new under the sun, eh ? :)

I thought you'd like that ;-)
(imo There are plenty of new ideas, new themes, variations on old
themes,...)

> Have we shone enough light on LAMPS ?

We are pretty much where we started - what we know is what Harlan Mills
wrote.

Robert C. Martin

2005-01-28, 8:57 pm

On 27 Jan 2005 15:30:43 -0800, "Isaac Gouy" <igouy@yahoo.com> wrote:

>Can anyone shine a light on why Mr Larman added this information?
>(Maybe Mr Larman had another source which wasn't cited?)

I suggest you ask him. craig@craiglarman.com

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

Laurent Bossavit

2005-01-28, 8:57 pm

Isaac,

>
> Wouldn't that be "Modify Capability Description" to remove all planned
> capabilites in this and following increments. :-)

Yeah. That box should really read "Embrace change"...

> What do we know in practice about Agile project cancellation?

A colleague of mine, working in one of the few companies to have gone
Agile as a body, says that he is regularly called on to assess project
status, based on velocity etc., and recommends cancellation on occasion.
His management flowchart does include a "Cancel" box, in other words.

> We are pretty much where we started - what we know is what Harlan Mills
> wrote.

Do we have grounds to assume that what Robert Quinnan wrote in that
article was applicable to LAMPS ? I got the impression that that article
was "about" the way IBM FDS managed projects. Of course lots of people
write about how it /should/ be done even though they've never /actually/
done it that way, and that might include Quinnan.

Another problem with abstract, high-level descriptions of "how we manage
software projects" is that they may give an impression altogether
different from the reality. We read "design to cost", the word "design"
may lead us to think of two UML diagrams in competition, but maybe the
actual choice was between two database vendors.

Laurent

Isaac Gouy

2005-01-29, 3:56 am

-snip-
>
> A colleague of mine, working in one of the few companies to have gone

> Agile as a body, says that he is regularly called on to assess
project
> status, based on velocity etc., and recommends cancellation on
occasion.

Lots of questions - how many projects recommended for cancellation are
in-fact cancelled, what proportion of projects are recommended for
cancellation, are 'big' projects more likely to be cancelled, how soon
are they cancelled etc; and the really interesting question - when
projects are cancelled how long does the previously delivered
functionality remain in use.

To take a recent example "The bureau has had repeated warnings that the
Virtual Case File project was not going smoothly; there were delays and
reports of problems. The signs were not subtle. But somehow, the FBI
stuck with the project."
http://www.washingtonpost.com/wp-dy...-2005Jan23.html

More opinion on that project
http://www.nytimes.com/2005/01/22/o...print&position=

Mills[color=darkred]
>
> Do we have grounds to assume that what Robert Quinnan wrote in that
> article was applicable to LAMPS ? I got the impression that that
article
> was "about" the way IBM FDS managed projects.

Yes, it was about the FSD 'approach'; no, we don't know the extent to
which that approach was used on LAMPS.

> Another problem with abstract, high-level descriptions of "how we
manage
> software projects" is that they may give an impression altogether
> different from the reality. We read "design to cost", the word
"design"
> may lead us to think of two UML diagrams in competition, but maybe
the
> actual choice was between two database vendors.

Do Table 1 & 2, pages 466 & 467, help us understand what was meant by
design in-this-case.

Isaac Gouy

2005-01-29, 3:56 am

I already have asked the author directly.

Robert C. Martin wrote:
> On 27 Jan 2005 15:30:43 -0800, "Isaac Gouy" <igouy@yahoo.com> wrote:
>
>
> I suggest you ask him. craig@craiglarman.com
>
>
>
> -----
> 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

Laurent Bossavit

2005-01-29, 8:56 am

Isaac,

> Do Table 1 & 2, pages 466 & 467, help us understand what was meant by
> design in-this-case.

Hardly. Is the database part of functional design or program design ?
(It's probably not part of test design...)

Laurent

Isaac Gouy

2005-01-29, 3:57 pm

Let's recap.
These comments seem to run from "We are pretty much where we started -
what we know [sic about LAMPS] is what Harlan Mills wrote."

Let me say again, "no, we don't know the extent to which that approach
[sic Quinnan] was used on LAMPS".

Let me say it again - afaik LAMPS may have been managed in a completely
different way than Quinnan's description of the IBM FSD approach; what
we know about LAMPS is what Harlan Mills wrote.

Having said that:
Yes, the problem with "abstract, high-level descriptions" is that they
are "abstract, high-level descriptions"; they are a shorthand that
assumes a common-understanding, which is unlikely to continue across
decades of technology change.
[color=darkred]

Is this just an example "abstract, high-level descriptions" having
different concrete possibilities; or... ?

Laurent Bossavit

2005-01-29, 8:56 pm

Isaac,

> Yes, the problem with "abstract, high-level descriptions" is that they
> are "abstract, high-level descriptions"; they are a shorthand that
> assumes a common-understanding, which is unlikely to continue across
> decades of technology change.

Or across a few hundred or thousand miles of cultural difference ? Do we
know for a fact that software development is the same practice in France
as it is in the US ?

> Is this just an example "abstract, high-level descriptions" having
> different concrete possibilities; or... ?

Yes, just so.

What if choosing one concrete possibility over another has the effect
that the abstract description is no longer quite true ? ("Leaky"
abstractions are a problem in the design of the software itself, by the
way.)

Laurent

Sponsored Links