Slashdot Mirror
Extreme Programming Explained
The Hook
Want to write better code? How about working less overtime, getting along with your team better, meeting customer demands more quickly and accurately, spending less money, and having more fun?
Extreme Programming may be for you.
Be prepared to make some adjustments and sacrifices. Individual code ownership? Gone. Programming for the future? Slow down, cowboy. Working on your own? Grab a partner and dance.
What's the Scoop?
Extreme Programming is a way to improve software development by focusing on what really matters. If it will cost you $50,000 to implement a feature now that may not be used for two years, and it will cost you $55,000 to implement it in two years, hold off. If running test suites is good, write tests for every significant piece of the system. If multiple pairs of eyes make bugs shallower, program in pairs. If you enjoy meeting deadlines (and not working your fingers to the bone every night for weeks to do so), make shorter deadlines.
It sounds simple, even deceptively so. It may also set your teeth on edge at first.
Imagine that your customer has the time and the manpower to send a representative to sit with your programming team. He is actively involved in the design, writing 'stories' about how the system works for the end users. Every morning and afternoon, your programmers meet to decide which tasks to tackle, and they pair off, sharing one computer between them. One person codes and the other watches, and they switch off as necessary.
With every change to the system, the previous tests are rerun until they work perfectly, and new tests are added to test new functionality. Changes are not commited until all tests run successfully.
Releases are started early (six months, for a big programming project) and continue quickly after that (every couple of months). With a customer sitting in with the programmers, feedback can be instantaneous. The initial investment pays off quickly, while expenses are spread out over a greater period of time.
With no one owning a particular section of code, and with everyone working with different partners from day to day, everyone should have a good overview of the system as a whole. This can lead to better programming, from less bugs to very quick refactoring. New programmers can also be brought in and up to speed much more quickly.
What's to Like?
The book is clear and readable -- even funny. Chapters are short and to the point. Beck uses the metaphor of driving to bring his point across. (Driving is not about pointing in the right direction and maintaining that course, it's about making slight corrections all of the time.)
The bibliography is a great place to find some classic works (including books by Brooks and Knuth and even the movie 'The Princess Bride' -- no, really!).
Extreme Programming itself has a lot of promise. Some of the principles (programming for today, releasing early and often, peer review, community code ownership) fit in pretty well with open source/free software. Some of the other ones would be nice to see....
What Might Annoy You?
It's not clear where Extreme Programming fails. To the author's credit, he mentions this and gives some guidelines, but the choice and the implementation ultimately rest with the managers and bean counters. There will be some resistance at first, but Beck's enthusiasm is infectious and his clarity of explanation might be enough to overcome it.
The Wrapup
If you're a member of or a manager of a moderate programming team, you ought to read this book. It will go nicely on the shelf next to "The Mythical-Man Month". If you're curious about new ways to look at programming (especially in a group), you'll want to pick it up.
Purchase this book at fatbrain.
Table of Contents
- The Problem
- Risk: The Basic Problem
- A Development Episode
- Economics of Software Development
- Four Variables
- Cost of Change
- Learning to Drive
- Four Values
- Basic Principles
- Back to Basics
- The Solution
- Quick Overview
- How Could This Work?
- Management Strategy
- Facilities Strategy
- Splitting Business and Technical Responsibility
- Planning Strategy
- Development Strategy
- Design Strategy
- Testing Strategy
- Implementing XP
- Adopting XP
- Retrofitting XP
- Lifecycle of an Ideal XP Project
- Roles for People
- 20-80 Rule
- What Makes XP Hard
- When You Shouldn't Try XP
- XP at Work
- Conclusion
if($msg =~ /TROLLMASTAH/i) {$reject = 1;}
Sounds like a great way to write non-maintainable code to me. I think I'll pass on this one.
Thanks for the informative review, BTW.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Get praise for the work you do right, and be ashamed for your mistakes. Community code, as such, doesn't teach each programmer his mistakes, IMO. If you feel that you have the syntax correct, and convince your partner in that, what if the next day a new pair of coders happen upon it and tear it to pieces. Granted, it was returning null values in the first place, but if the work is already done and posted up, you can look over it, but do you really learn from it?
The way I like it, each person on their own, knowing what to work towards. On routine schedules, a manager(s) will look over everyone's code and test it together. If a problem is found, the manager will discuss it with the coder, and give help on fixing it.
This may be less time effective, but you know that the skills of each programmer are rising, rather than looking at the overall skill of the community (the strong make up for the weak).
I like the part about customer feedback (i.e., end user feedback). That is often hard to come by in projects I work on. The tricky part is balancing it with management feedback. A typical situation is one where the users of the software want ultimate flexibility, but management wants software that adheres to certain business rules. As in "you can't set a ship date for whatever you want, it has to be within five weeks of the order date."
BTW, all this is from the perspecitive of "business apps," which some twit said wasn't "real programming" here a while back. Whatever.
DO NOT DISTURB THE SE
Well, technically speaking a Troll is a posting designed to elicit a particular response from a person or group of people, usually made to show how easily irritable (bitchy) or arrogant th person is. In a classic Troll the perp would post something quite normal, but with either a factual error or an offensice statement in it. The mark would reply to correct or express their outrage, and the perp would either respond with something to defame them (i.e.- you ever stop beating your wife, Mick?) or let the reply stand on it's own if it was a particularly good one. For those interested it comes from th term "trolling for newbies", which itself implies that only an uninitiated would bother responding to correct the troll. Posting to a lightwave discussion group for instance, saying tha the copy of lightwave didn't include the dongle but works anyway, someone would be sure to reply back flaming the person for supporting piracy.
Flamebait, OTOH is a very specialized form of trolling. Basicly the goal is to piss of everyone. There is a fine line between using irony and posting flamebait. This first posing may very well be a troll, however due to the obvious attempt to imflame McDougal. Of course had I still my moderator access I would simply mark it as offtopic because noone else on slashdot really cares.
> hehehehe, gawd I'm so fucking funny!!
No, no you're not.
Okay, so you feel encouraged by this response? Shame on you.
With infinite resources anyone can write the most beautiful, bug-free code. I agree that 2 pairs of eyes are better than one, but if they can get that 2nd pair of eyes to go program something else, they can get more programmed in the same amount of time. These are the days of companies being shortstaffed and projects having to be done "yesterday". It all sounds great in theory (just like all the good practices you learn in college C++ class), in the real world, things don't work how you'd ideally like them to.
Now I can't stand to program alone... drives me nuts! I go a lot slower too. Really screwed up my CS grades last year, we were explicitly not allowed to work in pairs on the code :(
"God does not play dice with the universe." -Albert Einstein
Those who fail to understand communication protocols, are doomed to repeat them over port 80.
The 'extreme' moniker is probably just marketing hype. This is isn't really all that 'out there'. This is the way most large consulting firms and code shops work. It may not be the most efficient (or enjoyable) way to develop small apps, but it keeps the pace manageable and the schedule on track for multi-million, multi-year engagements. Specifically, to address the previous poster's comments regarding non-maintainable code: This is in fact one of the best ways to write maintainable code, because everything has has to be documented because everyone has to work on it. No one person owns the code. Again, takes some of the random joy out of coding (no more pink floyd lyrics in the header), but if you're into that, you probably don't work for a consulting firm or a code shop anyway. -thanz
VERY LOW SODIUM
I have flipped through this book at the bookstore and it looks to me as if they initiate a code then analyze/fix methodology. I have no problems with doing this on a project that has flexablity and no deadline. I do have a problem with the idea that you can skip the analysis and design stages of a large complex implementation and just code then go back and fix issues as they come up. Bad habits == bad results. A little planning goes a long way. I have great experience with past projects on this matter. But like I said I only have flipped through the book. Now I have to go buy it and really understand.
Bascially, he embraces a hacking mentality instead of rejecting it, and then looks for ways to improve this process through peer review and heavy testing.
As it stands, I think his approach is both good and bad - good in that it doesn't try to turn your world upside down and fore a new methodology on you, but bad in that it seems to deny the usefulness of some valid quality engineering practices.
If it's anywhere close to being as effective, it's definitely worth a look.
I learned about XP (Extreme Programming) a while back and while we don't follow all the practices Beck recommends, the pair programming has worked well for us! This should be obvious to Open Sourcer's since it's just peer review on an immediate level. The real advantage of this for us is that it produces code which is understandable to more than one person, right off the bat. This alone is a good thing. But if you do something devious like pair a programmer with a more knowledgable person, you're also getting some training in. Add to that the fact that more than one person at a time is actively designing the system, and you've got a pretty solid system in place.
This is something I highly recommend that everyone try at work. Only people with huge egos shouldn't bother, but you did remember to check that at the door, right?
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
>who need to do programming but don't have time to do the engineering phase
Whoa. People have time to do the enginerring phase?!?!?
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
After doing "normal" coding for the past 7 years, I thought I had it down pretty good. We started switching over to "XP" about 12 weeks ago and our company is on it's 2nd project using it. One difference, we split our teams out into 3 week chunks. The teams are small and we work tight. After 6 months of this, each programmer really has a feel for the system and because they work on each piece for 3 weeks, they're not leaving a mess of bugs for the next team. This "XP" thing isn't as bad as it seems. When run side by side with a "normal programming", the XP team always comes in under budget, ahead of schedule, and with fewer bugs. And the constant client feedback on each 3 week iteration is a lot better than the old school "design sessions" and "requirements gathering" phases, which left out a lot of developer/client contact.
I don't like the name either, it gives managers the willies and makes them think we're going to program their pet project while snowboarding. We just call it "pair programming", makes it sound boring and safe.
..."
"You got that routine done yet?"
"Not yet, got snow in my goggles!"
"OK. hey watch out for that
*aiiiieeee*
"...tree." *wince*
:+>
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
When coding a library, write just those functions you actually need to support the application, and put the tests for that functionality in the test program alongside the library source, which must run successfully before committing the code.
Then, as the functionality develops, watch for factoring opportunities and allow yourself two days to re-factor, running the identical test program successfully to ensure you haven't messed it up.
Every so often, allow four days for a major new-functionality-free re-coding.
This approach gets results quickly and above all allows re-use for the next application with just those extra functions needed being added as required.
Don't spend forever in meetings discussing library design. Let the application drive the libraries and watch as successive application coding efforts get shorter and shorter with greater re-use.
Just my opinion. Flame on.
--------------------------------------
--------------------------------------
Dere's a storm a-comin'...
Is this like programming on a TRS-80 while bungee jumping?
this sig limit is too small to put anything good h
I am glad you don't have moderator accces.
The first post I saw said that this sounds like a good way to write unmaintainable code.
Working day to day, with constantly changable goals, with no clear plan or design to implement IS a recipe for disaster.
I hope nobody thinks anything but a hack or a prototype should be written this way.
That being said, there is nothing wrong with using prototypes for real work, it is just sloppy (IMNSHO)
I could just imagine PHBs reading this book then applying it to EVERY project just to reduce time/costs. Then the code maintance people will have a hell of a time. One of the reasons is that one end-user has no idea what the program act like for a wider group of end-users.
The book also seems to be advocating bad coding. Its what I went to university to learn how not to do.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
But if your project has a history of needing to re-write code, pair programming will be cheaper. Guaranteed.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
Finally a breath of freshair!
HOORAY!
To some degree, this is a welcome backlash. Many OO/reuse-nuts tend to advocate its principles for all projects across the board when many projects aren't helped, and some are in fact hindered by these techniques.
Comments about user feedback are right on the money. Frankly, if you're developing a mission-critical app and you *don't* have constant feedback from the users during development, you're asking for failure. Software engineers aren't domain experts, and we will screw it up we lock ourselves away from the users. Yes, you'll have management constraints but you must always present options to the user. "We can implement the 100% solution using X time/money, or we can give you the 80% solution in X/2 time/money and also have resources to attack Y and Z. You pick."
Neutron
I get my kicks above the
I can't believe that no one else has posted a link to the Extreme Programming web site yet. A former coworker pointed it out to me. It is worth the time to read. Some of the ideas are excellent. The one I particularly liked which I have seen used by a group I work with is coupling an automated regression test suite with a requirement that all code changes must pass that suite before they can be committed.
The net will not be what we demand, but what we make it. Build it well.
But seriously, you need to have some idea of what you're developing before you start coding, just like you need to have some idea of what you're destination is before you set off driving. Otherwise, you don't know whether or not you're moving in the correct direction, to say nothing of knowing when you've reached your destination. Usually proper planning, implementing tools, and testing saves time in the long run.
"Wait a second!" shouted my partner, leaning over my shoulder and beginning to type.
"WHAT?" I asked, watching him move the cursor.
He cursored over to a piece of Lisp code, and pressed the space bar. "Sorry," he said, "That was bugging me. Now it's indented properly."
www.HearMySoulSpeak.com
One of the things I dream about is detailed specifications.
:) Time and time again the people I write applications for turn out to have no real idea what they're asking for, or how it should work. "uuh, I donno, make it work" really doesn't do much for me as a programmer, which is why the following bit caught my eye:
I used to dread the paperwork and meetings and monotonous never-ending corporate BS involved in "requirements gathering" and the like, but the last several jobs I've done have demonstrated their value beyond any shadow of a doubt.
People don't understand how programmers work, much less the computers they use
Imagine that your customer has the time and the manpower to send a representative to sit with your programming team. He is actively involved in the design, writing 'stories' about how the system works for the end users
The jobs that have been done correctly, the ones where you don't spend 1/2 the time "adding features" that should have been included in the initial design specification (requiring changes to the fundamental architecture, blah blah blah), have all included this kind of a buffer between the "client" and the programming team. These are the people that hammer out 80 page requirements documents, which may at first appear to take all the fun out of it, but in fact save a whole lot of work in the long run.
"The Client" always seems to know which "little changes" require you to rewrite the whole application. "Oh, what you've done is *great*, but could you just make this *little change*..." So you have to rework the whole thing from the bottom up, break half of it in the process, and "the client" can't understand why it takes you so long...
Those kinds of headaches can be avoided *only* by getting a detailed specification before you even start...
Anthony
"I think any time you expose vulnerabilities it's a good thing." -Attorney General Janet Reno
I am reading "The Pragmatic Programmer : From Journeyman to Master" by Hunt, Andrew and Thomas, David and they have many good idea that run parallel to XP. May be a another book someone could review. If needed I can do it if I can find the time.
While I can see it working well in a number of circumstances, most of the projects that I've worked on it wouldn't work very well.
Project type 1 where is wouldn't work is any large project, say over fifteen developers (plus management). Any system that big and complex will not be understandable by everyone. Cross-fertilisation is a nice idea, but when things get too complex you need an expert or a keeper.
I guess you could have several experts, but you come up against the cost aspects very quickly.
Project type 2 are those with varying technologies. One I worked on recently used Oracle, Unix, NT, LotusScript (Domino), NotesPump, VBScript, JScript and HTML. I would argue that you can't be an expert in all of them. I do Oracle and Unix and have an appreciation of the others, but I couldn't really add much when I reviewed the work in other teams.
Again you could switch around each team once in a while, but any good team-leader would do that if they could anyway.
And that's before you even get into the 'egoless' bits, and the fact that management like people to be responsible. How can you have a scape-goat if it's everyones fault?!
Anyway, that's enough. Nice idea, but it wouldn't work in real life.
I've just finished this book, and a lot of what Beck says makes much sense. I'm starting the coding of an information retrieval framework at the moment and the test-first strategy makes a lot of sense to me. However, how do you do these unit test thingies for User Interface? A lot of the testing theory in XP is based on the assumption that test results are quantifiable (i.e. the 'leave it at 100% testing accuracy so the next team know what broke' stuff) and automated. How do we do this for UI?
I've never tried this myself, other than in some debugging tasks. I'm intrigued. However, one question: doesn't this gain you a lot more in "difficult" tasks?
Some of the coding I do is tricky stuff. New technologies. Unusual tasks. Code that needs to be very robust. I can see where this would work wonders. However, some of the coding I do is nothing like that. It is dull stuff, iteration number 5 of stuff I've already done elsewhere. (Code reuse is hard when you change companies!) Basic debugging. Stuff that is really pretty trivial. It seems to me that pair programming would only slow things down in this case.
I suppose it is like everything. You need to learn when to apply it and when it is a waste of time.
The cake is a pie
Gee, we've managed to reinvent code reviews (a weird form, granted, but this is still just code reviews).
"If the feature costs $50,000 to implement today, and $55,000 to implement later when it's needed, implement it later." Well, DUH! It's not the features you expect, it's the features you don't expect which kill you. And this is what seperates a good design from a poor design- a good design can cope with unexpected requirements and features much better.
Brian
This book is available at Amazon for $20.97, instead of the $29.99 Fatbrain wants for it.
If you are so into the whole patent thing, well go ahead and pay more I guess. I just saved 8 bucks, myself.
DrLunch.com The site that tells you what's for lunch!
I keep harping on my boss to present a detailed specification to our customers for approval.
While my company does medium sized, database driven websites, I still get frustrated everytime my boss comes back and says, "Oh, the customer thought it was going to do this..."
I don't usually consider work 'coding for fun', because it's nothing like what I work on when I have spare time. It's a job for me, so I like it when it is very clearly stated what it is that the code I write should do.
Dana
That's sort of like what Brooks was arguing about, when he didn't like data hiding.
He changed his mind.
You need an overview of the whole system. Detailed knowledge has a hidden threat - it inclines you to think that the internals of other parts of the system are static, and that you can depend on them.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Treating coders as unspecialized labor tends not to work because coders are not like factory workers but more like artisans or craftsmen. When you treat programmers like cattle they tend to resent it and deliver substandard code, at best.
While getting the entire programming team involved with the design of every piece of the code might sound good, it results in design by committee, which doesn't tend to work in practice. The best designs come from inspired individuals or from very small teams of people.
Finally, individual code ownership minimizes the need for communication accross the entire group (the N^2 communication problem noted by Brooks in The Mythical Man Month). By requiring a very high degreen of communication between all coders in the group, this technique is almost certain to fail for any group larger than a half dozen or so.
Ignoring N^2 communication issues is inexcusable in any methodology postdating The Mythical Man Month.
A methodology that doesn't address the need to redesign the production system, however, will suffer from cost overruns and reliability problems (both of which XP is explicitly trying to avoid) due to the need to work around mistakes and compromises made when designing the prototype.
If XP is really dependant on some of these assumptions then it seems unlikely that it is a generally applicable methodology.
So, it sounds a good piece, but I don't see anything that sets it apart from standard practice or from design methodologies that have already been elaborated elsewhere. Some of the ideas are good, but others just seem to be naieve or illconceived: some even seem to smack of outright voodoo software engineering.
If you are doing the whole amazon.com boycott thing but still want to save a few bucks, you can always try out bookpool.com . They are selling it for $23.50 , which is more than amazon.com, but that is unusual - they are typically cheaper than the other online places. I have used bookpool.com several times in the past, and have always been impressed with prices and delivery time.
In this case, the book is out of stock (so you might have to wait a few weeks), but it is a good link to keep in mind the next time you are going to order tech books. All IMHO, of course.
It kinda reminds me of an event that took place one day at my house - a debugging party. I was showing off a game I had written, and was getting close to releasing a new version. A couple of my friends hadn't seen it, so, I set down and showed it off to them. I let one of the guys play it, and noticed an area where it slowed down a bit too much...
We spent hours all of us staring at the screen, finding places that the code could have been a little more efficent, etc.
It worked out great, really. I don't think I would want to program like that all the time, but, it's a great way to discuss the code all at once, what the function of a piece of code is, etc. and come up with ways to re-optimize things. I figure before my next release I'll go down to the liquor store and buy some Zima and some beer, and have another debug party :-)
Midnight RyderDavis Ray Sickmon, Jr - looking for something to read? Check out my three free novels at MidnightRyder.org
Chances are that in the first few months of software development this "customer rep" who sits in is going to have absolutely nothing to actually see, so he's just going to annoy everyone. In one of our companies earlier software projects we worked a bit like this - the client was involved way too much. He didn't really understand computers very well. He bickered about silly little things but asked for complicated things ("wouldnt it be nice if we could do x" type of thing). The end result was that he just got in the way too much, slowing down development. His notion of the priorities of the "TODO" list were totally different to that of the developers.
Also "release early and often" in this case seriously hindered progress, since it meant regular demos of the system, and anyone who has been asked during software development to quickly set up a demo will know that this puts a software project back anything from a few days to a few weeks. You hack all sorts of strange things into the code at the last minute to get a demo to look like it works. The code becomes messy and unmaintainable, nobody understands it, lots of bugs creep in, and yet you've still convinced the customer in the demo that things are going well. Lots of the hacked stuff finds its way into your final product.
What we learned from all this is that the customer should only be involved in the design phase and the final phase of software development, with only a handful of "milestone" demos along the way. If you planned your spec properly in the first place then this is normally more than enough to make the small adjustments along the way to make a good product.
I guess I'm skeptical about "extreme programming". I think you can't beat proper planning and system design if you want to minimize costs. If your deadlines are perpetually too close, then you have a management problem, not a technical one, and you should talk to your managers.
Programmers' hours are typically expensive. With a decent system design you can get each programmer to work on his own piece of code, rather than stare at someone else typing. While peer review is valuable, two programmers per station isn't worth it.
"Release early and often" applies well if you are releasing to other programmers, but it is meaningless for commercial clients, since they end up with nothing they can actually use, and they can't give you any useful feedback either. If I go to a restaurant I don't help the chef cook my food, he knows what he is doing. The same applies for software development.
For some reason this book reminded me of Gerald Weinberg's ancient tomb. Esp the advocacy of very small teams.
I can vouch for the team of 2 while writing code. Never actually seen it used in business (how would the bean counters justify it?), but I used it on some of my hefty college projects (like writing a pascal compiler). Felt that I was never more productive than in school coding as a team of 2. Or perhaps it was that I had a crush on my partner.....
Know there's a concept: Pair a geek guy with a beatiful woman and sit back and watch him try to impress her with his technical prowess (of course it never works, beatiful woman don't care about techy stuff, she'll use him to get promoted/ get an "A" then go out with a jock, but don't tell the geek that he'll create technical marvels in record time)
:)
Keep on keeping on.....
Coming soon to ESPN2:
SEE: some guy sitting in a dark room in front of a console, typing REALLY FAST!
SEE: The most extreme, hardcore debugging EVER shown on cable!
SEE: One-handed Altair 8800 Programming!
SEE: Guys drinking lots of coffee and haggling over database design!
SEE: Client-Server Action that will blow you away!
SURGE!
(By the way, has anybody ever had a beverage called "Mountain Lighting"?, You can only get it from Wal-Mart, and it's basicly liquid crack)
Go back and look. The first post you read is not necessarily the first post made to this story (check the # next to the timestamp of the post itself). Depending on how you have your preferences, the first post could actually be the last one you read, or somewhere in the middle.
This dude sounds to me like one of the better moderators, when he has points.
"You can never have too many elephants on your team."
A foundational part of XP is the mutability of code: you write the code for what you know now, and be willing in the future to totally change it. One of the best technical books I've read recently discusses the how-tos of this: "Refactoring" (by the way, the link directs you to a price comparison site which I find REALLY useful).
I tried to use this method is my latest project, a test framework, and I was extremely pleased by the results; not only did the design morph as I discovered the requirements (so the final result was a design I was pleased with), but the final result snapped into place around the item being tested and no bugs have been discovered in it!
I can highly recommend at least that part of XP: refactoring and coding for today. I'm going to try some of the other parts in small bits at a time, but from what I see they look very useful.
I certainly wouldn't describe XP as being for someone who doesn't have time to design; I would describe it as something for someone who doesn't expect to get it right the first time, and who wants to get it right anyhow. I would also describe it as being for someone who wants to be useful to customers without hurting his own productivity -- see the Bill of rights on the Extreme Programming website. In short, XP is about never having to tell a customer that you can't make that change now -- and it's also about always being able to make changes when you need to.
-Billy
Prices for this book range from $23.92 (Buy.com - out of stock) to $33.90 (Borders.com) (both are UPS ground prices).
It's saved me a few dollars, now and then.
Jeff
I have, and it works beautifully. In fact, the nastier and more complex the coding problem the better. Two people watching pointer arithmetic are always more careful than one.
That said, a few commonsense caveats must precede its adoption. Namely:
I know of no piece of code that I've written this way that hasn't been FAR less expensive than its more traditionally coded counterparts, once debugging and QA expenses are factored in. The interesting part is that design and refactoring remain part of the process long after they would normally, as ones assumptions must be continually re-examined as people new to the code come in.
"Ummm...maybe the developers were wrong"
Not in this case. The application was a VR training simulator, and definitely isn't the sort of system that "evolves" as the client uses it, like yours. The developers had a much better idea of how long certain features would take to implement, and why it would be better to put more planning into various features and less into others. The client had no such concept, in his mind, when he asked for some ridiculously complicated feature, it was "why can't you just quickly add it?". The other similar, related problem was that he kept nagging for new features that weren't originally quoted for and thus weren't in the spec for version 1; he was asking for more than they had paid for. In some cases we gave him extra features, but at a point we had to say no, because they were dragging development out and interfering with schedules. Many features you simply cannot "just quickly add".
I ran into XP via Cunningham & Cunningham, Inc.'s ExtremeProgrammingRoadmap. I had a lot of the same thoughts that many here have posted, with tons of reasons why it couldn't possibly work. I decided to use some of the XP methodology for some tutorials and samples I needed. I will never look at programming the same again. If you have some extra time I would suggest buying the book, opening your mind, and doing some extreme programming. It has changed my life, it might change yours.
The way would not exist if not for the laughter.
Yep, I live on that stuff. One of the higher caffene drinks out there- and it's cheaper than everyone else's stuff.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I think this is a common problem. I don't know much about this myself, since I'm working on the middle-ware portion of a 3-tier project. But, at least on our project, the testing people always have trouble setting up automated regression tests for the gui. If someone changes the layout of the screen, all the old tests fail. I don't know if they're using the testing tool wrong, or what. Does anyone have any experience with this problem?
--
Steve Molitor
smolitor@erac.com
"Emacs is the Computer"
Stephen Molitor steve_molitor@yahoo.com
Having practiced XP, it is similar to most methodologies in relation to the project triangle and other high-level management approaches. Its implementation, however, is where it significantly diverges. Anyone who throws up their arms and runs away at the ideas is simply adverse to change. Kent has some intriguing ideas that we have successfully implemented and a few new ideas on arbitrary approaches that I've always had problems with (i.e. one person estimating other peoples time, redefinition of the users requirements). The reviewer glosses over numerous key features to XP, such as story-writing, prototyping, and most importantly, pair programming, which is the key to XP. Pair programming is a cultural shift and is difficult to introduce simply because everyone wants their own "space". What you find; however, is with the proper environment, pair programming is quite natural and each of us has experienced it successfully in one way or another. You simply provide the developer with a place for them to go to to make their private calls or spend some time contemplating. Finally, XP only works in some environments. It's approach to modelling and testing doesn't work very well with UI-heavy products. You can only achieve automated testing in approx. 65 to 70% of the UI system (assuming a proper 3-tiered system and that the model represents the data and is not integrated with the UI) and ultimately have to resort to manually testing the GUI.
For a gentle introduction, check out ExtremeProgramming.org. They also have a nice on-going column about developing an "extreme"-style coffee maker.
cpeterso
Disclaimer : I hope I do not offend Design Pattern purists in my following loose interpretation of DP. I merely attempt to attribute my own ideas to others. If the following ideas deviate too greatly to be called DP, then I am grateful I have actually formulated or described something original.
There are many threads above that argue vehemently against and for a non-written-spec-based development pattern, "hacking" so to speak.
What makes a great project, and makes for great programming, is not the *winner* of the paradigm or design pattern.
It is not something as simple as "OO rulez", or
"Pedal to the Metal."
A great project, and a great programming team, distinguishes itself by the proper choice and appropriate use of paradigms and patterns.
// Flame Bait Alert Begins
Zealous proclamations like "Never have multiple function exit points", "Never use gotos" and "Never have modules exceed N number of lines" often stem from *inexperience* that never had such proclaiming coders be *forced* into such circumstances when breaking such rules lead to easier to read or more maintainable code in the long run.
// Flame Bait Alert Ends
Many development books and paradigms are written as if code and programs are created in perfect sanitized heavens that I have yet to experience in any game development house.
On the flip side, there are many game programmers or *hackers* who can so glibly discard decades worth of language or system theory research, and sincerely believe they can create thought systems of equal robustness in a matter of months.
We do not need more flame throwers.
We need accessible information and research to cloistered practitioners like us. And we need to contribute back to academia codified and scientific "development patterns" we corroborate with our colleagues/competitors so the system of knowledge can "grow" instead of "treadmill."
Post-mortem's and magazine articles, even interviews, are good baby steps. But our field needs something more scientific and codified than that.
We need to know not only what fails and what works. But what works in "which circumstances." What fails in "which other." Lots of lots of redundant information to prove one way or otherwise.
In retrospect, what I describe is more "development" pattern than "design" pattern.
I would greatly appreciate if fellow posters and programmers can point to me, or discuss from personal experiences, various "development" patterns that work, and various that fail.
The most enlightening discussions would be given the same "development" pattern, one that succeeds in one circumstances, and fails in another.
Then is the failure based on inappropriate circumstances, or improper application?
A more informative discussion is not "this paradigm fails" "this paradigm is god" but how which paradigm best works in which circumstances.
I hope to see from now on discussion goes more in that path.
Apologies of diverging from the topic of the specific book.
Disclaimer : If you are inclined to respond in flames, please at least first re-read what I am really saying. Thank you.
Corrinne Yu
3D Game Engine Programmer
3D Realms/Apogee
Corrinne Yu
3D Game Engine Programmer
For those who don't hang around the relativly small community, Kent Beck is a Smalltalk God (tm). Any list of the 5 most influential Smalltalkers would include his name, so I put a lot of stock in his work. He is also very infuential in the Patterns community, such as his contributions to the Portland Patterns Repository. Working with Ward Cunningham, he came up the CRC Card design method, which is the only "design methodoligy" I find I really use.
Someone once wrote that his list of recommended Smalltalk books starts with 'anything by Kent Beck', and his "Smalltalk Best Practice Patterns" is the definitive work for tactical programming patterns for that language.
Steve Cline http://www.clines.org, http://www.objectbap.com
For some reason this book reminded me of Gerald Weinberg's ancient tomb. Esp the advocacy of very small teams. What's this? Is Gerald Weinberg dead? Or is he simply alive writing less ancient tomes?
If you pair programmers in the same cubicle, with only one computer between them, you don't have to worry that one or both of them are wasting their time reading and replying to Slashdot articles.
I tried pair programming here at work [WebObjects/ObjectiveC], and it worked wonderfully!
We came out ahead of when we thought we could get through, had very few errors along the way, and had a LOT of fun.
I remember that when my partner left, everything suddenly seemed to slow down. Two people working on a problem at once has a synergetic effect. It forces a laser-like attention without distraction, and shows views of things from more than one angle. At least, that's my explanation for what happened.
An absolutely wonderful experience.
Read the articles here: you'll notice a lot of SPECULATIVE "I don't think it will work"s, and you'll notice a lot of "We DID it, and it works great."
Lion Kimbro =^_^= . o O ( Someday I'll get yet another Slashdot account...)
Extreme Programming (XP) is supposed to be an ongoing dialog between "Business" (the "Client") and Development. If the client wants a new feature, the developers need to introduce the Client to the "Software Triangle" (Cheap, Fast, or Good: choose two). Clients are paying for the software, so they should get what they are willing to pay for. If a client wants a new feature "quickly", the Developers give the client a revised time and cost estimate for the added feature. Developers are good at deciding how long something will take to implement. Clients are good at deciding whether they want to invest the time and money for that feature, once they know how long the feature will actually take to write.
cpeterso
Too bad I wasnt in your class or you could have done what most of my classmates did. They looked over my shoulder watching me while they handed me $30 to rewrite my programs enough so that they could hand it in too. I rewrote my C++ final program five times! That was the easiest $150 dollars I ever made, and I did it in one class period (about 1 hour). $150 an hour isnt bad for a college kid. Too bad that only happened once every other week when programs were due, cause it was more lucrative than writing people's term papers for them. Too bad that they will grow up to be bad programmers later, but I guess that will give more jobs to me.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
Since you don't know what I have or have not read, your opinion is also uninformed.
But I would not be so arrogant as to state that your opinion doesn't matter because it is uniformed.
The reason your opinion doesn't matter is that it is hypocritical.
Actually, in a way the unit test IS the spec.
"Refactoring is a fix-it-after-its-happened strategy. In our company that has turned out to be far more costly than just doing proper planning to begin with."
Yes, it is a fix-after strategy, but it is one I have found really works (even long before I had ever heard of XP). Very often I find myself chopping a function in half or sucking the middle out. It takes me *very* little time to turn:
int foo (
) {
int a1;
int a2;
do {something} while (sometest);
do {more} while (another);
}
into:
int foo (
) {
int a1;
do {something} while (sometest);
bar();
}
int bar (
) {
int a2;
do {more} while (another);
}
If I discover I need to use the 'bar' functionality someplace else.
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
that would be:
;)
So, so you think you can tell heaven from hell,
blue sky from pain. Can you tell a green field
from a cold steel rail?
from "Wish You Were Here," of course
Going on means going far, going far means returning. Tao te Ching
That's part of the problem -- even having "code maintenance people"!
Because, typically, that means the 'hotshots' are all doing feature-creep and the 'code monkeys' are doing maintenance -- is it any wonder we get bloated BSoD crapware as a result?
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
the book is actually cheaper there than at fatbrain. ridiculous one-click copyright lawsuits aside, amazon.com is still a pretty good place to buy the byproducts of growing trees.
here is the link to the book.
p.s. i wonder if they are going to sue me for providing a "one-click" method of getting the book at their site. hmm... perhaps even linking is illegal... oh, well, enjoy you new year's!!!
I was thinking of how to intentionally fail my drug test... It would make a good memoir story someday.
i think having someone look over my shoulder while i code would drive me insane
It would be interesting if their was anyone who knew what the ACM's reasoning is for having teams of three.
As a female college student in a dorm where people wander aimlessly in and out of each others's rooms, I find that the best way to get any coding project done is to leave it up on my monitor and wait for a critical mass of male compsci majors to come in and start arguing about it; it's the most time-consuming way, but it definitely provides enough options as one guy goes for elegance, another for obfuscation, another wants to write it all in another language ...
The dibble is rusty.
my experience with minute-by-minute customer feedback is that the entire notion of a functional specification is lost immediately, as about one out of every five opinions they have on something will in fact be a new feature they just thought of now that they are seeing their product come to life. Having the customer sit with the programmer all the time means there is no project management layer in between, its just the client making demands directly to the programmer who has much more pressing (and non-programmer intangible) issues on his/her mind than all the random little frills that should have been spec'ed out and properly scheduled. All of the customer's thoughts and use case scenarios should be gathered into a proper and complete specification before any programming work is begun - if the programmer needs to ask questions to the customer during development, then the specification was not completed. Continuing down the road of developing a large project without a roadmap will guarantee project failure, major psychological/physical trauma to your programmers, or both.
XP is nothing but engineering. Highly disciplined engineering, SEI CMM Level 5 Engineering. It's repeatable, it records, it measures, it optimizes, it plans software development in exquisite detail. XP is a painstaking and rigorous process that is simultaneously paper-light and stress-free. Anyone who disagrees with these statements simply doesn't understand XP. Plainly most of the correspondents here simply don't understand XP.
Beck's work fundamentally advances the state of the art in Software Engineering, and his book is at least as important as Design Patterns. Where Beck has failed is in anticipating the outrage of all you shmoes. Beck's book is obviously failing in communicating the idea that XP is *NOT* Cowboy Coding. If you think it is, get the book, read the book, understand the book. And then you'll probably want to try it. And then you'll understand, but that'll be too late to quench the flames.
Still, isn't this a risky way to evaluate the XP approach? Well, look at it this way: over half of the world's software projects fail outright. So far there are no known XP projects that have failed. None. So what have you got to lose? Besides, the whole thing is vastly more fun than you've ever had programming in teams. Quit yer yammering and give it a chance.
And if you're too cheap or lazy to buy the book, most of the material there is also out on the wiki-web. Most of the XP boffins hang out on wiki - go raise hell with them there and you'll find that all the questions here have been answered in detail.
XP is not programming without engineering. XP is engineering without therbligs.
No, really.
I found your comment about Business Programming being "programmed programing" interesting. A fair amount of what I do is repetitive (I would argue that some is not. That some businesses are so specialized in what they do and so convuluted in how they go to market that no AI computer program could ever replace a talented System Analyst and programming team).
This dovetails nicely with something I came across on the web the other day. General Office. It's an Open Source Accounting package. Many different modules. Ability to use a large variety of data sources (Access, SQL server, Oracle), although with the source you could use anything without too much problem. Written in VB6, source included. LIcensing options for resellers. I thought "man, we can start with that, customize for the client, and it'd be like doing a whole custom app for them!" I think this is a GREAT idea.
DO NOT DISTURB THE SE
I could see this being very painful if the person you're swapping out with is not capable with a decent editor or is a really slow typist. I know this has been one of my pet peeves when programming in pairs/groups in the past.
Cheaper still at buy.com. http://www.buy.com/books/product.asp?sku=30549158
I'm not saying that XP projects can't attain this level, but it certainly isn't a necessary result either.
XP is (thankfully) far less verbose than Humphrey's CMM.
Caveat: I was one of the technical reviewers of the book. (Yes, Kent misspelled my name.)-:
... often much faster.
... A methodology that doesn't address the need to redesign ...
I see some big problems with the technique:
There are concerns about when and how to apply XP (Kent raises some of them in the book), but your response based on the review is off base.
I haven't "done" XP; I have successfully used some of the practices Kent calls for as part of XP. Here's my experience on how some of those practices work.
no individual code ownership: this seems to suggest that the design would either be imposed from the top, which implies that coders would be treated as unspecialized labor, or that the entire team would be involved in the design of every piece of the code
No. Lack of individual code ownership is one of the extreme practices, but neither of your deductions is correct. The design is fluid (as it is with any working method); no one is forbidden from making changes (there's no code only I can touch), but no one [pair] makes changes without understanding the code as proven by the fact that their changes must pass the existing unit tests and must be supported by additional unit tests created before or at the same time as the changes.
Lack of code ownership is controversial. I work in a project with a couple hundred thousand lines of code, and half a dozen programmers, that makes it work just fine (not using XP). I work alongside a much larger project, with hundreds of programmers, that also works that way.
new team members: the review asserts that "New programmers can also be brought in and up to speed much more quickly." but doesn't specify how.
By pairing new members with more experienced members. (The new member "drives" most of the time, so the information flows through him or her; he/she's not watching, but doing.)
debugging in pairs is a good idea, and should be used by any programming team that has the personnel to spare
No no no no no no no. Programming in pairs is *not* just about debugging, and is NOT about "spare" staff. When it works, two people programming (designing/ coding/ testing/ debugging) in pairs work faster than the two individuals working together
XP (and refactoring, as described in a book reviewed here a few weeks ago) calls for generating huge numbers of unit tests, completely automated, that can be run at the push of a button, and which are run several times per hour by each pair. That's where your coverage comes from.
design to throw one away
XP calls for continous refactoring of the system "to work around mistakes and compromises made when" developing, not disposable prototypes, but earlier versions of the system.
Most programming projects don't have the latitude to set prices for each feature
Each feature will take as long as it takes. XP suggests ways a project can learn how to better estimate these "prices", and spell them out for the customer. Any project, XP or not, where the customer says, "You say this will take six weeks, but I need it in one, so you'll have it in one week," is doomed anyway.
Stupid job ads, weird spam, occasional insight at
Caveat: I was one of the technical reviewers of the book. (Yes, Kent misspelled my name.)-: Funny coincidence: I got my copy of the book Tuesday, just about exactly when the review was posted at Slashdot.
... not yet, anyway.
I can't find fault with anything in particular with the review, but to me it doesn't capture what makes XP so, um, extreme. Here's my take.
XP is a lightweight, high discipline method (to quote Alistair Cockburn). You don't write a lot of documents; no "Victorian novel" requirements boat anchors. What you do, you do all the time; no "cowboy coders" (despite what you might guess from this or other reviews).
What you do in XP:
o Programming in pairs: No one designs, codes, tests, or debugs by themselves. There's an incredible gestalt you can take advantage of; if you've done it, you know what I mean. (If not, read the book.)
o Unit tests: Hundreds, thousands of them, more every time you make a change, run several times an hour, all available at the touch of a button. The idea is to save time, not spend it; if you make a mistake, the unit tests have a good chance to find it fast.
o Refactoring: Don't design or code your system to do what you think it might do; instead, implement the features you're working on currently, but be willing to go back and refactor it (make big changes) "just in time". You're not making the smallest, simplest change each time; that leads to the evolution of unmaintainable dinosaurs. Instead, you're creating the smallest, simplest system that does what you need it to do, even if that's big time different that the smallest, simplest system that does what you needed last week. (How can you be sure you didn't break anything? Hit that "unit test" button, early and often.)
o Low tech project management. Break the project down into "user stories" (use cases); track the estimates and actual time for each; learn what your project's "load factor" is, and how to improve your future estimates. Gantt chart weinies need not apply.
o Short development intervals; incremental releases every few (two to six, often) weeks. Avoid the "90% done" disasters. Yes, this is in the spirit of what Grady Booch calls "spiral development." (Does anyone still think they're following the "waterfall" model???)
o Teamwork. Kent doesn't say so, but XP's not likely to work for programmers who punch a time clock (though he strongly encourages working only eight intense hours a day and then going home!)
XP is a very new method. There's not a lot of track record, sucesses or failures, out there yet. Consider it for a project with three to ten developers and the need for having something minimal working fast, and more features on a regular basis after that. (Read the book first!) Don't bet your next hundred developer project on it
Stupid job ads, weird spam, occasional insight at
Because no one does it!
Let's get real. Most Code-Review is a waste of time. Hours and hours of person time is wasted in what seems like should work, but never has.
What usually happens is a bunch of people sit around, looking at code listings, making superfluous comments about style and imagined execution. They are as a whole, unable provide ANY meaningful value in terms of evaluating context or correctness. IMO, the only result is mass MEGO.
This thread just proves that most "slashdotters" do not live in the real world. Try working for a living for and you'll quickly see that most thing you do code-wise make little sense, and most of the time its not your fault.
Because no one does it!
Let's get real. Most Code-Review is a waste of time. Hours and hours of person time is wasted in what seems like should work, but never has.
What usually happens is a bunch of people sit around in endless dreadful meetings, looking at lifeless code listings, making superfluous comments about style and imagined execution. They are as a whole, unable provide ANY meaningful value in terms of evaluating context or correctness. IMO, the only result is mass MEGO.
The question is, "Is Code Review Good?"
I believe it is in theory, if it worked, but in practice it doesn't.
So I believe the answer is, do it all the time, not as an exercise in seeing how many people you can get to come up with different opinions on where to put a curly brace!
How do you do it to make it work? How do you do it to make it work all the time? The only answer I have found that actually works is Pair Programming.
Don't trust your programmers to know what they're doing? To work cooperatively with each other instead of building cowboy kingdoms of knowledge? To share their knowledge and take the time to do the most difficult of all programming tasks: communicate?
The answer my friends is simple: If you don't trust them, FIRE THEM!
And So It Goes
And So It Goes
Sames
Sorry about the double post,
And So It Goes
And So It Goes
Sames
Isn't it interesting.
Isn't it interesting that all through our school years, we are told over and over that working WITH another is cheating. And what happens the first time we get out in the business world? We're told "We want team players!"
But we have no experience in doing that. So, as programmers, we talk the talk of "Team" and Tony What's-His-Name and sharing and empowerment, but the moment we start to work, we revert to the Cowboy ethic, which is, after all, the only thing we know.
The very idea of Pair Programming and Communal Code Ownership is so foreign to us as to not even make sense to us. It doesn't seem rational much less possible.
So we just say "It Doesn't Work", "It's Less Productive", "If Only We Did Right What We're Doing Now, We Wouldn't Be Talking About This Idiotic Fantasy"
And there in a nutshell is the problem. XP is an attempt to define a process where "YOU" are truly empowered, not just some lip service where in the end you just go back to your closed door office and pound the keyboard, Twinkie and Latte in hand.
"But Sharing Gets Me Nowhere!" you say in the quiet of your mind. "Power and career advancement does not come from sharing." True enough. In the "Real World" it comes from having knowledge and demonstrating ability that others do not have. This XP stuff all seems like some Utopian world where everyone knows the project that they're working on, can help anyone on their team with any part of the project, can be unafraid to attack a new or old part of the project that they've never seen before, to try new things all the time without worry that it will break something.
Yup. It's purely the things dreams are made of. Except... Except... It works. When all is said and done, and you do all of the practices, and you put your pride on the line that you will do the best for the PROJECT and the PROCESS as a whole instead of your small corner of the world, it works.
But that would be cheating!
And So It Goes
And So It Goes
Sames
Yeah, I'd like to see one too.
Haven't yet in 20 years in this business. I have time and again asked my Colleagues over the years if any one of them have seen one, but they haven't.
So I no longer believe they exist, any more than the Tooth Fairy, Hanukkah Harry, Compassionate Lawyers or Honorable Politicians.
That's why I support XP. It finally puts to rest the notion that what hasn't yet worked, should work, and will work, if we only somehow believe it harder... Maybe by clapping our hands together and chanting "I Believe In Detailed Specifications... I Believe In Detailed Specifications..." until Tinker Bell comes back to life.
Detailed Specifications are like UFOs. Some people want to believe they exist, and that someone out there has actually seen them. However while the evidence doesn't stand up to the light of day, it doesn't seem to diminish the large amount that is written about them, nor the hope that someday we'll prove they actually exist, despite the government cover-up.
It's too bad you don't consider work 'coding for fun.' It speaks volumes about the failure of the processes and procedures that pervade the industry. For me, its always fun. So much so, that I don't feel the want to hack at home much anymore. As a matter of fact, I tend to dislike it because I don't have anyone to work with. But then, I'm a consultant, and when I find a place that isn't fun, I just move on.
And So It Goes
And So It Goes
Sames
Studies have already shown that pair programming produces as much code as two people working separately. But the quality is much higher and that saves you time in the long run.
XP achieves everything CMM Level 5 calls for, except killing large numbers of trees. If XP's not Level 5, it'll do until something that is Level 5 becomes practical. See Ron Jeffries' XP CMM comparison for more reasons to think XP is what's worthwhile about Level 5.