Slashdot Mirror
Go Extreme, Programmatically Speaking
raelity writes: "The O'Reilly Network is featuring An Introduction to Extreme Programming, by Chromatic (of Slashdot and PerlMonks fame). 'The central tenet is, "Find the essential elements of creating good software, do them all of the time, and discard everything else." Programmers should program and make schedule estimates. Managers should make business decisions. Customers should choose the features they want and rank them by importance.'"
In another not-too-distant-life, I was a senior partner at a firm that championed Object-Oriented design and development. Over time, we found ourselves invited to spend time at more and more large IS organizations instituting our OO methodologies, and designing elaborate object models and artchitectures. I got to speak at big conferences in front of lots of CIOs and IS executives who were too busy trying to shake off their hangovers from all of the liquor our company had bought them the night before to get much more out of my talk than: "That guy sounds pretty smart. Better get his card."
These large companies were paying each of us $3,000 per day - sometimes for months on end (don't get me started about the number of $200/head dinners and first class flights they paid for as well) to have us scratch our heads, and think high-minded thoughts about the true relationships between their domain objects. What were the core logical abstractions at work? What (oh yes!) patterns were at work here?
At the time, we really felt like we were doing good work, and they were thrilled to embark on this road. The experience of most of these companies was a background of hard-to-maintain software and failed projects. What better spoke to the fear of the corporate bureaucrat than an approach that favored more up-front design. If they had failed in the past, it was becuase they hadn't planned effectively. Surely, these dirty just-out-of-college kids sitting in the programmer's chairs couldn't be the ones driving their enterprise software. They were much happier with the thought that a group of gurus in suits with the expensive PDAs and laptops somehow using the invisible hand of an abstract and expensive "design" effort to guide the ship.
When these project collapsed under their own weight, as they inevitably would, we were always able to look ourselves in the mirror and know that it wasn't (thank god!) for lack of a proper design. They had obviously tried to cut corners on the implementation. They had tried to cut out features. They had tried to limit the scope of the effort. No one believed that all business objects needed to inherit from the "DirectedBusinessIntention" class. Whatever. Point was that somehow or another, after thousands or millions sunk into these design efforts, things always seemed to go off kilter.
The best part was that when the management that had brought us in got canned along with us, they landed somewhere else and hired us again! Not only that, but they were a solid project reference!
What a great gig. High pay, high living, no real deliverables (other than diagrams and charts). Want to keep us around so that we can point out why all of the implementation problems are a result of something other than our "design"? You bet! That'll be $3,000 / day.
Today, I live in the world of XP. I roll up my sleeves. I write code. I see real design happen at whiteboards. I see designs get implemented. I see code being released to over a million customers EVERY TWO WEEKS.
Critics point out how flawed XP must be becuase they cut out all of the "design". Surely, this software that's being hacked-together on the fly can't be robust - it must be a maze of hacks that falls apart at the first real requirements change. Yeah, yeah. That sermon's sitting somewhere gathering dust in my book on "Deisgn Patterns". It's right next to my Tufte books.
Turns out that good programmers, much to my suprise, can turn out superior designs through the XP process. Abstractions get built when they become needed - not in anticipation of need. Needs change too quickly - you build only the ones that you need. It's a beautiful process. Design does happen, but it gets naturally prioritized with other requirements. You need to change a large piece of a system? Migrate to another platform? Abstract something to support new lines of business? Great. Figure out how to do it, make a case for it, and do it. Just do it in a couple of weeks.
It works. It really does. It's produced the most beautiful and robust software that I've ever seen a large team produce. If there's any downside, it's that it requires really good programmers. It's not a methodology that is well-suited for a situation that supports people who are, for the lack of a better term, "vocational" programmers, or tool-users. All of the developers in an XP project must be able to tread deeply into all aspects of the system.
So, it's no wonder why the people who still stand in the (nicely polished) shoes that I used to wear have a vested interest in attacking XP. Long-term upfront design efforts were (and still are for some) a lucritive gravy train. These folks will try to defend their position through fear-mongering (which works really well in big IS shops). Wherever there's doubt, there's always some extra money around to do some more evaluation. If the design-elite are really lucky, their sponsors will find some money to perform a methodology-evaluation! And who is really better suited to do a methodology evaluation than the design consultants? I wonder what it's results will show?
Oh, while they're frittering away months evaluating methodologies and designing logical and software constructs which may not be needed and will likely never exist, we'll have gone through dozens of major releases of our software. It's feature-set will have evolved to provide tons of dramatic new features that make us actual revenue.
It's not that I don't miss it. I really do. I honestly felt much of the time that I was better than everyone else becuase only I (and my elite friends) had the cranial mass required to really peer into the soul of our client's busienss and understand. That was a pretty good feeling. The $3,000/day and all of the free steaks and booze were okay too. Still, I'd not go back. It's just too darned rewarding to see my work being used by a worldwide audience - to see the ongoing transition from thought to feature happen in weeks instead of years (or never).
If someone's telling you that XP is doomed becuase it is design-poor, just think about why they're telling that to you.
But where XP can help recover from this is that the atmosphere for testing is still there. When an integration or enduser break happens, the inputs can then go back to the programmer to create a new test case and fix the code by making that test case do what should have been done.
So its still possible to have broken XP code, but at the same time, the fixing of it should also be easy...
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
A brief response:
1. Irrelevant. Describe the methodology and what it means and achieves. Call it XP right through this. Sell it well enough and when they do find out what XP stands for, they'll only find it amusing, not off-putting.
2. We should all be doing these things, but I've never seen them done properly by someone that hasn't read XP books. And I don't know many people that have.
3. I am continually annoyed, scared and depressed by the comments on designing up front. For $40m projects doing air traffic control then sure, you want some pretty sweet documentation. But for 98% of business systems you need enough to get to your first deliverable. And that's not much. The design needs to accommodate the immediate requirements, and if you follow design patterns and don't actually close off expansion capability, then you can adapt to the changes needed for further deliverables. XP isn't about diving on in and coding, it's about thinking how to deliver what is needed. And if future capabilities aren't needed now, just don't spend time writing them - it's quick, cheap and easy to change code.
4. Well written code is far more useful to me than bad documentation. And in a business environment, working on code more than a couple of months old, ALL documentation is bad documentation - it is invariably out of date, imprecise and often irrelevant. Whereas the code tells you very accurately what is happening.
This doesn't mean the occasional class diagram or process flow wont help, but any member of the development team should be capable of drawing them up on a whiteboard without prompting, and that's the correct place for them. Documentation that isn't updated but is referred to will cause more bugs than having none in the first place.
Bear in mind of course that if you're properly following XP, and you write your unit tests to the same standard that you adhere to for your live code, then the unit tests provide a fantastic resource for seeing example usage of the live code. And examples are immensely more useful than documents.
5. You put forward a very negative and close-minded view. I'm often irritable, I swear at my computer let alone other people, I am very opinionated and disagreeable and I love an argument. Worryingly, so is the guy I've been pairing with for the past few weeks. And yet we're now turning out code much better than either of us managed individually, and we're working very efficiently. And we're also very keen to continue pairing because there are so many benefits it would be silly to stop. If someone's personality prevents them pairing them it's almost certainly going to prevent them working with the team as well, in which case most businesses would be better off with someone else - a good team provides more than the sum of its components.
I'm sure a lot of people will keep using XP, and that a lot wont go near it. And I'm convinced that many of the practices should be kept. But I think discounting it because you don't like the name and are scared of pairing with someone else is highly unprofessional and closed minded.
~Cederic
XP is an interesting (and controversial) methodology that has proven its usefulness in real projects, and it is nice to see it covered on slashdot. It is gaining acceptance in the software industry. One indication of this is the number of talks on XP at the SD2001 West conference in San Jose 8-12 April.
However, decent references are sorely missing from this story, like for example
the book by Kent Beck and one of the more comprehensive web sites, www.xprogramming.com by Ron Jeffries, with links to a lot of other resources on XP.
Is anybody else sick and fscking tired of reading about Extreme Programming on SlashDot.
g ra mming
http://slashdot.org/search.pl?query=Extreme+Pro
Variations on the same article over and over and over and over and over again. I get the message already, and I'm not going to switch just because it's advertised here three times a week, so kindly *stop it already*.
Is this post not nifty? Sluggy Freelance. Worshi
So, they're saying, "Figure out what's good and do it," huh? Well, it's good advice, but isn't it pretty much what we're supposed to in the first place?
I've never had someone come up to me and say "Write good code!"
I always thought that the "write good code" statement was implicit. If I'm writing code in any serious fashion, it's going to be the best I can do.
Maybe everyone else has been writing bad code intentionally all this time... They just needed to be told to do a good job! "Well, no one ever SAID 'Write good code' to me..."
Oh no it's finally happened... Software literature has become facile and meaningless as management pulp. The central tenets here are tautological: the central tenet of making good soup is to to find the essential elements of good soup and use them. Well, duh. For anyone who learned something from the advice about programmers programming, managers managing and customers choosing, I have this amazing revelation: it gets dark at night. Trouble doesn't come when organizations don't do this (obvious) stuff. The problems are the boundary cases... Clearly program scheduling and product positioning are 'business decisions,' but where are the lines between these and task estimates and customer feature priorities? And all this promoted by O'Reilly... Maybe they intend to start up a self-help line of books: "12 Steps to Programming Your Way to a Slimmer Healthier You For Dummies."
Most comments are pointing out that XP is yet another management buzzword or it's just stating the obvious. Well, it's neither. XP stands against all the principles touted by the waterfall model or the Rational Unified process and shite like that. XP is basically saying "toss out that copy of Rational Rose because you ain't gonna need it". If it doesn't make your job easier (and Rational Rose doesn't, believe me) toss it out. If you're already building five classes to parse a simple parameters file toss it out because you ain't gonna need it. XP points out (quite accurately) that the design for change is only useful if we allow extendibility in the right places. Unfortunately this requires you to analyze your problem domain beyond what's needed to ship your product and most of the time you'll still get it wrong. You'll get it worong because you don't have a crystal ball. You can't tell what the customer will want next. This way you eliminate the whole code design circus and end up with simple code that does what it's supposed to do, no more, no less.
One of the most important aspects of XP is unit testing. XP recommends that unit tests be written before the code that's supposed to pass those tests. This is more important than you think for two reasons.
Reason one: how are you supposed to develop your code if you don't know how to test it? When you write your unit tests you gain insight into the exact functionality of your code.
Reason number two: If you write your tests after you develop the code your tests will most likely only test the scenarios you considered when you were writing the code. Your tests will most liekely be incomplete because they'll have a slant towards your implementation.
Coding in pairs is probably the most prominent and the most controversial aspect of the system. It's important to realise the benefits of pair programming though. No code ownership means people can't get territorial about their code so everyone is free to change it when they need to change it. I've seen shops where changing John's code was considered politically incorrect and often John would take the issue personally. In other words if John wrote the message dispatcher John and John alone would decide on it's shape, form and future directions. XP essentially says that the hypothetical John can no longer pee around "his" piece of code and keep it as a guarded secret because John is no longer the sole developer of the message dispatcher. If John gets territorial about his work, John gets moved on to do something else and somebody else takes over until they start growing attached to the code again. Lather, rinse, repeat.
Besides code ownership and territorial programmers the other issue that XP takes on is coding primadonnas. Most software shops have a standard (sad) working model. One self promoted primadonna coding 70% of the application including the critical subsystems and the other twenty developers working around the edges "helping" the primadonna and trying hard not to get in her way. Our primadonna often isn't even the best coder on the team but surely is the most bullish and opinionated and thus grabs all the exciting work. Everyone else is just supposed to feel inferior and work on some tiny pet project of their own. This is not only grossly underutilises the rest of the team but usually at some point puts the project in jeopardy because the primadonna has now found another company to prey on. Project "gurus" have mushroomed throughout this industry and weeding them out may prove challenging. XP offers a very radical albeit a very promising way of achieving that.
This comment is growing a little long now so I'll shut up at this point. I hope this offers some enlightenment to those who keep on saying that XP is just another waterfall mutilation. It's not. It's a hackers methodology. On the side not however, I to have an issue with the name and the accronym. It's just juvenile.
Your pizza just the way you ought to have it.
--
KMSMA (WWBD?)
I just love it when people blurt out erroneous information about a subject/product/project that they have never seen or used.
The main concern people have here is that in XP you don't design. That is a false statement. In XP iterations are encouraged and design, for an iteration, takes place at the beginning of that iteration. Its true in XP you don't design a large application at the beginning of the application, that ends up begin a waste of time. Any one who has ever worked as a programmer realizes that user requirements change on an almost daily basis. This iterative design process allows for change. In fact, one of XPs mottos is "Embrace Change".
The best argument for the use of XP is that it works, better then any other methodology I have ever used. The iterative design process, user stories, unit testing, constant code commitment, pair programming. These concepts brought together in the form of XP produce a balanced environment that tends to produce what the customer wants in the time frame he wants it. In short, it helps us do our job as developers well.
With XP you get well-designed, extensible, modular code. You are also encouraged to reuse it whenever possible.
Is XP a panacea? No, not by a long shot. On of the principle complaints I get when I introduce some of the concepts and procedures to a client is the statement "Oh our coders don't like procedures, they will never do that". This comes back to the fact that if you can't get your coders to follow any procedure, than it is likely that no procedure will work for you.
Although I am a full time coder and like XP, most coders do not. XP, by design, reduces the likely hood of cowboy coders (in the American sense) by design. If XP is implemented correctly it wont be long before almost everyone has a similar level of knowledge, this level is usually equal to the highest pre-XP level.
I'm a programmer, I don't have to spell correctly; I just have to spell consistently