Agile In Action
Vladimir Levin
comments.
I don't know to what extent the notions of up-front requirements
analysis and design are still being actively used these days, but I've
heard a lot of debate on the subject over the past few years. I'm
currently working on an agile project and today I had a good experience
in which three of us, a customer and two developers, worked together to
flesh out a requirement in a way that simply would not be possible in a
more traditional environment heavy on up-front requirement preparation.
Since this is an example from the real world, I'll be using
project-specific terminology, but I hope to make the general sense of
what's going on clear to anyone reading this blog. If you're reading
this and have something to say that may clarify matters, I encourage
you to e-mail me and I'll update this posting.
In our application (oil and gas production accounting), we have the
notion of a gas-equivalent factor (ge factor). It is a number that you
multiply by a volume of light oil, also called condensate, to get an
"equivalent" volume of gas. It's a bit like comparing, say, two grads
from different schools. One grad has a GPA of 3.2 and the other one has
a 78% average. To compare them, you may want to convert the gpa of 3.2
to a percentage, or vice versa. Anyway, the point is that this number
is displayed on several screen of the application. Now, there are
several different ways that this number is obtained, and as part of a
story I was working on, I had to include the source of the ge factor
along with the number itself. The story (similar to a use case)
specified that one of two icons should be displayed along with the
factor: "A" for analysis, and "E" for entered. In one case, an analysis
(a breakdown of the molecular constituents of the condensate) is used
to calculate a ge factor; in the other case, the user simply enters in
the factor manually. As I began to get into code, I realized that there
was a third case that the story didn't talk about. I turned to the
customer who had put together the story, who sits just across from me,
and asked him about it: Al, what happens when the ge factor is not
necessarily derived from an analysis, but it's averaged from ge factors
at several other measurements? After a bit of discussion, the user and
I agreed to include a third icon as part of the story, "C" for
calculated.
I implemented the requirement simply by putting a text label "A", "C",
or "E" next to the ge factors on the appropriate screens. Then I went
to talk to our resident gui (graphical user interface) expert about the
story: Hey Chris, I've put these text labels next to the ge factor on
our balancing screens. Could you cook up some icons that look a bit
nicer? Chris came over and asked Al: What if instead of an extra icon
next to the factor, we turned the factor itself into a link. If the
number came from an analysis, the link would actually take the user to
the analysis that was used. If the number was entered, the link would
lead to the screen where that number was entered. The user really liked
this idea. I objected: In the case that the number was calculated by
averaging several measurements, it would be a fair amount of work to
create a new screen that showed all of those measurements in one place.
The user however told us that it wasn't necessary to go that far. If
the number was an average, simply omitting the link was fine.
The buzzwordz "multidisciplinary" and "synergy" are used a lot these
days, but in this case, we solved a problem by combining our skills and
perspectives. Requirements are a bit like art. If you're a customer,
you generally know what you want when you see it, but describing it
ahead of time isn't so easy. In a non-trivial application, it's hard to
think of all the possible scenarios for a given feature. As a
developer, I'm close to the code and I can see those scenarios, so it's
a lot easier for me to ask the kind of question that I asked. Finally,
the user interface expert was concerned about clutter on the screen and
how effective the user interface would be, whereas I just cared about
the fact that the right information would show up as described in the
story. We all worked together to come up with a better solution -
without really extending the development time. The whole discussion
probably clocked in at about 15-20 minutes, and nothing about the
requirement caused an enormous amount of extra work. In the future, if
someone decides that showing all of the measurements that contribute to
an "averaged" ge factor, we can implement that as a separate story. The
important thing is that the users currently don't consider it to be
especially useful or a high priority. We've built the software not to
honor a general principle of orthogonality, but to meet our users'
actual requirements.
I was really impressed with the process we went through today and I
thought it was a nice simple example the kind of power an agile
approach can have.
bill turner
wrote:
>This is a post from my blog (vladimirlevin.blogspot.com). I welcome
>comments.
>
>I don't know to what extent the notions of up-front requirements
>analysis and design are still being actively used these days, but I've
Vlad,
I work as an independent contract programmer. I first became intrigued
with XP/Agile in 1999 (?) after reading an article in IEEE Software.
Since I have worked at three different clients since then and am now
seeking new work, I have seen little requirement for this knowledge.
In fact, a quick search on DICE would demonstrate that it has not been
as widely adapted as some seem to think. If fact, it seems only a
small percentage of shops have adopted these practices. Even in the
organizations I've been in that are well aware of XP/Agile, none are
taking any serious effort to adopt it.
One must wonder why, if this is the silver bullet claimed by the
zealots, that is has not been more widely adopted after so many years.
>heard a lot of debate on the subject over the past few years. I'm
>currently working on an agile project and today I had a good experience
>in which three of us, a customer and two developers, worked together to
>flesh out a requirement in a way that simply would not be possible in a
>more traditional environment heavy on up-front requirement preparation.
Why wouldn't it be possible? I don't see it. Nothing you have
described precludes the ability of an RE from identifying the three
types of analysis you describe. In fact, I would say it would be an RE
who failed to ask the appropriate defining questions. As for the UI
design, that too is completely doable. Whether or not people thought
creatively has little to do with the methodology used. In fact, I
would posit that quick drawings on paper or whiteboard could elicit
exactly the same response, then it could be formally defined in a
document.
Your conclusion, it seems to me, seems unwarranted.
<snip description of experience>
Bill
------------------------------------------
Bill Turner
A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
Views expressed are entirely my own and only coincidentally represent those of other persons or entities.
Phlip
> Your conclusion, it seems to me, seems unwarranted.
>
> <snip description of experience>
Welcome to USENET, Vlad! Your report of specific first-hand experiences gets
snipped in favor of idle gainsaying.
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Vladimir Levin
bill turner wrote:
> I have seen little requirement for this knowledge. In fact, a quick search on
> DICE would demonstrate that it has not been as widely adapted as some seem
> to think. If fact, it seems only a small percentage of shops have adopted these
> practices.
That's very possible. Since I make an extra effort to work on agile
projects, I am very likely to think they are more pervasive than they
really are! :)
> Why wouldn't it be possible? I don't see it. Nothing you have
> described precludes the ability of an RE from identifying the three
> types of analysis you describe. In fact, I would say it would be an RE
Good question. Here's my attempt at an answer: From my point of view,
the problem is one of time and perspective. For any requirement, one
can always ask "Is there anything more? Anything different? Anything
you haven't thought of?" as a generic question. One doesn't even need
an RE. One could write a computer program that responds that way to any
requirement that you input into it. In fact, it is something I try to
do, both in the software world and when I am leaving on a trip! I
suspect that in many cases the user would simply say "As far as I know
right now, no." I've had quite a lot of experience eliciting
requirements, and I have often witnessed the scenario where I ask
repeatedly whether a particular difficult feature will ever be needed
and repeatedly get the answer "no" only to see the feature pop up
later. Sometime's it's exactly the feature I asked about, and sometimes
there's a spin on it that would be difficult for anyone without
extremely deep knowledge and foresight to come up with. Anyhow, my
point is this: All of the stories we develop on our project go through
a review committee of subject experts before reaching the developers,
and yet it is often the case that stories are modified as in my example
during development. In my opinion (and it's just an opinion), one
cannot think of every possible angle on a story, and furthermore,
trying to do so is probably not a good idea (because the amount of time
and effort it takes to get there is prohibitive). When you're dealing
with a real, complex, application, the number of combinations gets
large, and it becomes almost impossible to cover things ahead of time.
If one thing is not missed, then something else will be. It reminds me
of diagonalization, where you can always add another infinitely long
binary string to the list, but then you look anew at the diagnonal, and
the complement is still not in the list, ad infinitum. Hence the set of
all infinitely long binary strings is uncountable.
In software, I believe there is this principle at work: For every new
requirement, there will always be a number of things that are vague,
can be interpreted in a several ways, or may not be considered until
the story is in development, or even afterward.
My point was to try to show how three people worked together to satisfy
a requirement. I introduced a requirement that had been missed because
it was not a common case and because our experts only have so much time
to develop stories. The GUI expert had some additional input that
neither I nor the customers had thought of. There is a natural
temptation to think that some more skillful forethought could have
achieved the same result. Personally, I don't think so, at least not in
most cases. It would be interesting to do some experiments with
requirement gathering to see how good up-front elicitation of
requirements really is.
Vladimir Levin
> Welcome to USENET, Vlad! Your report of specific first-hand experiences gets
> snipped in favor of idle gainsaying.
I think you might be ready for a break from usenet :) Seriously though:
First of all, I don't expect people to just fall over in recognition of
how right I am. I want people to ask questions and disagree. As long as
we can all do so in a respectful way, then we're all learning. I didn't
see anything in Bill's reply that struck me as gainsaying. His way of
looking at things is very natural. I had a long debate about this
subject with a student in one of my youth software courses. At 14, he
was convinced that rigorous analysis was the way to go. I don't think
even the bugs that he was constantly chasing in his project really
disuaded him from his point of view! Anyway, he's a very bright kid and
we had good discussions. Second: If there are people who's motivations
really are malicious, to discredit what I'm saying just for the heck of
it or out of some kind of deep-seated hatred of agile methodologies,
fine. All I can do is hope that people will largely take any postings I
make in the spirit that I intended: To share my experiences, help other
people in the software world, and also learn myself from responses.
Isaac Gouy
> bill turner wrote:
-snip-
> > Why wouldn't it be possible? I don't see it. Nothing you have
> > described precludes the ability of an RE from identifying the three
> > types of analysis you describe. In fact, I would say it would be an RE
>
> Good question. Here's my attempt at an answer: From my point of view,
> the problem is one of time and perspective. For any requirement, one
> can always ask "Is there anything more? Anything different? Anything
> you haven't thought of?" as a generic question.
afaict Your realization that there could be a third case which the
story didn't cover isn't necessarily linked to implementing the story,
but is necessarily linked to carefully reviewing the story and having
other domain knowledge.
A N Other person may just have gone ahead and implemented A & E.
(But now I'm curious - are the averaged ge factors possibly averaged
from both A and E ge factors, or just from Analysis; does the
additional category make any difference in how the information is
interpreted or is the useful distinction between a ge factor derived
directly from Analysis and a ge factor from some other source?)
Vladimir Levin
Isaac Gouy wrote:
> A N Other person may just have gone ahead and implemented A & E.
That's a good point. In the end, that's effectively what happened,
since for "C" that's the only information we provide - just that it's
calculated.
> (But now I'm curious - are the averaged ge factors possibly averaged
> from both A and E ge factors, or just from Analysis; does the
> additional category make any difference in how the information is
> interpreted or is the useful distinction between a ge factor derived
> directly from Analysis and a ge factor from some other source?)
I'm not sure. I think the reality is that the average could indeed come
from both A and E ge factors. For any given measurement, it comes down
to how much information is available. Sometimes there's a useful
analysis and sometimes there isn't. As far as I know, the users don't
care about the distinction you refer to - yet. One thing I've found
about the kind of project I am currently on, where we have more than 10
full-time subject matter experts preparing requirements, is that they
often don't agree about such matters. Some of them don't even seem to
care about providing the context information "A", "E" and "C". Others
think it's important to show the distinction in the app.
Phlip
> ... I had a long debate about this
> subject with a student in one of my youth software courses. At 14, he
> was convinced that rigorous analysis was the way to go. I don't think
> even the bugs that he was constantly chasing in his project really
> disuaded him from his point of view!
I ... don't think I need to defend you much. ;-)
Isaac Gouy
And that's ordinary - we can do a superset, we can make an arbitrary
choice between them, we can appoint one of the to be /the/ customer, we
can ask them to justify their opinion, we can weight each feature with
an opportunity cost (you can have X or Y - choose).
The way I heard your story, there was something a little strange - it
sounded like as part of implementing something we'd added another
feature which might or might not be useful. iirc That's one of the
criticisms made of up front requirements.
Phlip
> In fact, a quick search on DICE would demonstrate that it has not been
> as widely adapted as some seem to think.
I just heard, on KFOG in San Francisco, an advertisement requesting resumes
for "Agile" IT personnel. Note that ain't CraigsList. A radio advertisement
is an expensive, high-end investment, on the same level as, say, beer or
cars.
(The quality of search engine may also be a factor.;)
They plugged this:
http://www.solutionsiq.com/agile_dev_services.html
Of course one always has to work to detect the difference between buzz-word
compliance and "getting it", but I doubt the Bay Area will have much problem
with that.
From the page (for anyone claiming there's no statistics available for such
things):
KEY BENEFITS OF AGILE:
Agile development results in reduced time, costs and solid ROI according to
analysis from Forrester Consulting, 2004 and Agile Methodologies Survey
Results, Shine Technologies Pty Ltd, 2003
57% reduction in costs compared to other IT solutions for similar complex
projects.
62% reduction in effort compared to alternatives, including in-house
development and previously employed consultants.
80% reduction in critical defects
60% reduction in overall defects
93% stated productivity was better / significantly better
88% stated that quality was better / significantly better
83% stated that business satisfaction was better / significantly better
--
110% Phlip
Vladimir Levin
Isaac Gouy wrote:
> The way I heard your story, there was something a little strange - it
> sounded like as part of implementing something we'd added another
> feature which might or might not be useful. iirc That's one of the
> criticisms made of up front requirements.
Interesting point. When I am working on a story, I do tend to find
gaps, and in fact I dare say I tend to look for them. In this case, I
found a gap, and ultimately we just put in a placeholder to identify
the fact that the ge factor was neither based strictly on analysis at a
measurement, nor was it entered in for a particular measurement -
instead it's an average from several measurements. Since this didn't
tak a significant amount of time, I felt it was reasonable to include
it. If the users had wanted something more sophisticated, then I would
have asked them for another story. I have also asked questions only to
find out that the missing pieces were already coming up in future
stories. For me, the most important thing about identifying a piece of
functionality as a separate story is that it allows the customer to
prioritize each piece separately. There are other advantages too. For
example, it's easier to make sure a smaller story has good test
coverage. It reduces sloppiness. And of course, being able to estimate
consistently is easier when stories are smaller and more well defined.
>From my point of view, what was "agile" about the scenario I described
was that we were interacting and exchanging information, and
dynamically shaping how things would work out rather than deciding way
up front on things. Indeed, as you pointed out, I think it's a lot
easier to come up with a more complicated requirement up front - say
one in which the averaging case handled in a more sophisticated way.
Does that make sense?
Phlip
> Interesting point. When I am working on a story, I do tend to find
> gaps, and in fact I dare say I tend to look for them. In this case, I
> found a gap, and ultimately we just put in a placeholder to identify
> the fact that the ge factor was neither based strictly on analysis at a
> measurement, nor was it entered in for a particular measurement -
> instead it's an average from several measurements. Since this didn't
> tak a significant amount of time, I felt it was reasonable to include
> it. If the users had wanted something more sophisticated, then I would
> have asked them for another story.
One myth of Agile development is it forbids planning ahead. (Of course the
idle detractors love to rant about that one.)
The myth means two things. Don't plan your features based on an
extrapolation of an extrapolation of an extrapolation. The further in the
future you plan, the fuzzier you should keep the details.
Vladimir's story illustrates the other meaning. If you force yourself to
exclude features not requested during the iteration, then the act of
reviewing features for exclusion is itself a form of analysis. So planning
ahead happens - within very tight and exacting constraints that force up the
quality of that planning.
> I have also asked questions only to
> find out that the missing pieces were already coming up in future
> stories. For me, the most important thing about identifying a piece of
> functionality as a separate story is that it allows the customer to
> prioritize each piece separately.
"83% stated that business satisfaction was better / significantly better"
That's because the people stating their satisfaction were the ones appointed
to rate and rank these stories. The system put them in direct control.
--
Isaac Gouy
Vladimir Levin wrote:
> Isaac Gouy wrote:
>
> > The way I heard your story, there was something a little strange - it
> > sounded like as part of implementing something we'd added another
> > feature which might or might not be useful. iirc That's one of the
> > criticisms made of up front requirements.
>
> Interesting point. When I am working on a story, I do tend to find
> gaps, and in fact I dare say I tend to look for them. In this case, I
> found a gap, and ultimately we just put in a placeholder to identify
> the fact that the ge factor was neither based strictly on analysis at a
> measurement, nor was it entered in for a particular measurement -
> instead it's an average from several measurements. Since this didn't
> tak a significant amount of time, I felt it was reasonable to include
> it. If the users had wanted something more sophisticated, then I would
> have asked them for another story. I have also asked questions only to
> find out that the missing pieces were already coming up in future
> stories. For me, the most important thing about identifying a piece of
> functionality as a separate story is that it allows the customer to
> prioritize each piece separately.
If you'll allow me to rephrase a little - the most important thing
about identifying a separate requirement is that it allows the customer
to prioritize each requirement separately.
> There are other advantages too. For
> example, it's easier to make sure a smaller story has good test
> coverage. It reduces sloppiness. And of course, being able to estimate
> consistently is easier when stories are smaller and more well defined.
> From my point of view, what was "agile" about the scenario I described
> was that we were interacting and exchanging information, and
> dynamically shaping how things would work out rather than deciding way
> up front on things.
What are you assuming would have happened differently if things had
been decided way up front - would there not have been 10 full time
subject matter experts, would there not have been IT specialists
working with them, would they not have interacted and exchanged
information?
> Indeed, as you pointed out, I think it's a lot
> easier to come up with a more complicated requirement up front - say
> one in which the averaging case handled in a more sophisticated way.
> Does that make sense?
If that's what I pointed out, I mispoke :-)
We can ask for up front requirements to be justified, and we can ask
for up front requirements to be weighted with an opportunity cost.
Phlip
> If you'll allow me to rephrase a little - the most important thing about
> identifying a separate requirement is that it allows the customer to
> prioritize each requirement separately.
That's a great way to say it!
> What are you assuming would have happened differently if things had been
> decided way up front - would there not have been 10 full time subject
> matter experts, would there not have been IT specialists working with
> them, would they not have interacted and exchanged information?
> If that's what I pointed out, I mispoke :-) We can ask for up front
> requirements to be justified, and we can ask for up front requirements to
> be weighted with an opportunity cost.
The "Agile" movement formerly complained about Big Design Up Front as the
highest risk up-front behavior.
The research and surveys into requirements gathering has generally shown
that the worst risk comes from Big Requirements Up Front.
For example, even _after_ several decades of Toyota kicking Detroit's
butt, and after Detroit executives giving lots of lip service to
Just-in-Time design and lean manufacturing, Toyota is _still_ in the lead.
They put a cheap hybrid car, the Prius, out first, and they have a new
line that you never heard of, the Yaris, for the low-end. All these cars
have new design features that closely target what customers are asking
for. Toyota does it by delaying the specification process and distributing
it among all their team members.
--
Phlip
Vladimir Levin
Isaac Gouy wrote:
> If you'll allow me to rephrase a little - the most important thing
> about identifying a separate requirement is that it allows the customer
> to prioritize each requirement separately.
That's exactly right. As a user, I may ask just for X and Y. Or I can
break that up into x1, x2, x3, and y1, y2, y3. I may then find that I'd
rather see y2 done before x2 and x3. I may even eventually decide that
x3 isn't all that useful when it isn't lumped in with X.
> What are you assuming would have happened differently if things had
> been decided way up front - would there not have been 10 full time
> subject matter experts, would there not have been IT specialists
> working with them, would they not have interacted and exchanged
> information?
Well, I think we would not have the degree of interaction that we
currently have. Nor would we have the flexibility to make adjustments.
For example, we recently were working on two allocation methods
separately, but someone noticed that it should be possible to merge
many aspects of those two methods into one. We have begun merging the
code and the business people have adjusted the way they prepare
requirements accordingly. It should speed development up a lot. To
answer your question, I think we'd still have the subject matter
experts, but would they be they working right next to the developers
and discussing the stories being worked on every day? I assume not. I
assume that they would get the job of preparing requirements and would
leave (most of them anyway) when the developers arrived to begin the
implementation phase. That seems like a very different dynamic.
If you disagree, please describe the kind of interaction you would
expect to see if things were decided way up front. Maybe we're simply
using different terminology to talk about the same things.
> If that's what I pointed out, I mispoke :-)
> We can ask for up front requirements to be justified, and we can ask
> for up front requirements to be weighted with an opportunity cost.
Fair enough. It's somewhat off topic - more of a general discussion -
but I'd say that it's easier to make those opportunity cost decisions
as you go along with software rather than up front. Again, to
illustrate: Instead of X and Y, I ask for x1 and x2 to be devloped. I
have a look at the result. Now it seems more clear that y1 should be
next. Earlier on I may have believed that x3 would be the way to go.
Phlip
> That's exactly right. As a user, I may ask just for X and Y.
And as a developer, I can openly request to implement x<X and y<Y. And I can
also just implement them and see if they pass review. If they do, I don't
argue.
And if the Onsite Customer wrote an acceptance test, it shall certainly
require less X than all the written X could be.
> ...To
> answer your question, I think we'd still have the subject matter
> experts, but would they be they working right next to the developers
> and discussing the stories being worked on every day?
Why not? That helps write the acceptance tests.
> If you disagree, please describe the kind of interaction you would
> expect to see if things were decided way up front. Maybe we're simply
> using different terminology to talk about the same things.
Ask him for his own experience collating requirements.
David Lightstone
"Phlip" <phli...@gEEEmail.com> wrote in message
news:pan.2006.06.24....@gEEEmail.com...
(1) Care to cite a reference on the claim "Toyota does it by delaying the
specification process and distributing it among all their team members."
If you have ever read a GM, Ford or BMW system or component specification
you probably realize that there is little BDUF occuring within the auto
industry. It is much close to the Agile ideal (customer stories) than you
think. Each story would be something like. "Everything is just fine except
we observe this phenomena, fix it.". You have the test case that fails, and
the feature to implement from get go. Agile at its finest. Behavior
indistinguishable from hacking at its finest also.
Any chance the engineering by story will failed?
>
> --
> Phlip
Isaac Gouy
> Isaac Gouy wrote:
>
> > What are you assuming would have happened differently if things had
> > been decided way up front - would there not have been 10 full time
> > subject matter experts, would there not have been IT specialists
> > working with them, would they not have interacted and exchanged
> > information?
>
> Well, I think we would not have the degree of interaction that we
> currently have. Nor would we have the flexibility to make adjustments.
> For example, we recently were working on two allocation methods
> separately, but someone noticed that it should be possible to merge
> many aspects of those two methods into one. We have begun merging the
> code and the business people have adjusted the way they prepare
> requirements accordingly. It should speed development up a lot. To
> answer your question, I think we'd still have the subject matter
> experts, but would they be they working right next to the developers
> and discussing the stories being worked on every day? I assume not. I
> assume that they would get the job of preparing requirements and would
> leave (most of them anyway) when the developers arrived to begin the
> implementation phase. That seems like a very different dynamic.
>
> If you disagree, please describe the kind of interaction you would
> expect to see if things were decided way up front. Maybe we're simply
> using different terminology to talk about the same things.
You've brought in a new example which talks about coding, and that's
fine, but what I was really asking about was your original scenario
because it seemed to be about noticing something in the story (the
requirements).
We might assume that the subject matter experts would not be working
with the programmers. (I've always liked the term software developer
but I like it because it covers so many different roles.) Would it be
unreasonable to imagine yourself interacting and exchanging information
with the subject matter experts and an interaction designer, in just
the way you originally described, and then describe that role as a
requirements specialist?
> > If that's what I pointed out, I mispoke :-)
> > We can ask for up front requirements to be justified, and we can ask
> > for up front requirements to be weighted with an opportunity cost.
>
> Fair enough. It's somewhat off topic - more of a general discussion -
> but I'd say that it's easier to make those opportunity cost decisions
> as you go along with software rather than up front. Again, to
> illustrate: Instead of X and Y, I ask for x1 and x2 to be devloped. I
> have a look at the result. Now it seems more clear that y1 should be
> next. Earlier on I may have believed that x3 would be the way to go.
That seems possible - it doesn't seem to necessarily follow, it depends
on the assumptions we choose, it depends on what other artifacts
(sketched, screen painted, prototyped) we imagine as part of the
process.
Isaac Gouy
4 days ago in this newsgroup
http://groups.google.com/group/comp.software.extreme-programming/msg/591904d6b56bd40c
you wrote "Gouy then claimed I should not cite that book because it
misrepresents evidence. This outer claim is not falsifiable - the claim
that the entire book should not be read."
That is untrue - I made no such claim.
I've asked that you show where I made those claims and you have not
attempted to do so, nor have you in any way corrected your comments.
http://groups.google.com/group/comp.software.extreme-programming/msg/01ec147157bc8ac1
It doesn't seem to me that you are interested in honest discussion.
Phlip
> you wrote "Gouy then claimed I should not cite that book because it
> misrepresents evidence. This outer claim is not falsifiable - the claim
> that the entire book should not be read."
>
> That is untrue - I made no such claim.
Then the next time I recommend the book you won't complain?
> I've asked that you show where I made those claims and you have not
> attempted to do so, nor have you in any way corrected your comments.
> http://groups.google.com/group/comp.software.extreme-programming/msg/01ec147157bc8ac1
>
> It doesn't seem to me that you are interested in honest discussion.
The fallacy of this argument is I didn't read your post, hence couldn't
honestly discuss it. I suspect that's "excluded middle".
You were kill-filed at the time.
Isaac Gouy
Please show where I made those claims, or correct your comments.
Vladimir Levin
> We might assume that the subject matter experts would not be working
> with the programmers. (I've always liked the term software developer
> but I like it because it covers so many different roles.) Would it be
> unreasonable to imagine yourself interacting and exchanging information
> with the subject matter experts and an interaction designer, in just
> the way you originally described, and then describe that role as a
> requirements specialist?
I don't like that idea. Here's why: The point I was trying to make with
the agile process I described was that there was a useful feedback loop
between developers who knew the code and the customers who wrote the
stories and knew the business. Taking advantage of that constant close
interaction helped us guide the development in the right direction.
Defining 'Requirements Specialist' as a separate role would seem to
remove that very interaction; it would imply that a requirements
specialist would be sufficient without being a developer. For missing
requirement I brought up, there were several options the customer had
as a response:
1) That "averaged ge factors" case is in a future story, relax!
2) I don't care about it at all, just don't do anything in that case.
3) Wow, that's a good point. We'll write a story around that, thanks!
4) Well, if it's not too time-consuming, go ahead and label that case
but that's all - no fancy breakdowns of where the averages are coming
from.
I think *all* of these potential responses are helpful. It's the
feedback between the customer and the developer that helps both
parties. Consider the hypothetical scenario where that "averaged ge
factors" case were to have been covered in the original story. In that
case, if the requirement were complex, I'd have possibly asked for it
to be broken into a separate story when we went over the stories at the
start of the sprint, or even before I began working on the story if
that's when I realized that this requirement was complex and did not
impede the remainder of the story. It would be a red flag for the
customer to note that this would take more time than they might want us
to spend, and would given him/her a chance to remove or simplify that
feature. Or not, but at least it would be an informed decision.
bill turner
wrote:
>Phlip wrote:
Phlip often seems to interpret any questioning of the glory of
XP/Agile as unfound criticism. You seem to have understood that. What
you do not seem to have understood was that I was questioning your
position that the results would have been unlikely using a more
traditional method. Of course, if you use the straw man argument of a
pure waterfall development, something I've never seen done, not even
in th 70's when I first entered the field, then I would agree.
However, understanding that software development is always iterative,
and there have been many methods used to elicit requirements even in
traditional methods, I still say I cannot agree with your conclusion.
It seems, from your description, that the little suggestion that came
from your GUI expert could have come during the analysis/design phases
of a traditional project just as easily. And, just as easily, the
suggestion might not have ever occurred. It was a matter of a person
thinking creatively at an opportune moment. Perhaps, even, it would
have been more likely in a traditional process because there would
have been more opportune moments: during requirements elicitation and
analysis, during specification, during detail design: or during
implementation. In the process you described, there were far fewer
opportunities: story writing, story review, implmentation.
XP/Agile may, indeed, lead to discovery of requirements that would be
near impossible through traditional methods. Your experience, imho,
does not provide any real support of this hypothesis.
FWIW, I am neither an XP/Agile zealot or skeptic. I have been exposed
to its practice, both trying to use it and working with a vendor who
developed using said practices. These have been both positive and
negative experiences. I feel XP/Agile probably has its place, but that
it is another tool to know and use when appropriate, and probably
adpat to experiences on the ground.
Phlip
> Phlip often seems to interpret any questioning of the glory of
> XP/Agile as unfound criticism. You seem to have understood that.
I interpret the situation as Vlad's online technique doesn't suck. ;-)
bill turner
>bill turner wrote:
>
>> In fact, a quick search on DICE would demonstrate that it has not been
>> as widely adapted as some seem to think.
>
>I just heard, on KFOG in San Francisco, an advertisement requesting resumes
>for "Agile" IT personnel. Note that ain't CraigsList. A radio advertisement
>is an expensive, high-end investment, on the same level as, say, beer or
>cars.
>
>(The quality of search engine may also be a factor.;)
FWIW, Dice claims: "Dice is the #1 job site for technology careers".
There may be a problem with the search engine, but I would not jump to
such a conclusion. Since Dice is such a large and heavily used system,
any problems or quirks with the search engine has probably long been
ironed out. Of course, an operator problem is something else. I just
related my experience that very few jobs that came up on my searches
even mentioning anything about XP/Agile. I did nothing to include or
exclude such results.
>
>They plugged this:
>
>http://www.solutionsiq.com/agile_dev_services.html
>
>Of course one always has to work to detect the difference between buzz-word
>compliance and "getting it", but I doubt the Bay Area will have much problem
>with that.
Buzzword compliance is always an issue, isn't it? Your assumption that
someone in the Bay Area "gets it", though, seems to beg the question
of why you are skeptical of what is returned in job searches on Dice.
In the one case, you don't want to believe that which doesn't validate
your position, and in the other, you believe what does validate it. In
neither case are the claims more or less solid.
>
>From the page (for anyone claiming there's no statistics available for such
>things):
>
>KEY BENEFITS OF AGILE:
>Agile development results in reduced time, costs and solid ROI according to
>analysis from Forrester Consulting, 2004 and Agile Methodologies Survey
>Results, Shine Technologies Pty Ltd, 2003
>
>57% reduction in costs compared to other IT solutions for similar complex
>projects.
>
>62% reduction in effort compared to alternatives, including in-house
>development and previously employed consultants.
>
>80% reduction in critical defects
>
>60% reduction in overall defects
>
>93% stated productivity was better / significantly better
>
>88% stated that quality was better / significantly better
>
>83% stated that business satisfaction was better / significantly better
Didn't Forrester make some outrageous claims about Y2K? Like, the
world was going to end? Like COBOL developers would get $150/hr (I
never even met one billed close to that!). Haven't they made many
other incorrect predictions or inaccurate claims?
All you've stated above may be accurate, but I do question the
sources.
Overall, however, you seem to take offense at my questioning the
conclusion Vlad had reached. In what way has he demonstrated that the
results would not be the same or any less likely to occur when using
traditional methods? Other than pointing out that it has not been
widely adopted, though heavily discussed for the past eight or so
years and wonder why, I, in no way, said that there is anything wrong
or inferior about XP/Agile. Perhaps it was my questioning the
conclusion of its superiority in the analogy he provided that has so
upset you. If not, please explain how his experience could not have
occurred, or was even unlikely to occur, in traditional development.
And, please do not use the straw man argument of pure waterfall. You
know no one has done that in a generation, if ever.
Finally, I do not appreciate the ad-hominem attack. It is a logical
fallacy and I can only wonder why you did it. I come here for honest,
rigorous discussion and debate. My posting was not idle gainsaying in
the least. Thankfully Vlad understood that. I did not deserve the
attack.
Phlip
> Buzzword compliance is always an issue, isn't it? Your assumption that
> someone in the Bay Area "gets it", though, seems to beg the question
> of why you are skeptical of what is returned in job searches on Dice.
> In the one case, you don't want to believe that which doesn't validate
> your position, and in the other, you believe what does validate it. In
> neither case are the claims more or less solid.
Not at all. My fallacy is "argumentum ad autoritatem", where the Authority
is the Bay Area.
>>83% stated that business satisfaction was better / significantly better
>
> Didn't Forrester make some outrageous claims about Y2K? Like, the
> world was going to end? Like COBOL developers would get $150/hr (I
> never even met one billed close to that!). Haven't they made many
> other incorrect predictions or inaccurate claims?
Excluded middle. Forrester could have a corporate pessimism streak, in which
case their Agile numbers could err on the side of pessimism, as did their
Y2K numbers.
Also, check the motive. If Forrester sells Agile solutions, and sold Y2K
solutions, they have motivation to over-report Y2K problems and over-report
Agile problems.
> All you've stated above may be accurate, but I do question the
> sources.
>
> Overall, however, you seem to take offense at my questioning the
> conclusion Vlad had reached. In what way has he demonstrated that the
> results would not be the same or any less likely to occur when using
> traditional methods?
He didn't claim that. He posted a spot-check about one situation in one
project. He's not a liar, damned liar, or statistition.
You previous reported working a couple of bum projects that called
themselves Agile. I have too, but I knew the difference between the bum
parts and the Agile parts. If a team skips a critical practice, such as
Onsite Customer, they are asking for trouble, and will get there rapidly and
with a low defect rate!
> Other than pointing out that it has not been
> widely adopted
The problem with this theory is that it _has_ been widely adopted. 8 years
ago it was on one Wiki. Now it's on the radio (in the Bay Area), and in >100
books. So claiming it's not widely adopted is probably /argumentum ad
lubruscem acidus/. Sour grapes. ;-)
--
Isaac Gouy
I don't think you're succeeding in making the point you're trying to
make. Why wouldn't there be "a useful feedback loop" between the
requirements specialists who knew the existing requirements and the
customers who knew the business - that would cover #1, #2 & #3.
The "developers who knew the code" clause becomes important in #4
because of "if it's not too time-consuming" - however, what I hear #4
to say is if it's free we want it but we don't want to give up anything
else to get it.
> Consider the hypothetical scenario where that "averaged ge
> factors" case were to have been covered in the original story. In that
> case, if the requirement were complex, I'd have possibly asked for it
> to be broken into a separate story when we went over the stories at the
> start of the sprint, or even before I began working on the story if
> that's when I realized that this requirement was complex and did not
> impede the remainder of the story. It would be a red flag for the
> customer to note that this would take more time than they might want us
> to spend, and would given him/her a chance to remove or simplify that
> feature. Or not, but at least it would be an informed decision.
Again, why wouldn't that same scenario play out with requirements
specialists rather than programmers, with the customer choosing between
requirements.
(When we talk about "a chance to remove or simplify that feature" it
seem's like the customer already decided there was a requirement and
prioritised it, and now we are looking at different solutions to meet
that requirement.)
Vladimir Levin
> > Isaac Gouy wrote:
> I don't think you're succeeding in making the point you're trying to
> make. Why wouldn't there be "a useful feedback loop" between the
> requirements specialists who knew the existing requirements and the
In our case, the customers already know the existing requirements since
they are assigned to the project full time. In other words, the role of
customer is equivalent to the role of requirements specialist. I think
the point of contention between us comes down to how much can and
should be planned before a developer picks up a story for coding. In my
opinion, the example I brought up illustrates how much harder it is to
anticipate certain scenarios when developing requirements vs. writing
the code to satisfy those requirements. I feel it is useful to have a
close interaction between the customer (who is also the requirement
specialist) and the developer who designs and writes the code.
Vladimir Levin
bill turner wrote:
> On 23 Jun 2006 06:11:25 -0700, "Vladimir Levin" <vlad....@gmail.com>
> wrote:
Perhaps, even, it would
> have been more likely in a traditional process because there would
> have been more opportune moments: during requirements elicitation and
> analysis, during specification, during detail design: or during
> implementation. In the process you described, there were far fewer
> opportunities: story writing, story review, implmentation.
Clearly you disagree (and that's fine) but the point I am making is
that I believe it is much easier to recognize gaps in requirements when
one is forced to write code to implement those requirements. That's the
principle I was trying to illustrate. It is very easy to see when
confronted with an "else" statement that one hasn't got a requirement
for. Trying to ferret out those types of details during a successive
process of analysis, specification, and detailed design, in my opinion,
would likely lead to finding a lot of "fat" that was driven more by the
need for the process to justify itself, but could easily miss something
like what I described. Ultimately though, I was just describing a
specific experience that I thought I'd share as being representative.
If you (and others of course) don't find it very convicing, perhaps I
will try to share further experiences in the future. I had another good
experience today but it would require more background information than
the last one did and I don't want to get into descriptions that are too
domain-specific. If you're specifically interested, email me and we can
discuss it by email.
> negative experiences. I feel XP/Agile probably has its place, but that
> it is another tool to know and use when appropriate, and probably
> adpat to experiences on the ground.
As far as Agile is concerned, the first value expressed in the
manifesto is "Individuals and interactions over processes and tools."
Ipso facto, agile processes should be adaptable. For example, if an
actual future user of the app is not available to play a customer role,
find people who can stand in. The practices of XP are more rigid. For
example, if you don't want to do paired programming, that's fine, but
are you really doing XP, or rolling your own agile methodology? Of
course, if you only have a team of 2 or 3 developers, I'd imagine even
that fundamental XP practice ought to be tempered... Note that the
process we are using on my current project certainly has its fair share
of planning. We have a list of all of the features the whole
application is expected to have. This list (the product backlog to use
scrum terminology) is very high-level and is used for strategic
purposes to determine who much work needs to be done. Items in this
list would frequently break down into numerous stories, and those are
developed each month, then reviewed by the customers before being
introduced for development. So there is certainly planning, just not to
the same level of detail that I think you'd prefer to see.
Isaac Gouy
We both seem to be repeating ourselves.
I think I understand your opinion, what I don't understand is why you
think that example supports your opinion. (Really I'm saying it's no
where near as good an example as you seem to think.)
In the example, you review a requirement and raise an issue about the
requirement. There doesn't seem to be anything to suggest that your
programming knowledge, or the act of programming, were a factor. afaict
The missing factor was systematic review.
Perhaps the "review committee of subject experts" know too much about
the subject to ask the dumb questions that need to be asked.
Vladimir Levin
> I think I understand your opinion, what I don't understand is why you
> think that example supports your opinion. (Really I'm saying it's no
> where near as good an example as you seem to think.)
Well, the reason I felt it was a good example, or at least worth
posting about, is that I don't think the particular scenario I
described was especially likely to be raised in a semantic review.
Especially if you know the app we are working on, there are so many
little intricacies along these lines, that quite a few are bound to be
missed. I ran into another one today. We had a requirement to direct
allocations to downstream facilities. I and another developer raised a
question about whether directing to units was supposed to work (answer:
no) and this triggered our customers to think of what happens when you
try to direct to a unit in the upcoming story in question - Now they
may add a story for that, I don't know. So there are a lot of ways that
things can interact. When we developers bring these kinds of things up,
it's because we hit a test or a piece of code that raises the question.
It's not something we think of abstractly, and I think even an expert
is likely to miss these kinds of interaction without having a solid
substrate to deal with. Now, developers are not the only ones who can
bring to bear this kind of feedback. QA people also are excellent
sources - "What happens when I try this weird combination of options?"
I'll try not to repeat myself any further, because it's ok for us to
disagree and I don't want to just keep saying the same thing over and
over again... but for what it's worth, that's how I see things: That
when you are working with the code or the app directly, you are likely
to see things that are much harder to come up with in the abstract kind
of environment where you're discussing things in general with people in
a room or drawing diagrams on a whiteboard. Not that those activities
aren't necessary - the requirements have to come from somewhere, but
just what I've said before, that the developers' feedback is a valuable
aspect of the whole feedback loop. If that doesn't make sense, then I
apologise if I've wasted your time. I do think my example is of some
value, though I'm by no means trying to say it's something earth
shattering.
brxsep
Having been in the IT business for 25 years as PA and Business Analyst
(BA), would like to provide my own observations on this issue. So
everyone knows where I am coming from my experience range for one team
system development (back in the VAC mini days) to large scale multiple
million dollar projects using formal waterfalls methodology and now
transitioning to RUP.
What you have run up with is good observations and attention to detail
on your part. Add to that a flexiable environment/application allowing
an extension of the the current interation. In the formal waterfall or
under a good PM methodology, the situation would results in a change
management and dollar amount/schedule adjustment with sign-off by the
business area/project owner. Or, marked as a for future enhancement.
For myself, XP is not new. Done that with COBOL and IMS
transactions/screens, it comes down to what methodology/development
environment your dealing with. One other factor, and maybe I missed it
in the discussion, are the database constraints. If the DBA is on the
team, great, adding a new column to an existing table a snap. However,
if the organization is more formal where structure changes are limited
to say three times/year, then the process is by nature formal. Be it
Waterfalls, RUP, XP or SCRUM, you need to get to the sign-off.
But, there is still lots of room for development by prototype.
Overall, users tend to be of the "show me what you got and I'll tell
you what I don't want" then "this is everything I every want." The
bottom line is think quick, listen quick and toss back a picture to'em.
Use a white board, take a digital picture, cut and paste, pencil and a
quarter (when you don't have an IBM bubble template handy for Structure
Analysis) , anything to get the visual to your end user.
Good luck, have fun, I sure am in the RUPerroom.
Phlip
> For myself, XP is not new. Done that with COBOL and IMS
> transactions/screens
You did Test Driven Development with COBOL? How many edits did you make
before running all tests?
--
Isaac Gouy
Vladimir Levin wrote:
> > > > > Isaac Gouy wrote:
> > I think I understand your opinion, what I don't understand is why you
> > think that example supports your opinion. (Really I'm saying it's no
> > where near as good an example as you seem to think.)
>
> Well, the reason I felt it was a good example, or at least worth
> posting about, is that I don't think the particular scenario I
> described was especially likely to be raised in a semantic review.
> Especially if you know the app we are working on, there are so many
> little intricacies along these lines, that quite a few are bound to be
> missed. I ran into another one today. We had a requirement to direct
> allocations to downstream facilities. I and another developer raised a
> question about whether directing to units was supposed to work (answer:
> no) and this triggered our customers to think of what happens when you
> try to direct to a unit in the upcoming story in question - Now they
> may add a story for that, I don't know. So there are a lot of ways that
> things can interact. When we developers bring these kinds of things up,
> it's because we hit a test or a piece of code that raises the question.
Here's the missing piece - you've said "I and another developer
raised..." you didn't say I'd started writing a test and got stuck
because I didn't know whether directing to units was supposed to work
so...
afaik you're just reading the requirement, and another technically
competent outsider would also read the requirement and realize there
was something missing.
> It's not something we think of abstractly, and I think even an expert
> is likely to miss these kinds of interaction without having a solid
> substrate to deal with.
"an expert" - an expert in what?
> Now, developers are not the only ones who can
> bring to bear this kind of feedback. QA people also are excellent
> sources - "What happens when I try this weird combination of options?"
> I'll try not to repeat myself any further, because it's ok for us to
> disagree and I don't want to just keep saying the same thing over and
> over again... but for what it's worth, that's how I see things: That
> when you are working with the code or the app directly, you are likely
> to see things that are much harder to come up with in the abstract kind
> of environment where you're discussing things in general with people in
> a room or drawing diagrams on a whiteboard. Not that those activities
> aren't necessary - the requirements have to come from somewhere, but
> just what I've said before, that the developers' feedback is a valuable
> aspect of the whole feedback loop. If that doesn't make sense, then I
> apologise if I've wasted your time. I do think my example is of some
> value, though I'm by no means trying to say it's something earth
> shattering.
There's an assumption here about "abstract kind of environment where
you're discussing things in general" - what happens if you replace it
by an assumption about drilling-down into the detail of the
requirement, can you then see how someone would start asking the same
kind of questions you've been describing.
Vladimir Levin
Isaac Gouy wrote:
> Here's the missing piece - you've said "I and another developer
> raised..." you didn't say I'd started writing a test and got stuck
> because I didn't know whether directing to units was supposed to work
> so...
I should have been more clear. We did in fact raise this issue because
of a failing test while working on a different story. In this case we
were trying to direct to a unit while testing something else. The test
failed, and we asked if we should be able to direct to a unit. The
customers told us "no" but then realized this might be something to
consider for the story they had just written which allows one to direct
to higher level facilities.
> There's an assumption here about "abstract kind of environment where
> you're discussing things in general" - what happens if you replace it
> by an assumption about drilling-down into the detail of the
> requirement, can you then see how someone would start asking the same
> kind of questions you've been describing.
It's not that I don't think people should try to be as thorough as they
can when developing stories (or requirements, or whatever the right
term is). The examples I have brought up are meant to illustrate that
"drilling down into the detail of requirements" is not good enough when
developing complex applications. The feedback loop I've tried to show
is intented to handle the risk of missing requirements when the story
is being defined. Exhaustive planning in the requirements stage has
additional potential risks, such as analysis paralysis.
If I understand your objections properly, you seem to be saying that a
better approach would be for customers and requirement engineers to
carefully put together stories well ahead of development in a separate
phase. Once these requirements are prepared, the developers will not
have access to the customers any longer and will be expected to develop
the code only from the specs given and possibly from discussions with a
small number of requirement engineers. Presumably, issues like the ones
I've described simply won't occur. If they do, I assume the process for
dealing with them would be much more formal and time consuming than the
one I've descrived. I think that's not the right way to do development,
but you're entitled to your opinion of course. I've tried my best to
use a few examples to illustrate why such an approach would not
generally be useful, but I certainly am not claiming any kind of proof.
Still, I would be interested in finding out what kinds of experiences
you in turn have and what kind of approach works better for you than
the one I've outlined.
Isaac Gouy
Vladimir Levin wrote:
> Isaac Gouy wrote:
> > Here's the missing piece - you've said "I and another developer
> > raised..." you didn't say I'd started writing a test and got stuck
> > because I didn't know whether directing to units was supposed to work
> > so...
>
> I should have been more clear. We did in fact raise this issue because
> of a failing test while working on a different story. In this case we
> were trying to direct to a unit while testing something else. The test
> failed, and we asked if we should be able to direct to a unit.
That is essential information, the example just doesn't make any sense
if you miss that out :-)
I had two objections
- first, there was no mention of working with the code (you've fixed
that)
- second, too many negative assumptions about what would happen in
different scenarios (you're still doing that).
What you have is an example of your approach working - it's a mistake
to confuse that with an example of some other approach not working.
"I think that's not the right way to do development"
imo Without knowing the detail of what and who and why, it's silly to
be dogmatic about the right way to do development. Different projects,
different approaches.
brxsep
Yes. I developed the basic requirements to blend in a new line of
business to existing IMS transactions. At the time, there was lots of
filler space available on the record type in question so at PA just did
a redefine. For the screens, we were using a screen painter, the only
thing that was of value out of the then failed application of RAD. The
key here was the PA was there on the application from a few years
starting at unit test.
Myself, I was a member of the testing team. Together, we had gone
through the JADS, which as a BA believe someone from the techincal
team, SA or PA, should be in all user meetings from the get go. The
key is we were vets in terms of this application and we "smok'en" with
the development.
In terms of edits or data validation rules, the entire database had 900
of which maybe 20 applied to the screen. The edits were its own
application that sat between the GUI and the pending status records and
the active records. To edit data, an existing record was copied to a
pending status while production read the active one. At commit time,
the pending record overwrite the active record. It wa all take care of
by codes in the first three bytes of the record after the database key.
Zeros were active, non zeros indicated a pending record. But, both
shared the same basic database key so it all hung together.
The point I wnat to make here is the flexibility to include more
features is a factor or the organizational structure, methodology and
staff. The PA has every right to dig it and say "its not in the spec"
and push it off to the next interaction given the schedule of the
workload.
Take care.
bill turner
wrote:
Again, I think I have been misunderstood. Perhaps I am communicating
poorly. Your experience is great, but if I had kept track through all
my projects, there would have been many eureka moments experienced by
myself or others. What you described was, to me, merely someone
thinking creatively at an opportune moment, a moment when such
thoughts would be well received. I don't feel that the process used
had anything to do with that insight.
As for the rest, I only tried to explain my thoughts and experiences
with XP/Agile to demonstrate that I am not out attacking the process
as is frequently assumed when one questions any praise XP/Agile has
received. I am a very critical thinker. You made a claim. I questioned
whether or not the claim was justified by your experience. I felt not.
As for the level of detail I require, the level of detail varies with
circumstances. The process I use varies with circumstances. XP/Agile
is a tool. TDD is a tool. Structured Analysis is a tool. Like any
profession, we need to know which tool is the right tool for the job.
bill turner
>bill turner wrote:
>
>> Buzzword compliance is always an issue, isn't it? Your assumption that
>> someone in the Bay Area "gets it", though, seems to beg the question
>> of why you are skeptical of what is returned in job searches on Dice.
>> In the one case, you don't want to believe that which doesn't validate
>> your position, and in the other, you believe what does validate it. In
>> neither case are the claims more or less solid.
>
>Not at all. My fallacy is "argumentum ad autoritatem", where the Authority
>is the Bay Area.
I don't see how a radio advertisement could be stronger proof than the
postings of thousands of jobs. I am not saying it is worth less,
either, considering the market in which it played.
>
>>>83% stated that business satisfaction was better / significantly better
>>
>> Didn't Forrester make some outrageous claims about Y2K? Like, the
>> world was going to end? Like COBOL developers would get $150/hr (I
>> never even met one billed close to that!). Haven't they made many
>> other incorrect predictions or inaccurate claims?
>
>Excluded middle. Forrester could have a corporate pessimism streak, in which
>case their Agile numbers could err on the side of pessimism, as did their
>Y2K numbers.
>
>Also, check the motive. If Forrester sells Agile solutions, and sold Y2K
>solutions, they have motivation to over-report Y2K problems and over-report
>Agile problems.
I don't really understand what you are saying here. I liken evidence
provided by Forrester or Garner to someone on the witness stand. Once
they have made claims that are dubious, it is hard to take them at
their word on anything else.
>
>> All you've stated above may be accurate, but I do question the
>> sources.
>>
>> Overall, however, you seem to take offense at my questioning the
>> conclusion Vlad had reached. In what way has he demonstrated that the
>> results would not be the same or any less likely to occur when using
>> traditional methods?
>
>He didn't claim that. He posted a spot-check about one situation in one
>project. He's not a liar, damned liar, or statistition.
He didn't? It sure seems he did:
"I had a good experience in which three of us, a customer and two
developers, worked together to flesh out a requirement in a way that
simply would not be possible in a more traditional environment heavy
on up-front requirement preparation".
That sure sounds like a claim the results would not be the same using
traditional methods.
>He posted a spot-check about one situation in one
>project. He's not a liar, damned liar, or statistition.
What? Are you suggesting I've besmirched his reputation? Certainly not
my intent. If he felt I've called him a liar, I have not heard it. So,
I assume you are just using the name of a famous book to make clear
that Vlad was not performing a controlled experiement. I never took it
as such. I just question his conclusion based upon his experience. It
does not necessarily follow that the GUI expert asks a smart question
that the question would not have been asked in a traditional form of
development, or that it would not have been implemented. Nothing in
his experience suggests that in any way. If it does, please point it
out to me. Or, perhaps Vlad could chime in with greater detail to
explain why he believes it would not have occurred in a traditional
development environment. Until that time, there just is scant evidence
for the conclusion.
>
>You previous reported working a couple of bum projects that called
>themselves Agile. I have too, but I knew the difference between the bum
>parts and the Agile parts. If a team skips a critical practice, such as
>Onsite Customer, they are asking for trouble, and will get there rapidly and
>with a low defect rate!
>
>> Other than pointing out that it has not been
>> widely adopted
>
>The problem with this theory is that it _has_ been widely adopted. 8 years
>ago it was on one Wiki. Now it's on the radio (in the Bay Area), and in >100
>books. So claiming it's not widely adopted is probably /argumentum ad
>lubruscem acidus/. Sour grapes. ;-)
What are you talking about? Sour grapes?
Number of websites means little. There are hundreds of websites on
many given subjects. I'll bet you could find hundreds of websites
talking about Structured techniques, or RUP, or PSP. The same would
likely be true of books. Radio advertising? I don't know what that
means.
What does matter is the number of people developing using said
techniques. I suggested the informal survey of job requirements on a
general purpose software tech job board to determine how widely it has
been adopted. It is my belief, and I could be wrong about this, that
if not methodology or process is mentioned, then a traditional method
is likely used. My experience with doing a number of searches, many of
those recently since I am currently trying to find a new project,
indicates that knowledge of XP/Agile is not a common requirement, nor
is it mentioned very often as the environment used. That would seem to
indicate that it is not widely adopted. Of course, it could also mean
that the types of jobs posted on Dice are not very representative,
too.
Phlip
>>He didn't claim that. He posted a spot-check about one situation in one
>>project. He's not a liar, damned liar, or statistition.
>
> He didn't? It sure seems he did:
>
> "I had a good experience in which three of us, a customer and two
> developers, worked together to flesh out a requirement in a way that
> simply would not be possible in a more traditional environment heavy
> on up-front requirement preparation".
>
> That sure sounds like a claim the results would not be the same using
> traditional methods.
He said "experience", and you accuse him of implying proof but without data.
In context, he found that working together was better than a "traditional
environment" that forbade working together.
rmoldsk...@online.no
>
> In context, he found that working together was better than a "traditional
> environment" that forbade working together.
>
Are you in all seriousness making the claim that "traditional"
forms of software development forbids people from working together?
--
Leif Roar Moldskred,
bemused
Phlip
I gave a lecture on TDD to SCQAA last week, and I took time with the crowd
to learn what they were doing.
Let's say that many software projects use an "Analyst" role to collate
feature requests into scheduled, specified features. The programmers would
implement the features and produce a new release. Then QA roles would
take the release and verify that its features matched the input
specifications.
One major complaint among the QA people was access to the Analysts. They
often felt the written documentation was incomplete, both from programmers
and Analysts, and they felt the Analysts were unavailable for hard
questions. These people were often working other projects by the time QA
got the release. Apparently, they couldn't just interrupt them and take
time away from their current projects.
So regardless what we call these processes, or where their bosses learned
them, these people felt like they were _forbidden_ to collaborate with the
people most qualified to optimize and streamline their situations.
--
Phlip
David Lightstone
"Phlip" <phli...@yahoo.com> wrote in message
news:frvog.109764$H71.1...@newssvr13.news.prodigy.com...
When did the management demigods declare working together forbidden? Did I
miss something, or are you just engaging in a little silly rhetoric?
David Lightstone
"Phlip" <phli...@gEEEmail.com> wrote in message
news:pan.2006.06.28....@gEEEmail.com...
> rmoldskr+usenet wrote:
>
>> In comp.software-eng Phlip <phli...@yahoo.com> wrote:
>
>>> In context, he found that working together was better than a
>>> "traditional environment" that forbade working together.
>
>> Are you in all seriousness making the claim that "traditional" forms of
>> software development forbids people from working together?
>
> I gave a lecture on TDD to SCQAA last week, and I took time with the crowd
> to learn what they were doing.
Does this mean you really have begun to study the software development
process that is actually being followed (as opposed to believing that
everyone does waterfall)? (oh how I do hope so).
>
> Let's say that many software projects use an "Analyst" role to collate
> feature requests into scheduled, specified features.
Opps I'm made an assumption. Back to believing things that are dubous
(concealed wqaterwall assumption now in play)
> The programmers would
> implement the features and produce a new release. Then QA roles would
> take the release and verify that its features matched the input
> specifications.
So someone wrote something down, but, as you indicate below of very low
quality
>
> One major complaint among the QA people was access to the Analysts. They
> often felt the written documentation was incomplete, both from programmers
> and Analysts, and they felt the Analysts were unavailable for hard
> questions. These people were often working other projects by the time QA
> got the release. Apparently, they couldn't just interrupt them and take
> time away from their current projects.
And just how does this impact coding (the work of agile coders)
>
> So regardless what we call these processes, or where their bosses learned
> them, these people felt like they were _forbidden_ to collaborate with the
> people most qualified to optimize and streamline their situations.
That is not a software process problem, it is a complete and total
managerial failure. (not doing any verification reviews) Certainly not your
classical waterfall
>
> --
> Phlip
brxsep
Yes it can. Depending on the shop. 20 years ago I was yelled out by
the SA because I BA, former PA, asked a PA a simple what heppens when
X=1 in program Z? From that point on, had to write my question on
paper, send to typing, review the draft, approve it, receive final, put
in interoffice mail (going from the left side of the buidling to the
right side where SA was located). Only, then were the technical folks
ALLOWED to walk over and give me the answer. Total time, 7 to 10 days
due to work load from the typing pool and mood of SA. Back then, BAs
and users just got in the way of coding.
Said PA till the day he retired logged everything he did in steno pads
book by 15 minute blocks "for my protection" he would say. IT has come
a LONG way with all these neat methods that cut developement time and
gives the business what they need when they need it. Those were NOT
the happy days.
Phlip
> Yes it can. Depending on the shop. 20 years ago I was yelled out by
> the SA because I BA, former PA, asked a PA a simple what heppens when
> X=1 in program Z? From that point on, had to write my question on
> paper, send to typing, review the draft, approve it, receive final...
I would have so quit. Thanks for the anecdote.
And just after this post, a colleague (with whome I am sometimes allowed to
collaborate!) sent me this:
http://thedailywtf.com/forums/thread/79265.aspx
Subject: Not allowed to communicate something critically important to the
users.
Ah, but all these anecdotes are just us holding up that reliable old
Waterfall straw-person, right guys?
brxsep
Aaa, End Users, they just get in the way of good project.
bill turner
Phlip, if he was only speaking of his experience, I would never have
posted in the first place. However, he drew a conclusion. Once he drew
that conclusion, I looked for the argument to support the conclusion.
None was forthcoming. That is what I objected to.
Perhaps a little thing like logical argumentation just gets in the way
of a good conclusion?
Guess what! I've had an experience this past week. A developer came
over and said the place to which data was being written was not wise.
We decided it should be ftp'd to a different server. Hey! That would
have been an impossible result to reach using XP/Agile!
Based upon the arguments provided, either my conclusion is valid, or
Vlad's conclusion is not. I've supported my conclusion with as much
evidence as Vlad did his. So, what is it, Phlip? Have we both reached
sound conclusions and provided sound arguments to support those
conclusions? Or, have we both failed to soundly support the
conclusions? I suppose you could try to claim that Vlad supported his
conclusion while I did not mine, but then we are back where I began,
how is his conclusion supported by anything he has written?
Phlip
> Phlip, if he was only speaking of his experience, I would never have
> posted in the first place. However, he drew a conclusion. Once he drew
> that conclusion, I looked for the argument to support the conclusion.
> None was forthcoming. That is what I objected to.
>
> Perhaps a little thing like logical argumentation just gets in the way
> of a good conclusion?
You have read such rhetorical flourishes many times in all the literature of
software engineering. Our discipline is not a hard science; it has no
experiments or proofs. Aphorisms and thought experiments are all we have.
Don't play the victim.
Isaac Gouy
Phlip, this seems to be your argument
If software engineering was a hard science, then software engineering
would have experiments or proofs.
Software engineering is not a hard science.
Therefore, software engineering does not have experiments or proofs.
Have I stated your argument correctly?
David Lightstone
> bill turner wrote:
>
>> Phlip, if he was only speaking of his experience, I would never have
>> posted in the first place. However, he drew a conclusion. Once he drew
>> that conclusion, I looked for the argument to support the conclusion.
>> None was forthcoming. That is what I objected to.
>>
>> Perhaps a little thing like logical argumentation just gets in the way
>> of a good conclusion?
>
> You have read such rhetorical flourishes many times in all the literature
> of software engineering. Our discipline is not a hard science; it has no
> experiments or proofs. Aphorisms and thought experiments are all we have.
>
(1) Economics is not a hard science, yet somehow the practioneers have been
able to reach valid conclusions (ie not based on ideology) about significant
problems. The techniques are based upon rather sophisticated application of
statistics. See the book Freakonomics for some insight.
(2) Whether these techniques have been applied to the practices of software
engineering is unknown to me. Whether they have even been applied to the
practices of management is likewise unknown to me. I doubt seriously if they
ever will. Ideologies never like their foundations to be examined carefully
Isaac Gouy
Phlip knows that software engineering has experiments. In this
newsgroup, Phlip has referred to a paper titled "Experiment about
Test-first programming".
http://groups.google.com/group/comp.software.extreme-programming/msg/e3d1d0aa82f2d726
It doesn't seem to me that Phlip is being sincere.
David Lightstone
"Isaac Gouy" <ig...@yahoo.com> wrote in message
news:1152035959.4...@b68g2000cwa.googlegroups.com...
I have long held that opinion
>
Vladimir Levin
> What you have is an example of your approach working - it's a mistake
> to confuse that with an example of some other approach not working.
What I attempted to show was one or two examples where fleshing our
requirements
in a dyamic way with interaction between developers and customers
worked well. I hoped to indicate that such a mechanism was more
flexible than one which substantially separated requirements gathering
from programming. My point was to show that requirements that had been
carefully put together in good faith by experts and subsequently
reviewed were never the less leaky, at least in the case of a general
business application like the one I am working on. The leaks were
plugged in a quick and efficient way because the customers and
developers interacted, which is a key facet of most agile
methodologies. Your objection appears to be that these leaks would not
have occured the requirements were prepared more carefully with the aid
of a requirements engineer who knew to ask the right questions. My
response is that I don't believe that would be true, but that it's
always an objection one case raise. In reality, there are so many
possible questions one can raise that the requirements process would
take too long for that approach to be effective. In fact, this is just
a personal feeling, but I believe that the more one spends time on
requirements, the more difficult it becomes to be thorough in one's
approach. Check lists become larger and more unwieldly as one goes one,
and one spends increasing amounts of time on trivial details. In an
agile approach, the meat of the story is presented to the developer,
and from there the developer and the customer work out the details so
that each story is completed to the custmer's satisfaction.
Phlip
> What I attempted to show was one or two examples where fleshing our
> requirements
> in a dynamic way with interaction between developers and customers
> worked well. I hoped to indicate that such a mechanism was more flexible
> than one which substantially separated requirements gathering from
> programming. My point was to show that requirements that had been
> carefully put together in good faith by experts and subsequently
> reviewed were never the less leaky, at least in the case of a general
> business application like the one I am working on.
Well, I'm sorry to inform you, but that's because you are not smart enough.
If you were as smart as me, you could have rigorously collected many more
requirements, up front, and you could have safely and carefully reviewed
all of them to make sure they didn't have any errors or omissions.
The only reason you are promoting this Agile nonsense is because you are
too stupid to use a real, disciplined methodology.
--
Phlop
Ron Jeffries
<david._NoSp...@prodigy.net> wrote:
> Isaac Gouy wrote:
>> It doesn't seem to me that Phlip is being sincere.
>
>I have long held that opinion
I have long held an opinion about you two ...
But let me ask, to be sure. Are either of you interested in reaching any kind of
common understanding of the subject, which is, in this case, whether Agile
works, and if so, how and in what context?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
S Perryman
news:1b9ma2lulpqpb1208...@4ax.com...
> But let me ask, to be sure. Are either of you interested in reaching any
> kind of
> common understanding of the subject, which is, in this case, whether Agile
> works, and if so, how and in what context?
Does it work ?? And if so, how and in what context ??
And what development methods is "Agile" actually better than ??
Regards,
Steven Perryman
David Lightstone
> <david._NoSp...@prodigy.net> wrote:
>
>> Isaac Gouy wrote:
>
>>> It doesn't seem to me that Phlip is being sincere.
>>
>>I have long held that opinion
>
> I have long held an opinion about you two ...
>
> But let me ask, to be sure. Are either of you interested in reaching any
> kind of
> common understanding of the subject, which is, in this case, whether Agile
> works, and if so, how and in what context?
Oh I would say that we each have a common understanding of the subject. From
a practical perspective (with the goal being to develop software
successafully) probably as well as you (except neither of us writes books
advocating its use)
Being one the principle advocates of the practices, I would expect you to be
more than familiar with situations where it has failed to achieved the
claimed results than either of us (the difference being perhaps that you
carefully spin the failure as misapplications of the principles) From your
prespective, not mine, - whenever the current 10 or so principles are not
satisfied (a conciese and meaningless answer, see Extreme Programming
Refactored: the case againes XP for a humorous articulation of some known
problems). From my perspective - anytime that project is exploratory in
nature (see Ould's book, Managing Software Quality and Business Risk if you
don't recognize the term); anytime the organization functions under Matrix
management; anytime a death march is being conducted. anytime the
development team has not done a similar project;
As for you claimed goal -characterizing Agile like methods for purposes of
predicting whether its use will achieve a successful development or not - it
is a fools errand. Why do you even suggest that it be attempted?
Isaac Gouy
Yes I understood that was what you were attempting to show; and in one
case you are providing a case study example of something that actually
happened, and in the other case you are providing assumptions.
You provide an example of a possible missing requirement being
identified while unit testing some other story. When in your current
approach would you be able to say that there was a missing requirement
which had /not/ been identified by the customers or developers?
Ron Jeffries
<david._NoSp...@prodigy.net> wrote:
>> But let me ask, to be sure. Are either of you interested in reaching any
>> kind of
>> common understanding of the subject, which is, in this case, whether Agile
>> works, and if so, how and in what context?
>
>Oh I would say that we each have a common understanding of the subject. From
>a practical perspective (with the goal being to develop software
>successafully) probably as well as you (except neither of us writes books
>advocating its use)
I'm willing to accept that you (two) have some experience in developing software
effectively. There are many ways to do that.
Your words do not lead me to predict that either of you have any significant
experience using Agile methods, nor that you really have any interest in doing
so. That's why I asked.
>
>Being one the principle advocates of the practices, I would expect you to be
>more than familiar with situations where it has failed to achieved the
>claimed results than either of us (the difference being perhaps that you
>carefully spin the failure as misapplications of the principles)
Think about it, David. I make a living advising software teams on how to do a
better job of providing software to the people who ask it of them. I can only
succeed at that insofar as my advice works. I can make no money offering poor
advice. So I have no vested interest whatsoever in spinning Agile: it wouldn't
help me to do so.
>From your
>prespective, not mine, - whenever the current 10 or so principles are not
>satisfied (a conciese and meaningless answer, see Extreme Programming
>Refactored: the case againes XP for a humorous articulation of some known
>problems).
The book you reference is written by individuals who are selling their own
method, and who have never tried XP. For a better analysis of Agile and XP, I'd
recommend either Pete McBreen's book, Questioning Extreme Programming, or Boehm
and Turner, Balancing Agility and Discipline. Neither of these books quite nails
it either, in my opinion, again because the authors are speculating about what
might happen rather than reporting what does happen.
> From my perspective - anytime that project is exploratory in
>nature (see Ould's book, Managing Software Quality and Business Risk if you
>don't recognize the term); anytime the organization functions under Matrix
>management; anytime a death march is being conducted. anytime the
>development team has not done a similar project;
This sentence has no very. Any of those times ... what? Agile wouldn't work? Or
would? Agile itself is exploratory, incremental and iterative. It works
wonderfully in exploratory projects as far as I can tell. I've seen Agile work
in a Matrix situation, though I don't consider it to be a good idea. As far as
I'm concerned, nothing works in a Death March, but there are some Agile
techniques I'd use if I had to be on one.
I don't see why Agile would be particularly bad if a team had no prior
experience. I'm not sure what would be better and would be interested to hear
your thinking. I'd think that a project style that focused on delivering running
tested features every week or two would be a pretty good way to track how things
were going with an inexperienced team, and wonder what you'd think was better.
>
>As for you claimed goal -characterizing Agile like methods for purposes of
>predicting whether its use will achieve a successful development or not - it
>is a fools errand. Why do you even suggest that it be attempted?
I don't think I claimed that as my goal. I asked whether you had any sincere
interest in reaching a common understanding of the subject. You didn't answer
that. Have you, or not?
Ron Jeffries
>> But let me ask, to be sure. Are either of you interested in reaching any
>> kind of
>> common understanding of the subject, which is, in this case, whether Agile
>> works, and if so, how and in what context?
>
>Does it work ?? And if so, how and in what context ??
Yes. I've personally seen it work on IT projects, in web development projects,
in the creation of software products for sale, and in a number of other areas.
My colleagues in the Agile community report successes in many other areas such
as mathematical research projects, embedded medical and telecomms, and even a
bit of cool stuff at NASA.
That is not to say that there can't be success in all of those areas using other
methods: there can be, have been, and will be.
At a very simple, almost simplistic level, Agile works by focusing on iterative
delivery of continually refined versions of the program, each one ready to ship.
At that level it is not terribly different from Boehm's spiral model, or Gilb's
Evo.
Agile is characterized as well by a focus on the people and their interactions,
more than on an imposed specific process. It measures progress by the production
of software rather than by milestones such as requirements or design completion.
In my experience it works best in smaller teams, probably because as the team
size grows, the person-to-person communication model suffers and you have to
fall back on more documentation and more procedure, which moves you away from
Agile.
>
>And what development methods is "Agile" actually better than ??
Better? Depends what we mean by better. It tends to produce far more visible
evidence of progress. It is likely to have something shippable, and something of
value, earlier than many if not most other processes.
Many teams are reporting higher quality -- reduced defects -- over what they
were doing before, though it might be that what they were doing before wasn't a
very good process. However, to work at all, Agile needs a lot of intensive
testing, preferably automated, because everything in the code is potentially
changing every week. The result of this testing might credibly be faster
feedback on the state of quality, and a better ability to keep quality high.
So I'd say that Agile offers particular benefits in those areas. Again, it's not
the only way to do software: I've done quite a few other ways successfully
myself. It's my personal favorite for the kinds of projects I'm familiar with,
and it seems clear on the face of it that many of the practices are applicable
over a very wide range of projects.
What do you think?
S Perryman
> On Wed, 5 Jul 2006 08:44:10 +0100, "S Perryman" <a...@a.net> wrote:
RJ>But let me ask, to be sure. Are either of you interested in reaching any
RJ>kind of
RJ>common understanding of the subject, which is, in this case, whether
Agile
RJ>works, and if so, how and in what context?
>>Does it work ?? And if so, how and in what context ??
> Yes. I've personally seen it work on IT projects, in web development
> projects,
> in the creation of software products for sale, and in a number of other
> areas.
> My colleagues in the Agile community report successes in many other areas
> such
> as mathematical research projects, embedded medical and telecomms, and
> even a
> bit of cool stuff at NASA.
You will need to be a bit more specific than that with the systems that have
been developed (especially for telecoms which is where I live) .
> That is not to say that there can't be success in all of those areas using
> other
> methods: there can be, have been, and will be.
> At a very simple, almost simplistic level, Agile works by focusing on
> iterative
> delivery of continually refined versions of the program, each one ready to
> ship.
> At that level it is not terribly different from Boehm's spiral model, or
> Gilb's
> Evo.
So it is possible that the iterative process in general, as opposed to
specific
"Agile" methods, is the prime factor in "success" ??
Iterative development has been around for a long time (I first was involved
in
such projects in 1991) , long before "Agile" appeared on the screen.
> Agile is characterized as well by a focus on the people and their
> interactions,
> more than on an imposed specific process.
And yet several so-called "Agile" methods have an "imposed specific process"
(XP, FDD as immediate examples) .
> In my experience it works best in smaller teams, probably because as the
> team
> size grows, the person-to-person communication model suffers and you have
> to
> fall back on more documentation and more procedure, which moves you away
> from
> Agile.
For "Agile" in general, or only for specific methods ??
>>And what development methods is "Agile" actually better than ??
> Better? Depends what we mean by better. It tends to produce far more
> visible
> evidence of progress. It is likely to have something shippable, and
> something of
> value, earlier than many if not most other processes.
> Many teams are reporting higher quality -- reduced defects -- over what
> they
> were doing before, though it might be that what they were doing before
> wasn't a
> very good process.
Indeed. Most processes X are "better" than a poor process Y.
But until X and Y are given, "better" , "higher quality" etc are moot IMHO.
> However, to work at all, Agile needs a lot of intensive
> testing, preferably automated, because everything in the code is
> potentially
> changing every week. The result of this testing might credibly be faster
> feedback on the state of quality, and a better ability to keep quality
> high.
> So I'd say that Agile offers particular benefits in those areas. Again,
> it's not
> the only way to do software: I've done quite a few other ways successfully
> myself. It's my personal favorite for the kinds of projects I'm familiar
> with,
> and it seems clear on the face of it that many of the practices are
> applicable
> over a very wide range of projects.
> What do you think?
Not very convincing to me (but then what is) .
But the tone is a lot more sensible nowadays than days of yore.
Which IMHO is a lot more useful for the average reader who may wish to
examine or debate.
Regards,
Steven Perryman
Phlip
> What do you think?
Are you /that/ bored??
S Perryman
> Ron Jeffries wrote:
>> What do you think?
> Are you /that/ bored??
And Usenets' XP muppet is never far behind ...
David Lightstone
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSp...@prodigy.net> wrote:
>
>>> But let me ask, to be sure. Are either of you interested in reaching any
>>> kind of
>>> common understanding of the subject, which is, in this case, whether
>>> Agile
>>> works, and if so, how and in what context?
>>
snip
>>
>>As for you claimed goal -characterizing Agile like methods for purposes
>>of
>>predicting whether its use will achieve a successful development or not -
>>it
>>is a fools errand. Why do you even suggest that it be attempted?
>
> I don't think I claimed that as my goal. I asked whether you had any
> sincere
> interest in reaching a common understanding of the subject. You didn't
> answer
> that. Have you, or not?
Having I failed to understand your goal here?
Does not
">>> But let me ask, to be sure. Are either of you interested in reaching
any
>>> kind of
>>> common understanding of the subject, which is, in this case, whether
>>> Agile
>>> works, and if so, how and in what context?"
mean the same thing as
">>As for you claimed goal -characterizing Agile like methods for purposes
of
>>predicting whether its use will achieve a successful development or not "
Perhaps you should avoid trying to remember what you have posted and read a
bit more carefully.
The oversight could readily be confused with a serving of stone soup (that
is the term Phlip uses for a slow gradual shift in subjects conducted for
nefarious purposes is it not?)
David Lightstone
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSp...@prodigy.net> wrote:
>
>>> But let me ask, to be sure. Are either of you interested in reaching any
>>> kind of
>>> common understanding of the subject, which is, in this case, whether
>>> Agile
>>> works, and if so, how and in what context?
>>
>
> I don't think I claimed that as my goal. I asked whether you had any
> sincere
> interest in reaching a common understanding of the subject. You didn't
> answer
> that. Have you, or not?
>
If and when you find the content of a posting that I place to be insincere,
deceptive or misleading, do be so kind as to so indicate that. Until then
your efforts to imply that my postings are not sincere by means of inuendo
are something that I can only call insincere. Clean up your act
David Lightstone
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSp...@prodigy.net> wrote:
>
>>> But let me ask, to be sure. Are either of you interested in reaching any
>>> kind of
>>> common understanding of the subject, which is, in this case, whether
>>> Agile
>>> works, and if so, how and in what context?
>>
>>Oh I would say that we each have a common understanding of the subject.
>>From
>>a practical perspective (with the goal being to develop software
>>successafully) probably as well as you (except neither of us writes books
>>advocating its use)
>
> I'm willing to accept that you (two) have some experience in developing
> software
> effectively. There are many ways to do that.
>
> Your words do not lead me to predict that either of you have any
> significant
> experience using Agile methods, nor that you really have any interest in
> doing
> so. That's why I asked.
We have been down this road before both you know it and I know it. The only
people who probably don't know it are the readers of this and the previous
posting
The various gambits are
(1) Try it you will like it - until you try it you have no standing
(2) I (Ron Jeffries) am a keeper of the flame, I do not recognize you as
being able to understand what the flame is all about - you just don't know
(3) You just are not helping you are not sincere
Without doubt you are an expert on Agile like methods. You also seem to
believe that you are an astute evaluator of the skills, experience and
training of others. Whether this is true or not I do not know, nor do I care
to know. In this case 2 and 3 are applicable
>>
>>Being one the principle advocates of the practices, I would expect you to
>>be
>>more than familiar with situations where it has failed to achieved the
>>claimed results than either of us (the difference being perhaps that you
>>carefully spin the failure as misapplications of the principles)
>
> Think about it, David. I make a living advising software teams on how to
> do a
> better job of providing software to the people who ask it of them. I can
> only
> succeed at that insofar as my advice works. I can make no money offering
> poor
> advice. So I have no vested interest whatsoever in spinning Agile: it
> wouldn't
> help me to do so.
>
One could just as readily argue that because you earn your living advising
you must make great effort to avoid doing or saying anything that might
offend potential customers. Just how does avoidance differ from spin?
AndrewMcDonagh
> "Ron Jeffries" <ronje...@acm.org> wrote in message
> news:hlcpa2dgon5cubtbd...@4ax.com...
>
>> On Wed, 5 Jul 2006 08:44:10 +0100, "S Perryman" <a...@a.net> wrote:
>
> RJ>But let me ask, to be sure. Are either of you interested in reaching any
> RJ>kind of
> RJ>common understanding of the subject, which is, in this case, whether
> Agile
> RJ>works, and if so, how and in what context?
>
>>> Does it work ?? And if so, how and in what context ??
>
>> Yes. I've personally seen it work on IT projects, in web development
>> projects,
>> in the creation of software products for sale, and in a number of other
>> areas.
>> My colleagues in the Agile community report successes in many other areas
>> such
>> as mathematical research projects, embedded medical and telecomms, and
>> even a
>> bit of cool stuff at NASA.
>
> You will need to be a bit more specific than that with the systems that have
> been developed (especially for telecoms which is where I live) .
>
This might interest you....
http://www.vanu.com/resources/publications/Basestation_SDRFpaper.pdf
Aside from that, I worked an an OMC-R for a pico-cell basestation
Controller, which was TDDed and ran using XP - the project turned around
from being a deathmarch when we started using XP.
>
>> That is not to say that there can't be success in all of those areas using
>> other
>> methods: there can be, have been, and will be.
>
>> At a very simple, almost simplistic level, Agile works by focusing on
>> iterative
>> delivery of continually refined versions of the program, each one ready to
>> ship.
>> At that level it is not terribly different from Boehm's spiral model, or
>> Gilb's
>> Evo.
>
> So it is possible that the iterative process in general, as opposed to
> specific
> "Agile" methods, is the prime factor in "success" ??
>
> Iterative development has been around for a long time (I first was involved
> in
> such projects in 1991) , long before "Agile" appeared on the screen.
>
It certainly has - see Royce's paper from 1970 above
snipped...
Andrew
>
> Regards,
> Steven Perryman
>
>
David Lightstone
>>From your
>>prespective, not mine, - whenever the current 10 or so principles are not
>>satisfied (a conciese and meaningless answer, see Extreme Programming
>>Refactored: the case againes XP for a humorous articulation of some known
>>problems).
>
> The book you reference is written by individuals who are selling their own
> method, and who have never tried XP. For a better analysis of Agile and
> XP, I'd
> recommend either Pete McBreen's book, Questioning Extreme Programming, or
> Boehm
> and Turner, Balancing Agility and Discipline. Neither of these books quite
> nails
> it either, in my opinion, again because the authors are speculating about
> what
> might happen rather than reporting what does happen.
Everyone speculates about what will happen, some are just better at it than
others. You speculate all that time. Your principle speculation would be
something of the form - Practice the 10 principles, you will succeed. There
is no evidence for this being true. There is no evidence for this being
wrong. There may not even be a successful XP project (the participants may
claim to have followed the XP practices, but as we all know claim and
reality can be different). There are only explinations as to how the
principles were violated (hence the project can be ignored as evidence
either pro or con) when a project fails. This observation is the keeper of
the flame phenomena. (success is ours, failure theirs) In the set of all
projects, the only projects that failed were not practicing XP, ergo XP will
be successful (everything else has been excluded). In addition to being
excelent rhetoric, it is something other than valid reasoning.
Whether the authors of Extreme Programming Refactored are or are not
attempting to convince the reader to practice some other unmentioned method
is something I did not consider. They certainly gave no indication of having
a method of their own (other than being employeed as some company which may
or may not be marketing a method). Perhaps they are engaged in an extremely
sophisticated nefarious con. The certainly fooled me, they even fooled the
publishers of the book. That is what you would care for the reader to
believe is it not? Sorry, but it is a bit farfetched to me to accept as
fact.
I have no reason to doubt your claim that they have never even tried XP, I
also have no reason to believe that trying XP is a precondition for
evaluating the suitability or appropriateness of using XP.
David Lightstone
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSp...@prodigy.net> wrote:
>
>>> But let me ask, to be sure. Are either of you interested in reaching any
>>> kind of
>>> common understanding of the subject, which is, in this case, whether
>>> Agile
>>> works, and if so, how and in what context?
>>
>>From your
>>prespective, not mine, - whenever the current 10 or so principles are not
>>satisfied (a conciese and meaningless answer, see Extreme Programming
>>Refactored: the case againes XP for a humorous articulation of some known
>>problems).
>
snip
>
>> From my perspective - anytime that project is exploratory in
>>nature (see Ould's book, Managing Software Quality and Business Risk if
>>you
>>don't recognize the term); anytime the organization functions under Matrix
>>management; anytime a death march is being conducted. anytime the
>>development team has not done a similar project;
>
> This sentence has no very. Any of those times ... what? Agile wouldn't
> work? Or
> would? Agile itself is exploratory, incremental and iterative. It works
> wonderfully in exploratory projects as far as I can tell. I've seen Agile
> work
> in a Matrix situation, though I don't consider it to be a good idea. As
> far as
> I'm concerned, nothing works in a Death March, but there are some Agile
> techniques I'd use if I had to be on one.
You asked whether Agile like methods would work. Optimism is a great thing
to have, but risk management demands that failures be considered. I gave you
situations under which the methods would fail. I guess that means it does
not always work. More importantly I also indicated that the question was a
fools errand. You just will never be able to characterize the orgainization,
projects and process out there sufficiently well so as to be able to make
the predictions you wish to make (the how and what context). The choice of
the 3 was to achieve coverage (how many projects are not one of the 3? ie
failue is always a possibility don't pretend otherwise)
Sorry Ron, by its very nature exploratory implies the distinct possibility
of a complete and total failure. That possibility is why I provided
reference to Ould's book. (so that my revference point could be understoud).
As an exploratory method XP can fail, yet there are no examples of XP having
failed. Are there examples of XP failing on an exploratory project?
Having seen it succeed in a Matrixed organization, have you also seen it
fail?
David Lightstone
> On Wed, 05 Jul 2006 10:57:01 GMT, "David Lightstone"
> <david._NoSp...@prodigy.net> wrote:
>
>
> I don't see why Agile would be particularly bad if a team had no prior
> experience. I'm not sure what would be better and would be interested to
> hear
> your thinking. I'd think that a project style that focused on delivering
> running
> tested features every week or two would be a pretty good way to track how
> things
> were going with an inexperienced team, and wonder what you'd think was
> better.
>>
Add projects in which the 2 week operational cycle is infesible to the menu
of situations under which Agile like methods will not work.
I don't get to decide what would be better, I don't really care. One plays
the situation as best as one can. Changing the situation is just not my
goal. As they say in golf (a game I do not play) - You must play the ball
where it lands (you just don't get to changes your employeers golf course to
suit your pleasure). If the organization is screwed up, it is screwed up. I
can not do anything about it.
Systematic tracking against well defined goals, you have been in
organizations that do that, outstanding. Never seen it done, don't expect
to, Heck in most places being able to keep up with the requirement changes
is as good as things get. The best I can expect to see it the proverbial bug
hopper (aka Rational Clearquest or MSK Integrity Manager). Bugs go in,
people get tasks, more bugs get discovered, repeat until delivery or project
canceled. Mass production hacking at best. Punctuated perhaps by a coherent
architecture
Now change the words requirements and bugs to story. Considering that the
mass production hacking operations always insist on rigerous testing (but
sometime redefine the meaning of the word rigerous or make exceptions when
deadline approach) not much of a difference from the Agile like methods.
This would be especially so if you are practicing continuous integration. In
theory you aways have a working system after any change (can you be any more
Agile than that). In practice you always have a piece of crap to fix (there
is a process requireing rigerous testing and there is what is actually done)
Isaac Gouy
Ron Jeffries wrote:
> On Tue, 04 Jul 2006 20:14:02 GMT, "David Lightstone"
> <david._NoSp...@prodigy.net> wrote:
>
> > Isaac Gouy wrote:
>
> >> It doesn't seem to me that Phlip is being sincere.
> >
> >I have long held that opinion
>
> I have long held an opinion about you two ...
I don't know David Lightstone from Adam - we aren't a couple - malign
him separately from me.
A few weeks ago, I made a specific comment about a false claim made by
Phlip
http://groups.google.com/group/comp.software.extreme-programming/msg/9d8edc6ab5fe81c6
A week ago, you corrected another of Phlip's false claims
http://groups.yahoo.com/group/extremeprogramming/message/120894
A few days ago, I made a specific comment following a specific
statement made by Phlip - "Our discipline is not a hard science; it has
no experiments or proofs. Aphorisms and thought experiments are all we
have."
In response, you've voiced the baseless generalization that I am
insincere. You haven't provided any example to support your opinion,
it's no more than malicious gossip.
>
> But let me ask, to be sure. Are either of you interested in reaching any kind of
> common understanding of the subject, which is, in this case, whether Agile
> works, and if so, how and in what context?
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.
When Agile works and when Agile doesn't work.
There's nothing novel about recognising limitations - "No project is
started by the timebox teams that does not fit within the scope of the
methodology. Because of this, DuPont is able to claim that none of its
timebox projects have been failures."
David Lightstone
"David Lightstone" <david._NoSp...@prodigy.net> wrote in message
news:xwgrg.60514$Lm5....@newssvr12.news.prodigy.com...
One clarification is needed (failure is theirs because they did not know or
follow the proper procedure)
Ron Jeffries
>> Yes. I've personally seen it work on IT projects, in web development
>> projects,
>> in the creation of software products for sale, and in a number of other
>> areas.
>> My colleagues in the Agile community report successes in many other areas
>> such
>> as mathematical research projects, embedded medical and telecomms, and
>> even a
>> bit of cool stuff at NASA.
>
>You will need to be a bit more specific than that with the systems that have
>been developed (especially for telecoms which is where I live) .
Why will I need to do that? Still, one place to look would be at the work of Ron
Crocker at Motorola.
>
>
>> That is not to say that there can't be success in all of those areas using
>> other
>> methods: there can be, have been, and will be.
>
>> At a very simple, almost simplistic level, Agile works by focusing on
>> iterative
>> delivery of continually refined versions of the program, each one ready to
>> ship.
>> At that level it is not terribly different from Boehm's spiral model, or
>> Gilb's
>> Evo.
>
>So it is possible that the iterative process in general, as opposed to
>specific
>"Agile" methods, is the prime factor in "success" ??
Well, certainly it's possible. Agile can be seen as a set of ideas for making
iterative work smoothly. What if that were true?
>
>Iterative development has been around for a long time (I first was involved
>in
>such projects in 1991) , long before "Agile" appeared on the screen.
Yes. That's well recognized. There is little new in Agile, other than the
arrangement of practices that have been seen to work. Part of how those of us
who were in Agile at the beginning were confident enough to go ahead was that we
were doing things we had already tried and found to work.
>
>
>> Agile is characterized as well by a focus on the people and their
>> interactions,
>> more than on an imposed specific process.
>
>And yet several so-called "Agile" methods have an "imposed specific process"
>(XP, FDD as immediate examples) .
XP does not have an imposed process, nor a specific process for that matter. FDD
does, and to me, it feels less like what I perceive Agile to be than other
processes do. In the eyes of people who know FDD better than I do, it qualifies.
I could go either way on it.
The main thing is that it contains a set of good ideas that seem to work well in
concert and that are consistent with the values and principles of Agile.
Probably that it seems to work well is the main thing to recommend it -- to me
that would be the main thing to recommend any process.
>
>
>> In my experience it works best in smaller teams, probably because as the
>> team
>> size grows, the person-to-person communication model suffers and you have
>> to
>> fall back on more documentation and more procedure, which moves you away
>> from
>> Agile.
>
>For "Agile" in general, or only for specific methods ??
I don't understand the question. I was saying that in larger teams one tends to
need more documentation and procedure, which Agile processes generally try to
minimize. As you're forced to move more in the direction of docs and procs, it
seems to me that you become, perforce, less agile.
There are people who specialize in Agile for larger teams, such as the
aforementioned Ron Crocker, and Glen Alleman. They know far more about that than
I do, or than I want to.
What was I supposed to be convincing you of? I was just answering what seemed to
be reasonable questions.
>
>But the tone is a lot more sensible nowadays than days of yore.
>Which IMHO is a lot more useful for the average reader who may wish to
>examine or debate.
Maybe you're just finally getting mellow in your old age. ;->
Regards,
Ron Jeffries
Let's see, where does argumentum ad hominem fit into the hierarchy of useful
argument?
Ron Jeffries
>Ron Jeffries wrote:
>
>> What do you think?
>
>Are you /that/ bored??
No. I'm one of Ron's bots. I can't get bored. This is what I do.
Ron Jeffries
<david._NoSp...@prodigy.net> wrote:
>Does not
>> But let me ask, to be sure. Are either of you interested in reaching
>> any kind of common understanding of the subject, which is, in this case, whether
>> Agile works, and if so, how and in what context?"
>
>mean the same thing as
>>As for you claimed goal -characterizing Agile like methods for purposes
>>of predicting whether its use will achieve a successful development or not
Not remotely. One is a question about your motivation, not that I have much
doubt about it. The other is a statement from you suggesting that my question
claims a goal, which it manifestly does not.
Done with you, David. Thanks for playing.
Ron Jeffries
<david._NoSp...@prodigy.net> wrote:
>If and when you find the content of a posting that I place to be insincere,
>deceptive or misleading, do be so kind as to so indicate that. Until then
>your efforts to imply that my postings are not sincere by means of inuendo
>are something that I can only call insincere. Clean up your act
I find the posting quoted above to be insincere, deceptive, and misleading. I
also find it to be quite typical of your work.
Ron Jeffries
>In response, you've voiced the baseless generalization that I am
>insincere. You haven't provided any example to support your opinion,
>it's no more than malicious gossip.
My opinion is that you are not interested in learning about agile and how it
works. I base that opinion on a lack of examples, namely any examples where you
have asked any questions about Agile, offered any experienced opinions, or made
any on-topic contributions (that I can recall) of any kind. All you have done,
to my recollection, is to reiterate your opinions about the quality of material
in Larman's book, and then take potshots at people who find it to be valuable
anyway.
I am convinced, by experience, that you have no sincere interest in Agile or XP.
Whether you are generally sincere about some things, I can't guess. I'm
convinced that you're consistent in some significant ways, which may or may not
reflect sincerity.
I'd like to have some new contributions from you, by way of asking questions
about Agile or telling us about your experiences with it. I don't expect to get
what I'd like in this regard, but nonetheless, that's what I'd like.
S Perryman
> On Thu, 6 Jul 2006 11:54:10 +0100, "S Perryman" <a...@a.net> wrote:
RJ>What do you think?
Usenet XP muppet> Are you /that/ bored??
>>And Usenets' XP muppet is never far behind ...
> Let's see, where does argumentum ad hominem fit into the hierarchy of
> useful
> argument?
1. Don't become an apologist for Usenets' XP muppet.
2. Where in the "hierarchy of useful argument" do you believe the sentence
"Are you /that/ bored" exists ... ??
Regards,
Steven Perryman
S Perryman
news:e8k3no$tkb$1...@news.freedom2surf.net...
>S Perryman wrote:
>> "Ron Jeffries" <ronje...@acm.org> wrote in message
>> news:hlcpa2dgon5cubtbd...@4ax.com...
>>> Yes. I've personally seen it work on IT projects, in web development
>>> projects,
>>> in the creation of software products for sale, and in a number of other
>>> areas.
>>> My colleagues in the Agile community report successes in many other
>>> areas such
>>> as mathematical research projects, embedded medical and telecomms, and
>>> even a
>>> bit of cool stuff at NASA.
>> You will need to be a bit more specific than that with the systems that
>> have
>> been developed (especially for telecoms which is where I live) .
> This might interest you....
> http://www.vanu.com/resources/publications/Basestation_SDRFpaper.pdf
>
> Aside from that, I worked an an OMC-R for a pico-cell basestation
> Controller, which was TDDed and ran using XP - the project turned around
> from being a deathmarch when we started using XP.
And how would you compare both of the above to similar systems
that I have worked on using iterative development :
UMTS base station controllers performing 250-500,000 busy hour call
attempts.
Regards,
Steven Perryman
S Perryman
> On Thu, 6 Jul 2006 08:45:59 +0100, "S Perryman" <a...@a.net> wrote:
RJ>Yes. I've personally seen it work on IT projects, in web development
RJ>projects,
RJ>in the creation of software products for sale, and in a number of other
RJ>areas.
RJ>My colleagues in the Agile community report successes in many other areas
RJ>such
RJ>as mathematical research projects, embedded medical and telecomms, and
RJ>even a bit of cool stuff at NASA.
>>You will need to be a bit more specific than that with the systems that
>>have
>>been developed (especially for telecoms which is where I live) .
> Why will I need to do that?
Because any trivial system can be touted as a "success" in telecoms.
Still, one volunteer eventually came forward.
> Still, one place to look would be at the work of Ron Crocker at Motorola.
A quick search gave me the title of one paper :
"The 5 reasons XP can't scale and what to do about them"
Unfortunately the website (www.xp2001.org/conference/program.html) appears
to
be attacked by the filter here as having a high weighting of pornographic
phrases
(honestly) .
So until the weekend, if you have time perhaps you can list those five
reasons
here for us.
>>So it is possible that the iterative process in general, as opposed to
>>specific "Agile" methods, is the prime factor in "success" ??
> Well, certainly it's possible. Agile can be seen as a set of ideas for
> making
> iterative work smoothly. What if that were true?
If iterative development lead to say 60% improvement, and <insert your
favourite "Agile" method here> lead to 65% improvement, one can examine
the extra 5% more closely (especially wrt ROI) .
>>> Agile is characterized as well by a focus on the people and their
>>> interactions, more than on an imposed specific process.
>>And yet several so-called "Agile" methods have an "imposed specific
>>process"
>>(XP, FDD as immediate examples) .
> XP does not have an imposed process, nor a specific process for that
> matter.
Customer must write "acceptance tests" first.
Test-first approach. Pair programming. Etc.
I do iterative development, and none of those projects have any requirement
to
work in any of the above modes.
> FDD
> does, and to me, it feels less like what I perceive Agile to be than other
> processes do. In the eyes of people who know FDD better than I do, it
> qualifies.
> I could go either way on it.
You will find many FDD practitioners will consider the method very agile
indeed.
But they don't need the method to be called "Agile" .
>>> In my experience it works best in smaller teams, probably because as the
>>> team
>>> size grows, the person-to-person communication model suffers and you
>>> have
>>> to
>>> fall back on more documentation and more procedure, which moves you away
>>> from
>>> Agile.
>>For "Agile" in general, or only for specific methods ??
> I don't understand the question.
I think you do, Ron.
> I was saying that in larger teams one tends to
> need more documentation and procedure, which Agile processes generally try
> to
> minimize. As you're forced to move more in the direction of docs and
> procs, it
> seems to me that you become, perforce, less agile.
And yet FDD proved otherwise. On all counts.
It worked on its "poster-child" project (Singapore bank) .
And that project then increased in scale, and it worked again.
Perhaps that is the difference : people should be asking about *agile*
methods
that work across a spectrum of projects, as opposed to "Agile" methods.
> There are people who specialize in Agile for larger teams, such as the
> aforementioned Ron Crocker, and Glen Alleman. They know far more about
> that than
> I do, or than I want to.
Why do you not want to know about how "Agile" may succeed or fail in larger
teams, or projects ??
RJ> What do you think?
>>Not very convincing to me (but then what is) .
> What was I supposed to be convincing you of?
The "success" of "Agile" methods. ??
> I was just answering what seemed to be reasonable questions.
Consider them answered.
Regards,
Steven Perryman
David Lightstone
> On Thu, 06 Jul 2006 22:08:02 GMT, "David Lightstone"
> <david._NoSp...@prodigy.net> wrote:
>
>>If and when you find the content of a posting that I place to be
>>insincere,
>>deceptive or misleading, do be so kind as to so indicate that. Until then
>>your efforts to imply that my postings are not sincere by means of inuendo
>>are something that I can only call insincere. Clean up your act
>
> I find the posting quoted above to be insincere, deceptive, and
> misleading. I
> also find it to be quite typical of your work.
Kind of recursive, responding that way isn't it. Now you just have to hope
the rest of the world agrees with you, don't you Ron
Bjorn Reese
> "The 5 reasons XP can't scale and what to do about them"
You can find the article via
http://citeseer.ist.psu.edu/532056.html
The top 5 reasons are:
<quote>
o Pair Programming expands quadratically
o Planning Game is too introspective
o Collective Ownership leads to chaos
o Metaphor is too weak
o No means to effectively coordinate multiple teams exists in the
other practices
</quote>
The author goes on to suggest solutions to these problems, but I am not
sure that XP practitioners would call the result XP:
<quote>
[The Team Coordination layer] can be viewed as a layering [of] the
project structure, where at the highest level in the hierarchy there
is a collection fo teams being coordinated. At the bottom are the
individual teams that are doing the work.
[...]
The Team Coordination layer replaces the Metaphor, Pair Programming,
Collective Ownership, and On-site Customer practices with
"Architecture Lite"
[...]
An Architecture Lite fully describes the system architecture but at a
high level of abstraction. The description includes both structural
and behavioral aspects of the system.
</quote>
The "Team Coordination layer" sounds like a normal organization
hierarchy, and "Architecture Lite" like a normal system architecture.
--
mail1dotstofanetdotdk
David Lightstone
There is an expression I like to remember when I read articles such as that
one. It goes something like - When you stand on the shoulders of giants it
is best to be humble.
What pray tell is the big deal here? You have a massive waterfall or Big Up
Front Design (BUFD) project (implement GSM). You see a little itty-bitty
activity within that BUFD project, conduct an Agile type implementation and
you taut it as a poster child for Agile development.When you stand on the
shoulders of giants is most definitely applicable. T
As far as I can tell the must important information in the entire paper is
"This material is based upon work supported by the National Science
Foundation under Award Number DMI-0110460, Amendment No: 001". Other than
to implement GSM there has to be a reason for the funding decision. It is
not obvious to me. I would like to know that reason
On any International Communication task such as a GSM or UMTS development
the things other than pair programming would be ground zero preconditions
for even considering the project. If you don't have compatibility, you can't
sell. You establish compatibility by passing the well formulated tests that
the international community has negociated as being the standard for
acceptability. That act of negociation is generally called BUFD by those you
favor Agile type development. To now claim the fruits of that BUFD effort as
though they never occured is, well, chuptza (Yiddish word probably spelled
wrong)
That is Test Driven Development is an inherant characteristics of such
developments. That is you have both a protocal and protocal implementation
validation specification on day 1. It is just implementation, no changes in
the stories, just grind it out type development. Hard arduous task to do the
implementation, no doubt about it. There may be some serious challenges (the
latency issue mentioned), to call it Agile, that is just marketing hype
David Lightstone
> On Thu, 06 Jul 2006 22:05:10 GMT, "David Lightstone"
> <david._NoSp...@prodigy.net> wrote:
>
>>Does not
>
>>> But let me ask, to be sure. Are either of you interested in reaching
>>> any kind of common understanding of the subject, which is, in this case,
>>> whether
>>> Agile works, and if so, how and in what context?"
>>
>>mean the same thing as
>
>>>As for you claimed goal -characterizing Agile like methods for purposes
>>>of predicting whether its use will achieve a successful development or
>>>not
>
> Not remotely. One is a question about your motivation, not that I have
> much
> doubt about it. The other is a statement from you suggesting that my
> question
> claims a goal, which it manifestly does not.
>
> Done with you, David. Thanks for playing.
Funny, I didn't preceive it as a question about motivation. I/m certain
some will agree with your interpretation, some with mine. Thats life
Phlip
> The author goes on to suggest solutions to these problems, but I am not
> sure that XP practitioners would call the result XP:
Start small. If you actually need big, this analysis will tell you, very soon.
Break the project up into two or more small XP projects, each team
treating the next team as the customer.
--
Phlip
Peter Little
news:44ae346a$0$1961$ba62...@nntp02.dk.telia.net...
> S Perryman wrote:
> > "The 5 reasons XP can't scale and what to do about them"
> You can find the article via
> http://citeseer.ist.psu.edu/532056.html
Thanks.
I'll have a read and then comment.
I don't know whether Mr Crocker has any other papers, but I'll try and
see.
Regards,
Steven Perryman
Peter Little
> "AndrewMcDonagh" <new...@amc.com> wrote in message
> news:e8k3no$tkb$1...@news.freedom2surf.net...
>>S Perryman wrote:
>
>> "Ron Jeffries" <ronje...@acm.org> wrote in message
>>> news:hlcpa2dgon5cubtbd...@4ax.com...
RJ>Yes. I've personally seen it work on IT projects, in web development
RJ>projects,
RJ> in the creation of software products for sale, and in a number of other
RJ>areas.
RJ>My colleagues in the Agile community report successes in many other
RJ> areas such
RJ> as mathematical research projects, embedded medical and telecomms, and
RJ>even a bit of cool stuff at NASA.
>>> You will need to be a bit more specific than that with the systems that
>>> have
>>> been developed (especially for telecoms which is where I live) .
>> This might interest you....
>> http://www.vanu.com/resources/publications/Basestation_SDRFpaper.pdf
> There is an expression I like to remember when I read articles such as
that
> one. It goes something like - When you stand on the shoulders of giants it
> is best to be humble.
> What pray tell is the big deal here? You have a massive waterfall or Big
Up
> Front Design (BUFD) project (implement GSM). You see a little itty-bitty
> activity within that BUFD project, conduct an Agile type implementation
and
> you taut it as a poster child for Agile development.When you stand on the
> shoulders of giants is most definitely applicable. T
> As far as I can tell the must important information in the entire paper is
> "This material is based upon work supported by the National Science
> Foundation under Award Number DMI-0110460, Amendment No: 001". Other than
> to implement GSM there has to be a reason for the funding decision. It is
> not obvious to me. I would like to know that reason
For me, the picture of the kit was more telling.
Looked like a micro-cell at best.
> On any International Communication task such as a GSM or UMTS development
> the things other than pair programming would be ground zero preconditions
> for even considering the project. If you don't have compatibility, you
can't
> sell. You establish compatibility by passing the well formulated tests
that
> the international community has negociated as being the standard for
> acceptability.
And here is the killer ... there are no tests !!!
When I first started work on UMTS in 1999, there was nothing like what
there is now for UEs etc (3GPP 34.108, 34-123x etc) .
And the customer (a real one, Vodafone, you may have heard of them)
certainly had nothing other than generalities (the radio plane configs
they wanted to use for CS/PS services etc, requests to conform to the
current versions of the stds as best one could and still get kit out) .
And the 3GPP (the requirements source) were changing their stuff massively
on a quarterly basis (not often you can prove this, but masochists can go
the 3GPP website and do diffs on all the docs from one quarter to the next -
1999 to 2001 - all x0,000 pages of them :-) ) .
Same thing is happening now.
Try the current WiMAX Forum specs.
And then find me all the protocol test cases (abstract, TTCN etc) that
describe conformance for the ASN Gateway, and basestation.
Regards,
Steven Perryman
David Lightstone
"Peter Little" <pe...@glendenecc.fsnet.co.uk> wrote in message
news:e8m5fu$rgg$1...@nntp.aioe.org...
The example is GSM, not UMTS. Second generation wireless, not 3rd .
>
> When I first started work on UMTS in 1999, there was nothing like what
> there is now for UEs etc (3GPP 34.108, 34-123x etc) .
It is difficult for me to believe that the starting point for their GSM
development was any less well developed than your current UMTS developing
point. That is something like the UEs that you now have, only on day 1. I
can not say if there are fully developed test suites for the various
protocals. I would expect that by now test equipment would exist for the
Layer 2 and Layer 3 protocols. Its not my current skill set. Did once work
X.25 (1991) we most devinitely had Layer 1 and Layer 2 analyzers and tests
suites (developed as a comercial product by HP)
>
> And the customer (a real one, Vodafone, you may have heard of them)
> certainly had nothing other than generalities (the radio plane configs
> they wanted to use for CS/PS services etc, requests to conform to the
> current versions of the stds as best one could and still get kit out) .
Fortunately you only had to understand the standards rather than write them
>
> And the 3GPP (the requirements source) were changing their stuff massively
> on a quarterly basis (not often you can prove this, but masochists can go
> the 3GPP website and do diffs on all the docs from one quarter to the
> next -
> 1999 to 2001 - all x0,000 pages of them :-) ) .
I have no doubt that the requirements are massive and changing. I will bet
that Vodafone was hopping mad each time the standards changes. I will also
bet that the system architecture was quite stable (ie no need for massive
refactoring, the prefered? Agile strategy for dealing with change). Anything
other than a well thought out architeture would be ignoring the history of
the industry
>
>
> Same thing is happening now.
>
> Try the current WiMAX Forum specs.
> And then find me all the protocol test cases (abstract, TTCN etc) that
> describe conformance for the ASN Gateway, and basestation.
I do not have extensive experience with UMTS, just a little device driver
that managed both transmitter control and transmit power for a WCDMA handset
chip set. (the time sensitive algorithms were done in the ASIC that the
driver controller, so I was able to avoid a systematic reading of the
applicable specification. My lead was kind enough to have both summarized
the things I really neaded to understand, and to highlight that applicable
sections of the specification) As tasks go, probably no big deal. Didn't get
directly involved with the Layer 2 or Layer 3 type stuff.
The RF guys did have access to a rather expensive (> 100k) Anaritsu
(probably spelled wrong) layer 1 (physical layer) message packet decoder.
(this would be in 2005). You don't build those kind of tools on a whim. You
don't buy those kind of tools on a whim. Somebody must have decided that the
physical layer protocols were stable.
The guys developing layer 2 and 3 seems to be working from a well developed
game plan. That is they had three activities to address
(1) Develop algorithms
(2) Develop algorithm tests (Unit level)
(3) Develop chip set validation suite (ie simulate a base station, use the
simulation capabilities to run the various protocol exchanges)
I guess you probably could call it test driven, it certainly was not Agile
(the development was well planned, they knew what I would be implementing
before I arrived, I was told on day 1, but probably didn't understand
enough to appreciate how well things were thought out for about 2 weeks).
As a risk managment stategy we did a daily full regression tests of all code
developed (validation suite, unit tests and production intent). Change a
test or change an algorithm incorrectly and you would soon learn about it. I
don't ever expect to see such a development strategy again. The did it right
by comparison with the other projects upon which I have worked.
>
>
> Regards,
> Steven Perryman
>
>
Ron Jeffries
>The author goes on to suggest solutions to these problems, but I am not
>sure that XP practitioners would call the result XP:
We might not, But there's little doubt that it's Agile.
S Perryman
> "Peter Little" <pe...@glendenecc.fsnet.co.uk> wrote in message
> news:e8m5fu$rgg$1...@nntp.aioe.org...
>> "David Lightstone" <david._NoSp...@prodigy.net> wrote in message
>> news:nWqrg.192$2v....@newssvr25.news.prodigy.net...
>>> On any International Communication task such as a GSM or UMTS
>>> development
>>> the things other than pair programming would be ground zero
>>> preconditions
>>> for even considering the project. If you don't have compatibility, you
>>> can't
>>> sell. You establish compatibility by passing the well formulated tests
>>> that
>>> the international community has negociated as being the standard for
>>> acceptability.
>> And here is the killer ... there are no tests !!!
> The example is GSM, not UMTS. Second generation wireless, not 3rd .
Correct. And UMTS obviously is now similarly stable.
>> When I first started work on UMTS in 1999, there was nothing like what
>> there is now for UEs etc (3GPP 34.108, 34-123x etc) .
> It is difficult for me to believe that the starting point for their GSM
> development was any less well developed than your current UMTS developing
> point.
Indeed.
They are working on a stable subject domain of many years, with armies of
conformance tests already existing.
Quite a contrast for my days of 1999 (domain volatility, system size etc) .
>> And the customer (a real one, Vodafone, you may have heard of them)
>> certainly had nothing other than generalities (the radio plane configs
>> they wanted to use for CS/PS services etc, requests to conform to the
>> current versions of the stds as best one could and still get kit out) .
> Fortunately you only had to understand the standards rather than write
> them
:-)
>> And the 3GPP (the requirements source) were changing their stuff
>> massively
>> on a quarterly basis (not often you can prove this, but masochists can go
>> the 3GPP website and do diffs on all the docs from one quarter to the
>> next -
>> 1999 to 2001 - all x0,000 pages of them :-) ) .
> I have no doubt that the requirements are massive and changing. I will bet
> that Vodafone was hopping mad each time the standards changes.
Vodafone just said best efforts etc.
Do what one can to track the standards, but some leniency as long as you
meet
the Vodafone requirements.
> I will also bet that the system architecture was quite stable (ie no need
> for massive refactoring, the prefered? Agile strategy for dealing with
> change). Anything other than a well thought out architeture would be
> ignoring the history of the industry
Well I do this weird thing called "domain analysis" .
Domain analysis has this weird trait of leading you to the design of
something that
can best be called an "essential" system architecture.
Essential system architectures have this weird trait of remaining amazingly
stable in the face of volatility.
> I do not have extensive experience with UMTS, just a little device driver
> that managed both transmitter control and transmit power for a WCDMA
> handset chip set. (the time sensitive algorithms were done in the ASIC
> that the driver controller, so I was able to avoid a systematic reading of
> the applicable specification. My lead was kind enough to have both
> summarized the things I really neaded to understand, and to highlight that
> applicable sections of the specification) As tasks go, probably no big
> deal. Didn't get directly involved with the Layer 2 or Layer 3 type stuff.
> The RF guys did have access to a rather expensive (> 100k) Anaritsu
> (probably spelled wrong) layer 1 (physical layer) message packet decoder.
> (this would be in 2005). You don't build those kind of tools on a whim.
> You don't buy those kind of tools on a whim. Somebody must have decided
> that the physical layer protocols were stable.
You mean Anritsu (one of my previous clients) .
The physical layer bods (base station, terminals, test) really do get their
heads
together and scheme to get things working. They have to, because fancy
sys/network
architectures are irrelevant if nothing goes across the air.
Sometimes I think because they practice the dark arts of RF/DSP, they become
a
law unto themselves. :-)
> The guys developing layer 2 and 3 seems to be working from a well
> developed game plan. That is they had three activities to address
> (1) Develop algorithms
> (2) Develop algorithm tests (Unit level)
> (3) Develop chip set validation suite (ie simulate a base station, use the
> simulation capabilities to run the various protocol exchanges)
> I guess you probably could call it test driven, it certainly was not Agile
> (the development was well planned, they knew what I would be implementing
> before I arrived, I was told on day 1, but probably didn't understand
> enough to appreciate how well things were thought out for about 2 weeks).
Not "Agile" at all.
A lot of up-front study is done before getting to 1, and for providing 2.
I can tell you this for fact as I am currently on assignment with a client
doing
exactly this.
And shed-loads of data is generated by 2.
But no "pass/fail" tests. Just shed-loads of results to analyse.
Regards,
Steven Perryman
Isaac Gouy
> On 6 Jul 2006 17:49:58 -0700, "Isaac Gouy" <ig...@yahoo.com> wrote:
>
> >In response, you've voiced the baseless generalization that I am
> >insincere. You haven't provided any example to support your opinion,
> >it's no more than malicious gossip.
>
> My opinion is that you are not interested in learning about agile and how it
> works. I base that opinion on a lack of examples, namely any examples where you
> have asked any questions about Agile, offered any experienced opinions, or made
> any on-topic contributions (that I can recall) of any kind. All you have done,
> to my recollection, is to reiterate your opinions about the quality of material
> in Larman's book, and then take potshots at people who find it to be valuable
> anyway.
You can have your own opinion, you can't have your own facts.
You base your opinion on faulty reasoning and faulty memory:
Faulty reasoning
- absence of evidence is not evidence of absence
- instead of accepting the burden of demonstrating that your opinion is
sound, you wrongly place a burden on others to show that your opinion
is baseless
Faulty memory
- "asked any questions about Agile"
That's so absurd it's funny! A sensible criticism would be that I ask
an endless stream of questions, and too many pointed discomforting
questions.
http://groups.google.com/group/comp.software.extreme-programming/msg/b19507d948ae79e3
- "offered any experienced opinions"
Here's an offered opinion based on experience
http://groups.google.com/group/comp.software.extreme-programming/browse_frm/thread/07e1c13cfca331c6/55d9996cf1ef8943#55d9996cf1ef8943
- "any on-topic contributions (that I can recall) of any kind"
John Roth called this on-topic contribution "An excellent observation"
http://groups.google.com/group/comp.software.extreme-programming/msg/00268e249e3513fb
Two weeks ago, I made an on-topic contribution that even drew praise
from Phlip!
http://groups.google.com/group/comp.software.extreme-programming/msg/3660bc98728e6573
> I am convinced, by experience, that you have no sincere interest in Agile or XP.
> Whether you are generally sincere about some things, I can't guess. I'm
> convinced that you're consistent in some significant ways, which may or may not
> reflect sincerity.
>
> I'd like to have some new contributions from you, by way of asking questions
> about Agile or telling us about your experiences with it. I don't expect to get
> what I'd like in this regard, but nonetheless, that's what I'd like.
You may indeed be convinced - that conviction is not based on reason or
fact.
"When the facts change, I change my mind. What do you do, sir?"
John Meynard Keynes
David Lightstone
"S Perryman" <a...@a.net> wrote in message news:e8o9co$9rv$1...@nntp.aioe.org...
I think the cornerstone of conformance tests is just an inherent
characteristics of the industry. This out of necessity
I doubt however whether this implies Test Drive Development. Nine yards and
a cloud of dust rigorous development and testing is probably more the norm
>
> Quite a contrast for my days of 1999 (domain volatility, system size etc)
> .
>
>
>>> And the customer (a real one, Vodafone, you may have heard of them)
>>> certainly had nothing other than generalities (the radio plane configs
>>> they wanted to use for CS/PS services etc, requests to conform to the
>>> current versions of the stds as best one could and still get kit out) .
>
>> Fortunately you only had to understand the standards rather than write
>> them
>
> :-)
>
>
>>> And the 3GPP (the requirements source) were changing their stuff
>>> massively
>>> on a quarterly basis (not often you can prove this, but masochists can
>>> go
>>> the 3GPP website and do diffs on all the docs from one quarter to the
>>> next -
>>> 1999 to 2001 - all x0,000 pages of them :-) ) .
>
>> I have no doubt that the requirements are massive and changing. I will
>> bet that Vodafone was hopping mad each time the standards changes.
>
> Vodafone just said best efforts etc.
> Do what one can to track the standards, but some leniency as long as you
> meet
> the Vodafone requirements.
They were realistic and reasonable. That is a nice thing to have working in
your favor. Reminds me of job descriptions which end with something like -
... and must be able to deliver results on time (anything but being
realistic)
>
>
>> I will also bet that the system architecture was quite stable (ie no need
>> for massive refactoring, the prefered? Agile strategy for dealing with
>> change). Anything other than a well thought out architeture would be
>> ignoring the history of the industry
>
> Well I do this weird thing called "domain analysis" .
>
> Domain analysis has this weird trait of leading you to the design of
> something that
> can best be called an "essential" system architecture.
>
> Essential system architectures have this weird trait of remaining
> amazingly
> stable in the face of volatility.
Not entirely certain what you mean by domain analysis it probably dovetails
into Hatley-Pirbhai's essential model or architectural model, or probably is
equivalent to something that I recognize by another name. If you do a good
analysis you will be able to get the needed stability. I will do some
referencing
just to make certain I understand the perspective
>
>
>> I do not have extensive experience with UMTS, just a little device driver
>> that managed both transmitter control and transmit power for a WCDMA
>> handset chip set. (the time sensitive algorithms were done in the ASIC
>> that the driver controller, so I was able to avoid a systematic reading
>> of the applicable specification. My lead was kind enough to have both
>> summarized the things I really neaded to understand, and to highlight
>> that applicable sections of the specification) As tasks go, probably no
>> big deal. Didn't get directly involved with the Layer 2 or Layer 3 type
>> stuff.
>
>> The RF guys did have access to a rather expensive (> 100k) Anaritsu
>> (probably spelled wrong) layer 1 (physical layer) message packet decoder.
>> (this would be in 2005). You don't build those kind of tools on a whim.
>> You don't buy those kind of tools on a whim. Somebody must have decided
>> that the physical layer protocols were stable.
>
> You mean Anritsu (one of my previous clients) .
That looks about right for the spelling. You are doing some high end type
stuff.
>
> The physical layer bods (base station, terminals, test) really do get
> their heads
> together and scheme to get things working. They have to, because fancy
> sys/network
> architectures are irrelevant if nothing goes across the air.
>
> Sometimes I think because they practice the dark arts of RF/DSP, they
> become a
> law unto themselves. :-)
I haven't dealt enough with RF types to have observed this. The one RF type
with whom I worked was a really nice fellow. He took the time to explain the
things I need to know. He took the time to indicate the hazards and risks
associated with the equipment.
>
>
>> The guys developing layer 2 and 3 seems to be working from a well
>> developed game plan. That is they had three activities to address
>> (1) Develop algorithms
>> (2) Develop algorithm tests (Unit level)
>> (3) Develop chip set validation suite (ie simulate a base station, use
>> the simulation capabilities to run the various protocol exchanges)
>
>> I guess you probably could call it test driven, it certainly was not
>> Agile (the development was well planned, they knew what I would be
>> implementing before I arrived, I was told on day 1, but probably didn't
>> understand enough to appreciate how well things were thought out for
>> about 2 weeks).
>
> Not "Agile" at all.
>
> A lot of up-front study is done before getting to 1, and for providing 2.
> I can tell you this for fact as I am currently on assignment with a client
> doing
> exactly this.
>
> And shed-loads of data is generated by 2.
> But no "pass/fail" tests. Just shed-loads of results to analyse.
Have to be careful here, unit test means different things in the
communication than in software development at large. On a different project
at Motorola several years earlier a unit meant a processor board and all its
software. A unit test was a massive operation, Roughly equivalent to a
system validation test of say an airbag controller.
For the unit tests they were running a test pass/test fail checklist type
operation. This mostly to test fundamental algorithms. Basically the same as
being done with the various xxxUnit test script drivers, except on target
hardware. Using the capabilities of the emulator to capture test result data
was something really neat (had to be really careful about not loading down
the system to much with data collection), for purposes of
verifying that (1) the compiler didn't goof up the algorithms, and (2) that
the device under control behaved as expected (the receiver driver guys had a
much more difficult task than I)
For the chip set validation roughly the same idea only at the level of
protocol exchanges. Roughly equivalent to a X.25 test suite
>
>
> Regards,
> Steven Perryman
>
David Lightstone
"Peter Little" <pe...@glendenecc.fsnet.co.uk> wrote in message
news:e8m5fu$rgg$1...@nntp.aioe.org...
> news:nWqrg.192$2v....@newssvr25.news.prodigy.net...
>
>> "AndrewMcDonagh" <new...@amc.com> wrote in message
>> news:e8k3no$tkb$1...@news.freedom2surf.net...
>
>> On any International Communication task such as a GSM or UMTS development
>> the things other than pair programming would be ground zero preconditions
>> for even considering the project. If you don't have compatibility, you
> can't
>> sell. You establish compatibility by passing the well formulated tests
> that
>> the international community has negociated as being the standard for
>> acceptability.
>
> And here is the killer ... there are no tests !!!
>
> When I first started work on UMTS in 1999, there was nothing like what
> there is now for UEs etc (3GPP 34.108, 34-123x etc) .
>
> And the customer (a real one, Vodafone, you may have heard of them)
> certainly had nothing other than generalities (the radio plane configs
> they wanted to use for CS/PS services etc, requests to conform to the
> current versions of the stds as best one could and still get kit out) .
>
> And the 3GPP (the requirements source) were changing their stuff massively
> on a quarterly basis (not often you can prove this, but masochists can go
> the 3GPP website and do diffs on all the docs from one quarter to the
> next -
> 1999 to 2001 - all x0,000 pages of them :-) ) .
>
>
> Same thing is happening now.
>
> Try the current WiMAX Forum specs.
> And then find me all the protocol test cases (abstract, TTCN etc) that
> describe conformance for the ASN Gateway, and basestation.
>
I wish to thank you very, very much. Off and on I have been wondering how I
was going to get some meaningful test data for a requirements scrub tool
that I have been developing. Toy problems are easy to create. Examples can
easily be drawn from confidential data, but can not be provided to third
parties. Worst case 3GPP specifications can be bought, or a similar
semi-open process effort can be exploited.
Anyhow the test data will be used to validate a process (not an algorithm)
that will propagate a requirements citation trace/audit from one document to
its revision. It intent being to make the task an itty-bitty less
masochistic. If you have had to read those sort of things, you can figure
out the implications.
Ron Jeffries
>You may indeed be convinced - that conviction is not based on reason or
>fact.
Contribute, or don't. Or play logic games. It's all good.
Bjorn Reese
> We might not, But there's little doubt that it's Agile.
Including the "Up-front Architecture Lite" ?
--
mail1dotstofanetdotdk
Phlip
>> We might not, But there's little doubt that it's Agile.
>
> Including the "Up-front Architecture Lite" ?
When you break a big team up into little teams, the decision where to split
their responsibilities is, indeed, an early and irreversible decision.
The "The Team Coordination layer" is an architectural decision regarding the
"project structure". The Agile distinction is we'd be _aware_ that it's a
high-risk activity. We would not load the decision up with details,
schedules, projections, or speculative designs. Instead, we would lean it
out, and push the actual decisions out to the teams.
And we might provide for reviews for these responsibilities, over time. If
one team always has a slower velocity than others, then...
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Phlip
> The Team Coordination layer replaces the Metaphor, Pair Programming,
> Collective Ownership, and On-site Customer practices with
> "Architecture Lite"
Suggestion: Each team arrange customer liaisons with the next team, and they
"buy" features from them. Within each team, at the package and module level,
the hard and low-level details are still the product of pair programming and
collective ownership.
Teams write acceptance tests for others to pass.
> An Architecture Lite fully describes the system architecture but at a
> high level of abstraction. The description includes both structural
> and behavioral aspects of the system.
You mean like the OMG's specifications for CORBA?
http://groups.yahoo.com/group/extremeprogramming/message/121012
What's amazing about the relationship between Michi Henning's article (
http://tinyurl.com/nrlbf ) and XP is this: With our training, we only need
to read Michi's premise before guessing exactly what will happen.
The OMG does not require reference implementations before it will ratify a
CORBA specification. Reference implementations are a Best Practice. It's how
ISO collects new features for C++.
Reference implementations would be the equivalent of one team (the
user-programmers) writing failing acceptance tests, and patches, for other
teams (the vendors) to pass. That system would prove the resulting features
will be technically viable, and actually useful.
Instead, OMG members debate via paperwork. And we can easily predict the
cruft, politics, low velocity, uncompetitive features, and loss of market
share that the OMG's BRUF and BDUF will cause.
Then we read Michi's conclusion, and it's true: CORBA's modern versions are
besotted with cruft, politics, low velocity, uncompetitive features, and
loss of market share.
And the OMG is the smartest consortium of the smartest programmers in the
world, right?
David Lightstone
> Bjorn Reese wrote:
>
>>> We might not, But there's little doubt that it's Agile.
>>
>> Including the "Up-front Architecture Lite" ?
>
> When you break a big team up into little teams, the decision where to
> split their responsibilities is, indeed, an early and irreversible
> decision.
>
> The "The Team Coordination layer" is an architectural decision regarding
> the "project structure". The Agile distinction is we'd be _aware_ that
> it's a high-risk activity. We would not load the decision up with details,
> schedules, projections, or speculative designs. Instead, we would lean it
> out, and push the actual decisions out to the teams.
Gee I wish I was following this one closely. Project structure is not also
Agile. It is an irreversivle decision.
Why pray tell should the project architecture not be as organized as the
software architecture? Shouldn't it just evolve by means of refactoring, or
perhaps there is some limitation that has been discovered? Why does this
limitation not also impact the softwarte architecture?
I would have naievely though that the project organization could be
refactored.
Convolutions upon convolutions eventually must fold back upon themselves