Win a copy of Rust Web Development this week in the Other Languages forum!

Alistair Cockburn

+ Follow
since Feb 21, 2002
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alistair Cockburn

I have read those definitions there. apart from that I have atleast 4 to 5 books on s/w engineering , which never had mentioned that definition. . . . what do you think the reason must be ?
The reason for the confusion is that most writers (I recall reading many such in the early 1990s) interpret the word "iterative" as "repeating the waterfall cycle."
Note that this interpretation covers both of my definitions of incremental and iterative - in other words, it gives no advice.
I split those two apart along the lines of "repeat the development cycle on the same piece of code" (iterative) versus "repeat the development cycle on a new piece of code."

do you see where waterfall still beneficial as development model ? steve maconnell & royce walker have mentioned that modified waterfall method still holds chance . what is your perception ?
Rarely. Even incremental as a sequence of waterfall subprojects is almost always better.
(edited by moderator to fix quotes)
[ March 28, 2002: Message edited by: Junilu Lacar ]

Originally posted by Junilu Lacar:
Alistair, thanks for hanging around

I hang out where the conversation is good

Originally posted by Junilu Lacar:

BTW, I am re-reading your book now and the tip of my highlighter is getting raggedy. Thanks for sharing the articles in the appendix. I find it pretty amazing how simply being aware of the three stages of practice can change so many things

Perhaps most surprising to me is how many people have such strong reactions to that single part of the book. Originally, those three levels were at or near the back of the book - a casual colleague commented so strongly on it that I moved it to the front, where more people will see it.
At a personal level, I find this perhaps the most satisfying contribution of the book - because people listen to each other better than before, and with more empathy for the other's situation. This is an almost impossible desire to fulfill, so having something so simple as the three levels in the, and having that make such a big difference, is triply rewarding. (Thanks for mentioning it).

Originally posted by shailesh sonavadekar:
alistair , thanks for giving the difference between iterative & incremental. but ,most of the texts on software engineering doesn't give this fine line or rather one can say they are treated as same. can you please elaborate more upon it ?
[ March 21, 2002: Message edited by: shailesh sonavadekar ]

Indeed, most don't. I wrote this definition first in 1993, and repeated it in my Surviving OO Projects book in 1997. Martin Fowler told me I had "lost", and iteration was going to become the common word for both. I still keep the two separate because I periodically encounter project iterating without incrementing, and they inevitably fall into deep trouble.
The two, and their relation to waterfall are explained in my
VW-Staging article (which is a bit short, perhaps, but sets out the main points).
I think "increments are units of work that will be project managed. And each increment is developed iteratively" is a fine summary of the strategy.
I like to think of "An Increment" as being something that gets delivered to a real user, possibly every month, or three months. That definitely needs to be project managed.
XP uses what I call "nano-increments", function add in a 15-minute to 4-hour session, tested, and then checked in. Those don't get delivered to the user, of course. The "iterations" in XP are hidden - they just happen all the time, part of business-as-usual. In most organizations, both increments and iterations are larger and need to be scheduled / managed.
Use of incremental development is a critical success factor in most projects, and easier to manage than iterative. Iterative development happens whether you like it or not - it is hard to "schedule", however.
"Incremental" means "add onto".
"Iterative" means "alter".
In incremental development, you produce a piece of final, tested code that is a part of what is finally needed. Then you repeat and produce another piece of final, tested code. You "add onto" the existing chunk, grow it.
In iterative, you produce a best first guess at a piece of design or code, and you evaluate it. Then you go and improve it. (e.g UI design)
Most people do both at the same time, so they don't notice the difference. But if you get them mixed up you can mess up badly
Hi, Junilu,
When I "play a game" (e.g. rock climbing, chess, boccia) I don't use mathematical theory to select my moves. Ditto software development. The point I'm after is that software development is a movement structure in the form of a game (as opposed to "in the form of model building / theatre / engineering / etc").
The fact that I don't have any idea about how to apply Nash's game theory mathematics to generate team software development moves, does not at all mean that someone else won't see a way - just not me, not yet.
Actually, I have a little note in my book about VOI vs VOF (value of information vs. value of flexibility). That will be an application of math to sw-dev game development, and i look forward to that.
Otherwise, I look forward to being surprised by someone else's application of game theory economics to sw devt.
It ain't RUP, but there's no reason it can't be used within a RUP development case... look at
(and let us know if you find you can use it in conjunction with RUP - I just wrote somewhere that it would be possible in principle :-)...)
The thesis is roughly titled "People and methodologies in software development". It is built around my articles: The implication of OO on application development, Surviving OO Projects' case studies, Selecting a project's methodology, Characterizing people as first-order nonlinear components in software development, Just-in-time methodology construction, Barely sufficient methodologies.
The delta from those articles is the notion of a project instance as an "ecosystem" that includes people, stairways, watering holes, etc. The details of the ecosystem affect the methodology and vice versa. The two need to be in interplay.
That means a methodology off the shelf will basically never fit a team - the team needs to modify it to fit them (and perhaps change themselves in the process). The technique for doing so is in the Just-in-time paper, which is at
Of course, before it becomes a PhD thesis, it has to be accepted by a triumverate, and that's never a given...
The people factor is much more important for the project manager than for the programmer.
<<Agile approaches emphasize quality of design.<br /> <<<Doug , in agile , Alistair is saying that people find it hard to follow disciplined proceess . so , the least disciplined process is going to be successful. big statement. he also advocates the ease development at the cost of productivity.>>> <br /> I dont agree with you. Less discipline only means ease of execution, not likely sucess.>>

Doug's right here ... in Agile it also says that disciplined adherence to effective practices makes better (and disciplined adherence to ineffective practices makes worse).
Undisciplined is easier to set into motion... doesn't necessarily mean will produce better results. That's the trade-off inherent in the XP vs. Crystal comparison.

Originally posted by Jim Baiter:
I really like the approach you are offering with Agile especially in the "no fixed process per project" rule. But do you think there could be a "cafeteria" of processes in an organization from which projects could choose?

A bit of a rephrasing perhaps...
The OPEN process consists of an kit bag of process parts and techniques you might like to use, but you have to put it together yourself. I don't think people can do this "putting together".
The RUP process consists of a truck full of process parts put together for you, but you have to whittle it down to the size you need (ever try making a motorcycle from a truck?). I don't think people can trim it down enough.
The naive Crystal process consists of not enough parts and you have to add to it to make it full. I doubt whether most people can name the necessary parts needed to add and put them together.
The newer Crystal process consists of examples from other projects yours might be similar to, so you can copy and modify from that. There are only three in the literature to choose from, so it's pretty thin pickings.
There is some question in my mind as to whether there is ANY solution anywhere that will work - I constantly bear in mind that there might be no answer. Obviously the newer Crystal process is where I'm putting my money for the best next (9th?) guess.

Originally posted by shailesh sonavadekar:
Alistair , what claim Barry Boehm made ? did he said that good people are not required ? surprising. person who developed win - win model as an extention to spiral development & COCOMO model saying so .

Well, he's changed it now. Originally, though, he wrote that the "home ground" for agile vs. 'plan-based' development are:
Home-ground area for:
- Agile methods
- - Developers
- - -> Agile, knowledgeable, collocated, collaborative
- - Customers
- - -> Dedicated, knowledgeable, collocated, collaborative, representative, and empowered
Plan-driven methods
- - Developers
- - -> Plan-oriented, with a mix of skills
- - Customers
- - -> Mix of capability levels
In other words it was a "set up": you'll never get good enough people to apply agile methods, but you can use any normal mix with plan-based.
Obviously I disagreed, and he agreed with my disagreement enough to make some modification.

Originally posted by John Wetherbie:
Do other groups (and who are these groups?) really pretend you don't need good, senior people to help assure success. I can see where this is ignored because it is so obvious that it is easy to overlook but pretending implies that someone knows that this is important/required and chooses to ignore it. Definitely a good step towards failure.
Can you cite any examples? You can change the names of the other groups to protect the guilty, if necessary!

Barry Boehm of great software engineering reknown just wrote a paper for IEEE Computer comparing Agle and Planned approaches. He wrote a table in which he made just that claim. After soveral rounds of email, he agreed to dilute his claim somewhat. So yes, and he was putting it into print very out loud. (I haven't seen the Jan issue to see what he finally wrote).

Originally posted by John Wetherbie:
BTW, isn't "cheating legally" an oxymoron?
I'd prefer to think of it as intelligently ignoring those aspects of the game that do not contribute to you playing well and winning.
Or maybe I'm getting carried away... :roll:

You are quite correct, John. I only say "cheating" because when I tell other people how we do agile software development, that's what they tell me - "But that's cheating!" So I conclude I must be "cheating", but legally somehow.
What it really means is detecting that some "rule" isn't really a rule, and so can be bent or broken.
All the modern methodologies are combined incremental-iterative. All involve "build some, show some, revise if needed, show again, ship asap"
You've got them, John.
Watch your back for risks all the time (technology & people), get close to the customer, show and get feedback as quickly and often as possible, check the design for quality, test where possible, and especially in risk areas, communicate with the team.
Look across the effective teams and methodologies, and you'll find these themes in many clothings.