How good the design is doesn't matter near as much as whether the design is getting better or worse. If it is getting better, day by day, I can live with it forever. If it is getting worse, I will die. --KentBeck Truly new things are not the provenance of scheduled software development. Ordinary wonderful things, however, can be produced to enough of a schedule that you can play the Planning Game. --KentBeck Recovery is a tar-pit for programmers who like to play in the mud. --MichaelFeathers. ---- Good software doesn't depend on genius, it depends on clear communication and coordination between customer and programmers, and between the programmers themselves. --RonJeffries Most practices that aim to motivate developers by fostering competition seem to have the reverse effect. --TomAyerst When I suddenly understood how each of the practices of XP have weaknesses that are made up for by certain strengths of other practices I wanted to try a pure XP project, not just struggling to get away with as many practices as I could sneak in. --RodneyRyan But all the other programmers were doing it! --PhlIp ---- More quote(s) at MatrixManagement, JobSecurity, MockObject, ResilienceVsAnticipation... ---- We tried pair designing but the process doesn't know how to track it so its discouraged, (incidentally it did work well). We tried for an oral or very small written coding standard for our group, but instead got a massive company wide document. We've tried to move our group into a large room with tables, but its too weird, and besides we've already got all of these nifty cubicles.... The consultants from the avionics firm are particularly unreceptive to XP. They want hard data; they think anything else is bs. They argue that if they based decisions on gut feelings that planes would fall from the sky, rockets would spin out of control, and they would lose business. Personally I think they don't like XP because it could cause them to lose some consulting business. --Christopher J. Helck Arrrggghhh! We're in the middle of a crunch time. (We used big design up front,. Took six months to design and we now have three weeks to implement the entire project. Things are not going well.) Can I contact you again in a few weeks when things sort themselves out? I'm really interested in seeing pair programming in action. --GeoffreyClements ---- Don't swing your bat before the ball gets to you and don't swing it afterwards either. Refactoring constantly is like keeping your eye on the ball. It will let you see exactly when and what and where you need to do. --PhilGoodwin ---- Beck presses it while he talks. I suspect he presses it in his sleep. --RonJeffries The "Run" button is addictive. I sometimes press it two or three times in a row, if I need a little extra confidence boost before proceeding. I always feel like a Skinnerian experiment when I do, but at least now I know what those rats felt like. --KentBeck ---- For instance: if your program has a requirement that it update and retrieve specified information from multiple applications at specified intervals, a metphor for that section of the system could look like this: The system "mailman" then begins his route. He stops at each "house", picking up the outgoing mail that is sitting in the mailbox (as long as the flag is up), and delivering any mail from his mailbag that was supposed to go to that address. As you can see, the metaphor is much more colorful than any analysis document could ever be. --RaviDesai ---- Sufficient for the iteration are the requirements therein. --RobertMartin and ... '''Amen''' ''Sufficient unto the day is the evil thereof. --MAT 6:34'' ---- Forget about dividing the world up into philosophically correct hierarchies. Divide the *problem* into *pragmatically* correct ones. --MichaelHill ---- Expensive setUp() is a design smell. --KentBeck ---- At 09:09 AM 7/9/2000 -0700, kjray wrote: > Well, we ARE going slower because bug fixes are taking longer to do than > expected, but it doesn't seem to be the case that pairing now makes the > fixing go > quicker. What I'd not quite naively EXPECT is that maybe pairing while finding the bug wouldn't go faster, but that pairing while fixing it would both go faster and get better results. If you get any subjective data on this, please let us know. > My Customer wants 'feature complete with lots of bugs' instead of 'most > features with few bugs' (bugs and features are prioritized via the > planning game), > so they get what they ask for. I hope you've got THAT in writing, preferably blood. In all the places I've visited, even when they said this, they were then really angry about bugs once the crap came out. I hope you'll update us on how this aspect plays out after your initial release. Ron Jeffries www.XProgramming.com . ''Update - no anger. Situation normal - everything a few weeks late as usual. Programmers frustrated because they want to do this again with version two -- but with even less time for software development.'' -- kjray ---- Books Kent and Ron did not write on Extreme Programming: Pretty Adventuresome Programming About As Much Excitement in Programming as You're Likely to Need Dials Somewhere Up Pretty High Dials to 9.3 Plus or Minus a Half Do Something Fairly Simple if it Works for You --AlistairCockburn ---- The code done yesterday should be as good as you could make it yesterday. The fact that you know more today, and are more capable today, is good news about today, not bad news about yesterday. --RonJeffries ---- I find running an XP project is easier than convincing your managers to try it for the first time! --JamesDobson ---- PhlIp: Politics is friction between the needs of the individual and the needs of the group. Dossy: Politics comes from the greek word "poly" meaning "many", and "ticks" which are small, blood sucking arachnids. ---- ThereIsNoSuchThingAsNoBugs ---- BigDesignUpFront >is< CodeAndFix. You just do it to speculative diagrams instead of unstable testless code. -- PhlIp (on the TestDrivenDevelopment list) ---- See also XpMailingList, XpFaq, SteerWithYourEyes, XpNewsgroupQuotes, BrufPredictsFailure. "Yahoo's [group] search system blows goats." --DossyShiobara [reposted without permission from the XpMailingList] ---- "In software, the reverse engineering process is done with a decompiler, which can produce startlingly obscure code which can, nevertheless, be compiled to produce the original program. The part that's missing is the theory: the mental construct that pulls everything together into something that one can understand and reason (or whatever it is we do) with. This has been a discussion in XP from the beginning: can you write a program text so that someone can pick it up and build the needed internal representation efficiently, or do we need additional artifacts (design documents) to assist that process?" --John Roth, extremeprogramming mailing list, September 29, 2005 2:19 PM ---- CategoryExtremeProgramming