Slashdot Mirror
Beck and Andres on Extreme Programming
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."
I was hoping for something a little closer to Extreme Ironing.
That would have been cool.
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.
The more you regulate a company, the worse its products become.
To me, the word "extreme" sounds like they program in assembly 24x7 for one week straight, or they program with laptops, while running away from a pack of wolves or something. But apparently it's not like that. So what makes it so "extreme"? Did they come up with that name when they were discussing their interests with their jock-friends?
"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!"
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Kent Beck hits the proverbial nail on the head with this zinger (which I'm sure is certain to stir up quite a few):
... I think programmers are, or at least can be, adults and can and should, for the good of development and themselves, act that way."
"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.
Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer. Traditional code reviews tend to be frustrating for the programmers, because the reviewers are in position of authority.
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.
Proud member of the Weirdo-American community.
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?
IMO real extreme programming should involve at least 3 of the following:
ccalam - acoustic versions of new songs.
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.
I view XP as a methodology to solve a major problem I've seen in software - communication.
/before/ the code is written, the latter written by the customer(!)). We continually run them using a Continuous Integration server which monitors the code repository and checks out the latest version, notifying the team of any conflicts.
/not/ to be "XP", it's to deliver value to the customer. And if your current practices are doing that, then that's what is important.
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) and here (part 2).
Random Musings
I found pair programming to be very efficient. But it depends on how you pair people.
(Summary of my best practices article)
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.
But all or nothing is not just an XP problem. All methodologies say their way is best, if you deviate you are a heretic and if it all fails then it's your problem for not following the rules. The people that "invent" a methodology make their money from teaching people how to do it, why would they kill their cash cow by telling people they should just take the bits that work for them? Methodology advocates, like preachers cannot afford to have people think for themselves.
Because all the programmer I know around are quite adult, responsible, and do not care for the latest toy. But they do care that they are given enough time to implement features, taht the features are correctly documented, that the spec are there etc... And in the last 6 years I was there, those point were not met, and usually the manager were responsible for a reason or another, but never beared the responsability.
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".
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
"It's not all about programming. It's not all about programmers. Programmers aren't somehow special and to be protected and coddled."
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?
If nothing else, it's worth it just for the song lyrics:
Agile Programming is like a late night infomercial without the "these results are not typical" disclaimer.
First a disclaimer: I worked on an ADP project that involved Intelliware - an XP shop to build a mutual fund prospectus preprinting system (system that collected information from different mutual fund vendors, and used customer information to decide what and when to print and to mail to that customer.) This was a second iteration of the project. The first iteration had to be scrapped, because the same vendor provided a solution that did not scale to the task, when major Canadian banks came online.
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.
You can't handle the truth.
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.