Slashdot Log In
Go Extreme, Programmatically Speaking
Posted by
michael
on Thu May 10, 2001 06:55 AM
from the two's-company dept.
from the two's-company dept.
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.'"
This discussion has been archived.
No new comments can be posted.
Go Extreme, Programmatically Speaking
|
Log In/Create an Account
| Top
| 259 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:XP Journals? (Score:3)
1) Write unit tests before writing the actual class. This works great because I can initially lay out what I want my component to do, and if it changes then I just change the test then go change the component. When all the tests succeed the component works and I am done.
2) I have not yet tried this extensively but I understand it in the XP sense. Pair programming is not one person programming with the other watching over their shoulder. It's two people working together on the same problem. Maybe one person has an idea they want to try so they take the drivers seat for awhile, during which the other person thinks of something and suggests it, or maybe he takes over the coding for awhile, explaining his idea to the other person all the while.
3) Requirements gathering.. XP has a pretty good approach to gathering requirements and estimating the time it takes to do a task. I'm not an expert on this aspect so I won't go into it in detail, but it is basically the development team works with the customer to define what is required, then the team comes up with estimates, the customer then helps determine which features are top priority. I think this is pretty common in most processes, but XP so far is the only process I've really thoroughly explored.
4) YAGNI+refactoring (you aren't gonna need it), basically XP states that you don't waste time planning and designing for things you do not presently need. If sometime in the future the software needs something you haven't accounted for, you refactor what you have to allow for the new features. This reduces bugs associated with programming for future requirements that you hardly understand anyway, that may or may not actually be needed. Then when you get to the time you actually need the thing, the requirements have probably changed or solidified and what you originally wrote is now useless.
5) Refactor mercilessly and continuously. If you know what your writing is crap, and you know how to make it right, then stop writing crap and make it right, regardless of whether or not it requires a little backtracking. Read Martin Fowler's "Refactoring" for a good text on this.
RE: Design -- Another thing I've noticed a lot of people saying is that XP completely throws out upfront design. This is not true, it just places less emphasis on it. I still do UML diagrams before I start coding, but it's not so that I can put it in a document and give it to my boss. It's more of a tool for me to play around with different ideas to come up with an approach to how I'm going to solve a problem. Once I think I understand it, I stop diagramming and start coding... if I get stuck, I go back and start diagramming again to kind of work through the problem in an abstract sense. For diagrams to publish, when my software is finished I will usually go back with a tool that will construct UML diagrams out of the actual code, then clean up the generated diagram, and that is what I end up publishing.
XP a threat to the "Design Elite" (Score:4)
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.
This seems to be what we're doing.. (Score:3)
We don't do pair programming (I'd like to try it some day), but I do find that development is carried out much in the style of XP, especially on web sites.
The customer identifies what they want. The programmer(s) then examines their demands and tells the customer how long each feature will take. You don't say "impossible", you say "we can do it, but that part will take 50x as long as everything else". Since they're paying, they decide what order they want to do things in, and what they can live without. ("oh, I had no idea this feature is so difficult. Nevermind."). Think 3 month plan.
You deliver what they asked for. The customer reviews the deliverable and reports any bugs or whatever they don't like. This is determined by managers to either be new work or a mistake. Then, the next phase begins anew. Customer submits a list of features, you estimate time to complete. This time around, the features they're interested in may go in a totally different direction after they see what you've rendered.
The biggest problem is that the codebase you're developing tends to gravitate towards many different goals, and thus design decisions you made early on may be irrelevant now. After every 4 or 5 development phases, the customer has to realize that you have to take 3 months and consolidate all of the code you've already written. Otherwise you proceed towards chaos.
This seems to be how our sites go. They happen this way because the customer usually wants a site up immediately and can't wait 2-3 years for their grand vision to take place. It seems to work. They're making money, the code isn't terribly unmaintanable. We just kind of gravitated towards this naturally. I've only started hearing about XP very recently.
You still reserve the right to tell customers a flat out no. You're not aimlessly following their demands. They should trust you (since they're paying you) and in this, they are usually understanding of what you say is a good and a bad idea. The managers are there to translate your statement from "Moron. That's a terrible idea. It'll never work" into something non-offensive.
Oh yes it can...Re:XP code can never be broken! (Score:5)
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)
Re:My perspective on XP (Score:3)
>> the documentation I'm producing is very well recived by the development team.
Ok, you scared the hell out of me.
I hate it when you get a combination of
- a designer who doesn't developer and
- developers who don't design
Tht developers must be involved in the design. They need to be talking about it, thinking through it, and ultimately making the decisions about it. If they're not, they wont buy into it, they have less chance of understanding it, and the likelihood is a less well written piece of software.
Obviously keep someone around who has good design skills. Make them available as a tutor, a guide, a reviewer or a consultant to the developers. But let the developers create the design, reach concensus on the best approach and then go ahead and write it.
Speaking personally about the project I am just finishing, the developers on the project thought through the architecture, bounced a few ideas off the other users of the final solution (it's a technology solution, so good integration was an essential) and then we sat down and thought about the OO design of the main software deliverable. And a couple of hours later we had a piece of paper with pencil scrawls on it, which got pinned on to the board of our pair programming area.
That piece of paper is still there 3 months later, still describes 7 of the 8 major components in the system, depicts their relationship accurately enough that it's not technically wrong, and we're only just next week going to redraw the diagram so we can hand the code over to the support team.
Now I'm not pretending that the only design we did was on a single piece of paper. But the rest of the design was discussed initially in the pair doing the programming on that area, and if necessary by the team as a whole. There were a whole ton of issues that were resolved in this way, including performance considerations, security concerns, and a lot of the run of the mill "so just what does this object do?" type questions. And swift decisions were made, only one of which has so far proved wrong. [That decision was how on much functionality to include in a base class. We abstracted too far and need to refactor a base class and its immediate specialisation to create a single class - hardly a major design flaw.]
Incidentally the system isn't the simplest I've ever written - securely handling financial transactions in a time critical environment for several hundred concurrent users.
So to get back on topic, had we been developing to documentation provided by another designer, I'd have quit the company by now and we wouldn't have any software to deliver. Instead, by using experienced software engineers to assist and guide and making sure the development team knew their design patterns, we have created a fine piece of software. Trust your developers, they're better than you think.
~Cederic
Re:Programmers write the Unit Tests? (Score:3)
Programmers should always write unit tests. Most don't (in my experience) but they should.
However, in XP a programmer never tests his own code. TWO programmers test THEIR code. Which means that while one is writing it, the other is sat there thinking of other ways to break it. And at the unit test level, this is highly effective.
System level testing (I'm going to avoid the "what is system/integration/uat/etc testing" debate) still needs to be done, and should not be done by the programmer responsible for the code. But in XP those tests are determined and designed by the customer, not the developer.
~Cederic
Re:My Take (Score:5)
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
Quick Q: Who is chromatic? (Score:3)
What's even weirder is that even his resume [wgz.org] doesn't contain his real name!
Unless this person legally changed his name to 'chormatic', this is just a bit too eccentric for my taste. Anyone got some insight?
PS: I'm asking this because I'd like to know who exactly am I criticizing when I'm placing comments on someone's reviews.
Re:XP code can never be broken! (Score:3)
The book wasn't designed. He just kept adding chapters until it passed all the tests. :^)
References (Score:5)
However, decent references are sorely missing from this story, like for example
the book by Kent Beck [fatbrain.com] and one of the more comprehensive web sites, www.xprogramming.com [xprogramming.com] by Ron Jeffries, with links to a lot of other resources on XP.
My perspective on XP (Score:3)
I did like the idea of generating a test case and coding to it. I think that in a lot of cases regular regression testing can save you big hassles down the raod.
What I didn't like was the "design as you go" concept. I can't imagine this doing anything but biting you in the ass, lots, really hard. A lack of design and forethought can only create a huge mess as soon as you try and extend anything.
I have a theory were this idea comes from. A lot of the design work that goes on in projects is done very poorly. The design as you go approach is a reaction to it. Its' pretty common to have a design team that spins its' wheels, goes off into rediculous tangents and generates reams of paper without seeming to acomplish anything tangible. This is really a common thread in my experience and a lot of other people's I've talked about it with. I think this happens because design work is really hard, its' way too easy to get stuck. Many of the people that work on design teams or as application arcitects have no buisness filling that role.
Good application design is really its' own disipline. I'm working as a design guy in the very early stages of a project right now, the first time I've done this kind of work. To my own surprise I seem to be pretty good at it. I'm able to keep the work moving, hitting the milestones I've set for myself on time and the documentation I'm producing is very well recived by the development team.
I think its' unfortunate that this approach to design is becomming more popular. I think if people made more of an effort to understand the design phase of a project and get the right people working on it they'd be way better off. To many really bright programmers get stuck doing this kind of work as they gain more experience and some of them just aren't any good at it.
AAAARRRRRGHHHH!!!!! (Score:5)
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*.
Err... (Score:5)
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..."
My Take (Score:3)
1. Stupid, stupid name. Guaranteed to turn off management and mature programmers. Extreme sports = risky and dangerous. Extreme Programming has the same connotation.
2. Some aspects are just good development practices - frequent unit testing, constant customer feedback, code review - that we should all be doing anyway.
3. Some aspects are worrysome, especially the idea that one shouldn't design up front. As far as I'm concerned, we should always start with a thorough requirements spec and design, but we should always be ready to make changes to the spec and design in response to customer feedback. XP wants us to develop requirements and design as we go - to skip design and jump to the change process. That might work on small projects, but on anything non-trivial it's a recipe for disaster.
4. Another worrysome aspect - XP holds that code should be self-documenting and that other documentation isn't necessary. I've been programming for more years than I care to admit here and I've never seen code that was truly self-documenting. I saw some code recently that was written by someone using XP methodologies and it was as obtuse as any code I've ever seen. I pity anyone who has to go in and maintain XP code a year after it was written.
5. Finally, pair programming might work for some people, but for others it will be a productivity and morale killer. It depends on the personalities of those involved. Personally, I can't think with someone looking over my shoulder.
XP looks to me like the next management/development/whatever fad. It will make a big noise for awhile, lots of projects will be started using it, lots of projects will fail, and in the long run, some of the good parts of it (unit testing, feedback, etc.) will be added to our utility belts and the rest discarded as it should be (esp. the stupid name!).
Your Management Skill (Score:3)
I think these comments reflection on your [lack of] Management ability rather than your programmers [lack of] ability. If your Engineers are consistently getting their estimates this wrong, YOU must be at fault.
I can imagine the scenario; after reading the email request from your customer, you print it out and walk over to the guy's desk, hand over the print out and ask how long; you stand over him whilst he reads the email and when he gazes at the roof in though, you hit them with it. How Long ? He um's and arh a little and you repeat a question. They respond, with a figure they know will make you go away.
As you walk away, your think to yourself; these guy's always get it Wrong. So you think to your self, no he can't do it that quickly, so you double (or triple) the estimate and enter in your plan (I'm giving you the benefit of the doubt and assuming you have a plan). Some times you think it's too long; the Customer will never go for it, so lets half it, and enter that in the plan. So not only have you not given the engineer a reasonable chance to consider the question, you ignored his response.
Result, your programmers only ever make the plan by accident, and you believe programmers cannot estimate.
My team, (of which I'm the senior Engineer, not the Manager) has just made three Project plans, with time to spare and exceeded the requirement (by including lower priority deferred requirements). Now this is not because I'm (or anybody else) is some super coding or team leading guru.
It is not even difficult, it just takes discipline. Firstly we clarify and digest the requirements. We chew over the requirements, and a few implementation details, to make sure we understand them. We conduct and document the design at high level. We can usually count the function points, by now, this gives a raw estimate. We factor in detailed design, testing and integration, based on the number of function points to produce an highly accurate estimate. We factor in a contingency; all this takes a couple of days. The customer gets estimate they can believe. They even start to really listen to you, and trust your judgement.
Re:Not practical (Score:3)
Why would the non-XP code already have these functions in place, but the XP code wouldn't? If there was a previous requirement to do similar tasks then the code would be in place in XP. If there wasn't a previous requirement, why did you waste time adding it, rather than shipping what they needed earlier? How much other code is in your software that you don't need yet?
It's possible that the functions were more tightly bound into specific objects rather than in nice class hierachies in the XP version, but if the unit tests are in place for the original functions, it shouldn't take too long to refactor the design to make it more generic (by abstacting out the functions that you are actually going to be using in two places rather than ones that you think might be needed in the future). This may sometimes take longer than the equivilent change in a system that has had major design done up front, but in my experience, the that's more than balanced out by the huge savings in upfront design time and writing these functions that someone might use in the future (but usually don't).
Re:Quick Q: Who is chromatic? (Score:3)
>> I'd like to know who exactly am I criticizing...
Why does that matter? Your citicism of TPKAC's 1 work should not be any different simply because you can pin a face to the moniker. If you disagree with chromatic's work, then do so. Remember, the criticism is only effective when it's offered in response to what a person does, rather than who they are.
Clearly, chromatic values his privacy for reasons that have not been documented publically. I can think of several reasons why this might be the case.
He could be a celebrity in certain circles and wants his technical contributions valued on their own merit or without the baggage of his real world identity.
He might work for an agency unpopular in Hacker circles, e.g. the NSA, FBI, CIA, DOD, or other TLA organizations.
He could be a fugitive from a legal authority or extralegel agencies.
He's been the victim of identity theft and wishes to never repeat that experience.
He knows there are some real weirdos online and doesn't want to open his family or home life to the more aggressive wackos.
Maybe he thinks it doesn't really matter who he is.
He could be a conspiracy theorist waiting for the MIB at FEMA to trigger the NWO.
Maybe he's small furry green creature from Alpha Centauri. Or maybe he's Hitler's son.
(And, yes, I'm assuming that chromatic is a he, since our language doesn't have an appropriate genderless pronoun. He could be a she; it's happened before.)
Regardless, I strongly suspect that chromatic wants you to focus on what he does, not who he is.
Cope.
--c
Footnote 1 - The Person Known As Chromatic.
Let's just call in Drucker and Covey... (Score:4)
Uninformed comments (Score:5)
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.
Re:Experiences of extreme programming? (Score:3)
I would also not recommend using XP if you are using a team of consultants for the short term. What usually happens first when you implement XP is that documentation tends to become poor. This is bad if the developers are leaving your company next month.
Those XP features that I have seen to be most useful are:
"Pair" programming or rather more extensive code reviews whitout having to sit in each other's lap. Two developers are always responsible for a certain area.
Short release cycles (yes 6 weeks is possible for a major B2B site)
Extensive testing with as much help as possible from an automated tool such as a Build Manager, Rational teamtest etc
Heavy focus on feature prioritization. This will involve people who might not be used to prioritization for short cycles.
Also make sure that you do "sunset reviews" (including the entire team) after each cycle to continually gather feedback on how the previous cycle worked out and how to improve the coming cycle.
All in all it is not that "Extreme" but more like common sense.
Peter
Also forgets about REFACTORING (Score:3)
Good advice (Score:5)
--
Re:Err... (Score:3)
A coder knowing the context is a bad thing. His context ends at the public interface and if he needs more information then something is wrong with the design. If he knows more than the public interface spec then he is likely to use that information (consciously or not) and make assumptions about the environment in which his code will run. In the long run, those assumptions will turn out to be wrong and his code will break.
The most productive environment I ever worked thought about the problem and listed the functions that were likely to be useful in creating the application (we were coding in C).
Once the specific functions were identified, it was considered if they weren't instances of more generic functions. If so, then the generic function was substituted as a requirement.
Then people split into pairs and wrote code to implement those functions without regard as to their application. Since we had a prototype statement and everything had to be explicitly passed in and out, we could. Coding in pairs allowed one person to focus on syntax and typing while the other thought about the algorithm and spotted bugs. If a routine turned out to be more than about 50 lines (without comments) it was mostly likely broken into two routines.
Each "finished" routine was then tested rigorously. Inputs which caused failure had to be fixed or at least caught. All the routines were kept in libraries by religiously using make with ar to keep things synch'd.
Only after all the library routines were written did we go back to the application which was now fairly trivial to write. Using these techniques we were able to write as much as 2,000 LOC of bug free C code per pair per day. Typical productivity was more like 500 LOC per pair per day of bug free code.
By bug free I mean relative to normal standards. Obviously we sometimes found a bug but the rate was something like 1 bug per 100,000 lines of code in the first six months of use, or less. Code that had been in use for more than six months had perhaps 1 bug in a million lines of code and that showed up in the first year. Code older than a year didn't provoke any bugs that might have remained.
Think top down then code bottom up, don't make assumptions about contexts, pass everything explicitly, test continuously (especially unit test - consider making it the last step make does when compiling), use good tools like make, RCS/CVS, ar, or whatever analogues apply in your environment.
Understand before you speak (Score:4)
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.