> <>
> It doesn't! What it does is remove the "problem" in the first place :-)
>
> Let's try to remove all our existing knowledge: if you didn't have to
> care about the build, why would you?
Because it's hard for me to imagine caring about the product without
caring about the build. If we don't care whether software builds
correctly, well, then all bets are off. We might as well go out and in
the street and play marbles rather than write software. So, for that
reason it is important to care -very publically- about the build. It
builds that sense that: hey, we as a team, care about quality work.
> <>What the developer will still need to care about is committing
> frequently. This is the important part because this is what is causing
> the integration to happen.
>
> -Vincent
The problem is... it cycles back on itself. In your system, developers
don't have to care about committing frequently, they have to care about
committing frequently and correctly. And, it appears that in the
situation you outlined, they don't care about committing correctly yet.
In cases like these, teams are usually in a good deal of pain. The key
thing is to get them to feel what it is like when good habits get them
past the pain rather than applying analgesics.
Michael Feathers
author, Working Effectively with Legacy Code
www.objectmentor.com
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
