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 spent large parts of the 80's programming with a salesman sitting behind me saying things like "You've spelt that wrong" or "that won't work" or "why are you doing it that way?"
As far as I'm concerned, if anyone ever suggests I should program in pairs with someone again, I'm going to reach for my flamethrower.
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. When requirements change frequently (which XP is supposed to be geared towards) it's hard to complete the tests much less complete the code before we're asked to change something, and changing even a small piece of code often requires changing a lot of tests. If you can offer any suggestions about how to improve that, I'm all ears.
Pair programming, on the other hand, is something that I wish I could have done when I was fresh out of school and not really as smart as I thought I was. It seems like an effective way to show the newer programmer how the veteran does things, both in the code and in how the day is scheduled.
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?
Pair programming may stop people from wasting time on slashdot, however, they seem to waste time in a lot of other ways. Like whether a specific for loop should be written as for(i = 0;imyArray.length();i++) or as for(i = 0;i=myArray.length()-1;i++). That and whether the opening brace should be on same line following the for statement, or on the next line. Oh, and whether certain things should be put in functions, or put inline in the code. Peer programming, while I can see the advantages of having someone sitting there, watching you, and correcting you as you go along, also has a lot of downsides. I often program in a very non-linear way. Sometimes i'm aware that I've made a mistake, but finish typing out my entire thought before I go back and correct it. Whenever I have someone watching me, and they point out the mistakes, telling me to go and correct something, I often lose my train of thought. It's like to writing a story and having somebody make you go back and correct all the grammar mistakes before while your done trying to get your thoughts out.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
Most people have moved onto other agile methods like SCRUM. XP had a lot of hype, by its authors mainly, and now many of its techniques have proven to unusable and have no value. I know of at least 1 300 billion dollar company that tried it and left it behind because it was wasteful in many ways.
That's the wrong way round. Shouldn't you be rewriting the tests to conform to the new specifications then changing the code for the re-written tests that fail? Doing it your way will make it very difficult to trace code.
Another way of pair programming could be to have one person writing the tests and one writing the code.
America, Home of the Brave.
Chip design is a good example of such uses in "real engineering". The whole semiconductor industry is permeated with "strongly formal" tools implementing different types of formal methods at their core. These vary hugely, from loose fuzzy logic design aids to stronger expert system parameter, timing and topology validation, to the full blown formal methods that a language-based computer scientist would recognize.
And it's been going on for decades. The FPU of the well-known transputer CPUs from the 80's were designed using formal methods.
If integrated circuits were crafted using our current manual programming methods, 99% of computers would be dead 99% of the time.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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 comes my boss (who's never tried to so much as launch a text editor - back then, it was common for programmers to have bosses who weren't even terribly comfortable with computers) who asks me what I'm doing. I explain that I'm setting up a program to test the program I'm working on (and making subtle changes to the target program itself so that it can be "unit tested") and he berates me for wasting time. As a beginning programmer, I have no choice but to figure he knows something I don't know, so I abandon what I'm doing. (Actually, I continue to do it in secret, because nobody's proposing any more effective ways to get my job done).
Fast forward about seven or eight years - Martin Fowler publishes a book called "Refactoring", Kent Beck publishes a book called "Extreme Programming Explained". My boss introduces me to these revolutionary concepts that will change the way I program. Now I can finally begin writing unit tests in the open and admit to it freely! I start to write unit tests and subtly refactor programs so that they can be unit tested... and the programmers around me berate me for disturbing their pristine, pure code (that works just fine, thank you very much!) by removing things like hardcoded file names and IP addresses in the name of some new-fangled, high-falutin "extreme programming" concept. Sigh...
Proud neuron in the Slashdot hivemind since 2002.
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.
FFS, Intelliware may be the top XP solution provider in Ontario, but you've said yourself: Feature Creep - absolutely. A Feature Creep caused by the politics of the vendor, who used XP to his own advantage because it is just so easy to hide the fact that Feature Creep will happen.
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 order to implement the business requirements various frameworks have to be put in place. It is true, the frameworks have to be put in place, what is not made apparent is that these frameworks do not have to be implemented in house. XP is not to blame for the politics of the company, but it is a bloody excellent mechanism to make it nearly impossible to give any estimates on what actually will happen when these frameworks, that need to be implemented, start blowing up into a 'proper' application server.
Give me a bloody break, and don't badmouth XP until you've done it properly. - oh, jeez. So what you are telling me is that you apparently know that XP was not done properly by this top XP provider in Ontario (a bloody huge province.) This is insulting to the intellect of the casual reader.
I'm quite happy for you to criticise XP - shit, I can give you a couple of pages of solid criticism myself - but at least base it on reality, not your experience of some fucked up cowboy method that someone told you was XP. - I don't see you giving me anything but statements, that are full of horse manure. Apparently you are THE authority on what makes a proper XP implementation. Whatever. I worked on XP projects twice in my life, I researched what XP is supposed to be and compared to my experiences. As far as I am concerned the Intelliware XP experience was as close to a 'perfect' XP experience as anyone should ever hope to get. I was there, what is your basis for your statements?
I haven't bought into the entire XP religious propaganda. If I had I'd be insisting we use it where I work now. I don't, because I evaluate multiple development methods and I recommend the appropriate one for the work being done, in the environment in which it is happening. I just get pissed off with the dogmatic refusal from a significant percentage of the IT industry to actually objectively evaluate new and different ways of working. Stop holding my industry back you luddite wankers. - holly crap. So I am a luddite wanker now, who is dogmatically refusing to objectively evaluate a new way of working.
I evaluated it. I worked with it. I am being objective here: from my experiences, XP suggests some nice features (unit testing/wiki on the go documentation,) that can positively influence design/development of a project. From my experiences XP is also a great management tool to avoid any blame for any wrong doing (and people do the wrong thing quite often.) From my objective point of view, XP is just another methodology and has the same limitations as any other methodology and does not provide an obvious edge over any other methodology if any of those methodologies are properly followed.
But forget you, I am not answering to any of your accusations any longer.
--
For the normal readers, not for the XP evangelists: Unit testing does objectively help to develop better code. Wiki documentation (and xPlanner especially for CVS checkin flag blocking) can be useful tools IF people in the team do not actively hate the idea. If someone (a team lead hopefully) decides to use the Wiki as supplementary documentation source, it may become a very useful tool indeed. All kinds of communications can happen through this documentation resource.
As to paired programming: it is up to your project management. If they will to pay for it, go nuts. It won't make your code worse, but again, objectively speaking, I found paired programming to be ONLY useful at moments w
You can't handle the truth.