> Most XP discussion seems to be of the concept "you shouldn't do
> business that way."  Nice idea, I say, but I have a mortgage to pay,
> and maybe a cat to feed.  ;->

I think "don't do business that way" is a natural reaction.

At the root of the problem with fixed-bid contracts that Peter
described is this : when I'm "costing" such a contract, I'm essentially
lying through my teeth, saying "we know to Y% accuracy how much
it will cost to do X" when in fact I know no such thing, and in fact
expect to end up building something other than X.

It seems to me that lying to our customers is to be avoided, even at
the cost of not closing contracts and having to look for other ways to
pay the mortgage and feed the cats.

I used to feel uncomfortable about this situation at the end of the
project, when it was too late. The conversations here have gotten
me into the habit of feeling uncomfortable about it at the start of the
project, when I can still do something about it, such as say "no" to
the project.

I agree that XP doesn't seem to say much about what might be
done about it other than that. ;)

> Maybe 90% is available when the end of the release plan is
> reached, which is okay because the business guys added 17% risk
> contingency (in addition to 35% margin for profit) and since they
> eventually exceed the target by only 11% the gross margin is actually
> more like 38% and everyone goes home with bonuses.

I don't believe this could be a realistic description of an XP project,
as it seems to me that "90%" implies "90% of some linearly
measurable original quantity", and the only such variable on a
project is calendar time.

By the end of the project, but also at any one time in between, I'd
want to have solved enough of the customer's problem to have
deserved the money they spent so far. You can't put percentages on
this strategy, or compute a risk contingency.

Hello merrifie,

Friday, March 01, 2002, 4:23:04 AM, you wrote:

> --- In extremeprogramming@y..., "geektank" wrote:
>> --- In extremeprogramming@y..., "Charlie Poole" wrote:
>>
>> > A good manager over an XP team would be clearing
>> > obstacles rather trying to control how things are done.
>> >
>> > Of course, the hard thing is to convince a manager to act
>> > that way.
>>
>> I've always been told that this is how all good manager's act,
>> regardless what sort of team they manage.

> Yes, good managers act this way. These are managers who work for
> their staff. The other kind of manager thinks his staff works for
> him. This type of manager thinks the other type is weak. They don't
> think good managers should act this way and don't think their own
> sytle is bad. If you have one of these managers, you can't convince
> them to act differently.

> -- Mike
> Eugene, OR

I don't think it's only the manager who are to blame. The traditional
view of a manager is that s/he has the responsibility for the project.
Since s/he has the responsibility and the overview etc. s/he shall
delegate all the work and ensure that it gets done properly. Thus, a
manager both have the traditional opinions about what s/he ought to
do, as well as demand from the subordinates who expect the manager to
act according to the traditional view.


Best regards,
  Jonas

When you come to a fork in the road, take it!
  - Yogi Berra

thanks you guys, already had 39 votes whilst ive been asleep :D

If you havent voted you can at

http://test.on30.co.uk/survey/index.php

and to view the results so far

http://test.on30.co.uk/survey/results.php


thanks again for everyones help


andy

didnt know everyone liked win32 so much :p


[Non-text portions of this message have been removed]

Laurent Bossavit wrote:
>
> > Maybe 90% is available when the end of the release plan is
> > reached, which is okay because the business guys added 17% risk
> > contingency (in addition to 35% margin for profit) and since they
> > eventually exceed the target by only 11% the gross margin is actually
> > more like 38% and everyone goes home with bonuses.
>
> I don't believe this could be a realistic description of an XP project,
> as it seems to me that "90%" implies "90% of some linearly
> measurable original quantity", and the only such variable on a
> project is calendar time.
>
> By the end of the project, but also at any one time in between, I'd
> want to have solved enough of the customer's problem to have
> deserved the money they spent so far. You can't put percentages on
> this strategy, or compute a risk contingency.

Phrase "money then spent so far" implies something other than fixed-price
contract, doesn't it?  I agree with the moral principle, but not that
it comes to play much in fixed-price until the final result is
delivered to the customer.

I also don't really agree that one can't reasonably accurately
label a project 90% complete at some point in time near the end,
if one is using XP.  With other methods, the remaining 10% is the
10% that takes another 90% of the time, while with XP delivering
business value in priority order, that 10% might realistically
represent 10% (or even less, or slightly more) of the remaining time.

-Peter

Andrew Edmundson wrote:
>
> thanks you guys, already had 39 votes whilst ive been asleep :D
> If you havent voted you can at
> http://test.on30.co.uk/survey/index.php
> and to view the results so far
> http://test.on30.co.uk/survey/results.php

Might be a bug.  In the final question I voted for "won't be used"
(because you didn't give me an alternative "don't know") but
the results show 0% voted for that one...

> didnt know everyone liked win32 so much :p

I think that :p might be a smiley of some kind, but regardless:
please don't change the questions when you publish the results!
We were not asked which OS we _liked_ best, but which
one we _used_ most.  I do *not* like Win32 best, but I do have
to use it most frequently.

-Peter

> Phrase "money then spent so far" implies something other than
> fixed-price contract, doesn't it?

It does, it does.

> I agree with the moral principle, but not that it comes to play much
> in fixed-price until the final result is delivered to the customer.

Doesn't that observation nail the problem down exactly ?

> With other methods, the remaining 10% is the 10% that takes another 90%
> of the time, while with XP delivering business value in priority order,
> that 10% might realistically represent 10% (or even less, or slightly
> more) of the remaining time.

I'm missing something. "10% of the remaining time" I understand -
that was the point of my remark. You say that some other 10%
"represents" less or more of that 10% of the time; my question is,
that other 10% is 10% of ***what*** ?

Laurent Bossavit wrote:
>
> > Phrase "money then spent so far" implies something other than
> > fixed-price contract, doesn't it?
>
> It does, it does.
>
> > I agree with the moral principle, but not that it comes to play much
> > in fixed-price until the final result is delivered to the customer.
>
> Doesn't that observation nail the problem down exactly ?

Maybe.  I'm sorry, but I got lost.  Must come from waking in the middle
of the night and starting to reply to mailing list messages. :-(
Maybe we cut too much context.

> > With other methods, the remaining 10% is the 10% that takes another 90%
> > of the time, while with XP delivering business value in priority order,
> > that 10% might realistically represent 10% (or even less, or slightly
> > more) of the remaining time.
>
> I'm missing something. "10% of the remaining time" I understand -
> that was the point of my remark. You say that some other 10%
> "represents" less or more of that 10% of the time; my question is,
> that other 10% is 10% of ***what*** ?

Ah, that's 10% of the promised functionality.  Yes, clearly that
is very hard to measure, but my point was that if XP focuses on
delivering the riskiest and highest business value first, then
when you've got 90% through the esimated time, you're very likely
to have close to 10% (or even less) of the remaining work to do
in terms of functionality/risk/business value, and therefore about
10% (or even less) of the remaining time.  At least that's my theory.
Or maybe it was more of a question for the group. :)

-Peter

Around Thursday, February 28, 2002, 10:23:10 PM, Peter Hansen wrote:

> I'm ever more convinced that Google is god:

> http://www.google.ca/search?q=realized+fastest+change+laugh+folly

I almost did that. Should have. Was lazy. Nothing new there.

Ron Jeffries
www.XProgramming.com
First they ignore you, then they laugh at you, then they fight you, then you
win.
   - Ghandi

Around Thursday, February 28, 2002, 10:21:35 PM, Dossy wrote:

> _Who Moved My Cheese_

> http://www.amazon.com/exec/obidos/ASIN/0399144463/panoptic0f

> Don't you remember that long ugly thread I started months ago
> about this book?  :-)

Yes, but I failed to memorize the book. Apologies.

Ron Jeffries
www.XProgramming.com
Sigs are like I Ching or Tarot. They don't mean anything,
but sometimes if you think about them you'll get a useful idea.

Around Thursday, February 28, 2002, 10:24:34 PM, Dossy wrote:

>> I'm giving the best advice I have. You get to decide whether it's true
>> for you.

> Couple that with "free advice is worth just that" and it becomes
> _really_ interesting ...

I assume that since information wants to be free, I'm doing the right
thing here, launching these ideas into the world ...

Ron Jeffries
www.XProgramming.com
Bang, bang, Jeffries' silver hammer came down upon their heads ...

Around Thursday, February 28, 2002, 11:05:49 PM, Mike Clark wrote:

> If only the wedging were immediate, it might be an easier sell.  As it is, the
wedging
> is a slowly tightening noose.  When it becomes uncomfortable, it's often times
too
> late.

Yeah, see, that's why I don't wear ties any more. They sneak up on
you.

Ron Jeffries
www.XProgramming.com
Accroche toi à ton rêve.  --ELO

Around Friday, March 01, 2002, 1:39:40 AM, drawstho@... wrote:

> Let me chime in on this issue. I don't think it has anything to do with
wanting to succeed or not. I
> think that it has to do with discipline. People want to succeed, and may even
know how to succeed, but do
> they have the discipline to do it? XP requires that each member of the team
develop the discipline to
> stick with the practices.

"You keep using this word. I do not think it means what you think it
means."

Well, actually, I'm halfway between you and Kent on this one. As you
surely know, he doesn't agree that XP requires discipline.

I think it takes discipline to learn it but after that it is just what
you do.

> IMHO, one of the reasons for high-ceremony processes is that they
> try to replace individual discipline with process discipline, which
> is enforced by a QA group, normally. This means that not everyone
> has to have the discipline to do it right, just the process
> police...

Which doesn't work because no one pays attention to the process group.

> So, agile processes are quicker, cheaper, and more responsive, but
> require more disciplined people. High ceremony processes can get the
> job done with less disciplined people, with a higher cost in both
> money and time.

That's the theory. I think it's not obviously true, for two reasons:

1. In the high-process form, it still only works to the extent that
everyone does what they are supposed to do, so the workers still have
to behave according to the discipline, even if it is forced, and there
is definitely MORE discipline going on.

2. High-process approaches work abysmally poorly unless they are
really adopted by the real workers. This fact tells us that it is
still what the workers do that counts.

Workers on an XP project do less weird stuff. Therefore, less
discipline. Mostly they do what programmers are supposed to do: test,
code, design, analyze, etc. And they do it in a form that is quite
close to what we find in the wild.

Therefore XP requires less discipline, not more, than high-ceremony
processes. It works as well as it does, arguably, for exactly that
reason.

> As I said before, think Special Forces A-team versus regular infantry... this
analogy works for me - but
> I'm a soldier...

Do the special forces guys do what they do because they have
discipline, or do they have discipline because they do what they do?
Or do they just do what they do, and it happens to be really good for
special forces work?

Ron Jeffries
www.XProgramming.com
The practices are not the knowing: they are a path to the knowing.

Around Thursday, February 28, 2002, 10:20:29 PM, jeffgrigg63132 wrote:

> --- Peter Hansen <peter@e...> wrote:
>> [...]
>> So what was the problem again? :-)
>> -Peter

> Good question!

> The original problem was this:
> XP doesn't tell you how to estimate and bid on a fixed-bid contract.
> You have to use some other estimation and bidding technique if you
> wish to compete in that marketplace.

I do not see why (a) this would be a problem since you are already in
that marketplace and thus presumably already have idiots making up
your bids out of their orifices, and (b) a release plan multiplied by
a suitable integer between e and pi would work even better. You'd have
to let the programmers actually look at the specs before bidding,
which is idiotic, but otherwise it seems like it would work.

> Which is not to say that XP shouldn't be used to implement the system
> once you get the contract.  Only that XP doesn't help you get the
> contract.

> Most XP discussion seems to be of the concept "you shouldn't do
> business that way."

Yes. Your customer will get a better product, we think, in a steering
style of project. But nema problema, just do as you suggest here and
use XP where it applies and continue your normal practice of asking
for the amount you think he'll pay.

> Nice idea, I say, but I have a mortgage to pay,
> and maybe a cat to feed.  ;->

Chet's cat barfed on the keyboard of Chet's new laptop yesterday and
now the laptop doesn't work. Rethink that cat idea, that's my advice.

Ron Jeffries
www.XProgramming.com
I must create a system, or be enslaved by another man's;
I will not reason and compare; my business is to create. --William Blake

On 2002.03.01, Ron Jeffries <ronjeffries@...> wrote:
> Around Thursday, February 28, 2002, 10:24:34 PM, Dossy wrote:
>
> >> I'm giving the best advice I have. You get to decide whether it's true
> >> for you.
>
> > Couple that with "free advice is worth just that" and it becomes
> > _really_ interesting ...
>
> I assume that since information wants to be free, I'm doing the right
> thing here, launching these ideas into the world ...

Ah, we all know you're just stirring the pot, Jeffries.  Poisoning
the minds of IT people everywhere with your blasphemous Extreme
Programming heretical nonsense.

The First Church of Waterfall's archdiocese will have to excommunicate
you for your treacherous acts against the One True Faith.

-- Dossy

:-)

--
Dossy Shiobara                       mail: dossy@...
Panoptic Computer Network             web: http://www.panoptic.com/
   "He realized the fastest way to change is to laugh at your own
     folly -- then you can let go and quickly move on." (p. 70)

On 2002.03.01, drawstho@... <drawstho@...> wrote:
> People want to succeed, and may even know how to succeed,
> but do they have the discipline to do it?

Excellent!

> XP requires that each member of the team develop the discipline to
> stick with the practices.

Every methodology requires that the whole team (well, every person
fulfulling one or more roles) must have the discipline to carry out
the tasks assigned to their role(s).

I think XP is "better than" other methodologies because its requisite
tasks are simple and easy, thus my guess is that they should be easier
to perform or "stick to" than those tasks of other, more complicated
and difficult methodologies.

For those people who even find it difficult to adhere to XP,
I wonder what possible methodology they have the discipline to
stick to.  Code-and-fix probably.

> IMHO, one of the reasons for high-ceremony processes is that they try
> to replace individual discipline with process discipline, which is
> enforced by a QA group, normally. This means that not everyone has to
> have the discipline to do it right, just the process police...

High-ceremony processes are geared towards playing the blame game.
They enumerate in detail the functionality, who's responsible for
delivering/implementing, testing, accepting, and releasing the
deliverables, on what timeline, and some processes go so far as
to even detail the actual deliverables themselves.

The only value this could possibly deliver is so that you know
who to blame with no uncertainty.  The only value this might
possibly have is to get rid of the team members that are to
blame, and try again hoping for more success in the next
life.

> So, agile processes are quicker, cheaper, and more responsive, but
> require more disciplined people. High ceremony processes can get the
> job done with less disciplined people, with a higher cost in both
> money and time.

Do you really think so?  High ceremony processes by definition have
more ceremony, and doesn't it take discipline to carry out that
ceremony?

-- Dossy

--
Dossy Shiobara                       mail: dossy@...
Panoptic Computer Network             web: http://www.panoptic.com/
   "He realized the fastest way to change is to laugh at your own
     folly -- then you can let go and quickly move on." (p. 70)

> Jeff grigg (jeffgrigg63132) wrote:
> > Nice idea, I say, but I have a mortgage to pay,
> > and maybe a cat to feed.  ;->

--- Ron Jeffries <ronjeffries@a...> wrote:
> Chet's cat barfed on the keyboard of Chet's new laptop yesterday and
> now the laptop doesn't work. Rethink that cat idea, that's my
advice.

"Cats are just weird."
    - from "Everything I need to know I learned from Sandman"
      http://home.fuse.net/vetinari/EINTKILFS.html

> So, agile processes are quicker, cheaper, and more responsive, but
> require more disciplined people.

I'd like to pursue the smoker analogy... There are many ways you
can quit smoking, from keeping a list on paper of every time of day
you've wanted a cig since going cold turkey, to nicotine patches or
chewing gum or whatever, to just no longer wanting to smoke one
bright and beautiful day.

These processes require varying degrees of formality in your
commitment to them. Do they require more or less discipline
according to their degree of formality ? Or is that not the case and
what matters is that you "really want" to quit, not just say you want to
quit ?

I believe it's a matter of strength of commitment, and that there are
various ways in which one can be strongly committed to something.

So I also suspect that there is no useful distinction to be drawn
between "really wanting" something and "having the discipline" to
pursue it - but I'm open to learning more about what distinctions of
that sort might be drawn...

But I'll note that for "the same" strength of commitment, some
processes might conceivably yield more concrete results than some
others. It's even possible that such a relation holds between XP and,
say, classic Waterfall.

> Phrase "money then spent so far" implies something other than
> fixed-price contract, doesn't it?

Actually I shouldn't have agreed with that so readily.

Fixed-price does not imply that you are paid 100% of the price after
spending 100% of the planned time... So I would think that "money
spent so far" does *not* imply something other than fixed price. (I
had to scribble Ps and Qs and arrows on a piece of paper to check
it out, but I'm somewhat sure that's a valid inference.)

Anyway, you seem to be saying that in a fixed-price contract we only
make sure once, at the end of the project, that the business value
delivered was worth "the money spent so far". I think that's precisely
the problem with these contracts.

[In XP at 90% of the project you really have 10% left to deliver - to
which I'm asking, "10% of what"]

> Ah, that's 10% of the promised functionality.  Yes, clearly that
> is very hard to measure

Do we even promise to deliver specific functionality ? I thought we
promised to deliver business value. It seems to me that if we learn
anything during the course of the project, we are not going to deliver
the promised functionality. And we want to learn.

A project does not go from a point A to a point B, such that it would
make sense to say "we're 90% of the way there". We start from a
problematic situation, and keep going until we're far enough from
where we were.

> when you've got 90% through the esimated time, you're very likely
> to have close to 10% (or even less) of the remaining work to do

Isn't it at least possible in principle that, when you've gone through
just 50% of the budget, you suddenly discover that you've delivered
99% of the business value ?

Am I splitting hairs here, or is what I'm saying making sense ?

Hello Ron,

Friday, March 01, 2002, 7:36:10 AM, you wrote:


>> Nice idea, I say, but I have a mortgage to pay,
>> and maybe a cat to feed.  ;->

RJ> Chet's cat barfed on the keyboard of Chet's new laptop yesterday and
RJ> now the laptop doesn't work. Rethink that cat idea, that's my advice.

Most o th k ybo rd orks

Best regards,
  Chet                            mailto:chet@...

Around Thursday, February 28, 2002, 11:05:49 PM, Mike Clark wrote:
>
> If only the wedging were immediate, it might be an easier sell.  As it is, the
wedging
> is a slowly tightening noose.  When it becomes uncomfortable, it's often times
too
> late.

"Prevent wedgies: use XP."

Laurent Bossavit wrote:
>
> > Phrase "money then spent so far" implies something other than
> > fixed-price contract, doesn't it?
>
> Actually I shouldn't have agreed with that so readily.
>
> Fixed-price does not imply that you are paid 100% of the price after
> spending 100% of the planned time... So I would think that "money
> spent so far" does *not* imply something other than fixed price.

I'm not sure any more either. :-)  And I've been deleting the messages
as they arrive and don't think I'll go back to review the thread
right now.

> [In XP at 90% of the project you really have 10% left to deliver - to
> which I'm asking, "10% of what"]
>
> > Ah, that's 10% of the promised functionality.  Yes, clearly that
> > is very hard to measure
>
> Do we even promise to deliver specific functionality ? I thought we
> promised to deliver business value. It seems to me that if we learn
> anything during the course of the project, we are not going to deliver
> the promised functionality. And we want to learn.

With _XP_ we deliver business value, but with a "typical"
fixed-price contract we are expected to deliver specific
functionality.  The issue seems to me to be how, with a customer
expecting a fixed-price contract in the theoretical sense (not
in the usual sense of a death march failure which goes way over
schedule), how can we use XP safely to accept a fixed-price
arrangement?  I think XP reduces the risk internally (i.e. within
the organization, even if we don't expose XP to the real customer
and just use an internal proxy Customer) to the point where the
company can safely accept fixed-price.  Perhaps much more than
with many other methods.

> A project does not go from a point A to a point B, such that it would
> make sense to say "we're 90% of the way there". We start from a
> problematic situation, and keep going until we're far enough from
> where we were.

Again, from the XP point of view that's true.  If we keep the XP
features purely internal, not exposed to our customer, while we
implement the fixed-price contract, I think we can reach a point
where we are "90% of the way there" as compared against the contract
requirements.

To some extent, it might be acceptable not to focus on delivering
business value in a fixed-price contract, but instead just focus
on delivering the requested functionality.

Put another way, one might say that a fixed-price contract is a
defective way of requesting development work, but if a customer is
insistent on that approach, even XP can deliver it.  If a customer
is really interested in business value and not contracted features,
it might be relatively simple to convince them (at least after a
time working with them and gaining their trust) that time-and-materials
with XP underlying the relationship is the better way to go.

And I seem to recall reading that in the XP literature several times.

> > when you've got 90% through the esimated time, you're very likely
> > to have close to 10% (or even less) of the remaining work to do
>
> Isn't it at least possible in principle that, when you've gone through
> just 50% of the budget, you suddenly discover that you've delivered
> 99% of the business value ?
>
> Am I splitting hairs here, or is what I'm saying making sense ?

What you're saying makes total sense, from the XP point of view where
business value matters.  I think if we agree perhaps a little
simplistically
that fixed-price implies features and not value, we can agree that
XP can be used for fixed-price simply because it reduces risk and
allows the development organization to deliver features safely, and
therefore to take on that kind of work.

Am I getting closer to the fundamental difference here?

-Peter

> The issue seems to me to be how, with a customer expecting a
> fixed-price contract in the theoretical sense (not in the usual sense
> of a death march failure which goes way over schedule), how can we use
> XP safely to accept a fixed-price arrangement?

I agree that this is the issue. As I see it, though :
  - the customer expects something
  - you knowingly set out to do something else.

This isn't "safe", ever. You may be able to mitigate the risk. But in
one sense, if you're pretending to do fixed-price while doing XP
"internally" you're missing out on at least one XP value.

The customer has one mental model of how software development
goes. You have a different mental model. Communication across
the gap in mental models is going to be difficult and distorted; XP
says communication is essential to project success.

This is my model... If it is correct, failure is to be expected.

If you and your customer share a model of how software
development goes, and this shared model is effective, then -
however you formalize the model in your contract - success
becomes possible, though not assured.

> Put another way, one might say that a fixed-price contract is a
> defective way of requesting development work, but if a customer is
> insistent on that approach, even XP can deliver it.

I'm pretty sure XP can (sometimes) deliver it. It's an open question
whether it "should".

Dossy replied to Ron:
>
> On 2002.02.27, Ron Jeffries <ronjeffries@...> wrote:
> >
> > Dossy said that you have to want to be successful to do XP. It seemd
> > he was saying that (a) there are people who don't want to be
> > successful and (b) people who don't want to do XP don't want to be
> > successful.
> >
> > I disagree with both of those.
>
> A person who is developing software may tell you they want to
> ship quality software on time but they refuse to take the
> steps (we as XP practitioners) believe are necessary to do
> just that.  Do they really want to deliver quality software
> on time?  Are they just saying it and believing it but
> not acting in such a way to achieve their desire?
>
> I don't think I ever said anything that translates to (b), but
> it's entirely possible.  Either way, I certainly didn't mean
> (b).

Dossy, your paragraph sounds a lot like (b) to me.  You're saying
that the evidence that they want to ship quality software on time
is that they follow the practices you (we) recommend.  This implies
that if they don't want to follow the practices, they must not be
serious about wanting to ship quality software on time.

It's quite possible, however, that they do want to ship quality
software on time and they may believe that the XP practices will
cause them not to do so.  Or they may believe that if they just
get the requirements right before they start, they will be able
to do so.  Or they may believe that if they have a good enough
Architect do the design before the coders start, they will be
able to do so.

In any of these scenarios, saying that they must not *really*
want to ship quality software on time is not congruent with
their beliefs and will do nothing to change their mind.  It
is an argument that may undermine your intent with uninvolved
observers, too.

  - George

A friend told me last night that
  - Good managers remove roadblocks
  - Bad managers create roadblocks
  - Managers who do nothing are better than average

  George

> -----Original Message-----
> From: geektank [mailto:emeade@...]
> Sent: Thursday, February 28, 2002 8:30 PM
> To: extremeprogramming@yahoogroups.com
> Subject: On wanting success (was Re: [XP] cons of XP -- on "success")
>
>
> --- In extremeprogramming@y..., "Charlie Poole" <cpoole@p...> wrote:
>
> > A good manager over an XP team would
> > be clearing obstacles rather trying to control how things are done.
> >
> > Of course, the hard thing is to convince a manager to act that way.
>
> I've always been told that this is how all good manager's act,
> regardless what sort of team they manage.
>
> Erik Meade
> http://junit.org
> emeade@...
>
> -----------
>
> Views expressed in this message represent those of Object Mentor.
>
>
>
> 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
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

I've been lurking here for the last couple of years, ever since reading the
white book. I thought my experiences would be relevant to recent threads.
Today I am a lead programmer on a team of 10. Our project is embedded,
real-time, C++, CORBA. Five years ago I was tech writing for this same
company. As I grew to understand the machine, I asked for some programmig
projects, and  the lead software engineer  agreed to start me out on a few
simple, side projects. I have an Engineering background, but the last time
I'd actually programmed anything was fifteen years before, back in school,
using Fortran - I had absolutely no method indoctrination. As I grew into my
current position, there were a number of things which began to annoy me
about writing software:

- I was given stacks of outdated documents, which I was suppose to digest
and maintain, but which did little to increase my understanding of the
project.

- I found most of the comments in the code useless, things like: " // now
loop through the collection & // get a pointer to the next element "

- I was afraid to "disturb" the senior programmers - in their offices, down
several halls, with their headphones - with my silly questions.

- I wondered what other programmers were working on, whether it could help
me, whether I could help them.

- I noticed we never knew how long it would take to complete a new project.

- I got really sick of the debugger.

- I questioned why there couldn't be a better way of testing to ensure my
changes didn't break anything.

- Many times I found myself thinking, gee, it'd be easier if I could change
this code myself instead of submitting a request to its creator.

- I found myself making smaller and smaller changes, wondering why our team
merged only once or twice a month.

- I stopped working past midnight just to prove myself; I found that I was
making lots of dumb mistakes, thus "disproving" myself.

- When no one was watching, I rewrote existing code, to make it easier to
understand; at first, I had no set of practices to guide me, just a touch
and feel kind of thing.


... blah, blah, you get the idea. The XP books and Martin Fowler's
Refactoring were like lights coming on in the dark. I'm not crazy, I said to
myself, other people have the same issues. Arriving at the XP principles as
I did, carrying very little software baggage, XP seems natural, obvious.
Just thought I'd share.

Peter Hansen <peter@...> writes:

> Laurent Bossavit wrote:
> >
> > > Phrase "money then spent so far" implies something other than
> > > fixed-price contract, doesn't it?
> >
> > It does, it does.
> >
> > > I agree with the moral principle, but not that it comes to play much
> > > in fixed-price until the final result is delivered to the customer.
> >
> > Doesn't that observation nail the problem down exactly ?
>
> Maybe.  I'm sorry, but I got lost.  Must come from waking in the middle
> of the night and starting to reply to mailing list messages. :-(
> Maybe we cut too much context.
>
> > > With other methods, the remaining 10% is the 10% that takes another 90%
> > > of the time, while with XP delivering business value in priority order,
> > > that 10% might realistically represent 10% (or even less, or slightly
> > > more) of the remaining time.
> >
> > I'm missing something. "10% of the remaining time" I understand -
> > that was the point of my remark. You say that some other 10%
> > "represents" less or more of that 10% of the time; my question is,
> > that other 10% is 10% of ***what*** ?
>
> Ah, that's 10% of the promised functionality.  Yes, clearly that
> is very hard to measure, but my point was that if XP focuses on
> delivering the riskiest and highest business value first, then
> when you've got 90% through the esimated time, you're very likely
> to have close to 10% (or even less) of the remaining work to do
> in terms of functionality/risk/business value, and therefore about
> 10% (or even less) of the remaining time.  At least that's my theory.
> Or maybe it was more of a question for the group. :)

But you're missing two of the points of XP - 1. the Customer drives, and 2. you
never promise functionality, only effort. The Development team *never* knows how
much work there is left to do - the Customer decides when it is done. If the
Customer did not select the most valuable stuff to do first, then the Customer
was not doing his/her job. By definition, this is outside the scope of the XP
development team. If it's inside the scope of your contractual arrangement with
your Client you have a problem, but it's not a problem that XP will help you
solve... it's probably one of those "cons to XP" we were discussing earlier -
"Must have a Customer that is empowered to drive"

Dan  ;-)
>
> -Peter
>
> 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
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Rick Hightower made a strange utterance something like this:
> >Unfortunately I am technically the junior person on the team having been
>hired last and having the least experience.  So I'm not in a position to
>screen anyone.
>
>Ouch... been there. Maybe you should have screened the company.

Well, I was not in a position of power.  I just graduated from college and
though I had two years of industry experience I wasn't flooded with
offers.  The company I'm with now made me a good offer and it turns out I
really like the environment; all the people I work with are great and we
get along really well.  This is a big difference from jobs I've had in the
past and it really makes me appreciate the job.  It also makes the
inexperience of some of the people I work with all the more frustrating.

>Suggestion: Help them improve the screening process for new recruits.
>Put together a training program, brownbag technical lunches (which include
>book studies), etc. to improve existing staff.

I don't think we're hiring anyone new right now.  Plus, I work for a large
company and they have some institutionalized hiring practices I doubt they
would let a programmer alter.


--
"The best programmers that I have ever met have an amazing ability to make
nasty sh*t disappear. *Poof*" Gareth Reeves -- reevesg@...

> > J. B. Rainsberger:
> > For my part, the *only* way in which a 36-hour stretch feels
> > good is as a
> > reminder that I don\\\'t have to do it very often any more.
> > It\\\'s a reminder of how
> > far I\\\'ve come as a programmer that I don\\\'t rely on it any
> > more.
>
>    From: \"Blum, Robert\" <rblum@...>
> I don\'t rely on them either. Do you _never_ enter a state of flow where
> you
> can just go on? Do you never have the feeling that if you just add that
> one
> more feature, it will be so much better?

Absolutely I do. Remember, Sustainable Pace is about understanding how much
work you can handle, doing that much, and no more. It\'s about being honest with
yourself and admitting that you just can\'t do 40 hours this week. I do not
advocate stopping work just because it\'s 5PM: if you are having more fun at
work than you would be at home, then stay at work! :) If you notice that doing
so makes it more difficult for you to do work over the long haul, then change
what you\'re doing. I see Sustainable Pace as simply a reminder that this is not
a sprint -- it\'s at least a 5-km run. Pace yourself.

> Yes, the last one does not happen if you strictly follow XP. What if
> you
> explore on your own?

I disagree with this statement. If you strictly follow XP, then you work as
much as you want to work and no more. This is different for everyone and it
requires being honest with oneself about how much one wants to work. This last
part is not always easy. On that basis, perhaps the occasional long hours are
good.

> > The long hours,
> > in and of themselves, are PURE EVIL. I love my wife and my
> > cats more than my
> > job.
>
> I love \'em both. (MY wife and MY cats, and MY job, that is :)

Right now, I don\'t love my job. I have enjoyed my job in the past, but my wife
and my cats still win every time. Maybe if my wife abused me a little or my
cats tried to kill me more often, the pendulum might swing in the other
direction.

> And sometimes, I just encounter a challenge that is too good to pass
> up
> anyways. It doesn\'t happen often. But when it happens, it\'s a fun 36
> hour
> stretch. And no, just putting in time to get things done is not my idea
> of
> fun either.

Fun is fun; it\'s different for everyone. To me, fun is not working for money. I
do everything I can in support of that goal, in addition to whatever is
necessary to keep the people paying me happy.

> P.S.: What\'s with the escaping of all quotes?

Assuming the problem remains, this will be quote humorous: I don\'t know. :)

J. B. (Joe) Rainsberger
President, Diaspar Software Services
http://www.diasparsoftware.com
Let\'s write software that people understand.

> Plus, I work for a large company and they have some institutionalized
> hiring practices I doubt they would let a programmer alter.

As an exercise, please list three ways in which the actions of a
"lowly" programmer might have influence on the hiring practices of a
large company.

(I'll list one for free - date a nice-looking girl from HR, make her see
things from your point of view.)