Slashdot Mirror
Go Extreme, Programmatically Speaking
raelity writes: "The O'Reilly Network is featuring An Introduction to Extreme Programming, by Chromatic (of Slashdot and PerlMonks fame). 'The central tenet is, "Find the essential elements of creating good software, do them all of the time, and discard everything else." Programmers should program and make schedule estimates. Managers should make business decisions. Customers should choose the features they want and rank them by importance.'"
That little blurb about the "central tenet" leaves out the most important key to XP: extensive unit tests, written *before* or simulataneously with the code. Thorough, extereme regression testing is the key to mastering XP. XP with out regression tests, just ain't XP.
A conference on XP will be held in Cagliari (Italy) at the end of May. Info here .
Try bathing, and you'll have better luck interacting with others. Mouthwash would be a good idea too.
This has been my experience with XP so far:
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.
In another not-too-distant-life, I was a senior partner at a firm that championed Object-Oriented design and development. Over time, we found ourselves invited to spend time at more and more large IS organizations instituting our OO methodologies, and designing elaborate object models and artchitectures. I got to speak at big conferences in front of lots of CIOs and IS executives who were too busy trying to shake off their hangovers from all of the liquor our company had bought them the night before to get much more out of my talk than: "That guy sounds pretty smart. Better get his card."
These large companies were paying each of us $3,000 per day - sometimes for months on end (don't get me started about the number of $200/head dinners and first class flights they paid for as well) to have us scratch our heads, and think high-minded thoughts about the true relationships between their domain objects. What were the core logical abstractions at work? What (oh yes!) patterns were at work here?
At the time, we really felt like we were doing good work, and they were thrilled to embark on this road. The experience of most of these companies was a background of hard-to-maintain software and failed projects. What better spoke to the fear of the corporate bureaucrat than an approach that favored more up-front design. If they had failed in the past, it was becuase they hadn't planned effectively. Surely, these dirty just-out-of-college kids sitting in the programmer's chairs couldn't be the ones driving their enterprise software. They were much happier with the thought that a group of gurus in suits with the expensive PDAs and laptops somehow using the invisible hand of an abstract and expensive "design" effort to guide the ship.
When these project collapsed under their own weight, as they inevitably would, we were always able to look ourselves in the mirror and know that it wasn't (thank god!) for lack of a proper design. They had obviously tried to cut corners on the implementation. They had tried to cut out features. They had tried to limit the scope of the effort. No one believed that all business objects needed to inherit from the "DirectedBusinessIntention" class. Whatever. Point was that somehow or another, after thousands or millions sunk into these design efforts, things always seemed to go off kilter.
The best part was that when the management that had brought us in got canned along with us, they landed somewhere else and hired us again! Not only that, but they were a solid project reference!
What a great gig. High pay, high living, no real deliverables (other than diagrams and charts). Want to keep us around so that we can point out why all of the implementation problems are a result of something other than our "design"? You bet! That'll be $3,000 / day.
Today, I live in the world of XP. I roll up my sleeves. I write code. I see real design happen at whiteboards. I see designs get implemented. I see code being released to over a million customers EVERY TWO WEEKS.
Critics point out how flawed XP must be becuase they cut out all of the "design". Surely, this software that's being hacked-together on the fly can't be robust - it must be a maze of hacks that falls apart at the first real requirements change. Yeah, yeah. That sermon's sitting somewhere gathering dust in my book on "Deisgn Patterns". It's right next to my Tufte books.
Turns out that good programmers, much to my suprise, can turn out superior designs through the XP process. Abstractions get built when they become needed - not in anticipation of need. Needs change too quickly - you build only the ones that you need. It's a beautiful process. Design does happen, but it gets naturally prioritized with other requirements. You need to change a large piece of a system? Migrate to another platform? Abstract something to support new lines of business? Great. Figure out how to do it, make a case for it, and do it. Just do it in a couple of weeks.
It works. It really does. It's produced the most beautiful and robust software that I've ever seen a large team produce. If there's any downside, it's that it requires really good programmers. It's not a methodology that is well-suited for a situation that supports people who are, for the lack of a better term, "vocational" programmers, or tool-users. All of the developers in an XP project must be able to tread deeply into all aspects of the system.
So, it's no wonder why the people who still stand in the (nicely polished) shoes that I used to wear have a vested interest in attacking XP. Long-term upfront design efforts were (and still are for some) a lucritive gravy train. These folks will try to defend their position through fear-mongering (which works really well in big IS shops). Wherever there's doubt, there's always some extra money around to do some more evaluation. If the design-elite are really lucky, their sponsors will find some money to perform a methodology-evaluation! And who is really better suited to do a methodology evaluation than the design consultants? I wonder what it's results will show?
Oh, while they're frittering away months evaluating methodologies and designing logical and software constructs which may not be needed and will likely never exist, we'll have gone through dozens of major releases of our software. It's feature-set will have evolved to provide tons of dramatic new features that make us actual revenue.
It's not that I don't miss it. I really do. I honestly felt much of the time that I was better than everyone else becuase only I (and my elite friends) had the cranial mass required to really peer into the soul of our client's busienss and understand. That was a pretty good feeling. The $3,000/day and all of the free steaks and booze were okay too. Still, I'd not go back. It's just too darned rewarding to see my work being used by a worldwide audience - to see the ongoing transition from thought to feature happen in weeks instead of years (or never).
If someone's telling you that XP is doomed becuase it is design-poor, just think about why they're telling that to you.
So the jack-booted thugs come over to my desk and say "Hey, there mister emacs-using dvorak-typing linux geek...you're gonna switch to windows 2000 and JBuilder. And you're going to start typing in qwerty like everybody else so that you and Marty can pass this here keyboard back and forth effectively."
Are there any XP advocates out there willing to allay my fears?
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
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.
I hope you're not suggesting that Drucker's works are facile and meaningless. Otherwise, you've pretty much destroyed your credibility with anyone that's followed his works over ther years.
-Stu
... for their actions.
If a customer makes a bone-headed requirements move, he or she has the freedom to fix it by reprioritizing. When a customer is in the driver's seat, their own problems in defining what they want and when they want it become more apparent...
...which is why XP will probably fail quite often. The customer must speak with one voice... and in a CYA culture, that's usually not the case when multiple vested interests are involved.
On the bright side, the development team gets to actually *deliver* stuff, and is somewhat removed from the area of incompetence (though there's no shortage of incompetent programming teams..)
-Stu
...or maybe they realize that Kent Beck is a software developer with a pristine record of developing great software and being well respected within the Smalltalk community?
And WTF is a "REAL" software engineering text?
You seem to be falling into the typical trap of being cynical over something without even trying to understand its motivation, history, or intent.
-Stu
Nice to hear some authentic experience. I'm very happy about XP methodology, it's the directon I've been moving in for years, but you meet huge resistence when you can't call it anything except common sense and experience.
After 12 years OO development, and dozens of large successful projects I felt I knew something. In particular I knew that huge hierarchies of interacting ill thought out classes were a far greater pain in the ass than a bunch of flat C code. Then, suddenly you couldn't write OO code without it being designed by a bunch a wankers, with their copies of RR, their GOF Design Patterns book, drawing UML shite everywhere, but knowing fuck all about programming. People would show off their "OO design" skills by proposing 40 classes within 60 minutes of being introduced to the problem. "Ooh, we'll need a Factory here and an Actor there, and..."
http://rareformnewmedia.com/
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.
I disagree with this in the sense that, as a systems designer and a programmer (embedded systems), it pays for the coder in me to know what the system is to do as well as what the customer wants for the future. Nothing is worse than blindly following spec and having the customer say "I'd like it to be able to do x" after he sees it and having the codebase set up in such a way that it would be difficult to do. I suppose that is why I am very active in the specification design in the first place so I can try to see the future of the project and communicate my ideas and possibilities for future-proofing the desired system.
Modular programming helps this immensely but in my professional opinion having a programmer who's making code to meet "just a bit more" than the bare spec is essential. Of course, that "just a bit more" is very hard to quantify.
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.
I too am a big fan of this type of design or "software design/flow specification" -- it's created from the spec, usually started before the main specification is completed so that the two can be juggled back and forth in order to create a robust system.
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.
Again, I agree totally. Your description of small functions with well defined entry and exits (and data dependencies too) makes it very easy to test rigorously. And in time you build up a very impressive general library of functions for future products. I think this is where I start to come apart from XP - modularity and making functions generic enough to be reused instead of recreated all the time. That, and programming pairs would bug me.
When I program I get into a very peculiar frame of mind -- part of my head as the top-down overview of the entire system and the other part is actually laying down code. The top-down (I call it the angellic point of view) part of my brain keeps the functions' use in mind and guides how the functions themselves are written. Having someone stand over my shoulder and ask questions would drive me insane.
So, yeah, well "duh", but I do think the industry's in a "duh" state.
The other important aspect of XP is that it also removes techniques that don't work or aren't worth the effort. Although the programmer is expected to write test cases for *everything* before they write production code for it, XP tries to cut through the artifacts of other processes like big Word docs and Visio charts that nobody reads anyway and ends up being obsolete soon after being written.
Yeah, sure, I can understand the objection about its obviousness. So shouldn't you "obviously" use XP, then? Can I assume you're personally using XP's specific techniques?
Refactoring (the technique used to deal with changing requirements like this) depends on the programmer having extensive unit tests and therefore being able to trust the code as he changes it. XP specifically disallows knowing "every aspect of the application", because the planning phase doesn't even specify the functionality that far into the future.
Your anecdote is certainly interesting, but is this a real-world example? Are you saying this actually happened every time to this guy, or just that one time? Was he using unit tests extensively and refactoring as he went?
1b) they're only supposed to present a paragraph of 1-4 sentences anyway, so all Stories are only going to be an overview. the team makes an estimate based on this information, with a granularity of one man-week, and asks the customer for more info if they need it.
1c) if it affects the estimate, then the programmers say "that affects our estimate. here's our new one. you still want it?"
XP puts the customer and the programmer on the same team, rather than an adversarial position. It's in the interests of everyone to get the project out the door, so there's nothing wrong with negotiation. The programmers can't override the business priorities, and the customers can't override the estimates. So the rules of engagement are quite clear.
Like all methodologies, xp has some good points and some impractical ones. I prefer not to choose any one methodology, but cut and paste from many to suit the environment I am in (kind of the flavor of the project). If I had to think of some core habits, it would be:
coding:
- decouple your classes (if using an oo approach)
- unit test (easier when decoupled)
- document the class behaviour in a paragraph or two
- biggest pet peeve is deceptively named functions. i hate functions that are called getSomeName() or isSomeCondition() that do more than return a value or state - they go ahead and change the state of the object. yuck.
- persistence layer should be abstract to your business logic
management:
- participate in scehdule creation.
- email a task as completed only after unit testing, and code checked into source control (email should got to schedule keeper, and fellow teammates)
my anti xp-isms:
- on some projects it does make sense to keep an eye on whats around the corner.
- i like to code while listening to music. the 2 person coding style doesnt really fit me.
-
Am looking for jobs in Canada (Toronto/Vancouver)
Actually, I think this would *add* value to Microsoft's upcoming OS...
In any case, the extreme programming people had the acronym first.
Fine, but I want to be the first to publish "The Idiot's Guide to 12 Steps to Programming Your Way to a Slimmer Healthier You For Dummies".
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
But where XP can help recover from this is that the atmosphere for testing is still there. When an integration or enduser break happens, the inputs can then go back to the programmer to create a new test case and fix the code by making that test case do what should have been done.
So its still possible to have broken XP code, but at the same time, the fixing of it should also be easy...
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
I've got a copy of Extreme Programming Explained in front of me, on the back cover it says:
-- Ed Avis ed@membled.com
Heck no. Unit testing has always been (and should always be) the responsibility of the coders.
But even so, that's irrelevant. You will find it tough to get programmers to try out unit testing, XP style, but, every single developer I know that has done a project using the XP approach to unit testing has insisted on keeping it on his next project - even if the next project isn't following XP.
Programmers love unit tests. See the JUnit.org website for a document describing this. Consider me to be living proof - I hate testing but I now insist on writing unit tests for my own code.
~Cederic
I would agree with that, although we've found that our unit test suite includes what would normally be described as integration tests. We have a few tests that actually test a process flow throughout the entire system, using 98% of the classes, with variations on those tests making sure different flows are checked. And those tests run 100% every time we run the unit tests.
~Cederic
Two flaws with this:
- you'll both end up changing the same code at the same time. Or trying to compile half-way through the other person's change. It'd be disaster
- The second person shouldn't be writing code. They should be thinking about it. Is the design correct, are they taking the right approach, what unit tests are missing.
~Cederic
Ironically, when I am forced to give a surname in a webform, I enter my name as
Cederic A
~Cederic
>> 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
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
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
While I am a firm believer in not coding alone, in tag-team development and constant review, 'extreme' practices don't insure completeness.
Design is essential to insure the viability of the development effort and documentation is essential to insure the survivability of the implementation.
Who insures that objects with state transitions are able to negotiate transitions forwards and backwards (or that they can''t when they shouldn't?)
The designer has to be able to do a complete job of writing specifications based not merely on what the existing customer base asks for, but on what the objects involved reveal as posibilities.
The clients will come back and ask for those very features when they see the system in operation.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
What it does for the implementation of non-trivial project is very good (and any military project is non-trivial and specified to the n-th degree, which is why they cost so much up front and then disappear from the political radar during implementation.)
The same is true for every major development effort from payroll systems, (would you want your payroll calculated by some if-fy procedure,) to diagnostic expert systems (it takes a major earth-quake to shut down some "million dollar an hour" production lines.)
When developping a 'mission critical, bet-the-farm product which will sell for real money (say a million $ down and $ 5k per seat,) you have to prove that it has been spec.'ed out to the n-th degree and how far along the implementation from design to 'finished' product you are, and what your strategy for getting there is. Extreme programming is part of that strategy.
Clients who spend real money are not buying "'shirk'-wrapped" fluff cobbled together in a slap-dash way.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Sometimes it sounds that way, but in fact the adherents of XP are quite intensely interested in strong designs.
This can indeed be a big challenge.
You want the flexibility and confidence that an XP-ish suite of unit and functional tests all through a project would provide.
But you have either (1) no tests, we just hope it works, or (2) some tests that a testing team goes through manually, and may or may not pick up problems, and take weeks to do.
Solution: Start adding tests. Start refactoring a bit at a time. Get a fast, automatic build running. Add more tests. Add more tests. Refactor a little more. Continue until you have tamed the beast.
Regarding change control, the challenge is to make it really be "control". As organizations get larger or more further up CMM, and projects become more complex, change control often looks a lot more like "change prevention"... the cost of each change gets larger and larger (due to heavyweight processes) that even most worthwhile changes get killed before any work can be done.
A big point of XP is that the sum effect is to make software stay "soft", to make it possible to change even as it gets larger and more complex.
Well, then do you use XP? Your comments are the best reasons to try using XP practices in your development environment.
Personally, I think that if you followed all of the XP practices it would become impractical. However, that doesn't by any strech mean that I throw all of XP out. I happen to think that pair programming would become impractical for large projects, but I think that automated unit test programs run up front from the start of a project would be extremely valuable.
Myself, I don't turn the knobs up to 11, just 7, but at least I know where my knobs are set. Do you?
Ben
If its so common sense, then why do so few people do these things?
pooptruck
It never ceases to amaze me how posters on Slashdot feel qualified to comment on something when it's really obvious that they don't know the first thing about it.
Here's my suggestion: Actually find out what Refactoring is about before posting this kind of nonsense. It's a well-documented procedure and is used by a great many professional software developers. It's not about "kicking crap code to extend its life a bit longer". If it involves crap code at all, it's about making it not crap.
What would you do with crap code if you weren't going to refactor it into something better?
--
Don't imitate. Enervate.
So, you're saying that in an instance where you are unsure of who your customer is, or what they want, then XP doesn't make sense, and traditional methodologies are more effective?
What about instances where what the customer wants changes over time (new business strategy; new tactical goals; change in company emphasis) - how well does XP deal with those cases?
What about instances where the customer changes over time - company X gets bought out by company Y, or (if you're a shrink-wrapped software shop) it becomes apparent that your marketing department fsck'ed up and you target market is not greenhouse managers, but home gardeners?
XP looks interesting, and in a lot of ways, appeals to me. I don't think that it sufficiently addresses some of the edge cases in project management, though; and in the past ten years, every project I've worked on has had some edge case behavior. Inevitably, XP seems to deal with this by saying "Well, those aren't normal software development projects"... when studies by Yourdon and others seem to indicate that they are (take a look at Death March).
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
If there's a point of failure in an XP implementation, this is it.
What's more likely... tht the VP of product development or customer relations will go along with a new programming methodology that reduces their importance in the company, or that any department that feels threatened by XP will do their best to scuttle the effort by injecting themselves into the process as "advisors" who promise features that are impossible to implement, ship dates that are impossible to meet, or anything else that might put those damned uppity programmers back in their 5x5 cubes where they belong?
Except that many, many companies consider ship dates to be a business decision... because the customer is willing to pay more money to see it done more quickly. Many, many companies consider feature lists to be a business decision... because the customer is willing to pay more money to see what they consider essential features implemented. Many, many companies consider the quality of the code a business decision... because the customer will then spend 10x as much money over the next ten years, paying for bug fixes, support, and incremental upgrades that add the feature that was supposed to have been put in 5 releases ago.
In short, many, many companies look upon programmers not as valuable employees, but interchangable assets that can be used to leverage money out of paying customers. There are companies that are different, but they are few and far between... and I think they would tend to be companies that have business, sales, or development models that make XP harder to implement for technical (as opposed to political) reasons.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
Understood... this seems to make XP unusable (or at least harder to use properly) for shrink-wrapped software, though, in that there is no single customer; unless you define the "customer" as the internal sales/marketing team. The overall emphasis of XP seems seems to be on consulting-type development, where a single client is interacting with a company to produce custom or customized software.
Not always true. Where I'm working now, product requirements were laid out before design/development began, and we've managed to stick with them. We're developing a new product, though - one that we think will appeal to our target market for a number of reasons, but which hasn't existed up to this point. How do you ask a customer what they want when they don't even know they need your product?
To be honest, our initial product requirements (generated by business dev) and design goals (generated by development) included the ability to customize the product on a per-customer basis; when we get to that phase of development, perhaps the XP development model will be more effective.
Thanks for the references - I will take a look at them. Mind you, I'm not dismissing the methodology out of hand; from what I've already read, it seems to work extremely well under certain circumstances, when implemented properly. I question it as a cure-all solution for all possible development problems, though. In my mind, XP advocates would gain a lot more credibility if they could enumerate the situations in which XP was not a solution, and explain why, in those cases, XP was not applicable.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
I worked for Trytel Internet for eight months doing web development and left because of the development model they chose to adopt. It's difficult to develop anything modular, extendable and scalable when your customer needs these twenty things next Tuesday.
Now that's not to say that the model is wrong or bad, it's just not what I personally would subscribe to. I like documents stating that indeed we need a certain number of things and we have this reasonable timeline in which to do them in.
The only real flaw I see in the idea of XP is if you have managers who make horrible business decisions then it's kind of a null isn't it? :)
"It's here, but no one wants it." - The Sugar Speaker
Pair programming is NOT the same as a collaboration meeting. I've done development where we did collaboration every 1 to 2 days, assigned tasks, rotated tasks, and everyone went off to do their own thing (no pair programming ... there were only 4 people). On very large and very complex system, I assume there is a point where pair programming is a win. On smaller projects, there certainly is a point where it is a big lose.
Based on a talk I heard recently about XP, it was mostly designed for very large projects, and seemed to also be for those kinds of projects where a customer contracts out for custom development, where 20 or more people are needed.
But the iterative design/code/test cycles are good even on small projects. I know because I have done that, or things very much like that, all through my programming career (without really know a name for it other than "it makes sense and it works"). Many of my projects simply never came back with bug reports, and the rest very few, when I did things this way.
now we need to go OSS in diesel cars
Lots of projects vary in size. The problem with a 5000 LOC project is that contract brokers never take them, so they are never outsourced. There's not enough revenue in 5000 LOC for a broker to mess with. They either get done in-house, or not at all.
But some aspects of XP can still work on small projects. The iterative cycle is one of them. Pair programming obviously is not.
now we need to go OSS in diesel cars
Some of XP can work. Obviously pair programming is a problem with just one person. But iterative cycles do work well.
now we need to go OSS in diesel cars
...there should be someone simular that analyses the business impact of features, and provides guidance to help customers choose the features that will have the most positive impact on their business. I would add to this, that there needs to be someone from the customers side, who has knowledge of the business practices, who can help in the design of the user interface. I have seen functional software (and disfunctional software) which was a nightmare to use all because the user interface (which was technically functional) worked in a manner counter to the function of the end user. The examples which come to mind were a hotel software package and a point-of-sales package. Both were mostly functional, but their user interface was disfunctional relative to the tasks at hand.
In a place beyond time and space, in a land far better than this, look for me there...
The core policy was on page 83 of a book on it?
Man, that's a badly designed book.
We talked about it at work, and took a very small compoenet and test out the XP. And here are the few thing we found...
1. Management just does not like the idea even if the project finished on time. For a small company, for 2 advanced programmer to work on the same project is just not cost saving for today's market.
2. We tried to have one senior and one junior on one project, it end up the senior spending extra time teaching the junior, and resulting in the junior working for the senior instead of working together.
3. The best result was for two equally mached progrmmers with strength in different areas. For example, one is a advanced java programmer, and the other being a advanced sql/database programmer.
I think XP will only work, with proper maching of people and team on the proper project. Management will nver spend double the money even we tell them that the result might be twice as fast, and twice better.
weink dot net
Yeah, that's ture...
But again, we have to introduce methods like XP inorder for us the programmers or managemnts to have another level of choice in attacking the programe of software development.
It's almost like when OOP 1st came out, it sounds like a good idea, but everyone just say "it's a good idea, but it will never be used or work." Well, time has changed, and I hope XP can break through and do the same.
weink dot net
It's just way too weird... guy publishes on slashdot and on O'Rilley + has an open source project called Jellybean but he never uses his real name?
What's even weirder is that even his resume 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.
> Having read many articles on XP, I am still left wondering exactly how it is implemented. Programming in pair could mean many different things -- but what /does/ it in the case of XP?
Ever hear how the Spartans and the Theban Sacred Band used the "buddy system" to acheive their elite status?
Same kind of thing here.
--
Sheesh, evil *and* a jerk. -- Jade
> It is gaining acceptance in the software industry. One indication of this is the number of talks on XP at the SD2001 West conference in San Jose 8-12 April.
Or maybe that just indicates the intensity of the hype surrounding it.
I wonder how often we'd hear about it on Slashdot if it were called Quality and Productivity Assurance Methodology for Software Development instead of eXtreme Programming.
--
Sheesh, evil *and* a jerk. -- Jade
Sounds intruiging. So why has there never been a slashdot story on Extreme Programming before?
;-)
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
He has a link to his thread under "Who am I?"
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
First, let me say that this is *not* an advertising.
Have you ever heard of a little company called TogetherSoft? Their product, Together, lets you keep your design and code 100% in sync constantly! As you develop your model, the tool is actually writing code. When you write code that effects the design, the model is updated. That simple.
So, to say the least, I have to disagree with you 100%. Process instilled modeling CAN work -- it just needs to be easier than tools like Ration Rose make it out to be.
As I understand it, not only does XP not encourage you to design for re-use, it does not allow re-use outside a single project, since that would violate the principle of providing only the simplest possible code to pass a test.
As far as I'm concerned XP is an inherently broken methodology. Then again, as far as I'm concerned, so is everything else, so why not use XP anyway? ;^)
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
I don't have much XP experience, but *good*. You're supposed to think up the unit tests that break your code - then fix the code so that it isn't broken any more. When you can't think of any more tests, the code works.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
That would be true if XP was expected to handle all testing through this mechanism: however it isn't, or at least not in any practical application of it that I've ever come across. There is no replacement for real testers, the evil sort with black waxed moustaches who spend half their time tying maidens to rail tracks, and the other half crashing your finely tested code.
Of course, XP makes better use of these testers than many other methodologies: as soon as a tester finds a way to break your program you don't fix it. Instead, you write a test that demonstrates the bug, and then fix it. As a result, the error won't arise again.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
That's not the XP model, though. There you write the test, and then fix it as simply as possible, then write the next test. There isn't any code to stress and break until after the test has been written.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
The book wasn't designed. He just kept adding chapters until it passed all the tests. :^)
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Programmers program and schedule estimates and then miss them by a factor of 3.
Managers make business decisions based on incomplete or incorrect knowledge and then make excuses.
Customers choose the features they want and complain when they are delivered that they weren't what they wanted.
Seriously, if the summary given is the gist of "extreme programming" (do I need to wear knee pads to do it?), then I guess it sums up to.
Extreme Programming: Practice Common Sense
Granted, a lot of people don't practice this, but it's hardly a revolutionary concept.
You are in a maze of twisty little passages, all alike.
This morning when I read that line about "Find the good stuff and discard everything else", that's what I thought of. You're probably not going to use good XP all the time, unless you are in a situation where you always have to be screaming through space in the most efficient way imaginable. I mean, you can make a space ship go faster by doing things like jettisoning fuel and cargo, but you don't always do that just because you can. Sometimes you have to decide how extreme you wanna get based on the ultimate goal of your efforts.
www.HearMySoulSpeak.com
"Programmers should program and make schedule estimates. Managers should make business decisions. Customers should choose the features they want and rank them by importance."
If this is truly the way that XP will be implemented, and I don't doubt that in most cases, it is, it is a recipe for near useless software dripping in chrome.
The fundamental problem is that customers don't know what they want, and if they do, they envision it within a very narrow context rather than what is possible and do-able. This in no way devalues their input, but the key to a really good software design is vision. The scenario described above has compartmentalized vision as outside the scope of all three groups of players. This is why we need software architects that can bridge the gap and have some idea of what is possible.
Case in point: A few years back, I pitched a proposal to a title compnay that had an extremely advanced workflow system that was extremely well-tuned to their needs, and gave them a cost structure and response time *much* lower than their competitors. Unfortunately it was based on an old non-Y2K-compliant version of NeXTstep, so it had to be rewritten or replaced. Even though they had a system in house that met their business needs perfectly, they were not able to adequately define their needs. Also, they were concerned about document file formats, since the documents need to remain usable for decades. I realized that what they really wanted was thier current system modified to protect them from file format horrors, and we proposed a OO re-write of the existing code to include TeX or SGML-based document formats.
The point is this: Neither the programmers, the business people, or the customer knew what was really wanted or required - it took a vision of how the entire thing should work to come up with the solution that all three agreed was what they *really* needed.
Finally, it seems to me that XP is still doomed as a way to write breakthrough apps simply because it generally pushes big developmet groups and flies in the face of Bill Joy's smallness principle: Good software is never written by more than about six people. You can have a bunch of others testing and whatnot, but all the design decisions need to be made by a small group, or you're toast...
"The future's good and the present is nothing to sneeze at." - Roblimo's last
Mmmmh... I used to think so, but it's not always true. The current trend, as I can see, is that (at least for some managers) it is better having something quickly packed together and half working today with the promise of making it fully working tomorrow than having something well designed and fully working, but not before the next week. In other words, there are people out there thinking
- good code/design == works well == more time
- bad code/design == works enough == less time
- bad code/design now plus good code/design after == good code/design
which, unfortunately, is not true.So, while I'm agreeing with you, to some people it is not so evident that a coder should write good code...
Yes, I am. I'm pretty well known for being critical of XP, but even if I thought it was great stuff I'd still be tired of it being pushed so relentlessly here by biased editors. There are other methodologies out there worth reading about, and at least half the audience is incapable of making an informed judgement about the benefits of XP anyway. It's almost enough to make me wonder whether the people pushing XP so hard here have some sort of vested interest.
Slashdot - News for Herds. Stuff that Splatters.
That's a bad idea, actually. If the code is written to pass tests instead of to meet requirements, then *at best* it will only meet requirements to the extent that the tests *accurately and completely* express those requirements. Any bug in the tests will end up being reflected in the production code. Production code should be written directly to requirements, period.
That doesn't mean that requiring tests isn't a Very Good Thing, though. In an ideal world, there would be two full sets of tests for production code. Unit tests should be written by people intimately familiar with the production code, to probe weak spots in the structure of that code. Acceptance tests should be written by people who do not know the structure of the production code, directly to requirements. This helps to ensure that production-code programmers' blind spots don't skew the whole testing process, and also allows using the same acceptance tests for a totally different implementation without loss of efficacy.
Note that unit tests should still be based on the production code, not the other way around, and the production code should be written to the requirements, not to the acceptance tests. The first question when a test failure occurs should always be "Is this a failure against the test, or against the actual requirements?" If the answers are different, the next question should be "How can the test be improved to more accurately reflect requirements?"
Slashdot - News for Herds. Stuff that Splatters.
I've seen it done a bunch of times and, in my experience, no, it doesn't. It often seems to, though, until the product gets into the field.
XP, with its emphasis on constant refactoring, even makes the problem worse. Good unit tests are targeted toward the actual structure of the production code. If you wrote the unit tests first, then refactored the production code ten times, you wasted a lot of time writing unit tests that had nothing to do with the structure of the production code. *Acceptance* tests are the ones that are implementation-independent, and XP has precious little to say about them.
Slashdot - News for Herds. Stuff that Splatters.
Congratulations. You're the first XP proponent I've met who was able to make even one valid point. I stand corrected wrt acceptance tests being part of the XP canon.
That doesn't change the fact that it's a bad idea to let the unit tests drive the code instead of vice versa, though, for all the reasons I mentioned in my original post.
Slashdot - News for Herds. Stuff that Splatters.
"Specification written in the form of executable code" sounds a lot more like an acceptance test than a unit test. It probably doesn't matter, though; IMO even writing toward the acceptance tests is a mistake (though perhaps not as bad as writing toward unit tests). The tests are *not* the requirements. Obviously the former should reflect the latter, but it's no more possible to write tests that perfectly match requirements than it is to write production code that perfectly matches requirements, and if we could do that then we wouldn't need acceptance tests in the first place. There *will* be differences between the requirements and the acceptance tests. Sometimes this will take the form of code that does not in fact meet requirements passing too-lenient tests, and sometimes it will take the form of "false alarms" from tests that misconstrue requirements or are themselves buggy. If you've spent any significant amount of time actually doing development, you've probably had a bellyful of both scenarios. I know I have.
The way to avoid these problems is to keep in mind that the *requirements*, not the tests, are authoritative. One of the worst mistakes I've seen made on a project is allowing tests to dictate changes to requirements, but when you treat tests as a specification or target in their own right that becomes almost inevitable.
Slashdot - News for Herds. Stuff that Splatters.
What kind of programming process do the slashcode guys use? XP? something else, I am curious.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--
I disagree. In most companies, trouble comes from people not understanding that the role of business software in a business is to automate the processes of that business where it makes sense to do so.
The processes come first.. from the business process come requirements.. from the requirements a design is formed.. then coding/testing is done, resulting in a deliverable. That's the *ideal*. Businesses typically implement a different approach.
Typically, the processes are broken and misunderstood. It's not clear in a common company why a thing is done a particular way, it Just Is. At some point, a broken process will gather opponents, though these opponents won't be any more introspective into the process space than anyone else is. They just want Change. So they do one of two things -- bring in consultants to Jargonize everything, or buy software to give them new processes.
Either way, the stage is set for what I think is the common paradigm for software in business: "If something seems wrong, buy new software or outsource".
Neither approach addresses the fact that the processes were broken in the first place, and that the way a business operates is crucial in trying to get whatever goals that company has accomplished.
There are things in XP that bother me, but one thing that it brings out is the importance of involving users in the process in terms of their own words, their own thinking. In other words, make them think about their processes. It's a start. Contextual Design is better, but XP is more "hip".
Any exposure of good ideas is, tautologically speaking, good. (maybe I should have capitalized all of those words)
I didn't read the article, only the summary in the comment, so I believe that the only thing XP says is "do good things and don't do bad things". Since that's practically tautological, XP must be really stupid. Also, since Microsoft has a product called XP, and there couldn't possibly be two things in the world with similar names, I conclude that XP comes from Microsoft, so it must suck.
.sig.
--Moss
This is a
Now there are two of them.
--Moss
This is a
Now there are two of them.
There are two _____.
Well, I'm not one to defend Java (I've only recently started doing OOP, but the more I use Java the more I get curious about Smalltalk), but it's worth noting that there are some good Java refactoring tools. I currently use JRefactory, largely because it's free (speech) and works with the IDE I'm using; another interesting one is jFactor.
.sig.
--Moss
This is a
Now there are two of them.
--Moss
This is a
Now there are two of them.
There are two _____.
The tests are also of central importance to the XP theme of refactoring mercilessly and having confidence that the code continues working as you add more features.
Read Code the unit test first for more details.
This is bunk. You think of the unit tests as the way to define the requirements that your code must fulfil. The tests serve as a check that those requirements continue to be met as the code changes. After all, you are only implementing the simplest thing, integrating often, and ensuring that your tests always pass 100%, aren't you?
Because, alas, common sense is not very common.
Practices, or processes, degenerate to a point where the point of the process becomes irrelevant and the process itself becomes an end rather than the means.
The XP movement is an effort to reclaim some sanity. Lightweight methodologies try to restore some balance.
I'm amazed at the number of times in a normal week (in programming and in normal life) I find myself telling someone, "There's no substitute for doing things The Right Way."
If it takes a book and a methodology to get people to understand reflexive logic, so be it.
I worked on a project like that once.
The client never figured out that Primadonna Guy was spending most of his (billable contractor) time on "make-work" and leaving so little for the rest of us to do that they eventually had to scale back the whole project just to get costs back in line.
So the software never really got completed, it's unnecessarily hard to maintain, and a couple of other contractors are looking for work elsewhere.
That's a shop where XP might have been a good idea. I doubt that Primadonna Guy would have stuck around if he knew that there'd be ongoing reality checks.
I think the problem here is that many programmers have never been asked to make estimates of implementation time. If you ask people walking down the street how long it will take them to get to the next corner, most will get it wrong. But with a little practice anyone can do it. I everytime a programmer started a project, no matter how small he made a guess, then by the time he really needed to know how long something will take, he will be able to make a good guess.
Spencer Ogden
Sure they do. Just tell them: "The project's going to be late unless we take out one feature." and watch them prioritize away.
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!"
Sure, this is what people are supposed to do. In theory, businesses run sanely, politicians govern wisely, bueaucrats manage efficiently, and citizens behave responsibly. As you may have noticed, reality is somewhat different than theory.
According to McConnell's Rapid Development, "about two-thirds of all projects substantially overrun their estimates." And despite all this extra time and money, we all know there is a lot of crappy software out there. This suggests that the implict "write good code" is not sufficient. Realize "best you can do" is only the best you currently know how to do, and that there might possibly be ways to make the "best you can do" even better.
Extreme Programming is an interesting look at some of the reasons why things often go wrong in the software development process. And it presents some interesting solutions. It's not the holy grail and I don't buy all of it, but I have tried a number of the XP practices, and they are surprisingly effective.
If you want to be a serious professional programmer working in a team environment, Extreme Programming is absolutely worth reading, even if you never adopt any of it. For those who always work alone, it's only moderately interesting, especially if you already write lots of unit tests and are comfortable using a short-cycle iterative development model.
Not to sound rebellious against the article, but looking at things from an outside perspective this isn't so called "Extreme Programming" to me, its more like custom programming. Not all customers need the same features in a program so who will be the thinktank customer to help with the foundations of it all?
Excellent question! Beck's book covers this in more detail.
The theory here is that you want the developers to have complete control over the "how" and the customer to have control over the "what". And that "when" emerges from this process. The goal is to avoid the nightmare where a manager says "build X features in Y time for Z dollars" by pulling the numbers out of his ass.
In the case where you are making a product for a large, diverse body of customers, you get a proxy for them. Typically, this is is somebody from marketing. This person then is the one to say "of these 323 features that we think would be cool, these five are the most important ones." The developers then give estimates on how long those features will take, and the developers and the proxy customer go back and forth until they all agree on the things to tackle next.
In this case, though, I strongly recommend doing frequent user tests with real users. As Jakob Nielsen is happy to tell you, the difference between what we think people want and what they actually want is often miles apart.
But to a large extent, the developers will have to trust that the marketing person knows what he is doing, in the same way that the marketing person has to trust that the developers know what they're doing. Normally this is pretty scary for both sides, but the short release cycles and continuous feedback make it work out pretty well in practice.
Who insures that objects with state transitions are able to negotiate transitions forwards and backwards (or that they can't when they shouldn't?)
As another poster pointed out, this is what unit tests are for.
The designer has to be able to do a complete job of writing specifications based not merely on what the existing customer base asks for, but on what the objects involved reveal as posibilities.
Yes and no. This is certainly true if your system is brittle or hard to change. But if your design is flexible and you aren't scared of changing your code, then you can do tomorrow's work tomorrow.
The book that made me see the light on this aspect of it is Martin Fowler's Refactoring. Before I read it, design was always a big scary thing, like laying the foundation for a building. If you didn't get it right the first time, you were basically fucked forever. But Refactoring shows how to make small, incremental changes to continuously improve design.
This doesn't mean that you can turn your brain off; I still find it valuable to think about where I'm going down the road. But I've stopped doing a ton of work based on my design theories and instead put the labor into what's actually needed.
The clients will come back and ask for those very features when they see the system in operation.
XP's answer is that you add those features then. Either that or you say up front "wouldn't you like X instead?" But either way you don't just sneak features in. You trust the customer to decide what they need; the customer trusts you do build the stuff properly.
If you have a cycle time of years between releases, this of course doesn't work; the feedback loop is too slow. But XP should only be used on projects where you can use an iterative process.
Well, duh. For anyone who learned something from the advice about programmers programming, managers managing and customers choosing, I have this amazing revelation: it gets dark at night. Trouble doesn't come when organizations don't do this (obvious) stuff.
That's pretty much bullshit. I see trouble come all the time when people don't do this allegedly obvious stuff. Customers try to dictate the schedule; programmers ignore customer requests and add features that they think are important; managers do stuff straight out of Dilbert. Every professional programmer I know can tell project horror stories that are directly traceable to these kinds of errors. You want examples or more details, go read McConnell's Rapid Development, which is full of 'em.
The problems are the boundary cases... Clearly program scheduling and product positioning are 'business decisions,' but where are the lines between these and task estimates and customer feature priorities?
In the XP model, the lines are very clear. The customer says "in this cycle I want X, Y, and Z." The developers estimate and say, "you can only have two of those in this cycle." The customer then says, "Oh, I want X and Z then." And feature Y goes back on the pile of features to look at for the next cycle.
This basically works like a kid with an allowance. He goes into the store and picks whatever he wants as long as it adds up to the amount of money in his pocket right now, based on the prices the developers set. Next time he gets his allowance, he gets to buy more stuff.
The customer is happy because he gets what he wants, and the developer is happy because he sold the products at prices he decided were the right ones. Each group is in control of the things that they are most knowledgeable about. And the process allows for a lot of feedback and error correction, so that if there is a bad choice or a bad estimate, the consequences are small.
It's almost enough to make me wonder whether the people pushing XP so hard here have some sort of vested interest.
My vested interest is never having to work death-march hours another project with overly ambitious goals and inadequate resources until the whole thing collapses in a big blame-fest. XP has a lot of practices that I find useful in that regard.
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.
Of everything else here, this is my biggest worry. It's all well and good to say you won't "close off expansion" for further development. But many, many times, you have no choice.
For instance, what you're going to run into is a situation whereby design decisions you made during round 1 of development hamstring possibilities for developing rounds 3 or 4.
Good design can help to take some of this into account. If you know that the customer is going to want Y in 6 months, then you'll develop to be compatible with Y, as opposed to doing something different that will be faster to develop now but harder to integrate later.
Overall XP does seem to have some good points, but so does the general writing on making programmers' lives easier in general. I'm afraid I view XP as merely a way of getting rid of Configuration Management.
[a] Programmers will just love trying to create the impossible some customers will be asking for.
[b] Again customers will be asking for an outrageous amount on tasks that will likely be unfeasible.
Not to sound rebellious againstthe article, but looking at things from an outside perspective this isn't so called "Extreme Programming" to me, its more like custom programming. Not all customers need the same features in a program so who will be the thinktank customer to help with the foundations of it all?
Too many hands in the pot spoil the food (or something similar to that) and if you get caught up with trying to cater to one or two customers, your slighting the remainder of your customers' wants or needs, and if you cater to one too many your liable to create one huge worthless program filled with obsolete bloat.
What we think of Linux.com
Want Root?
Hmmm...maybe this is the ultimate question.
Let's see:
Nah, that doesn't really fit.
--
Later...
KangarooBox - We make IT simple!
XP is an interesting (and controversial) methodology that has proven its usefulness in real projects, and it is nice to see it covered on slashdot. It is gaining acceptance in the software industry. One indication of this is the number of talks on XP at the SD2001 West conference in San Jose 8-12 April.
However, decent references are sorely missing from this story, like for example
the book by Kent Beck and one of the more comprehensive web sites, www.xprogramming.com by Ron Jeffries, with links to a lot of other resources on XP.
You have mistaken the purpose. Sure, a lot of folk post for humor's sake, in the hopes that they will get modded up to 3:Funny; however, a purpose of this very rating (any number, the Funny, Interesting, Insightful, etc... are what I'm talking about) is one rarely discussed anywhere. Latin is dead. Ancient Greek, Egyptian heiroglyphics, et. al are dead. English is a living language. It is our responsibility as English speakers (I want to be sure to include those with my native tongue as one of their alternatives) to advance the language. This is why new dictionaries come out, new encyclopedia are published, new phrases are coined, and new jokes are written! Don't chastise a person for their pedanticism. It only encourages others to be more specific in what they mean to say and how they say it. I would like to ask you to hit your 'eject' button now, but you're not flying a fighter jet. ecd.
Why is it whenever I hear the term "extreme programming," I picture some guy jumping out of a plane with a parachute and a laptop?
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
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.
I hear what you're saying and I agree with you completely. This pahse our project is really early on. The stuff I'm doing is meetings with business development and marketing types to talk about what the software is going to do. I'm trying to take that and build a feature list and some use cases so I can show the development team what we need build. The next step is pulling in some other guys and talking about an object model.
The point I was kind of trying to make was that I've seen developers doing what I am now and start thinking about objects and patterns right away, before they've organised the information they've captured into something that makes sense to other people. That way you tend to get stuck without showing anything for the effort.
There were a few people at my last employer who were pretty behind XP. We had a few people into to talk about it and they did some interesting presentations for us. I thought it was pretty interesting but I don't really want to apply it.
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.
Well, there is more to XP than just the idea "write good code". XP is a methodology to give you a way to write better code than you would produce by just trying to do your best.
Reminds me of the old program/design motto:
Fast (development), Cheap, Good: Pick ant two
Having read many articles on XP, I am still left wondering exactly how it is implemented. Programming in pair could mean many different things -- but what /does/ it in the case of XP?
Has anyone practising XP kept journals of progress, or are there any case examples out there?
--bazop
Computers are like air conditioners.
They stop working when you open windows.
You're not giving the whole story either.
In XP you *AND* your partner in crime design the test cases, and write the code.
Pair Programming is a fundamental in XP.
This point and the others you've made all come back to a single underlying problem: most s/w developers don't get any better unless they are forced to. This is a sad comment on the industry in which I work. Geeks, hackers, s/w professionals, etc. all pride themselves on keeping their knowledge level at the leading edge (i.e., they're up on the latest developments) and yet they spend no time on personal discipline. Watching how I do my work so that I can ferret out mistakes and do a better job doesn't appear to be part of how the average person works.
Sigh.
NOT to your credit, you've responded negatively and harshly to the poster's concerns. Rather than simply tell of your positive experience with pairing, you denigrade the poster's concern. That isn't the way to win him over to your perspective!
It is interesting to note that none of the concepts advocated by the XP method are new to XP. XP is simply the latest collection of these practices; all of which are good and should be practiced.
In my experience managing software developers the difficulty is this: after even 10 years writing software, most programmers have no idea how long it will take them to implement a feature specification. At a higher level, most developers don't have any idea how long it will take them to develop the feature spec. in the first place. Go another step and ask them to write a test plan, and you'll discover that most developers don't even know what a test plan is.
Even more disturbing is the fact that after these lackings have been pointed out to the so-called developers, they show no personal initiative to improve their skills. Until I, the manager, force them to improve, they don't. There is still way too much of the "s/w development is an _art_" thinking floating around.
Is anybody else sick and fscking tired of reading about Extreme Programming on SlashDot.
g ra mming
http://slashdot.org/search.pl?query=Extreme+Pro
Variations on the same article over and over and over and over and over again. I get the message already, and I'm not going to switch just because it's advertised here three times a week, so kindly *stop it already*.
Is this post not nifty? Sluggy Freelance. Worshi
So, they're saying, "Figure out what's good and do it," huh? Well, it's good advice, but isn't it pretty much what we're supposed to in the first place?
I've never had someone come up to me and say "Write good code!"
I always thought that the "write good code" statement was implicit. If I'm writing code in any serious fashion, it's going to be the best I can do.
Maybe everyone else has been writing bad code intentionally all this time... They just needed to be told to do a good job! "Well, no one ever SAID 'Write good code' to me..."
Finally, a well reasoned response in the midst of the increasing sea of juvenille crap.
I find it incredibly ironic that slashdot is the place of all places where XP gets put down. I wonder how many have programmed in groups before.
Code reviews are wonderful things and pair programming is instant code review. I'd kill to have someone else checking my work as I go along (and vice versa). The few times I was able to try it for small projects the code quality was measurably better. Isn't this site the place where people love to tout "may eyes makes bugs shallow"?
Unit tests are awesome tools. With unit tests and regression suites you ensure that you don't break what you've coded. For the simple scripts that most of the readership code this may not be applicale, but for any reasonably complex system testing is a gigantic hassle and time hole. Unit tests alleviate the need to manually operate tests and check code behavior for correctness (One reason I think Java is really cool, you can code a unit test for each class in the class files). Unit tests can solve the never ending "it works on my machine" problem.
Code refactoring and redesign is continual in XP. You don't write what you don't need. This is different from not thinking about extensibility or design. You actually need an above average sense and feel for design to do this part effectively.
XP doesn't lock you into too many methodologies and you would be foolish to buy 100% into all of it. You'd probably need to adapt parts of it for your environment and resources. XP is really just taking common sense and a really agressive attitude towards programming. Smirking at it while you continue down a path that is proven to be fraught with weaknesses is being short-sighted.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
So based on an incomplete sample you've discarded a practice without ever trying it. Furthermore, you advise others to do so based on your non-experience. eg: From observing the way one open source project on sourceforge failed (of the many thousands) I could conclude that open source is a fatally flawed methodology.
I've tried it. It's worked well. There are documented examples of it working in expensive production environments (xprogramming.com). Sometimes it doesn't work so well, but at least TRY the practice before you go spewing forth about it.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
...and the tests have to be kept current with public API changes (and implementation changes if the test delves into the backend like initialising the DB etc.)
I am not criticising unit testing, just the posters assertion.
${YEAR+1} is going to be the year of Linux on the desktop!
Yes we can say software crisis. Take a bunch of requirements, spend months designing a wonderful class library that can do everything that is required, set the code-monkeys loose writing it, and then find that it doesn't do what the customer wanted. I don't think XP is a magic bullet that will make the software crisis go away - but on the other hand, sticking rigidly to Principles of Good Software Design that have been tried and tested for decades and have yet to consistently deliver quality products on time isn't going to do any good either. Oh, and claiming that the central tenet of XP is that you don't bother designing anything seems to be a bit wide of the mark. If I had to put only one aspect of XP into practise, it would be writing unit tests before writing each unit of code. I've tried this a few times, and it has paid dividends - and it isn't possible to do this without having some kind of design in mind before you start.
-- Andrem
There has been a major scientific break-in
Of course, that's an average. A linked list (back before STL) might have just taken a few hours, while a VHDL parser could take several months. But in the end, they all average out to 6 weeks.
...sounds like it might be a good idea. But what if you want to read Slashdot while you're 'working', but your partner wants to read LinuxToday?
We have an XP enthusiast at my company - he's pushing it hard. My reaction so far:
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!).
No sig? Sigh...
XP is not primarily about how to structure your programs, or how to "write good code". Instead it focuses on the process of software engineering. How to use your time best, make test cases so you can safely change your code and catch unexpected side-effects, how to learn and solve tasks better in pairs, etc, etc.
/. header gets to be scored 5. I remember last time I was modded up, I was ashamed of having written such crap and wished I could delete the post. Tells alot about what is mainstream here on /.
Btw, it's silly how a stupid comment based on ONE LINE in the
- Steeltoe
http://www.debunkingskeptics.com/
While you could be funny, if you just weren't ignorant, do YOU know what is essential in the process of programming? Can you make a verbose list of what is essential, what is not and why, without any snide remarks. "Essential" is perhaps a bit misleading, since it's like claiming to be the facit. However, it's a reason they call it "Extreme".
Here's a translation of your "funny" phrases:
"When to buy, and when to sell which stocks."
"How to jump off a bridge safely with a bungee-cord"
"How to safely transport lethal scissors by foot"
If you reread the quoted sentence, you'll understand that you have oversimplified it and that there are more ways to do it.
- Steeltoe
http://www.debunkingskeptics.com/
Disappointed with O'Reilly
O'Reilly have quickly growth a reputation for excellence, particularly adept at picking through all the hype & crud and producing useful books on important stuff. However here they seem to have fallen hook line and sinker for all this XP hype.
XP is NOT the awesome paradigm shift that it is made out to be by its advocates; it is NOT even that new. It's mostly just a repackaging of the RAD fad, with a few real Software Engineering ideas thrown it. It is an exercise in marketing. Those that have not come across it (or the ideas) before should read more REAL Software Engineering texts.
also getting all the same old responses.
Newbies: What is this, never heard of it before.
Perl hackers: WoW that's good I'll try that next.
Cynical Old C Hackers: Seen it before, next :)
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.
Acceptance Tests have to pass before the system is handed off to the customer. The customer just designs the tests, they aren't the sole keeper of the tests.
-no broken link
The Unit Tests are used to test the contract for a unit in the code. They are there to alert later developers that a refactoring has broken a contract. They can then either fix their refactoring, or change the test and code that assumes that contract, which will mostly be discovered by other Unit Tests or Acceptance Tests breaking. This is why the tests must be automated.
I personally run a nightly build on my current project at 4. Then I run the tests at 6. The results are emailed to me, with the failures at the top, and the successes under them.
-no broken link
You aren't even supposed to refactor globally: you just refactor the parts you are working on because that's what the customer is paying you to work on. Because of this, I would say that using an automated refactoring tool is missing a point (certainly not THE point, as all the other practices are just as important and you can fudge a bit on one or two).
-no broken link
Actually, XP has a whole section on design. You can see in the rules that you do indead have design sessions and use CRC cards to actively communicate in them.
-no broken link
Is it just me or does the corporate philosophy of "milk your resources harder and faster" seem kind of poisonous? Do you think DaVinci could have cranked out more paintings of higher quality is some wise creep had deigned to teach him 'Extreme Painting'? Doesn't anyone notice that every cool thing was produced outside of the corporate culture? Look at every groundbreaking inventer/artist/philosopher; they strive for pleasure, not dreams of profit. The best software is open source produced for the joy of creation. Corporations are good at is being efficient, but then so are amoebas and termites. What is a corporation anyway? A machine. A machine designed to deliver the dream of security and wealth to it's stockholders. Are security and wealth so important that we're willing to whore ourselves to any machine that promises to deliver them? I guess the answer is yes. Sincerely, your fellow whore. Deep throating the corporate robocock for 2 years and counting. What we need to make happen is a workless society, not develop our human-squeezing technology.
From what I have found every project is different and different styles of attacking those projects are good. However I think that XP makes some very scary assumptions. First of all do customers ever even know what they want. Their assumptions may be very different that was is realistic which leads to very odd demands for features. Second, I am sure that programmers can program given just one feature but from my experience I think that its important to get a good look at the forest over the trees. At least sometimes. Programs can often be streamlined and optimized only when the full problem is understood. I do agree that managers should make the business decisions but they also need to be involved in the schedule estimates. Programmers are programmers for a reason. Many good programmers are not good at evaluating their own work. Sometimes they are but there are tools that managers can use to evaluate the time it will take to program something given past work as a basis. I guess programmers could do this as well but like the artical says, "Programmers should program". Anyway just my thoughts
Most of the ideas in XP seem reasonable. Most except the idea of programming in pairs. Programming in pairs almost NEVER works for the simple fact that people rarely have similar skill sets. The result of the usual disparity is that one programmer does the work while the other watches and quickly gets bored. I've seen this through the 4 years of my degree where we received many pair programming assignments and I can't remember one single pair (out of a hundred or so) that didn't have the skill disparity problem.
XP is a software development methodology. Check out XProgramming.com or ExtremeProgramming.org for more information.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
- anonymous
That's why the iterations are short (XP suggests 3 weeks) and the customer must be on-site and available to answer the programmers' questions as they come up.
The article is just a brief overview and so it may be misleading, but XP most definitely does not assume that any up-front information, from the customer or otherwise, is perfect. Quite the contrary, it assumes that requirements will change, and that the current design will need to change.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
- anonymous
No offense, but it's obvious you didn't take the time to learn what XP is before posting that. It reads much more like an argument for XP than an argument against it.
XP is an iterative approach in which the design evolves naturally and the customers and programmers are always involved in constant communication. In XP there are no "specs handed to us from project managers." The "Planning Game" involves customers and programmers and produces "User Stories" (which replace requirements specs) that the programmers understand and are simple enough to estimate. The customer decides which stories to have the programmers implement during the next three-week iteration, based on the programmers' estimates of how much can be done during that time. The customer is required to be on-site and availabe to converse with the programmers whenever questions arise. XP is most definitely not designed to take power away from the programmers. Why on earth would programmers design a methodolgy to take power away from themselves?
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
- anonymous
XP is NOT against design. It's against designing the entire thing up-front, because that never works. In XP the design is continuous and iterative, and is expressed in code instead of in documentation.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
- anonymous
XP has unit tests and acceptance tests. The unit tests are for the programmers, so they're written by the programmers. They test the classes to make sure that they do what they're supposed to do. They allow the programmer to spend more time programming and less time debugging, which is beneficial in any methodolgy. They also allow the programmer to make design changes to existing code without breaking it, which is essential to XP.
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
- anonymous
Sure, that's simplistic, but it's not as mockable as many would think. What this means is "Do no work just because it's part of the process." XP doesn't have requirements documents, because the requirements documents aren't the end result. They have story cards, which are basically lean 'n' mean little requirements documents.
Need a document to show to management? Then that's a story card. It's just that XPers don't create documents for the sake of creating them, which is what requirements documents often feel like.
On its own, the "do only what you have to do" sounds facile. Within the context of the last 10 years of software process (CMM, etc), it makes much more sense.
--
One solution is very rigid models, along the lines of the waterfall model, UML, Rationa Rose, and Ada. This produces solidly reliable software that's hard to change and may solve the wrong problem. Think Linux kernel.
A second solution is decoupling, making components as loosely coupled and flexible as possible. This is what most Web-based systems look like, and is why Perl is called "the duct tape of the Internet". Programming is moving in this direction, because it's easier. There's an efficiency penalty, and systems may not work all the time, but they tend not to fail catastrophically. This is good enough for most business applications. Think Slash.
Extreme programming is applicable to systems of the second type, but not the first.
Yeah, well... programming methodologies *sigh* As far as I am concerned XP is yet another take at the cesspool of murky monstrosities that is the mind of the programmer. As such, it places itself in the tradition of Fred Brooks' seminal "The Mythical Man Month". The central 'tenets' of XP are primarily instruments with which to tackle the almost mythological ideosyncrasies of The Programmer: megalomania, vanity and hysterical perfectionism. So, while XP isn't all thing to all people (and, most definitely, not The Silver Bullet), it is certainly a worthy contribution to the ongoing development of the art and craft of programming. Okay, XP is also about project management and customer relations, but, um, I skipped those chapters.
For the sufficiently clueless, even trivial applications of common sense are indistinguishable from wisdom
Where is Billy Connelly when you need him...
We want it all, and we want it yesterday, and we'll change our mind tomorrow...
Or Dilbert
If we combine these three requirements into one, can we have them all
Special Relativity: The person in the other queue thinks yours is moving faster.
After reading the article and finding that "extreme" programming just happens to be the way we develop software (or at least the way we aim to), I can say I've found the approach to work quite well.
I think the only thing we're missing is the "pair" programming, which didn't make sense to me initially, but once I thought of it as two developers are RESPONSIBLE for a module, not just working on it, it made alot of sense, sortof a built-in quality control system.
I am a young guy with a non-traditional (at least from an educational perspective) programming background who has been developing a programming team for the last three years, and in that time we've evolved from the "gluing code samples together" stage to implementing a formal development framework (Microsoft Solutions Framwork), formalized functional specifications and 60% of our time spent in up-front analysis before any code is written.
I have to say that the "XP" approach closely mimics what we have grown to embrace, and we have been sucessful in the approach. There are still major problems, primarily being communications with the customer (trying to explain why some features cost more than others), but for the most part it's been effective.
I would say that the major places that need improvement are at the business and process analysis levels, not so much at the design and implementation level. I think that just as we developers review features and document their technical impact on the project (time, money, complexity), there should be someone simular that analyses the business impact of features, and provides guidance to help customers choose the features that will have the most positive impact on their business.
Let programmers focus on perfect applications, and let businessmen/women focus on perfect business.
second society
I have yet to try "real" extreme programing, but IMO working in pairs is superior to writing code alone. I'd rather have someone peeking over my shoulder pointing out bugs than spending the many needed nights hunting for them.
Does anybody here have any experiences working with XP?
/Smuffe
People are starting to take XP very seriously simply because it delivers quality code instead of just documents about code. The core philosophy can be summed up: "A feature does not exist unless there is a test for it." (P.83 of XP Installed) This means that coders (pairs of programmers in XP) first construct unit tests of product features before the attempt to code the features. What this means in practice, is that the code that XP delivers (continuously in 3 week long iterations) can never be broken! I'll say that again just to make sure you read it: XP code can never be broken! I really think XP's adaptive, test-first philosophy is the best thing that has happened to software engineering since Dijkstra told us that the "Goto Statement is Considered Harmful" in 1968.
D
Mad Scientists with too much time on thier hands
The first, last, and only tech news site on the net
I can't seem to figure out exactly what "Extreme Programming" is... with all the buzzwords in the article, and the capitalized letters in the name, I'm lead to believe its some kind of product. Except, the ideas of the article make me believe its a concept.
So, did somebody put a concept into a box and mark it for sale?
Anybody want to help me out with this one?
Skiers and Riders -- http://www.snowjournal.com
Formal Education
College:
Summa Cum Laude or not, I think I'd hide, too.
Unit tests in XP are for testing everything that could break. The only people who know that is the programmer. All unit tests must test 100% in the checked in code. If they don't, you must fix them before you do anything else. Programmers don't write test specs. They write tests. In fact they don't write code first, they write tests first and then make the code work with them. These unit tests are like smoke tests. But they are fairly comprehensive. They give you the ability to refactor your code without the fear of breaking something unknown. As soon as you make the radical change, you know what broke. Integration testing is VERY important. So is code integration. Code should not be left unintegrated for more than a day. Then all unit tests are run. The customer (the person who forms the requirements) helps QA create the integration testing. The integration tests express their requirements. These tests are also called acceptance tests. The project isn't done until 100% of these tests pass. And they don't have to be written all at once. New ones can be invented. Hopefully as the project progresses you'll have more of the tests pass. They should be run often (a couple times a week) but not all the time. They can help guage the progress of the project.
If you CAN'T get rid of that person then you a bigger problem then one person slowing down another. If you can't spread knowledge around in a group, you have an even bigger problem when alpha geek leaves. Hey it happens, alpha geeks are awesome in any setting. They get hired away.
But if the person is teachable, eventually they get it. They get better. And they may even add value to you. Pointing out places where you make simple mistakes, or get lax with testing or code style.
And hey, in XP pair programming doesn't require you pair with the same person all the time. Some people just aren't good together. XP is about learning.
Also get this book written by one of the pioneers of extreme programming (which has been around for 5 years BTW): Extreme Programming Explained: Embrace Change by Kent Beck.
So, what you're saying is that XP is a solution for ppl who need to buy into a system, and bought into a bad one w/ Rational? Strange, I assumed that my "Introduction to Engineering Design" and "Systems Engineering" classew covered all these ideas about how engineering works, and then a quick read-through of The Mythical Man Month took care of some 'real world' examples.
I don't think new methodologies are the key, but simply adapting proven, existing engineering methodologies, and adhering to them would do wonders. If you haven't noticed, software designers don't exactly have much credibility with real engineers (mechanical, electrical, chemical..), and it's not without reason. If any -physical- product, be it a bridge, car or toothbrush were shipped in the same condition that much software does, people would be dead, and companies would go out of business. Of course with software, the physical price of the media (and w/ the internet, merely bandwidth), is insignificant, and replacing, fixing the product is a trivial task when compared to replacing a bridge. In a way, it's comparable to LSD distribution. (a 1x1mm square of paper is a dose, but only contains arround 100 micrograms of content))
my sig's at the bottom of the page.
If you drive it all the way from the customer directly to the programmers, and you're dealing with hundreds or thousands of Mb of data, or you're trying to scale up at all, and you're changing the schema every week, you (and the customer) are going to be unhappy. Perhaps there's an intermediate layer missing from the model.
Maybe the end-user isn't the customer. Maybe the end-user talks to the software architects and designers, who consolidate, clarify, help define and tease out the requirements from the end-users. Then, these people that actually know what the end-user wants become the customers of the programmers. The turbulence of the daily end-user requirement changes are smoothed over and presented to the development team in a larger meta-cycle. Think of it as eXtreme Programming buffered by a cache of eXtreme Design.
I guess I should trademark that and write a book. At least now you have some control over the process. Now you can make the application work efficiently, instead of just work.
Not A Sig
Of course, you can also write bad unit tests, but that's a different problem.
Can anyone with XP experience comment on how good the unit tests are? I would assume if the project was properly broken down designing a unit test to attempt to break your code would be easy.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
Actually, unit tests should be written to break someone else's code. You should never do final testing on your own code. Ideally, you hand your code off to someone whose job it is to stress and break code. At least have someone else help to think up the test cases.
Remember, You are unique...just like everyone else.
Coincidently, I had the unfortunately "pleasure" of looking at the mod_perl source code yesterday in order to figure out something I'm working on. What a piece of garbage! There are almost zero comments throughout the code. It was incredibly frustrating.
And what's amazing is that this isn't isolated. Way too much OSS software is like this. I might even say the majority of it.
What is wrong with these people? Why aren't they embarrased about releasing code that is so badly documented? I would *never* in a million years release code in that condition that someone else would see.
I see this as one of the biggest flaws in OSS development. A lot of it is developed by rank amateurs that should not be allowed near a computer. I would really like to see some professional standards written up. Maybe people would ignore them, but at least we would have something we could beat them over the head with and say "you should be using this."
Sorry for the rant, but I wasted *so* much time yesterday on that pile of crap.
--
Sometimes it's best to just let stupid people be stupid.
So, when the inevitable feature request comes along, the 'extreme programmer' spends the next week rewriting previous code to handle the new feature, while the rest of us just stick the button in there, add a function here and there, and reuse a lot of the functions we've already written, thus we finish it in a matter of hours rather than days.
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).
The point of XP is that it is iterative, which means that you specifically don't expect your customer to provide complete or correct requirements.
By iterating through a quick iterations, much like Open Source, the application is evolved rather designed. Of course there is micro design within each iteration where developers plan how they will achieve the functionality required, but there is no longer a detailed static plan of the whole system, because we have found that such large detailed plans become outdated and corrupted over time as developers change the plan to meet the customer requirements.
XP accepts that we are unable in the quick paced business world to do long term (over one year) projects on monolithic applications that do not evolve with the needs of customers, and provides a means of programming in a flexible manner that does not comprimise quality or productivity.
For a resource on this and other related topics, take a look at here
I was under the understanding is the first thing you do in XP is to develop test cases. How are you going to test your code before you do anything else.
Also the whole point of XP is to be able to release code, as the customer needs it adding functionality as you go, that is why you build test cases first to understand when you add that new module to make sure it works with all the previous versions. But I think pair programming is the most beneficial aspect of XP. I remember nights at school that the most work we ever got done, was in front of a whiteboard, writing / collaborating code, almost without design, in different color markers. That is the true power of XP, collaboration.
Rehab is for quitters...
"It takes many nails to build a crib, but one screw to fill it."
From the message you wrote, I just can't quite determine if you're talking about Windows XP, or eXtreme Programming.
In short, extreme programming is a nice idea, but unless you know EVERY aspect of the application before the first line of code is written, and don't intend on ever releasing a next version, it's a timewaster
This statement does not match the description of XP in the article at all: Most experienced programmers are familiar with the "large scale up front" design approach. XP programming doesn't embrace this approach...
It makes the real world point that not only do user not know everything they need at the beginning of the project, they ask for things that they don't really need very much.
XP claims to have formal methods of dealing with both these issues.
Well, the rest of us just kind of looked at him funny and continued our usual practice of evaluating possibilities and writing modular code.
Most software development methodologies consider giving your colleague funny looks and continuing usual practices as a big red flag. These are defensive psychological techniques for dealing with threatening ideas and are often early indicators of the validity of the ideas.
The impression I got from a recent Tech journal (don't recall which one) is that you don't bother to design anything, just plough on ahead and do your code. Anything unessential to the task in hand should be ignored. So don't bother identifying potential future needs and requirements, or bothering overmuch about resuse, because it MAY never be necessary.
To me it sounded just like prototyping. Can you say "Software Crisis"?
---------------------------
'No rational religion claims "supernatural" exists, that's an atheist slander.' - seen on slashdot.
Your first post is dangerously close to being on topic to the article. Don't let it happen again.
---------------------------
'No rational religion claims "supernatural" exists, that's an atheist slander.' - seen on slashdot.
Or their new article on how to walk, titled, "Putting one foot in front of the other."
I'm sorry, I stole that from George Carlin!
"And like that
However, I don't see the practicality of always working in pairs. For example, I have found the most time consuming tasks are interfacing with a third party tool and creating an easy to use wrapper for the rest of the team to use. My question is how can a pair of programmers work on a task like this? There's just one class, you need to understand the whole tool to use it correctly and write the code. Comments?
dynamo
Fred Taylor figured workers were lazy and stupid, so they needed professional planners to tell them what to do and professional quality people to catch them screwing up. 100 years ago with illiterate blue-collar workers this was a bad idea. Today with programmers it's even worse. If the programmers are the ones who can affect quality, they have to be the ones responsible for quality. Nothing else makes sense.
"Refactoring is where you take crap code and kick it hard enough that you can extend its life a bit longer. The idea behind XP is this: the customer gives requirements. Programmers write test cases to verify these requirements. Then, they kick the code, doing the minimal possible work so that it meets these requirements while not failing the others. Then they repeat this. " What a stupid idea. What if instead you told me honestly how long you thought it would take to get the code into real good shape, and I told you to go ahead and do that as long as we deliver new functionality to the customer in two weeks. How good could you make the software then?
If you have stupid customers you can either make all their decisions yourself, help them get smarter, or work somewhere else. You have chosen 1). XP chooses 2). 3) seems reasonable, too.
I've been introduced to this concept a while back. One of the other guys over here insisted that this method of programming was ideal and more efficient, and to prove it, he started following that idealism. Well, the rest of us just kind of looked at him funny and continued our usual practice of evaluating possibilities and writing modular code.
I've never seen a project that has 100% of EVERY feature written down and agreed upon before the first line of code is written. So, when the inevitable feature request comes along, the 'extreme programmer' spends the next week rewriting previous code to handle the new feature, while the rest of us just stick the button in there, add a function here and there, and reuse a lot of the functions we've already written, thus we finish it in a matter of hours rather than days.
In short, extreme programming is a nice idea, but unless you know EVERY aspect of the application before the first line of code is written, and don't intend on ever releasing a next version, it's a timewaster.
Oh no it's finally happened... Software literature has become facile and meaningless as management pulp. The central tenets here are tautological: the central tenet of making good soup is to to find the essential elements of good soup and use them. Well, duh. For anyone who learned something from the advice about programmers programming, managers managing and customers choosing, I have this amazing revelation: it gets dark at night. Trouble doesn't come when organizations don't do this (obvious) stuff. The problems are the boundary cases... Clearly program scheduling and product positioning are 'business decisions,' but where are the lines between these and task estimates and customer feature priorities? And all this promoted by O'Reilly... Maybe they intend to start up a self-help line of books: "12 Steps to Programming Your Way to a Slimmer Healthier You For Dummies."
The article says:
1) Customer lists the features that the software must provide.
2) Programmers break the features into stand-alone tasks and estimate the work needed to complete each task.
The article assumes that the customer is perfect. There are several steps missing in between 1 and 2:
1b) The customer only supplied 40 to 60 percent of the needed information.
1c) The customer is not clear about his needs, and provided some information that is misleading.
If you take into account missing steps like these, the methods required to manage change considerably.
Bush's education improvements were
I agree with most of what you say, but two areas worry me: lack of code ownership and pair programming.
:-)
For both of these to work, you need to have programmers of a consistently high caliber. Unfortunatly, most of the people I have worked with are not people I would trust to refactor my code, nor would I want to pair with them. I also suspect you need to keep your teams small.
There have been collaborative experiences in my career that were fantastic, but were exceptions, not the rule...
I've skimmed through a book by one of the XP guru's (forget the names, sorry); he made it abundantly clear that many projects and many organizations should not use XP. It is not a one-size-fits all methodology.
Code ownership has downsides, but also positives. If code is "mine", then I may have to live with my mistakes for years to come. If I have some spare time to refactor, I will clean up my own mess, because it is in my best interests to do so. Unowned code however is less likely to be refactored, because it "isn't my problem". Unowned code tends to deteriorate over time, as various people slap quick hacks on top of it.
I do like the "no overtime" rule though
I suppose either they are on a different planet or I will wake up and find out who shot JR?
Uh...
Customer's never list everything they want, and they damn well don't prioritize. After all they would not ask for something if it wasn't important.
There are obviously many "bullet points" missing from the list, mainly those where management blows holes throughout any possible planning and implementation.
I guess this would be published in the science fiction section eh?
* Winners compare their achievements to their goals, losers compare theirs to that of others.
It depicts a lead programmer speaking to his team, and the caption reads "OK - you guys start coding and I'll go find out what they want".
I can't even imagine what management would do with the tenets of extreme programming. The company I work for has already laid off 1300 people in the past two months. I'm currently supporting software that took 10 people to support until our group was handed a new project. They want it to be exactly like the previous product, but with new hardware, new software, a new compiler, new test equipment, and an untested platform, written in a different language. But otherwise just like the old product. Oh - and one of the 1300 people laid off was the lead programmer who designed the old product.
I'm not bitter -- really. But I am going to drag out support for the old product as long as I can before I get thrown into design of the new product!
Help find a cure for Gidget.
What's this, the fifteenth time we've talked about extreme programming over the last six months? GET ENOUGH!
Anyone?
--
Love the sig :D
--
Do you have to tell the customer that to implement feature X, we have to do a refactoring that will take 20 days???
Surely the customer will NEVER take any feature that involves a refactor; they don't feel like they're getting anything!
Rather than the current system, where you get some kind of structure, XP will give you NO structure!!!
The XP way is to pick "fast" and "cheap".
In fact these are declared virtues in XP.
YAGNI - You Ain't Gonna Need It. Don't code any thing that you don't explicitly need _now_.
DTSTTW - Do The Simplest Thing That Works.
And then use "test-first" and "refactor mercilessly" to sneak the "good" bit in via the backdoor.
I'd have thought extreme programming was something more like last minute recoding of a nuclear missile control system whilst NORAD was at defcon 5. Or will calling it "extreme" just get more column space and sell more lame books to dumb sheep than if it was called "common bloody sense programming" ?
You didn't take the time to learn what XP is all about. Perhaps your friend gave you the wrong impression. XP is SPECIFICALLY against planning things out too deeply. The analogy they use is that building a project is not like shooting a gun -- more like driving a car, with all the little course corrections.
The main disadvantage of this is that you'll inevitably need to change your code around because obstacles come up that you did not foresee. They sand down this disadvantage by strongly supporting "refactoring," which is a method to safely generalize & modify working code.
eXtreme Programming is definitely a hot spot of contention between those who favor a more individualistic approach and those who are more team-oriented. But whatever the case is, I've found that reading the book is useful even if you wish to discard most of what you've read. Many people could stand to consider the merits of automated unit testing, which is not a new concept but few people seem to do it. Same with smaller, faster iteration release schedules for quicker customer feedback. At the very least, the book provides analysis of situations and solutions many have to face.
It's certainly a small enough book to read at the bookstore café, if one has no intention of buying it.
Sure, it seems intuitive. Programmers spending their time programming instead of thinking up neat ideas. And, for business, it doesn't seem like such a bad idea. But then I look around at our organization. Specs handed to us from project managers are hideous -- they don't take into account what the technology (a damn web browser) can do with regards to input and output and aren't willing to spill over into new technologies. Customers aren't sure of what they want...they ask for a new feature and expect it generated without us bothering them again, and they want to be able to use it without training. And the only people holding this organization together is the programmers. Our programmers are with some exceptions, excellent at revising specs to be what looks good and is fnctional. We bring an air of experience and a feel for conformity to the world of interface design. And we're constantly implementing new features that customers love and that they never would have gotten if management had their druthers. Customers (who, by the way, are IT folks at other companies, not people who actually use the software. These people, often peons or temps, are never asked what would make their job easier) want features but they don't know what they need until they get it (who though they needed the internet or cell phones in 1994). Managers don't know what's out there or what can be done. The only people who really know what a technology can do easily are those with their fingers in its heart -- the programmers, and to a lesser extent the IT folks and the peon "users." As such, the best specs and features in the world will still have problems: they will not be sync'd with what the technology could do.
"So?" you may say, "isn't it a coder's job to fix these things?" Yes it is. But we fix problems with specs by letting the application take its own flow. Even in a modular, rational-esque approach to software, each module must still grow naturally through a series of trials and attempts before it can reach true usefulness and speed. Hence the numerous driver fixes that you see for complex hardware like video cards. After a week, you may have a working driver, but it won't reach its speed or stability peak for another year. And if things are as fast as they can get, you need a manager who will beleive in you...not a supscriber to XP who thinks that by specing the driver faster the hardware will follow.
XP, feh...much of it IS marketting bullshit, and it's designed to take power away from the people who have always made the revolution in computing -- the programmers. Of course, I'm all for the peer review and modularity stuff, but in the end it isn't programmer-manager-customer...the programmer has a hand at every level.
Hey freaks: now you're ju
Can you restate your point? I'm sorry but I think I missed it. In case you were defending the "old" methodologies (such as the Rational Unified Process) yes XP essentially says that they are all bollocks. And in my Not So Humble Opinion XP is right. We tried Rational and failed. I worked in a so called Rational shop and it was a plain nightmare. Diagrams out of date, designers without a clue about coding trying to come up with their Actors and Scenarios and all that pile of cruft with no deliverables. And despite programmers' best attempts to keep the Rose models in synch with the code it was just a big drag and those models did get outdated very quickly. Process instilled modeling doesn't work. Deal with it. Design is what programmers do on the whiteboard. Anything else is just fluff thought up by people who need to justify their existance. XP basically says cut the cruft and get on with the job. It doesn't prescribe sloppiness of coding. Quite the opposite actually. It prescribes an obscene amount of testing. Actually XP is more similar to traditional engineering than waterfall. How many electronic engineers do you know that just work on their own on "their" piece of the design? How many electronic engineers do you know that don't unit test their designs? How many electronic engineers do you know who design Actors and Stages for their next 3D geometry engine? Answer those questions and you'll discover that XP is a pretty formal methodology despite having such a relaxed name. Don't get conned by expensive software into thinking that because it costs $10000 a seat it must be something very "professional".
Your pizza just the way you ought to have it.
You must have small teams in XP. If you've more than twelve developers on your team (give or take two) it's probably a bit large for XP. But that's about as large as any single programming team should be. Go larger and any methodology collapses. It's all about effective communication breakdown. With more than twelve people collaborating it's extremely challenging to keep everyone in the loop. Solution? Split your work vertically to create small sized teams of eight to ten people and assign a coach to each team. If you're really building a single monstrous product split it according to functionality blocks and give each team a separate block to tackle. Teams have to be small but that doesn't mean that companies those teams work for have to be small too.
There is more and more talk about XP being used in mission critical applications which traditionally followed very strict and conservative software methodologies. So there must be a grain of wisdom in all that stuff. Remember that XP doesn't force you to embrace all of it in one go. It just forces you to be aware how far your "knobs are turned" on the XP stuff. You can go all the way or you can go just a little bit at a time and implement more as you gain confidence in the techniques proposed. Anyway I'm not a professional XP evangelist, just an average Joe Coder who has had a really good experience with it.
Your pizza just the way you ought to have it.
Most comments are pointing out that XP is yet another management buzzword or it's just stating the obvious. Well, it's neither. XP stands against all the principles touted by the waterfall model or the Rational Unified process and shite like that. XP is basically saying "toss out that copy of Rational Rose because you ain't gonna need it". If it doesn't make your job easier (and Rational Rose doesn't, believe me) toss it out. If you're already building five classes to parse a simple parameters file toss it out because you ain't gonna need it. XP points out (quite accurately) that the design for change is only useful if we allow extendibility in the right places. Unfortunately this requires you to analyze your problem domain beyond what's needed to ship your product and most of the time you'll still get it wrong. You'll get it worong because you don't have a crystal ball. You can't tell what the customer will want next. This way you eliminate the whole code design circus and end up with simple code that does what it's supposed to do, no more, no less.
One of the most important aspects of XP is unit testing. XP recommends that unit tests be written before the code that's supposed to pass those tests. This is more important than you think for two reasons.
Reason one: how are you supposed to develop your code if you don't know how to test it? When you write your unit tests you gain insight into the exact functionality of your code.
Reason number two: If you write your tests after you develop the code your tests will most likely only test the scenarios you considered when you were writing the code. Your tests will most liekely be incomplete because they'll have a slant towards your implementation.
Coding in pairs is probably the most prominent and the most controversial aspect of the system. It's important to realise the benefits of pair programming though. No code ownership means people can't get territorial about their code so everyone is free to change it when they need to change it. I've seen shops where changing John's code was considered politically incorrect and often John would take the issue personally. In other words if John wrote the message dispatcher John and John alone would decide on it's shape, form and future directions. XP essentially says that the hypothetical John can no longer pee around "his" piece of code and keep it as a guarded secret because John is no longer the sole developer of the message dispatcher. If John gets territorial about his work, John gets moved on to do something else and somebody else takes over until they start growing attached to the code again. Lather, rinse, repeat.
Besides code ownership and territorial programmers the other issue that XP takes on is coding primadonnas. Most software shops have a standard (sad) working model. One self promoted primadonna coding 70% of the application including the critical subsystems and the other twenty developers working around the edges "helping" the primadonna and trying hard not to get in her way. Our primadonna often isn't even the best coder on the team but surely is the most bullish and opinionated and thus grabs all the exciting work. Everyone else is just supposed to feel inferior and work on some tiny pet project of their own. This is not only grossly underutilises the rest of the team but usually at some point puts the project in jeopardy because the primadonna has now found another company to prey on. Project "gurus" have mushroomed throughout this industry and weeding them out may prove challenging. XP offers a very radical albeit a very promising way of achieving that.
This comment is growing a little long now so I'll shut up at this point. I hope this offers some enlightenment to those who keep on saying that XP is just another waterfall mutilation. It's not. It's a hackers methodology. On the side not however, I to have an issue with the name and the accronym. It's just juvenile.
Your pizza just the way you ought to have it.
The group of folks leading XP have changed the name - "Agile Software Development". A good reference for the methodologies can be found at http://agileAlliance.org
Ok, you do have a point. However if you look at the majority of the posts, you'll see that it gets very mushy along the lines of equating XP to "doing the right thing", or just to prototyping, or peer review, or whatever. I was stressing the point that it is in the details and not the truisms / generalities that the value of method lies. The one thing I do not want is some half-brained manager using her half understood version of XP to screw my project & team. I've seen it done with OO... Also about refactoring: what does "not globaly" mean. We are talking about code, ie an abstraction. One small refactoring change may have big impacts (if not, then you wrote too much code !). And automated refactoring is a good thing if you can get it, and if you can't, pass me the red bull. (Ever tamed code monsters with the Cast workbench ?)
Apart from testing, another tidbit without which XP is just another swing of ye old formalism pendulum (you know, chaos vs. order, all that) is refactoring. This is what distinguishes XP from prototyping. Refactoring code is for example generating a function by taking a chunk out of an existing function. Refactoring, maybe, I'm not sure, prevents explosive complexity growth. A proper automated refactoring tool is hard to develop, and your code base had better be in a very coherent language, like Smalltalk or maybe Lisp/Scheme. IMHO XP in Java or C/C++ misses the point, and will go down in history as another misunderstood "fad".
--
KMSMA (WWBD?)
I think its better to share the keyboard. As long you don't mind pushing your fellow hacker off it every now and then, to correct syntax or style, just plain stop and think, or because your fingers are getting itchy - it works well.
The point is I think this is going to be a tough sell to many programmers brought up with this mindset, no matter how effective the solution may be.
-----------------
www.lucernesys.comHorizon: Calendar-based personal finance
It sounds like you're taking it on faith until you hand it off to the customer, and I can't believe that's the case.
-----------------
www.lucernesys.comHorizon: Calendar-based personal finance
First of all, it means programmers have to learn to write test specs (which is not trival), and second, it suggests that programmers test their own code, which I always thought was a bad idea(tm).
Aside from 'smoke testing' (you know, if smoke doesn't come out of the computer, it's passed the test) I think the testing should be done by someone else. Programmers get too intimate with their code too quickly.
Anyone from the XP camp care to comment?
BTW, what happened to integration testing? I didn't see it mentioned anywhere in the article.
-----------------
www.lucernesys.comHorizon: Calendar-based personal finance
German /. readers might be interested in the fact that the c't magazine featured some good articles about extreme programming in one of the last issues.
Developers at my last job started getting into XP a few months ago. However, even though they expressed interest (I think one developer was trying to rally the rest), only two or three that I'm aware of put it into practice. What I don't get is, even after reading the basic Beck book, XP *still* seems like a manger's methodology to me... why are programmers jumping on board with such enthusiam? Did they never do unit tests before now?
One of the things people should bear in mind is where XP was invented - Smalltalk (and VisualWorks, part of Cincom Smalltalk, in particular). It still works best in Smalltalk. Why?
Immediate feedback. You can create the tests initially without having the actual code written yet (as the tenets call for) - Smalltalk allows for that
You can test early and often. Why? because Smalltalk allows for testing of partially written systems, something statically typed systems generally can't do. And before you say 'VisualAge Java', recall that IBM are busy re-doing that in Java - and removing the dynamic features as a result
If you want to try it out, try Cincom Smalltalk:
Cincom Smalltalk Home Page
Cincom Smalltalk Download Page
to download it. You should also know that the people who invented XP (Kent Beck, Ron Jeffries, et. al.) did so in VisualWorks. It was born there - it's best there.
If you want to see the Original XP project and how it came about, follow this link. It's got tons of information on the beginnings of XP - and points out the Smalltalk origins. So if you want to do XP with the best results, do it with the best tools.
you'll both end up changing the same code at the same time. Or trying to compile half-way through the other person's change. It'd be disaster
I agree what I mean is the second person corrects spelling errors, missing semicolons stuff like that. And only when the first person has finished with that code.
One thought I had was instead of having the second person looking over the shoulder of the first. Have the second person on another computer next to the first person. The second person sees the code the first person makes and can also change it. The second people can automatically proof-read the code and correct minor mistakes without interrupting the first person.
The way I take your post is don't design everything upfront. What I get from the article is decide what's necessary, then add everything else as needed. It sounds to me to take a modular approach to the design. Build the core of the program (what's necessary) then whatever whiz bang plugin accessories later down the road that wasn't planned on that is now "essential" according to the customer or management. I don't know if you currently practice XP but it sounds like your approach and the XP method are similar in that respect. So yeah, to over simplify, modular programming with paired teams to make sure the code is right the first time, with the flexibity to add in unexpected fluff as needed... XP.
Beware blue cats moving at
Crafty.
shut up man.
You idiot, read about XP before you talk. XP wont even work if you only have one person. Although I will grant it works best for a new project - b it 500 or 5000000 lines of code. idiot
I'm a programmer, I don't have to spell correctly; I just have to spell consistently
I just love it when people blurt out erroneous information about a subject/product/project that they have never seen or used.
The main concern people have here is that in XP you don't design. That is a false statement. In XP iterations are encouraged and design, for an iteration, takes place at the beginning of that iteration. Its true in XP you don't design a large application at the beginning of the application, that ends up begin a waste of time. Any one who has ever worked as a programmer realizes that user requirements change on an almost daily basis. This iterative design process allows for change. In fact, one of XPs mottos is "Embrace Change".
The best argument for the use of XP is that it works, better then any other methodology I have ever used. The iterative design process, user stories, unit testing, constant code commitment, pair programming. These concepts brought together in the form of XP produce a balanced environment that tends to produce what the customer wants in the time frame he wants it. In short, it helps us do our job as developers well.
With XP you get well-designed, extensible, modular code. You are also encouraged to reuse it whenever possible.
Is XP a panacea? No, not by a long shot. On of the principle complaints I get when I introduce some of the concepts and procedures to a client is the statement "Oh our coders don't like procedures, they will never do that". This comes back to the fact that if you can't get your coders to follow any procedure, than it is likely that no procedure will work for you.
Although I am a full time coder and like XP, most coders do not. XP, by design, reduces the likely hood of cowboy coders (in the American sense) by design. If XP is implemented correctly it wont be long before almost everyone has a similar level of knowledge, this level is usually equal to the highest pre-XP level.
I'm a programmer, I don't have to spell correctly; I just have to spell consistently
I am using XP to build a serious software system. And since this is XP, I can dive right into any task because of the power of: Pair Programming: Two heads are better than one. You have to appreciate the development intensity when two coders attack a problem in front of one screen. Code Ownership: No one person owns the code, we all do. So, we all become experts on all parts of the system. No single point of failure. Nice. Testing: We code all our tests first and then write code to make them pass. Testing is not tacked on later haphazardly. If I make a code change, I can test all the other code immediately to see if I broke something. That is sweet. How many non-XP'ers can say that? Iterations: Forget long, drawn out, projects. XP provides a tight interation schedule. We code what the customer wants to see in that iteration. After the iteration is over, well, the customer can change their mind. And that's fine. Specs: Forget monsterous documentation that no one ever reads. Our test code and our application code is the documentation. Nothing gets out of date, as we are always... Refactoring: As part of the process we are constantly expected to refactor our code. Make it better, stronger, faster. This does not take that long and yields code that has no dust on it. Every byte is working. Problems? Yep. The biggie for me is when I have to interact with a non-XP oriented development team. They can't respond to changes as quick as we can, so sometime it becomes awkward. This XP stuff really works, too bad about the dorky name. It is working for us, but like any methodology, you need to stay loose and not get caught up in the letter-of-the-law. Your milage may vary.
XP sounds like a good idea for a ground up effort, but how can it be implemented in a project already in production? Now granted, I haven't read much on it, but it doesn't seem to include anything about change control or CMM (Capability Maturity Modeling) . Or, maybe that't one of the non-core items that should be left behind or concentrated on by managers.....
"Want in one hand and spit in the other and see which one fills up first." - My Dad
At least it's not there to sell you $10,000 development seats for bloated, painful tools. Don't buy a book, either -- there are gobs of web sites with accurate information (e.g. http://www.xprogramming.com).
Amusing that anyone would think months worth of meetings are ever productive. We meet. We produce a thick document that is largely lies. How productive.