Slashdot Log In
Beck and Andres on Extreme Programming
Posted by
ScuttleMonkey
on Tue Sep 19, 2006 06:19 AM
from the not-terribly-extreme dept.
from the not-terribly-extreme dept.
narramissic writes "In recent years, Extreme Programming (XP) has come of age. Its principles of transparency, trust and accountability represent a change of context that is good not only for software development but for everyone involved in the process. In this interview, Kent Beck and Cynthia Andres, co-authors of 'Extreme Programming Explained: Embrace Change,' discuss how XP makes improvement possible."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Extreme... (Score:4, Funny)
That would have been cool.
Re: (Score:3, Funny)
Article's dated 6th May 2005.... (Score:2, Insightful)
Re: (Score:3, Funny)
What do you need to pair progam? development software, check. monitor, keyboard, check. coffee, check. newspaper check.
Right, divvi that up between the pairs evenly, you get the software and PC, I get the coffee and newspaper. See how pair programming works?
Overrated (Score:3, Insightful)
Re: (Score:2)
Re:Overrated (Score:5, Interesting)
1. No company in their right minds wants to pay for TWO programmers to do a single job. But then, again, you can always get 2 programmers at half-price to do the job (and have half the quality of one full price programmer).
2. As with any other method, it assumes all the specs and implementation have been worked out before the code is even written....nobody has the freedom to write experimental throwaway code to even see if their approach is even feasible in the coding, or, if programming a device, if the device will even work with the approach being made (for you people not in the embedded world, most device datasheets are incorrect and seldom get corrected).
3. While its great at letting the mundane functions be rewritten (refactored) as many times as possible, it gives a mechanism where newer features are *always* put off (by managers usually) indefinitely....its an illusion, under a few managers, that the programmers will ever get to implement the newer features wanted by customers (its amazing how most new features are always rated as low priority by someone other than the customer....even more amazing about how many 'stories' aren't written by the customer.).
4. Even in the XP books it is explained that XP is not meant to work for every single software environment/situation....yet there are managers who will do their best to try to force it to work when it won't.
I always find it really is better for a group of Programmer Peers to sit down together and review the code AFTER it has been written (with tests). Trouble is, most companies/managers refuse to understand that 'Programming Peers' do not include the stock boy in shipping.
Just my $.02. Can you tell I didn't really like being under the XP model myself?
Parent
Re:Overrated (Score:4, Funny)
If nothing else, it's worth it just for the song lyrics:
Parent
Re: (Score:3, Insightful)
1. No company in their right minds wants to pay for TWO programmers to do a single job. But then, again, you can always get 2 programmers at half-price to do the job (and have half the quality of one full price programmer).
No, companies want to pay for what is going to deliver them the biggest ROI for the least amount of money. They don't care how many people are on a job, as long as they get the profit in the end.
2. As with any other method, it assumes all the specs and implementation have be
Re:Overrated (Score:5, Insightful)
But when you put two programmers with equal authority, you have one thinking about the bigger picture and the other reviewing his mind flow. At the same time the later is writing down the ideas in code, with the first one reviewing his code as he types.
Where have you been the last 20 years? The stereotypical programmer, hacking his piece of kernel over night is very endangered species, and rightly so. Like any kind of engineering, software engineering needs as much face to face collaboration as possible.
Parent
Re: (Score:2, Insightful)
You really think XP is Engineering?
Re:Overrated (Score:5, Insightful)
It's an attempt to achieve a greater level of quality through process/practices, which is as close as "software engineering" has gotten to real engineering so far. Arguably, though, "software engineering" isn't real engineering until you use formal methods to ensure the correctness of your design and implementation.
Parent
Formal methods in chip design (Score:3, Interesting)
And it's been going on for decades. The FPU of the well-known transputer CPUs from the 80's w
Re: (Score:3, Informative)
Re:Overrated (Score:5, Insightful)
I've never seen one of those. Every code review I've participated in has been a collaborative effort between peers. If you treat a code review as a cooperative effort between programmers, it doesn't have to be frustrating.
Like any kind of engineering, software engineering needs as much face to face collaboration as possible.
To a point. But real engineering requires planning and clear interface definitions, and XP -- almost to the point of being pathological -- attempts to avoid planning as much as possible by subsitituting endless chatter and tremendous time wasting repeatedly reimplementing what could have been done right the first time. (And yes, I know some things always have to be reimplemented, but just because mistakes are inevitable doesn't mean they have to be encouraged.)
Software development has an unfortunate tendency towards fanatical adherence to the latest silver bullet. Usually, this involves an implementation language backed by a marketing push; XP seems to be the first programming fad built entirely on book publishing. But then, no implementation language ever actively encouraged the kind of passive-aggressive personality that thrives on XP.
Parent
Re: (Score:3, Insightful)
You'll notice that firms who force crap like XP (but not limited to) onto coders fail in the long term. (o
Re: (Score:3, Insightful)
I have had successful "pair programming" sessions at my old job, but that was before I even knew what pair programming was. When someone had a tough nut to crack, w
Re: (Score:3, Insightful)
Unit testing is my
Re: (Score:3, Interesting)
Eivind.
Re: (Score:3, Interesting)
Probably running complete end-to-end regression tests every time he made even a minor code change, as his boss likely required him to do in the name of "efficiency".
I got my first professional programming job in 1990, back in the days before even the term "methodology" had entered the lexicon. After just a few months, practices like what we now call unit testing and refactoring seemed obvious to me - so obvious, in fact, that I just started doing them. Along
Re: (Score:2)
You often see arguments like this... I like this part, I think that part doesn't work well...
The XP books make very clear that it's either all or nothing. They don't claim that pair programming by itself is always useful, they just claim that this whole set of techniques taken together is useful. If you're going to do all the other things XP says, XP says you should combine it with pair programming.
If you're not using all the elements (on-site client, pair programming, collective code ownership, etc etc e
Re: (Score:3, Interesting)
Good marketing (Score:3, Insightful)
This is just good marketing. By making this "all or nothing" claim, XP has a built-in excuse that you are invoking here. Ever noticed that you hear the phrase "because you're not doing it right" more
Re: (Score:3, Insightful)
Sounds like writing management books (Score:3, Funny)
1. Take something obvious or counterintuitive (Doesn't matter if it will really work or not)
2. Label it with impressive sounding phrases
3. Copyright a bunch of specific steps (methodology) to do the obvious
4. Write and publish a 400 page book about the methodology steps using your new phrases
5. Sell it to PHBs and incompetents
6. Profit!
7. When complaints about non-success arrive, arrange seminars at hundreds of dollars per seat.
8. Give Seminar
9. More
Re: (Score:3, Informative)
It also was extracted from a real world project methodology used by the C3 project. So in fact this methodology came from real world practices, not out of someone's ass as you imply:
http://www.xprogramming.com/Practices/xpractices.h tm [xprogramming.com]
I've been in environments where we've used XP, I've been in environ
Re: (Score:3, Interesting)
Test driven development is seductive; who wouldn't want to have all those automated tests in order to check changes to their code? However, I find it hard to put into practice
Re:Overrated (Score:5, Interesting)
(Summary of my best practices article [mobydisk.com])
Junior developer alone: Can complete the project but with errors a senior developer could have fixed. Code reviews fix this, but are tedious.
Senior developer alone: Good code, but this tends to breed "cowboy coders" and doesn't pass on knowledge.
Senior + Junior: Highly effective, but only if the Junior developer is the one at the keyboard.
Other combinations can help, but aren't superb. I recommend pair programming (1) on tedious code, (2) to spread knowledge, and (3) when refactoring something crucial.
Parent
Re: (Score:3, Insightful)
Quite often it prevents me from doing very stupid errors. Having another person looking at what you're doing, and making questions about that pice of code, and suggestions makes you pay more attention, and gives a precious feedback.
Also, when I'm co-piloting (not at the keyboard, that is) I feel this incredible urge to return to my desktop and code something. Watching other people code, and talking about his code makes me want to code, its weird, but I always feel more motiv
Re: (Score:3, Insightful)
Sure, but the question is what percentage of the time does this happen and is it often enough to justify tying up two programmers all the time.
"The code only gets committed if *both* developers are happy - and that is a sure way to increase the quality of code, since the foibles of an individual are subsumed."
That's an idealistic view. It would be more accurate to say the code gets committed when the more agg
Re: (Score:3, Insightful)
Actually, the least productive time I've ever spent was spent pairing. YOu end up either arguing over everything or shooting the breeze more than coding. I find pairing reduces the productivity by at least 75%- that 1 pair is less productive than either one of the two coding alone.
Good desig
"Extreme" Programming (Score:2)
Laundry? (Score:4, Funny)
Why is it called "Extreme"? (Score:5, Funny)
"Oh yeah, I'm in to pretty extreme things. Currently I'm doing base-jumping and ultimate-fighting. How about you?"
"Well.... uh.... I'm in to.... EXTREME programming"
"Whoa! Radical!"
Re:Why is it called "Extreme"? (Score:5, Funny)
Parent
One of the best quotes ever... (Score:4, Insightful)
"It's not all about programming. It's not all about programmers. Programmers aren't somehow special and to be protected and coddled. I used to say often that programmers were children. They liked not to be yelled at and to have more toys
The above quote sums up almost every problem that I have seen over the past 10 years with the various development shops I've been a part of.
Is he a manager ? (Score:4, Insightful)
To sum up, to define the programmer as "child", is really disapparging, and far far away from reality of the average software developpement shop. Most are average guys which want to do a correct job, but are put in impossible situation by management.
No if the quote would be applied to manager "manager are like child, they like to play and win, but do not wish any responsasbility in tehir action".
Parent
Re:Is he a manager ? (Score:4, Interesting)
Beck is not a manager. That doesn't mean he lacks management skills (I've seen evidence that he does have excellent management skills) but reflects his hands-on nature. He writes code, and thinks about the process of writing code. And his thoughts tend to be somewhat broader than most peoples, and more complete, and when he shares them with others, better expressed.
In other words, find books and papers and software written by Kent Beck and read the lot. If every programmer on the planet did that, even if they disagreed with everything he'd said, the IT industry would become immensely more efficient and effective overnight.
Now consider Beck's quote that you have taken affront from. Think about new programmers, software heroes, cowboys, even experienced and capable programmers - they all want more toys, to be left alone to get on with their job (which they perceive as programming), that everything is handed to them on a plate. Your comment even reflects that - "enough time", "features are correctly documented", "spec".
Real life isn't like that. And instead of whining about it, Beck stepped back and re-evaluated how to approach software so that he could deal with those issues, and still write top quality code, and still meet deadlines and give the customer value.
No, Beck isn't a manager. He's quite beyond such limiting labels.
Parent
Real Extreme Programming (Score:5, Funny)
IMO real extreme programming should involve at least 3 of the following:
Treat programmers like other professionals! (Score:3, Insightful)
As a programmer, I agree 100%. I expect to work and be treated like any other professional.
NOT as a lab rat for "extreme programming" or whatever buzzword-laden feelgood bullshit management scheme comes along this week.
You wouldn't go to a painter and say "I want you to make me a painting. It doesn't matter what it consists of yet, we'll worry about that later. Just start out with a box or something and we'll meet every day and figure it out from there. And just to make damn sure you can't get anything done, I've hired another painter whose role is to sit around and annoy you." So why does that make sense for programmers?
Re:Treat programmers like other professionals! (Score:4, Insightful)
First there was the "cat herder" motif. Programmer's are savage animals to be herded about by sensible managers, since they are wild and unpredictable and can't possibly function in a professional manner. That didn't go down too well, so after that programmers are this special breed that must be protected from the evil clutches of managers, like an artist on a quest trying to get rid of those pesky debt collectors. Nope, didn't work either. So now programmers are, really, nothing special, *bemused chuckle*, so they must work in pairs because they really can't discipline themselves all that much, so can't follow deadlines and schedules and program their work accordingly (pun intended).
Really, wtf?!? Who comes up with this shite!?!
I'm a professional. I study. I work. I have to deal with clients and managers and other programmers and emails and schedules and deadlines and projects and planning and meetings and $"#%$$ hard disk failures and stupid IDEs and dumb APIs and idiotic OSs and back pain from lugging the laptop around and hand pain from sitting on %$#"%$$% chairs with %&#%#$ desks and &%%"% mice and #$£&% keyboards and procrastination and bills and everything else one has to deal with in any job. And above all of this I still love the job, so I have the extra duty of being wacky some of the time just to fulfill my geek quota.
And besides all of this, because I have this label someone stuck on my back somewhere without me noticing, announcing to the world that I'm a programmer, I have to also be a "lab rat [so aptly put by the parent, which is why I'm shamelessly quoting] for whatever buzzword-laden feelgood bullshit management scheme comes along this week" (or the next... and the next...), because someone is bound to read that buzzword-laden $#&%$%# and decide it would be so much more better amazing wonderful wow to make me work like the aforementioned buzzword-laden recommends as the oh so bestest way to get anything done with those darned critters^H^H^H^H^H^H^H^Hprogrammers!
Could you buzzword-writing freaks, like, go pester the street vendors or accountants or something? I really need to finish these project design reports so I can start implementing the architecture I designed together with my team on - *gasp* - separate computers.
Parent
Agile Programming == Late night infomercial (Score:3, Insightful)
Extreme Hogwash (Score:5, Insightful)
My impression from the entire excercise, (which included daily standup meetings, story cards, paired programming, unit testing, end of the day documentation.) The process became very very wasteful. I personally saw that putting 2 contractor programmers, each at 90/hr at one workstation does generate dialog between the programmer, where both have to generally agree on the approach to any given problem but I did not see any performance improvement achieved by this approach over havin one 90/hr contractor doing the same thing. Since the requirements of the system were still being 'refined' and since there still were deadlines to achieve, the pair had to produce as much code as possible in a very short time period and various bugs still slipped through the process (most of which admittedly were caught by the unit testing, but unit testing.)
The daily standup meetings were mandatory of-course even though most people loathed those. There still were 'overal architects' on the process, and due to the politics of this specific vendor they forced a custom server solution upon the customer (even amid my vivid objections. I was trying to get the vendor to use existing server and framework solutions, unfortunately my voice was not heard, there was no will to prevent the imminent demise of the project by concentrating on the problem at hand and not getting ourselves into a proprietary application server territory.)
Basically the project was not delivered on time (and as I at the time predicted) went over the original time estimates by about a year. I was forced to leave 3 months into the project because I became to frank with the department director. 3 months after I left, Intelliware was forced out the door as well. The project was partially delivered within the time that I estimated, the department director had to leave the department as well.
I do not get any warm and fuzzy feelings about anyone promoting XP, I right away start looking for ulterior motivations. My personal feeling is that people who do not want to carry any responsibility for the project, for the code, for the requirements welcome XP (or can be easily swayed to accept that methodology.)
In XP noone is really personally responsible for anything, and that attracts people who want to have it easy. Documentation is shunned upon, any forward thinking is met with contempt. Any questioning of the process/methodology is considered a heretic. Sweat shop mentality dominates XP, and it is not surprising, considering that it takes 2x as many people to deliver the same solution for 2x the money. Obviously there is a drive for those, who are actually producing code to work as fast as possible without any room for thought.
I did however find that unit testing is a very good approach to testing and that wiki style documentation is excellent if used properly.
Re:Extreme Hogwash (Score:4, Insightful)
Delivery of various pieces was done every 2-4 weeks actually, but the application server part feature creep that was unapparent to the client but obvious to me reared its ugly head. Every time a piece of code was 'delivered', it became apparent that it had to do more and more, and every time it had to be redone.
My point is that XP provides excellent conditions for this kind of 'delivery' mechanism because it objects to doing any real architecture (analysis of the requirements and features upfront.)
That's ludicrous. One key tenet of XP is "sustainable pace". Don't burn out, don't work late nights. - there was almost no late nights, but everyone got the CTS. One person at the computer had to provide the code that two people would generally provide during the day.
You are aware of the body of evidence (academic and business) that shows that while pair programming is less efficient than solo programming (in a lines of code delivered sense) it is nowhere near twice as slow and the code delivered is so considerably higher quality that it more than makes up for the overhead? - I am aware of my own experiences and I don't have to submit my experiences to any 'body of evidence' (academic or business.) XP forces the pair to provide similar amount of work as if they were working seperately.
I call bullshit on your statement you were using XP. You may have used many of the practices, and you may have called it XP, but you didn't do it. - you can call it whatever you want, Intelliware is the top XP solution provider in Ontario.
Don't feel bad - it's a bloody difficult thing to do properly. Possibly too difficult. By far the highest discipline method I've ever used. But don't badmouth it just because the company employing you didn't do it properly. - First of all, I was a contractor for ADP, and Intelliware was an outside resource, but all (4) ADP people were put into Intelliware teams and we had to work together, so I wasn't employed by an XP company.
Secondly, what I am feeling from you is exactly the same attitude that I was getting from that XP shop - do not badmouth XP. XP cannot be wrong. I am under impression that XP is a religious movement rather than a management solution to a technical/management/social problem.
The fact that so often you can hear people say exactly this: it's bloody difficult thing to do properly, should be a red flag - it is just like any other methodology or any other process. Anything is difficult to do properly and in theory anything will work well if done properly.
Give me a bloody break, just because you bought into the entire XP religious propaganda, doesn't make XP any more valuable a tool than any other methodology, process or a combination of requirement/design/development standards.
Parent
Re: (Score:3, Interesting)
In a proper XP project that is impossible. You only implement features for which there are stories. The customer chooses which stories to implement. Feature creep ceases to be an option. - Bullshit. The customer is told that in
Re: (Score:3)
Mostly, XP improves Kent Beck's net worth ... (Score:3, Insightful)
Re:buzzwords (Score:5, Insightful)
Why do we build software? It's to provide value for our customer, whether that customer be a marketing department, a gamer, or ourselves. And if we don't keep in touch with what it is that they want (recognizing that people generally don't know what they want until they see it), we probably won't provide the value we could.
To that end, XP encourages constant communication by using frequent releases of the stories (read: features) the customer thinks are most valuable. The customer gets a working version every week, or month, or 2 months, or whatever cycle seems to work for the team.
From the development side, XP encourages the code to always be potentially shippable by having a suite of Unit and Acceptance tests (the former written by the developer
It also encourages things like Collective Ownership, where, in theory, any developer can sit down and work on any part of the system. This is achieved partly through the unit test suite, and partly through pair programming with frequent swapping (we swap pairs generally twice a day, in the morning and at lunch, but some teams do more, and some do less).
But, regardless of all the practices (and there's more than I'm listing above), the end goal is
As far as TDD, I have a series I recently did which shows how TDD works here (part 1) [cornetdesign.com] and here (part 2) [cornetdesign.com].
Parent
Re: (Score:3, Insightful)
I must admit I found this site disconcerting - I'm unlikely to buy design tools from people who look (on this site) like they are in the "manic" phase of their bi-polar disorder...
Re:Write the test first (Score:4, Insightful)
Hmm. For the definitive description, I can only suggest you acquire (beg, borrow, buy, etc) a copy of Test Driven Development by (eek) Kent Beck.
My brief summary:
You write a test. To write the test you must know what it is you are testing. This means you have to think about interface, so you can access the functionality, and function, so you know what it's meant to do.
Thus before you've written any code you're already putting a lot of thought into what's going on with your code. Far more thought than most programmers put in (trust me, I've worked with too many
To be able to write a test with small enough scope (so you don't end up testing half the system - you may want to do that, but not right now) you need to be able to isolate the piece of code you're testing. There are multiple mechanisms to achieve this (see the paper "Endo-Testing: Unit Testing with Mock Objects" for an example) but the outcome is this: The code you write, to pass your test, can be isolated from the rest of the codebase. It is inherently decoupled (at least to a degree).
Now extrapolate this across the entire codebase. It's all decoupled. It has to be, so that you can test it all in isolation.
That makes the code easier to re-use too. If a block of code isn't tightly coupled to the things that use it, or to the things it uses, it's easier to re-use with other things.
Which leads to the other aspect of TDD: Eliminate duplication. If you're doing TDD by the book, you ruthlessly excise any duplication in your code. Where you see two blocks of code doing the same thing you refactor them into one block of code.
This is relatively risk-free, because all the code you're changing has a full suite of automated unit tests. Which you're running every few minutes (because they take a couple of seconds to run). So you're getting pretty prompt feedback on any errors you accidentally introduce while changing the code.
Of course, you have a lot of test cases now. These are a form of documentation. They provide examples of how to use your code, and also pretty definitive indications of how it's expected to work.
So the process of writing tests forces you to write testable code. I believe testable code shares many characteristics with well designed code.
You may also want to pick up Michael Feather's book on "Working Effectively with Legacy Code". Many of his techniques revolve around building test cases, and refactoring the code to make it more testable. That's not coincidence (and remember - refactoring means "improving the design of existing code").
As I said, I'm an amateur at explaining this compared to Beck, so find a copy of his book and read through it - it's actually not a long read, the basics really are simple.
Parent