|
5 August 2001, 15:03 GMT
"At last we have found our calling," junior programmer Billy Kiddster proclaimed in a recent telephone interview.
He continues: "I love this thing about 'pair programming', i.e. two people sitting around the same keyboard, hacking away at the same machine. The theory behind it is that if they are both clueless, then between them they should still be able to muddle through. I believe this part of the methodology is called 'The blind leading the blind'. It's pure genius!"
Kiddster, a true convert, explains: "First and foremost, [XP is] a re-examination of software development practices that have become standard operating procedures. What does this mean? Well I'll tell you: it means that nowadays, in what the unconverted (or 'unwashed' as me and my friends Bobby and Joe like to call them) sometimes term the 'Hacker Generation', there is so much pressure to get software to market real quick, like at Internet speed.
|
"I must have discipline!"
|
|
"So what do people do? They throw caution to the wind, and they just go at it, hacking out any old shit, hoping it's what is needed. Nowadays that is standard operating procedure. So XP simply takes that, and wraps a nice feel-good 'methodology' around it. And to hide the fact that we're embracing a lack of discipline, we maintain that XP is all about discipline!"
We were about to ask another question, but Kiddster, evidently on a roll, barely took a breath before continuing:
"In many software environments dynamically changing requirements is the only constant - in fact, XP is perfect for environments whose functionality is likely to change every few weeks. This means writing and re-writing.
"Of course, one time the answer would have been to educate the customer and tackle what is really wrong - lack of clear direction, and clueless idiots who don't know how to run a project. One time, people used to say that if you don't know what you're supposed to be programming then don't touch that keyboard.
"Not any more though, nowadays it doesn't matter if you're scared of offending the customer, you just let them go right ahead changing their mind at lightning speed, 'cos you've got XP hackeritis to speed you along and handle those random pointless changes..."
At this point in the interview there was a loud thump from the other end of the phone, and we realised that poor Billy, having forgotten to take a breath for over three minutes, had fainted.
Related Stories:
XP Month: Fanatical XP Splinter Group Takes Cult to Extremes (Part One)
XP Month: Fanatical XP Splinter Group Takes Cult to Extremes (Part Two)
Reactive Programming (RiP)
VB programmer invents new methodology.
Talkback - Have Your Say:
This forum is closed now. But check the Forums list for other areas to post a message.
Message Index:
Bull*@!#
Stremo
Nice one Stremo
Matt matt@SPAM-I-AM-bad-managers.com
Go Bad Managers
walrus
Managers in favor of conventional methodologies
Steffen Vulpius
Steffen - hehe, thatīs the other extreme.
Matt
Misconceptions about XP
Anonymous person
Ratios all wrong (Mecha XP must die!!!!!)
Dino
wisdom
Ron Jeffries ronjeffries@acm.org
AMEN
DORAN
re: wisdom
Matt
if X is good, do X all the time...
keith ray keithray@home
Very insightful Matt...
Bill Caputo logosity@yahoo.com
Ha ha, priceless
Dino
XP Sucks
Bill White dhyphen@yahoo.com
XP must be magic
Bill Fleischmann bfleischmann@medcharge.com
Billīs XP
Ron Jeffries ronjeffries@acm.org
Moderation in all things
Anonymous person
Pair Programming
Ron Jeffries ronjeffries@acm.org
open workspace
Ilja Preuss ilja.preuss@web.de
re - This is a classic logic fallacy.
blah blah@blah
re - This is a classic logic fallacy.
blink blink@blink
The Messages:
Bull*@!#
If there is a point to this article, would you please go back and put it in bold face, cause I sure couldn´t find it.
Millions have been tortured and killed in the name of Jesus (and Mohammed and probably a bunch of other religious guys I never heard of). What does that say about their message? Damned little. What does your little tirade say about XP? Likewise.
Why don´t you tell us what you don´t like about XP and see if maybe it´s just you?
Stremo
Stremo
Not sure where exactly, Probably the USA
Sun Aug 05 21:20:40 EDT 2001
Nice one Stremo
Stremo, your response speaks bucketloads about the religious fanaticism of some XP advocates.
"Why donīt you tell us what you donīt like about XP"? Try re-reading the article (and the one before it about RiP).
If that annoyed you, youīll *love* next weekīs article!
All the best,
Matt.
Matt
London, UK
Mon Aug 06 07:23:38 EDT 2001
Go Bad Managers
Kudos for daring to post this story. I know how religiously these guys defend XP.
I worked at a company where this manager was trying to introduce XP, pair programing and all. The coders just laughed, they recognized XP for the waste of everybodys time that it is.
walrus
Not sure where exactly, USA
Mon Aug 06 10:24:22 EDT 2001
Managers in favor of conventional methodologies
"What is so terribly wrong with doing it the old way?" Senior Manager of Technology Development reporting to Vice President (Technology Services) Howard Miller asked us in a recent interview.
"Iīve been in this business for 40 years and never had any problems with it." he continues. "We now have finally full documentation on every single step that needs to be done to successfully complete a project. The developers just have to read the 43 files of the documentation and follow the steps therein. And if they document every step they have completed, we always know where the project stands and can easily replace one programmer with another in case of sickness or one programmer leaving for the insecurity of some silly start-up company. Itīs so easy even a monkey could do it. We are even thinking about replacing some of our developers with monkeys to do a rentability study."
When asked about changing requirements he replied: "You know, I hear this a lot. Even from old customers. Suddenly, in the middle of the project, they want something changed. Not with me. A customer has to specify how the program should look like, what it should do, and how its inner workings are and we build it exactly like that. If they dont know that, I advise them to develop a prototype themselves and if they are sure it does what they want they can give us the specifications and weīll build them an innovative quality product. And if some new technology comes up in the meantime, like this java I heard about
lately, we can always negotiate about a follow-up project."
Steffen Vulpius
sv2@emw.inf.tu-dresden.de, Germany
Mon Aug 06 12:47:24 EDT 2001
Steffen - hehe, thatīs the other extreme.
Itīs really a cultural thing. Itīs important that a projectīs requirements arenīt set in stone. That helps no-one. However, XP fosters a culture where fickleness is almost encouraged. All very reactive - dart this way, now that way, now the other.
XP attempts to compensate for peoplesī incompetence by making it "okay" to get it wrong. This would be great if wrongness was genuinely free - i.e. if you could correct screw-ups without impacting the project. Of course thatīs never going to happen, so itīs much better to at least *try your hardest* to get it right early on: get the requirements right before you design; get the design right before you start programming; get QA involved as early as possible. Base the test specs on the requirements & Functional specs.
This doesnīt mean you shouldnīt change something if itīs discovered to be wrong. The project should be flexible; changes will impact the project plan. But it shouldnīt be so flexible that itīs liquid.
Matt
London, England
Tue Aug 07 05:01:08 EDT 2001
Misconceptions about XP
You say that ´XP attempts to compensate for peoplesī incompetence by making it "okay" to get it wrong.´ The article aims in the same direction. Somehow every critic of XP seems to miss the fact that testing is a central concept of XP. The main problem seems to be the fact that XP says ´change is good´. People fear change. The costs will explode! We wont meet the deadline! We´ll have to work overtime! XP assumes that the cost of change is less than the cost of anticipating every single feature. If we implement feature A now it costs us
$10000, if we implement later, when we are sure that we need it, it costs us $12000. If we dont need it, we´ll save $10000, if we´re wrong we pay $2000 extra. I concede that this assumption is open to debate, though I think it is correct. But if it is correct, XP´s conclusion to make it easy to change at every time makes perfect sense.
Anonymous person
Not sure where exactly, Probably the USA
Tue Aug 07 07:19:26 EDT 2001
Ratios all wrong (Mecha XP must die!!!!!)
Changing things is a lot more costly than
a tiny 20%.
If often goes to a factor of magnitude, of course
depending on what is asked for.
It is MUCH better to go in a straight line, from
A to Z, then to wander around like a drunk ant,
stumbling from stimulus to stimulus, attracted
to the nearest shiny object with a magpie mind.
Iīve in be in computers for 22 years, so Iīve seen
enough times what happens when people donīt
spec things out properly.
And as XP shows, people NEVER learn the lessons
of the past. There is always a īreasonī why īthis project doesnīt need specsī. Doomed.
Letīs build a car. No, a boat. No, a plane. No, a radio. Oh, it doesnīt matter, does it? Its all stuff.
Change is good? No it is not. It happens, like tidal waves, but that doesnīt make it a good thing. I can see a volcano without feeling the desire to sacrifice myself to the great volcano god.
Oh well, so shall it be, the newbies will go for XP, and those that know better will carry on.
Iīm sure in a few years we can all have a good laugh, and claim to have seen through it. "I was a double agent, honest!".
Dino.
Dino
Epsom, UK
Tue Aug 07 10:15:32 EDT 2001
wisdom
Wisdom begins when we discover the difference between "That makes no sense", and "I donīt understand". -- Mary Doria Russell
There was a time when I, too, thought that change was expensive and that I had to get the requirements and design right up front.
Certainly it is important to have a clue, and a customer, as we call them in XP, who has no clue can lead a project in a circle. Iīve never seen it happen, though, and for several good reasons.
The most important reason is that XP teams donīt just do random things at the whim of their customer. Each feature (whether a change or not) gets an estimated cost associated with it. The customer only gets to order features in the next two weeks that add up to what the programmers can do in those two weeks. This puts the customer in a position to make good decisions, because changing her mind is not free.
To do a really good job of criticizing XP, instead of just making up things that arenīt true, you might want to consider learning what it really is and how it works. Itīs not perfect, but it is well thought-out, and lots of people are having success with it. Thereīs lots more to it than these goofy articles suggest.
Ron Jeffries ronjeffries@acm.org
Michigan, USA
Wed Aug 08 06:18:12 EDT 2001
AMEN
Ah . . . so true. But lest anyone forget, there are a lot of people out there whose livelihood depends solely on writing about software not writing software.
I am currently reading Extreme Progamming Installed. I was baffled whether the authors were laughing all the way to bank or could possibly be serious. (Note: Having written Chapter 7 they then forgot about it in Chapter 8 which does not list the exigenicies of an existing system as the basis for what is included in an iteration.)
If XP catches on and 60% of Americans now designated as obese, maybe I can get rich designing really wide keyboards to accomodate pair programming. Next release maybe they should add "girth" as a criteria in who is paired with whom?
I think I will go to law school.
DORAN
Not sure where exactly, USA
Wed Aug 08 09:03:14 EDT 2001
re: wisdom
Wow, did they get to you too?
Thereīs plenty about XP which can be seen to make sense. Much of this is not exclusive to XP though:
"Testing is central to XP" - funny, I like testing too. "Automated acceptance tests" are great, and in a language like Java are surprisingly easy to set up (ability to add a main method to any class; introspection etc). Theyīre not exclusive to XP though.
"XP requires development to have a much closer relationship with QA" - Absolutely, makes a lot of sense. I promote this approach in every project I work on. QA should never be an insular domain that only receives completed packages from development. They should be closely involved with the project right from the initial spec-writing. Again, not an XP thing (especially not the spec-writing!)
"A customer, as we call them in XP" - Strangely enough we call them that too. Amazing!
"No overtime - Working overtime sucks the spirit and motivation out of a team" - Sweet lord yes. In fact, youīll notice the same thing mentioned often on this site.
And so on.
The trouble is, all these nice common-sense things are intermingled with the wild and crazy things that truly make XP the dangerous nonsense that it is:
Pair programming?? īMediocre programmerī + īmediocre programmerī = īunstoppable geniusī? Get real!
"The programmers are in constant contact with the customer"? Most customers will have a higher priority to clean their coffee cup than to return a junior programmerīs "urgent" half-hourly call.
"Developers should be integrating and releasing code into the code repository every few hours, when ever possible. In any case never hold onto changes for more than a day"
- Iīve seen projects crash and burn because of this crazy rule. Project managers love to clamp down on programmers who check-in uncompilable or unworking code, yet they insist on daily integration. Result: panicky programmers who constantly code as if the project is to be released tomorrow, even though the deadline is months away. All the extra time spent catering to this strange daily mandate is time lost to the project.
Whatīs that? XP prefers the code to be checked in every few *hours*? Well thatīs okay then...
I could go on, but a lot of this stuff is (or will be) mentioned in these articles (plus my lunch hour is almost over).
Yes, the Rumour Mill contains "made-up" articles, but then itīs a satirical site. The other areas of the site contain the "true story" stuff (itīs all clearly signposted).
Keep the messages coming,
Matt.
Matt
London, England
Wed Aug 08 09:11:29 EDT 2001
if X is good, do X all the time...
As is says in Extreme Programming Explained:
"If code reviews are good, weīll review code all the time (pair programming)."
There are several studies that say that code reviews find bugs and improve code. There are also several studies that pair programming results in less bugs and higher quality code. (see pairprogramming.com).
"If testing is good, everybody will test all the time (unit testing), even the customer (functional testing)."
XP says that before writing a line of new code, you first write a line of unit-test-code, so that you only write production code to make a failing unit test pass. By writing the unit tests first, you make the new code easy to test. By only writing production code to pass a test, you end up with nearly 100% of your production code tested.
When you fix bugs in existing code, you should first write a unit test that confirms the existance of the bug, then fix the code; the unit test confirms that you fixed it.
Running all unit tests and having them all pass is required before your code gets checked into your main line of source-control-control.
"If design is good, weīll make it part of everybodyis daily business."
XP doesnīt say "donīt do design", it says "do a little design every day and every week".
It also says to use refactoring (see refactoring.com) to improve the existing code. Because you have unit tests and acceptance tests, you will know if your attempt to refactor has broken any code.
"If simplicity is good, we´ll always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work)."
Remember that "simple" does not mean "stupid". You strive for the simplest code that WORKS, is understandable, etc...
"If architecture is important, everybody will work defining and refining the architecture all the time (metaphor)."
Metaphor is the hardest XP practice to do... a good metaphor leads to a system of names. Remember that "client-server", "window", and "fire-wall" are metaphors.
"If integration testing is important, then we´ll integrate and test several times a day (continuous integration)."
If building a testable version of your product is difficult, you will not test often. If people go off for a week or a month and program away from the rest of the team, there will be inevitably difficulties in integrating their code with the rest of the teamīs.
"If short iterations are good, we´ll make the iterations really, really short -- seconds and minutes and hours, not weeks and months and years."
By releasing to QA and your customer representative a working version of the product every two weeks, you get feedback a lot quicker than if you release once every six months...
Note that the "Customer" is not necessarily the end-user. In my company, the Customer is called "Planner". In others, the Customer is called "Product Manger", "Analyst", etc...
Note also that XP was designed for green-field projects. If you have legacy code, then you have to adapt XP to your project.
In fact, Kent Beck says that XP is "the starting point" -- "the minimum set of practices". Every project is expected to adapt XP and add practices for their specific project.
keith ray keithray@home
silicon valley, usa
Wed Aug 08 12:02:36 EDT 2001
Very insightful Matt...
Our elightened host quipped:
>"Developers should be integrating and releasing code into the code repository every few
>hours, when ever possible. In any case never hold onto changes for more than a day"
>Iīve seen projects crash and burn because of this crazy rule. Project managers love to
>clamp down on programmers who check-in uncompilable or unworking code, yet they
>insist on daily integration.
Given your dedication to pointing out its flaws, I can only assume you have read extensively about(and maybe even tried) XP to provide the insight you do.
However, I just wanted to mention that integrating changes every few hours would be suicide
IF ONE DIDNīT TEST THE ENTIRE APPLICATION END TO END BEFORE DOING SO
However, since XP teams *do* test and deploy their applications every time someone integrates, I am guessing you missed that bit.
There is certainly nothing wrong with Skepticism (in fact I would be suspicious of anyone who didnīt approach new things skeptically)
But, deliberately misrepresenting the object of your criticism in order to make your case is irresponsible, and childish.
I hope that you continue to succeed in software development, but I also hope that you donīt discourage someone who is having problems with the kinds of things XP addresses very well, from not even considering it with your straw man and otherwise completely misleading arguments.
XP is a disciplined and well thought out collection of practices in the only way that matters -- projects using XP ship software on time and under budget to the customerīs satisfaction.
XP isnīt magic, and it wonīt cure lack of skills, lack of vision, or other obvious deficiencies in a project. Anyone who thinks that its proponents are saying this is either ignorant or has an axe to grind.
Which are you?
Best,
Bill Caputo logosity@yahoo.com
Chicago, Probably the USA
Wed Aug 08 13:44:31 EDT 2001
Ha ha, priceless
The above 2 messages are just toooo funny.
Can´t wait for Sunday, and the new stories we´ll be seeing from Matt.
And no, I´m not going to be specific, wait till Sunday if you want to see some rebuttals.
Dino.
Dino
Not sure where exactly, UK
Wed Aug 08 13:48:03 EDT 2001
XP Sucks
I did XP for about two and a half months at Speakout.com, before quitting. The entire staff was made up of "junior programmers" -- people who didn´t know how to program -- particularly college interns. I was a "senior programmer". The manager was about 25 and had never managed anything before.
The entire staff worked overtime, mostly because they spent most of their day bull*@!#ting while "paired". Many had worked and *slept in their office*, and were paid "stock options" in return -- stock options that they never actually received. I remember one conversation where an intern turned "junior programmer" begged the vice president to work less than an eleven hour day.
Personally, I showed up, worked about seven hours, inlcuding half an hour for lunch, and left, doing twice as much work as the "Extreme" programmers and often sitting around for three or four days doing nothing while they caught up. I complained to the VP, and he told me "sitting around doing nothing for three or four days every two weeks is good for an employee, because it gives them time to relax and think about things."
The company burned $18 million in two years. In September it will be bankrupt. I left as quickly as possible.
Bill White dhyphen@yahoo.com
Silver Spring, MD, USA
Wed Aug 08 14:37:55 EDT 2001
XP must be magic
Wow--XP "sucked" the competence out of a 25 year old, inexperienced manager, and a deleted the talents of a staff of interns "who didnīt know how to program." With a crew like that, if theyīd only used the right methodology, theyīd all be rich, Iīm sure.
Bill Fleischmann bfleischmann@medcharge.com
Cortico-thoracic, USA
Wed Aug 08 16:03:03 EDT 2001
Billīs XP
So, Bill White, tell me a bit about the XP you were doing at this startup.
I already know the team wasnīt following the Sustainable Pace rule, since XP teams donīt work lots of consecutive overtime -- we claim it makes the work go more slowly.
And of course no process, even CMM Level 5, will make bad- or non-programmers into good programmers. But if you were doing XP, this should have become pretty clear.
XP teams deliver running software every two weeks. Didnīt anyone notice that the junior guys were delivering none?
XP teams have a business representative on site full time. Didnīt this person notice the programmers not doing anything?
XP teams have acceptance tests that show the customer what is done. Didnīt anyone notice that there werenīt any more tests running this two weeks than the previous two weeks?
XP teams have and track an overall plan showing what is predicted to be done, and when. Didnīt anyone notice that progress was not being made?
And just one more question: which of the 12 (or 13 the way I present them) practices was the team doing, and which ones was it not doing?
Thanks,
Ron Jeffries ronjeffries@acm.org
Michigan, USA
Wed Aug 08 16:11:38 EDT 2001
Moderation in all things
"If short iterations are good, weīll make the iterations really, really short -- seconds and minutes and hours, not weeks and months and years."
Implies:
"If drinking water five times a day is good then drinking water five times a second must be better"
This is a classic logic fallacy.
I imagine there are some environments and situations where XP works well. I think you would be better off taking some of the better ideas and adapting them into a more standard iterative design methodology then actaully trying to implement the entire doctrine.
Toss the wacky stuff, like two programers at one cube. Regardless of whether it produces better code faster most programers I know would absolutely *@!#ing hate that. I would kill the other guy in no time. (-:
Anonymous person
Not sure where exactly, Probably the USA
Thu Aug 09 20:27:42 EDT 2001
Pair Programming
"Toss the wacky stuff, like two programers at one cube. Regardless of whether it produces better code faster most programers I know would absolutely *@!#ing hate that. I would kill the other guy in no time. (-:"
Of all the ideas in XP, Pair Programming is the one with the most recent research behind it. One of the research results is that (among subjects), over 90 percent of people preferred pairing once they learned how to do it.
And the studies also have some pretty good numbers on productivity.
It took me a long time to get into pair programming myself. Iīm smart, sarcastic, a loner in many ways. I found that it makes my code better, keeps me on track better, and I like it more than working alone.
Thatīs not to say that you, too, will feel that way. But I do suggest that until you try it, you probably donīt know whether you like it or not.
Check out http://pairprogramming.com for more info.
Ron Jeffries ronjeffries@acm.org
Michigan, USA
Thu Aug 09 23:32:35 EDT 2001
open workspace
"Toss the wacky stuff, like two programers at one cube."
I would rather suggest to toss the cubes. Get into an open workspace.
When you feel the desire to kill your partner, switch to an other one instead. You had to find a new one after killing the current one anyway... ;-)
Ilja Preuss ilja.preuss@web.de
Berlin, Germany
Fri Aug 10 06:52:45 EDT 2001
re - This is a classic logic fallacy.
XP was created by trying out lots of different practices, and keeping those that worked well together. Unlike some other methodologies, it wasn´t created in an ivory tower based on "pure logic", abstracted away from real life.
Various medical people tell me that most Americans don´t drink enough water... none of them tell me to drink it five times a second.
When Kent says "seconds and minutes", he is talking about not separating "design phase" from the "code phase" from the "integration phase" from the "test phase"... and by putting "test" before "code", the test acts as an executable design/requirements document.
Having an executable design/requirements document is MUCH nicer than having some Word or Framemaker document filled with lots of vague requirements...
blah blah@blah
Cupertino, USA
Fri Aug 10 13:57:33 EDT 2001
re - This is a classic logic fallacy.
> it wasnīt created in an ivory tower based
>on "pure logic", abstracted away from real life.
Yes, damn that logic. Gets in the way all the time.
>Having an executable design/requirements
>document is MUCH nicer than having some Word or
>Framemaker document filled with lots of vague
>requirements...
Yeess. But having a directory with lots of short, well indexed Word documents filled with SPECIFIC requirements is much nicer again than letting your source code be the spec.
blink blink@blink
Somewhere, USA
Sat Aug 11 12:44:40 EDT 2001
Back to The Rumour Mill
|
Site Map Search 
