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."
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?
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.
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.