> To me, an appropriate interpretation of BRUF is: "Understand
> the big requirements up front". It is not appropriate to
> "Spend a big effort to understand the requirements up front".

Since this is an important concept, we may want to consider using the
acronym UBRUF.  :-)

Victor



----- Original Message -----
From: "Doug Swartz" <daswartz@...>
To: "Dominic Williams" <extremeprogramming@yahoogroups.com>
Sent: Wednesday, September 01, 2004 7:31 AM
Subject: Re: [good] [XP] Re: Oracle & Ford in need of XP


>
> Tuesday, August 31, 2004, 10:55:58 AM, Dominic Williams wrote:
>
> > I would just like to add that I consider the idea that
> > gathering requirements (and deciding whether to pursue)
> > is not addressed by XP's practices to be one of the
> > most common misconceptions.
>
> > XP says: don't just think about requirements - release
> > running software early and frequently to end users and
> > use the feedback to define further requirements.
>
> > XP says: keep doing that as long as what you gained
> > from the last release allows you to pay for the next
> > one.
>
> > So the practice that addresses those issues is frequent
> > releases. The value is feedback. It's all there.
>
> I don't remember anyone on this thread saying XP doesn't
> address gathering requirements or steering the project ("end
> the project" being one steering command).
>
> What many of us are talking about is "start the project".
> Classic XP has little to say about the project pre-work which
> is done in every organization I've worked in. Regardless of
> whether the development work is done in-house or contracted
> out; low-bidder wins, choose trusted supplier, or sole source;
> someone (a gold owner) has to decide it is worthwhile to start
> the project.
>
> Usually the gold owner requires some indication of three
> things: the approximate overall cost of the project,
> approximate time of value delivery, and a decent sense of what
> value will be derived (which is in large part determined by
> what features will be delivered). We know that none of these
> three factors will ever be exact. We also know that an XP
> development approach is one of the best ways to optimize in
> all three dimensions. But, it is appropriate for the decision
> maker to ask all three questions. In fact, I don't really want
> to work for a decision maker who doesn't ask all three
> questions.
>
> One of the ways to characterize XP is "How little can we do
> and still create excellent software?". This thread is about
> "How little can we do and still make smart business decisions
> about which projects to do?". While the two questions are
> connected because the ability to steer the project using XP
> techniques can lower the cost of making a poor decision
> up-front, let's not confuse the two different questions.
>
> To me, an appropriate interpretation of BRUF is: "Understand
> the big requirements up front". It is not appropriate to
> "Spend a big effort to understand the requirements up front".
>
>
> --
>
>  Doug Swartz
>  daswartz@...
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>

-----Original Message-----
From: Victor [mailto:vmgoldberg@...]

>If someone does not want to use TDD, she is for the time being free not to.
>But it's at her own risk.

This really is not about avoiding TDD, but if it's enough alone.

>
>Victor

kari

-----Original Message-----
>From: Ilja Preuss [mailto:preuss@...]

>>> But absence of syntax errors is *not* an indication of good code;
>>
>> It's not a proof, but it is an indication, that code is *better*
>> I have done PSP logging about this for a while, and the correlation
>> is very clear.
>
>That's interesting. How did you assess the quality of the code?

I track my errors. Lots of syntax errors correlate that unit tests don't pass.
debugging unit tests correlates to defects that my users find.

>> While this is true for logic errors, I'm not convinced it makes
>> difference in syntax errors. Logic errors found late require more
>> debugging, tools find spelling and syntax errors with the same speed.
>
>I still need to parse the error message, find the place that needs to be
>fixed and find out what would be the correction.
>
>When there appears a red squiggle under what I just typed, I just press
>Ctrl-Backspace for x times and try again (and of course I still know
>exactly what I wanted to do). If this happens too often in a short
>amount of time, I possibly get as alarmed as you when you find many
>syntax errors in a review.
>
>BTW, it just occured to me that I also often "misuse" this syntax
>checking by deliberately introducing an error and let Eclipse fix it
>(such as introducing a necessary type cast).

These things have costs and benefits. If your defect log clearly shows,
that fire fighting at users site takes minimal time, then you're
probably doing just fine. But I do get error reports. Many of those
errors could have been found by unit tests. But before the report,
I had no idea that I'm missing a special case condition. I don't know
how to write a test that checks if I have missing tests. Profiler is
good up to certain point. Finding bugs with adding tests later is
notoriously inefficient. Reviews rock.

>
>Cheers, Ilja

Kari

>-----Original Message-----
>From: Ron Jeffries [mailto:ronjeffries@...]

>>>... But if the only benefit is
>>> finding errors that will be found anyway, no thanks.
>
>> This is like saying you don't need a car because you'll get where you want
>> anyway, just by walking.

I'd refuse to do a routine maintenance for an aeroplane when all the
evidence shows, that it's been neglected for too long - thorough
maintenance is needed. But I don't seem to agree much with Randy.

>I take Kari's point to be similar to the one that Watts Humphrey made to
>me. Watts' belief is:

It's the very same point, that was taken to extreme by Harlan Mills.
I personally think, that Mills threw the baby out with bathwater when
he banned unit testing and even compiling in Cleanroom process.
But I can see the logic in it.

>I do know that my code, with TDD, is very free of defects compared to what
>I used to write with nothing but compiler diagnostics and sporadic testing
>to help me. I still don't know whether intense scrutiny would find
>additional things, but I can certainly see why it might.

I don't doubt it at all, TDD is very efficient.

If you have a list of defects that escaped the development, you can
estimate how much extra work might buy for you.

Kari

Kari Hoijarvi wrote:

> <>It's the very same point, that was taken to extreme by Harlan Mills.
> I personally think, that Mills threw the baby out with bathwater when
> he banned unit testing and even compiling in Cleanroom process.
> But I can see the logic in it.


It's funny, but I see more similarity than difference between TDD and
Cleanroom.  Both concentrate on code quality up front rather than
relying on testing after the fact.   The only difference is that TDD
uses tests as a tool to do what Cleanroom attempts to do with pure thought.

Michael Feathers
www.objectmentor.com

> "Jason Nocks" <nocksj@...> writes:
>
>>> "Jason Nocks" <nocksj@...> writes:
>>>
>>>> Clearly, we need to combat "requirements creep". Also clear to me is
>>>> that
>>>> requirements requested up-front are often far off the mark, so there
>>>> should be some effort towards minimizing wasted effort.
>>>
>>> Unless I misunderstand the term "requirements creep", I fail to see why
>>> it
>>> is
>>> an issue on an Agile project. The initial requirements may bear very
>>
>> I actually completely agree with this. I think it shouldn't be a problem
>> as well. I think it's quite possible that we have different definitions
>> of
>> "requirements creep", and unfortunately, I think humans will cause it to
>> be reality that must be dealt with.
>
> Maybe.

Can you elaborate?

>> I also don't believe that an XP team should be doing BRUF at all. Do you
>> feel differently. I can't tell from your post. The context in this case
>> was adding BRUF to XP (I think), and I believe that BRUF is a holdover
>> from Waterfall. Do you think BRUF should be an Agile practice? I can't
>> tell from your post.
>
> I woudl prefer to not do BRUF, but there may be situations where it is
> required (e.g. for tendering a bid, as described by Ken).
>
> I don't feel that BRUF would necessarily impact the rest of the project.

Why should we not be concerned that BRUF might negatively impact the
project? I'd love to think that was the case.

Some of the definitions of BRUF so far are vastly different than what I'm
calling BRUF.

To me, BRUF means "Waterfall Requirements". Just like BDUF means
"Waterfall Design" to me. If the customer is doing "Waterfall
Requirements", the data I've seen (mostly thanks to Craig Larman)
indicates we are likely to have a problem. Why should we not be concerned?
Why should we just say "we are immune"? I'd love to think I'm immune.
Where's the data that suggests that is the case?

>>> little
>>> relation to the final delivered software, but this is not an issue
>>> provided
>>> software is delivered frequently, and each iteration the most important
>>> current requirements are delivered. If requirement creep, morph, get
>>> cut
>>> or
>>> otherwise change, this is not an issue; you just address the changed
>>> requirements in the next iteration. If there's still more requirements,
>>> and
>>> there's still budget available, then you just schedule another
>>> iteration.
>>
>> I think it's possible that we have vastly different notions of
>> "requirements creep". I most likely did not clearly communicate my
>> understanding of the term. To me, the term closely resembles a term I've
>> heard before, called "scope creep". To me, that term indicates features
>> that are implemented but that are outside the scope of what's trying to
>> be
>> solved.
>
> That's the analogy I was thinking of too --- the tendency to add more and
> more
> requirements, to "ensure we haven't missed anything".

Exactly. I think we're on the same page with this definition at least.

>> IMO, in BRUF, this cruft gets sucked in like a vacuum cleaner. I think
>> it
>> happens when the requirements gatherers start saying things like "Let's
>> list everything we might possibly need". Sound familiar? I think the
>> data
>> point (64% of Waterfall-Requested features used "rarely" or worse)
>> supports this notion.
>
> I agree that you may end up with a large list of initial requirements, but
> I
> don't think that is a particular issue, provided the customer can
> prioritize
> them. Of course, any time spent thinking about them is wasted, but if you
> have
> to do BRUF, then it's a cost you have to handle.

I've personally seen customers experience great difficulty effectively
prioritizing BRUF requirements (where BRUF = "Waterfall Requirements").
I'll get a list of priorities certainly, but I often have a sense that the
prioritization wasn't given as much thought as would be the case without
BRUF. This is just my experience. Others may be much better at combatting
BRUF, but my primary concern is that I think I'm starting to hear "BRUF
isn't really a problem". I'd love for that to be the case because I
encounter it frequently, but I'm not aware of any reason to think this is
so. What am I missing?

>> I agree that XP planning games fight this trend much more effectively
>> than
>> anything else I've encountered. But, a team really following XP
>> (including
>> the Customer) wouldn't do BRUF IMO. If the team, or even just one member
>> of the team (the Customer) wants to do BRUF, then I think that impacts
>> the
>> XP Planning Game somewhat. I'm not sure how, but I have some concerns
>> based on the above data point and past experience.
>
> If you have done BRUF, it might make the planning game take longer (it
> must
> take longer to prioritize 3000 requirements versus 30) However, I think
> this
> is a one-time cost; once requirements have been pushed down the list, then
> there's no reason to ever think about them until we get that far down the
> list
> unless someone actively chases for them.

I'm not sure BRUF is a one time cost any more than BDUF is a one time
cost. Probaly not as big of an impact. BDUF impacts all of the developers
throughout the day every day. But, why doesn't BRUF impact every release
planning session?

>> I don't want to assume that an XP team is completely immune from
>> "requirements creep" (whatever that means). If one member of the team
>> becomes infected (the Customer) with "we might need this" and "we might
>> need that" kind of pressures from others and allows those pressures to
>> influence the priorities of stories, I think we have a problem. I could
>> certainly be wrong.
>
> If the customer bows to "we *might* need this" over "we *do* need that",
> then
> you're lost, I agree. I don't think it matters whether you've thought of

Thanks, that's basically what I had in mind. I've personally observed
this. The customer isn't consious of this, and if we don't address this
before starting the project, I think it's highly likely to become a
problem (not insurmountable, but still a problem).

> "this" and "that" up front, or whether they are new requirements that come
> along as the project progresses.

I'm concerned that some might be ignoring data that waterfall requirements
are highly damaging. You seem to be aware of this problem.

I don't think this "we might need this" stuff comes up as much if you
don't ask the question, "What's everything we think we might need", but
I'm not certain about this. Perhaps we're even less well off than I
thought.

>> It's very easy to just say "that's the customer's problem", but I don't
>> believe in blaming members of the team for being human.
>
> It's up to the Whole Team to help them not bow to these pressures.

What I often hear is "If the customer is a proxy for the rest of a
customer team, then it's the customer proxy's problem". I'm just trying to
ask if others think this view is adequate or perhaps a bit too simplistic.

>> How do we know that we haven't implemented a single feature that is not
>> truly needed? How do we know that we are completely immune from this
>> problem? Certainly if you develop a close relationship with the Customer
>> and work closely (onsite), this descreases the likelihood. But, are we
>> collecting data that proves that every feature implemented is used often
>> or higher? Or, is that too high of a mark to strive for?
>
> We don't know in advance that any feature we implement will be used.

Well said. So, IMO we're not immune from "requirements creep". Believe me,
I wish I could say I thought we were. I think we're much better off than
the alternative(s), but that's still a far cry from immune.

> However,
> if we address the highest priorities first, and release often, and get
> real
> feedback on the releases, then we stand a high chance of being reasonably
> on
> target.

Yes, "high chance", but not immune. Perhaps I took Uncle Bob's "let's
qualify our statements" speech a bit too literally.

Uncle Bob also had a quote recommending Craig Larman's book a couple of
weeks ago, "Show them the report that the U.S. Department of Defense lost
nearly half their major software projects in the 70's and 80's because of
up-front requirements analysis."

> Anthony

Thanks for the discussion,
Jason

-----Original Message-----
>From: Jeff Grigg [mailto:jeffgrigg@...]

>> --- Randy MacDonald wrote:
>>> As I may have said before, up-front tests provide this
>>> scrutiny at silicon speed, eventually covering anything
>>> the language designers have yet to implement. The
>>> benefits of a manual scan do not justify the extra time
>>> and effort.
>
>Test Driven Development (TDD) is good at catching functional
>regression.  But it doesn't detect code smells.  People still have
>to do that.

Pretty much what I'm trying to say.

>--- Ron Jeffries <ronjeffries@X...> wrote:
>> My code is better when I TDD, but it is emphatically not
>> perfectly bug-free. It seems likely that if I were able
>> to pay more attention, it would be better.
>
>Me too.  I read that people have been successful with the Clean Room
>methodology.  From what I read, it seems to make sense that they
>could.  I think I could successfully do Clean Room, and get similar
>results.  Better results than XP?  Well, that's not clear.  Higher
>productivity and/or a more enjoyable work environment?  Well, I
>doubt it.  But I haven't done it (and have no current plans to try
>it) so I can't be really sure.

I haven't done Cleanroom, but I have experienced such results.

One was a project long time ago: Some low level memory management
codethat just had to be right. I reviewed 350 lines again and
again, then compiled with two syntax errors. Worked without any
modification ever.

It can be done, but I just would not do it anymore. I can set
myself a goal to get the test+code working without unexpected
errors, it's even more difficult than Cleanroom, since tests
can contain errors too.

>> I'm not doing intense scrutiny, nor even recommending it.
>> But I do think it's unwise to dismiss it.
>
>Maybe a higher level of scrutiny that would be better.  Maybe there
>could be a sensible way to integrate this with XP.  If someone
>figures out how to do that successfully, I'd be glad to hear about
>it.

Reviewing is just like writing tests first, all that is required is
discipline to do it. That's the hard part. Afterwards, it gets
addictive.

Kari

Doug,
I strongly agree with the majority of your post. I'm cutting it out for
brevity, not because I don't care for it (the reverse is definitely the
case).

<snip>

I do disagree with your definition of BRUF. I'll include that and try to
explain why I disagree (and I agree with Victor that this is important):

> To me, an appropriate interpretation of BRUF is: "Understand
> the big requirements up front". It is not appropriate to
> "Spend a big effort to understand the requirements up front".

Is your definition of BDUF: "Understand the big design decisions up
front"? I've heard others try to use that definition.

That's not the definition of BDUF that I use. My definition of BDUF is
more akin to "Waterfall Design". Hence, my definition of BRUF is
"Waterfall Requirements". Am I missing something?

Sorry for violating once and only once (I've posted this definition a
couple of times), but I suspect this definition is easily lost in other
posts of mine. And, I welcome another defintion, provided I can understand
it and make sense of it. IMO, consistency is also a worthy goal. Thoughts?

>  Doug Swartz
>  daswartz@...

Thanks,
Jason Nocks

>-----Original Message-----
>From: Michael Feathers [mailto:mfeathers@...]
>
>> <>It's the very same point, that was taken to extreme by Harlan Mills.
>> I personally think, that Mills threw the baby out with bathwater when
>> he banned unit testing and even compiling in Cleanroom process.
>> But I can see the logic in it.
>
>
>It's funny, but I see more similarity than difference between TDD and
>Cleanroom.  Both concentrate on code quality up front rather than
>relying on testing after the fact.   The only difference is that TDD
>uses tests as a tool to do what Cleanroom attempts to do with pure thought.
>
>Michael Feathers
>www.objectmentor.com

Yes, I agree. I liked the original acronym TFD better than TDD,
since I always put the emphasis on TestFirstDESIGN.

Cleanroom requires formal verification, you can't verify a mess
so you have to make the design verifiable.

TFD requires testing, you can't test a mess so you have to make
a design that is testable.

That's why I don't like the Boehm's book title "Balancing Agility
and Discipline". Anybody who has tried TFD knows how much discipline
it requires. I was planning to write counter article "Balancing
Bureaucracy and Sloppiness" but some RUP guys might come after me.

Kari

> On Wednesday, September 1, 2004, at 4:06:42 AM, Jason Nocks wrote:
>
>> IMO, if the "gold owner" thinks a list of detailed requirements is
>> complete and not going to change prior to starting a project, then a
>> team
>> using XP has a serious communication issue that would need to be
>> addressed
>> before starting the project.
>
> What issue is that? That the team doesn't have that same belief? That the
> team is prepared for the customer to change their mind even if they don't?
> Or ?

First, reading my message again, it may not have been clear that I meant
"the 'gold owner' thinks a list of detailed requirements is complete and
not going to change [during the course of the project] prior to starting a
project".

Of course it's theoretically possible that the list of requirements won't
change. I've never seen that happen, and I'm not sure I'd try to use XP to
approach a project where that was sincerely expected to be the case.

My concern was that there might be a difference in expectations. I would
expect that a project with a fixed set of detailed up-front requirements
would also carry an expectation of a fixed price (based on estimates
provided). I'd be very concerned if the team were operating under
different expectations than the "gold-owner". I'd want to get those
expectations out on the table and try to arrive at a common set of
expectations if there was a difference.

"Communication issue" probably wasn't very clear. Is the above clearer?
Does it make more sense?

> Ron Jeffries
> www.XProgramming.com
> Will Turner: This is either madness or brilliance.
> Captain Jack Sparrow: It's remarkable how often those two traits coincide.

Cheers,
Jason Nocks

Hi,


there have been several posts on the "[good] [XP] Re: Oracle & Ford in need of
XP" thread about replacing legacy apps.

This seems to me a case of BRUF even without somebody deciding to collect all
the requirements for a business decision - they are just there. We seem to get
all the same problems like "this new system has to have all features of the old
one (and more) - there are no priorities". When we know how to deal with this
case we should be able to deal with any BRUF case.

I'm not sure yet how to effectively keep the barbarians from the gates ;-)


Jürgen

--------
Jürgen Ahting - AMECO GmbH

If you give me six lines written by the most honest man, I will find something
in them to hang him. -- Cardinal Richelieu

_______________________________________________________
WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern
Informationen unter: http://freemail.web.de/?mc=021199

Kari Hoijarvi wrote:
> -----Original Message-----
>> From: Ilja Preuss [mailto:preuss@...]
>
>>>> But absence of syntax errors is *not* an indication of good code;
>>>
>>> It's not a proof, but it is an indication, that code is *better* I
>>> have done PSP logging about this for a while, and the correlation is
>>> very clear.
>>
>> That's interesting. How did you assess the quality of the code?
>
> I track my errors. Lots of syntax errors correlate that unit
> tests don't pass.

I wonder, do you do TDD? How can you get "lots of syntax errors" in the
small amount of code to get the next test to pass?

I feel like I'm still missing something essential from your description
of your working style... :(

> debugging unit tests correlates to defects that my
> users find.

What do you mean by "debugging unit tests"?

> These things have costs and benefits. If your defect log clearly
> shows, that fire fighting at users site takes minimal time, then
> you're probably doing just fine.

Well, I am mostly working on legacy code today, with miserable test
coverage, so "doing just fine" isn't exactly what I would call it. Not
sure wether more testing or more inspection (or rather which balance)
would be optimal. Currently I am more into trying testing...

> But I do get error reports. Many of
> those errors could have been found by unit tests. But before the
> report, I had no idea that I'm missing a special case condition. I
> don't know how to write a test that checks if I have missing tests.

You might want to take a look at both

http://hansel.sourceforge.net/

and

http://jester.sourceforge.net/

No silver bullets, but at least interesting.

Cheers, Ilja

Kari Hoijarvi wrote:

>>-----Original Message-----
>>From: Michael Feathers [mailto:mfeathers@...]
>>
>>
>>
>>><>It's the very same point, that was taken to extreme by Harlan Mills.
>>>I personally think, that Mills threw the baby out with bathwater when
>>>he banned unit testing and even compiling in Cleanroom process.
>>>But I can see the logic in it.
>>>
>>>
>>It's funny, but I see more similarity than difference between TDD and
>>Cleanroom.  Both concentrate on code quality up front rather than
>>relying on testing after the fact.   The only difference is that TDD
>>uses tests as a tool to do what Cleanroom attempts to do with pure thought.
>>
>>Michael Feathers
>>www.objectmentor.com
>>
>>
>
>Yes, I agree. I liked the original acronym TFD better than TDD,
>since I always put the emphasis on TestFirstDESIGN.
>
>Cleanroom requires formal verification, you can't verify a mess
>so you have to make the design verifiable.
>
>TFD requires testing, you can't test a mess so you have to make
>a design that is testable.
>
>That's why I don't like the Boehm's book title "Balancing Agility
>and Discipline". Anybody who has tried TFD knows how much discipline
>it requires. I was planning to write counter article "Balancing
>Bureaucracy and Sloppiness" but some RUP guys might come after me.
>

Re the title, that was pretty much my thought too. :) But, in fairness,
I haven't read the book.  I guess I should.

It look at Cleanroom like this.  It is like saying that we would all
make fewer errors in documents if we didn't have a spelling checker.
And, it is a subtle argument because everyone knows that spelling
checkers don't catch all errors.  It seems that the theory is that they
could lull people into false confidence.


Michael Feathers
www.objectmentor.com

-----Original Message-----
>From: Ilja Preuss [mailto:preuss@...]
>Kari Hoijarvi wrote:
>> -----Original Message-----
>>> From: Ilja Preuss [mailto:preuss@...]
>>
>>>>> But absence of syntax errors is *not* an indication of good code;
>>>>
>>>> It's not a proof, but it is an indication, that code is *better* I
>>>> have done PSP logging about this for a while, and the correlation is
>>>> very clear.
>>>
>>> That's interesting. How did you assess the quality of the code?
>>
>> I track my errors. Lots of syntax errors correlate that unit
>> tests don't pass.
>
>I wonder, do you do TDD? How can you get "lots of syntax errors" in the
>small amount of code to get the next test to pass?
>
>I feel like I'm still missing something essential from your description
>of your working style... :(

Yes, I do. It's very hard to get 30 lines done without a single mistake.
When doing short cycles, max 10 lines, it's easier. but it's still
difficult. lack of concentration for whatever reason shows very clearly.

>> debugging unit tests correlates to defects that my
>> users find.
>
>What do you mean by "debugging unit tests"?

That I get an unexpected failure. I call finding defects this way
debugging, although not nececessarily with a debugger.

>> But I do get error reports. Many of
>> those errors could have been found by unit tests. But before the
>> report, I had no idea that I'm missing a special case condition. I
>> don't know how to write a test that checks if I have missing tests.
>
>You might want to take a look at both
>
>http://hansel.sourceforge.net/
>
>and
>
>http://jester.sourceforge.net/

I'll check them when I do Java next time, thanks.

Kari

As I understand it - refactoring should be done with the aid of a test
harness.  I feel this is what I meant - continual improvement with the
safety net of a test harness.

I did this on a vb3 to vb6 conversion project - very boring with some
extremely poor code which I ripped out and replaced with vb6 classes and
vbUnit3 test rigs.  Not all the code was replaced - however the team
maintaining should endeavour to carry on this effort to improve the code
rather than patch it (with more bugs).  Made it more interesting for me and
the customer has benefited also with a better performed application.

I'll be interested to read the book when it comes out.

-----Original Message-----
From: Michael Feathers [mailto:mfeathers@...]
Sent: Wednesday, 1 September 2004 10:03 PM
To: extremeprogramming@yahoogroups.com
Subject: Re: [good] [XP] Re: Oracle & Ford in need of XP

Dominic Williams wrote:

>Nick Zdunic wrote:
>
>
>
>>I agree with replacing legacy apps bit by bit. A
>>refactoring effort of some sorts.
>>
>>
>
>I would rather replace the app bit by bit by making
>completely new code work with (interface with) the
>legacy app.
>
>So I have in mind something very different from
>refactoring. Can't speak for Ron, though.
>
>
I haven't done much touting of this yet, but I just finished a book
about working with legacy code.  The emphasis isn't on replacing the
code, it's on getting it under test so that you can make it better.
Street date will be 9/20.  The real cover looks much better than the one
shown here :-)

http://www.amazon.com/exec/obidos/tg/detail/-/0131177052


Michael Feathers
www.objectmentor.com



To Post a message, send it to:   extremeprogramming@eGroups.com

To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

On Wed, 2004-09-01 at 10:42, Dave Cronin wrote:
> > As far as I understand, it is strongly against iteration development
> > for building a coherent approach to interaction among users and
> > programs.
>
> Around here, we generally believe that while iteration development may
> be a highly effective way to build software, as well as determine
> low-level requirements and interface designs, there is a better way to
> initially define a product and develop a high-level interaction design
> which involves upfront user, business and technical research, analysis
> and synthesis.

Interesting! That's a different impression than I had from, say, reading
the interactions between Cooper and Beck. What bad effects have you seen
from doing the planning in parallel with an agile development process,
rather than your preferred sequential approach?

Thanks,

William

> I've personally seen customers experience great difficulty
> effectively prioritizing BRUF requirements (where BRUF = "Waterfall
> Requirements"). I'll get a list of priorities certainly, but I
> often have a sense that the prioritization wasn't given as much
> thought as would be the case without BRUF.

Does having done more research about the project really make it
harder for the customer to participate in the planning game
effectively? How does this happen?

> What am I missing?

Do you have a way of effectively measuring the customer's ability to
participate in the planning game effectively with and without BRUF?

> But, a team really following XP (including the Customer) wouldn't
> do BRUF IMO.

Before there is a team doing XP on the project, some form of RUF is
usually done to define the project. This RUF isn't always done by the
XP team that will work the project and in fact there may be no XP
team in existance yet when the RUF is done. Should Ford have formed
an XP team to do it's Oracle project before they knew they were going
to do the Oracle project?

On Wednesday, September 1, 2004, at 10:03:11 AM, Michael Feathers wrote:


> I haven't done much touting of this yet, but I just finished a book
> about working with legacy code.  The emphasis isn't on replacing the
> code, it's on getting it under test so that you can make it better.
> Street date will be 9/20.  The real cover looks much better than the one
> shown here :-)

As long as it doesn't have your picture on it. I need the book, would hate
to have to tear off the cover. People would think I had stolen a
remaindered copy. Couldn't have that. :)

Ron Jeffries
www.XProgramming.com
Agility might be said to be about encountering
all the problems so early and so often that the
effort to fix them is less than the pain of enduring them.

On Wednesday, September 1, 2004, at 10:13:24 AM, Randy MacDonald wrote:

> ----- Original Message -----
> From: "Ron Jeffries" <ronjeffries@...>
> To: <extremeprogramming@yahoogroups.com>
> Sent: Tuesday, August 31, 2004 11:01 PM
> Subject: Re: [XP] Continuous Testing

>> My code's not as bug-free as I'd like it to be.

> Who's is? I suspect it's not as profitable as you'd like it to be, either.

Got that right. :)

> I find automated inspections are less costly for the coverage they give.

Me, I don't know. I haven't tried the other kind. It does seem that many of
my bugs are kind of stupid. I'm keeping a list ...

Ron Jeffries
www.XProgramming.com
There is really no such thing as bad weather,
only different kinds of good weather.  ~John Ruskin

Ron Jeffries wrote:

>On Wednesday, September 1, 2004, at 10:03:11 AM, Michael Feathers wrote:
>
>
>>I haven't done much touting of this yet, but I just finished a book
>>about working with legacy code.  The emphasis isn't on replacing the
>>code, it's on getting it under test so that you can make it better.
>>Street date will be 9/20.  The real cover looks much better than the one
>>shown here :-)
>>
>>
>
>As long as it doesn't have your picture on it. I need the book, would hate
>to have to tear off the cover. People would think I had stolen a
>remaindered copy. Couldn't have that. :)
>
>

My picture?  On the book?  Don't be silly, we want the book to sell.

It does have a cool cover though.  I never knew that Charles Babbage's
Difference Engine could look that sexy.  Hats off to the folks at
Prentice Hall.

Michael Feathers
www.objectmentor.com

On Wednesday, September 1, 2004, at 3:42:07 PM, Michael Feathers wrote:

> I never knew that Charles Babbage's
> Difference Engine could look that sexy.  Hats off to the folks at
> Prentice Hall.

You should have seen it as I did, with sensual Ada, Lady Lovelace, lying
back against the Machine, her bodice ... but that's another story.

Ron Jeffries
www.XProgramming.com
The main reason that testing at the end of a development cycle finds
problems is not that problems were put in near the end, it is that
testing was put off until then.

hi!

is there a list of planning software (like xplanner) somewhere?
i searched for a while, but didnt really come up with anything
except xplanner.

thanks!

ciao!
florian

----- Original Message -----
From: "Kari Hoijarvi" <hoijarvi@...>
To: <extremeprogramming@yahoogroups.com>
Sent: Wednesday, September 01, 2004 12:01 PM
Subject: RE: [XP] Testing vs Inspection


> -----Original Message-----
> >From: Jeff Grigg [mailto:jeffgrigg@...]

> >Test Driven Development (TDD) is good at catching functional
> >regression.  But it doesn't detect code smells.  People still have
> >to do that.
>
> Pretty much what I'm trying to say.

If one defines code smells are those things that seem wrong about a piece of
code, but what wxactly is wrong is hard to define, I'd say that, by
definition, people have to detect them. It sounds to me like I'm getting an
analog-vs-digital argument: CD's will never sound as good as LP's; people
will always be able to detect things software cannot, who needs cars when
you can walk. I'll use the computer to detect 98% of the errors, and not
spend the same or larger amount to detect the other 2%.

Big = expensive = bad
Big = important = good

I think there's a lot of violent agreement here. What Big _should_ mean
seems to be a side issue.

----- Original Message -----
From: "Jason Nocks" <nocksj@...>
To: <extremeprogramming@yahoogroups.com>
Sent: Wednesday, September 01, 2004 12:07 PM
Subject: Re: [good] [XP] Re: Oracle & Ford in need of XP


>
> Doug,
> I strongly agree with the majority of your post. I'm cutting it out for
> brevity, not because I don't care for it (the reverse is definitely the
> case).
>
> <snip>
>
> I do disagree with your definition of BRUF. I'll include that and try to
> explain why I disagree (and I agree with Victor that this is important):
>
> > To me, an appropriate interpretation of BRUF is: "Understand
> > the big requirements up front". It is not appropriate to
> > "Spend a big effort to understand the requirements up front".
>
> Is your definition of BDUF: "Understand the big design decisions up
> front"? I've heard others try to use that definition.
>
> That's not the definition of BDUF that I use. My definition of BDUF is
> more akin to "Waterfall Design". Hence, my definition of BRUF is
> "Waterfall Requirements". Am I missing something?
>
> Sorry for violating once and only once (I've posted this definition a
> couple of times), but I suspect this definition is easily lost in other
> posts of mine. And, I welcome another defintion, provided I can understand
> it and make sense of it. IMO, consistency is also a worthy goal. Thoughts?
>
> >  Doug Swartz
> >  daswartz@...
>
> Thanks,
> Jason Nocks
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>

On Wed, 1 Sep 2004 11:01:30 -0500, Kari Hoijarvi <hoijarvi@...> wrote:
> Reviewing is just like writing tests first, all that is required is
> discipline to do it. That's the hard part. Afterwards, it gets
> addictive.

Amen.

After reading about XP and TDD for over a year and being thoroughly
converted in theory, I eventually actually sat down with a friend and
colleague and we spent a half-day actually doing 100% Pure
pair-programming and TDD (as opposed to reading about it on the bus).

It was my TDD epiphany.

I had pair-programmed before, but not TDD. Now I'm utterly hooked.
Literally the next day at my regular project I did TDD all day, and
the day after, and the day after that, too. And today, and tomorrow
morning I'll continue.

Just actually *doing* TDD (via pair programming to boot) was a
mind-expanding experience. And in a few weeks we're gonna set aside a
whole half-day on our project and my colleague and I will coach our
team (4 others) through a similar experience, and my epiphany sensors
will be fully deployed at full sensitivity :)

TDD rules, in theory. TDD rules absolutely, in practice.

t.allan

On Wednesday, September 1, 2004, at 12:25:36 PM, Jason Nocks wrote:

> First, reading my message again, it may not have been clear that I meant
> "the 'gold owner' thinks a list of detailed requirements is complete and
> not going to change [during the course of the project] prior to starting a
> project".

Yes ...

> Of course it's theoretically possible that the list of requirements won't
> change. I've never seen that happen, and I'm not sure I'd try to use XP to
> approach a project where that was sincerely expected to be the case.

I would. Why might you not, and what might you do instead?

> My concern was that there might be a difference in expectations. I would
> expect that a project with a fixed set of detailed up-front requirements
> would also carry an expectation of a fixed price (based on estimates
> provided).

Yes. I could imagine not accepting a project if the price were too low.

> I'd be very concerned if the team were operating under
> different expectations than the "gold-owner". I'd want to get those
> expectations out on the table and try to arrive at a common set of
> expectations if there was a difference.

Yes. I'd prefer to have everyone on the same page. But at the end of the
day, sincere expectations notwithstanding on both sides, things either
would change, or they would not. Learning would occur, or it would not.
Either way, everyone involved needs to adapt.

Ron Jeffries
www.XProgramming.com
It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)

I decided on the way home I wanted to run off at the mouth a little
more here:

>> I've personally seen customers experience great difficulty
>> effectively prioritizing BRUF requirements (where BRUF="Waterfall
>> Requirements"). I'll get a list of priorities certainly, but I
>> often have a sense that the prioritization wasn't given as much
>> thought as would be the case without BRUF.
>
> Does having done more research about the project really make it
> harder for the customer to participate in the planning game
> effectively? How does this happen?

Let's pretend there are 26 actual things that need to be done,
labeled A-Z in order of prioritization. (This is a 20/20 hindsight
view)

Let's pretend that someone does some BRUF and comes up with 10
correct requirements (A,B,D,F,etc.), 10 close requirements (c,g,h,l,
etc.) and 10 completely bogus requirements (1,2,3,etc) (a BRUF view
if you will)

And finally, let's pretend that someone else does some LRUF and comes
up with 10 requirements and just because they can see the obvious and
to stack the deck in favor of LRUF, lets say they're
A,b,D,e,F,g,h,l,and 2. (a LRUF view)

Now to me, the best customer is the one who gets A,B,C,D,E, etc
done in that order and who wastes as little time with 1,2,3, etc. as
possible and gets from b to B as quickly as possible.

Does the customer who can't prioritize with BRUF do a better job
prioritizing and discovering with LRUF or do they depend on LRUF
discovering the high value items (such as "C") when they need to be
discovered.

(And I honestly don't know the answer to this one:) If so, does LRUF
with LRUF iterations find "C" faster than BRUF with LRUF iterations
or does it just appear that the bad customer can make decisions
better because their are less decisions to make and no one faults
them because the right choice wasn't in the pile.

Did any of that make sense?

Hi Ron,

> Yes. And yet, we only know what people do, not what they
> think. Is it perhaps even more insulting to tone down our
> style for the weak and not-so-fleet of tongue?

The insult would be in making certain kinds of assumptions about
the other person.  Perhaps you could avoid that by asking the
other person's preferences for how you interact with them.

> I do try not to make it personal. I try to edit "you" out of
> my conversation.

Interesting.  My approach is to make it more personal, such as by
speaking about myself and my experience in a personal way, or by
speaking to the person I'm speaking to in a more personal way.

I'm probably wildly inconsistent in using "you" to refer
specifically to one person I'm talking to and to refer to a
general "you."

I've come to have a bad reaction to the pronoun "one" in
reference to some general person.  It feels too abstract and
impersonal to me.  I drag in all kinds of stereotypical
associations with academia, including a feeling of being
pontificated at.

Dale

--
Dale Emery, Consultant
Collaborative Leadership for Software People
Web:    http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

Whenever two people meet, there are really six people present.
There is each man as he sees himself, each man as the other
person sees him, and each man as he really is. --William James

--- In extremeprogramming@yahoogroups.com, "Ken Boucher" <yahoo@n...>
wrote:
> > I've personally seen customers experience great difficulty
> > effectively prioritizing BRUF requirements (where BRUF
= "Waterfall
> > Requirements"). I'll get a list of priorities certainly, but I
> > often have a sense that the prioritization wasn't given as much
> > thought as would be the case without BRUF.
>
> Does having done more research about the project really make it
> harder for the customer to participate in the planning game
> effectively? How does this happen?
>
> > What am I missing?
>
> Do you have a way of effectively measuring the customer's ability
to
> participate in the planning game effectively with and without BRUF?
>
> > But, a team really following XP (including the Customer) wouldn't
> > do BRUF IMO.
>
> Before there is a team doing XP on the project, some form of RUF is
> usually done to define the project. This RUF isn't always done by
the
> XP team that will work the project and in fact there may be no XP
> team in existance yet when the RUF is done. Should Ford have formed
> an XP team to do it's Oracle project before they knew they were
going
> to do the Oracle project?

This is a good observation. In fact, it's one of the more frequently
mentioned problems with XP: it doesn't contain any prescription for
a "project initiation" phase.

Doing all requirements up front in depth is a defense against the
inability to continue to "grow" a code base so that a (conceptually)
similar sized change will cost the same regardless of the place it
occurs in the project timeline.

XP, of course, promises that it can do exactly that. Does that make
an up front requirements phase obsolete? I frankly don't have an
answer to that. I do know, for example, that if you have a missing
stakeholder going into the planning game, you're probably going to
have a lot of trouble going forward whatever methodology you're using
(at least until you find the stakeholder and get him integrated into
the customer team!)

On the other hand, there is undoubtedly a lot of stuff in the
traditional requirements process that isn't needed until the
developers are ready to deal with it, and doing it up front simply
increases the investment and risk before providing any return on the
investment.

The point in the Chaos Reports about close to 50 % of all requested
features never being used is really important - that's a cost problem
right there.

So I think the answer to your question is a very heavily
qualified "yes." The qualification is that the team to be formed
needed to be able to do project enactment (including whatever
requirments analysis was really needed) in a way that takes into
account the assignment of an XP team to do the development. I don't
know what to tell such a team, though, other than to give them a copy
of "Lean Software Development."

John Roth

On Wednesday, September 1, 2004, at 7:38:22 PM, Ken Boucher wrote:

> Did any of that make sense?

I'm sorry. You lost me on an early turn. I'll try again when I'm warmed up.

One problem is that BRUF and LRUF aren't very well defined, nor do we all
even agree on what they are. Some words saying what's really done, how long
it takes, etc might be helpful.

Ron Jeffries
www.XProgramming.com
Those who attain to any excellence commonly spend life in some single
pursuit, for excellence is not often gained upon easier terms.
    -- Samuel Johnson