Go Extreme, Programmatically Speaking 259
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.'"
Re:XP Journals? (Score:3)
1) Write unit tests before writing the actual class. This works great because I can initially lay out what I want my component to do, and if it changes then I just change the test then go change the component. When all the tests succeed the component works and I am done.
2) I have not yet tried this extensively but I understand it in the XP sense. Pair programming is not one person programming with the other watching over their shoulder. It's two people working together on the same problem. Maybe one person has an idea they want to try so they take the drivers seat for awhile, during which the other person thinks of something and suggests it, or maybe he takes over the coding for awhile, explaining his idea to the other person all the while.
3) Requirements gathering.. XP has a pretty good approach to gathering requirements and estimating the time it takes to do a task. I'm not an expert on this aspect so I won't go into it in detail, but it is basically the development team works with the customer to define what is required, then the team comes up with estimates, the customer then helps determine which features are top priority. I think this is pretty common in most processes, but XP so far is the only process I've really thoroughly explored.
4) YAGNI+refactoring (you aren't gonna need it), basically XP states that you don't waste time planning and designing for things you do not presently need. If sometime in the future the software needs something you haven't accounted for, you refactor what you have to allow for the new features. This reduces bugs associated with programming for future requirements that you hardly understand anyway, that may or may not actually be needed. Then when you get to the time you actually need the thing, the requirements have probably changed or solidified and what you originally wrote is now useless.
5) Refactor mercilessly and continuously. If you know what your writing is crap, and you know how to make it right, then stop writing crap and make it right, regardless of whether or not it requires a little backtracking. Read Martin Fowler's "Refactoring" for a good text on this.
RE: Design -- Another thing I've noticed a lot of people saying is that XP completely throws out upfront design. This is not true, it just places less emphasis on it. I still do UML diagrams before I start coding, but it's not so that I can put it in a document and give it to my boss. It's more of a tool for me to play around with different ideas to come up with an approach to how I'm going to solve a problem. Once I think I understand it, I stop diagramming and start coding... if I get stuck, I go back and start diagramming again to kind of work through the problem in an abstract sense. For diagrams to publish, when my software is finished I will usually go back with a tool that will construct UML diagrams out of the actual code, then clean up the generated diagram, and that is what I end up publishing.
XP a threat to the "Design Elite" (Score:4)
These large companies were paying each of us $3,000 per day - sometimes for months on end (don't get me started about the number of $200/head dinners and first class flights they paid for as well) to have us scratch our heads, and think high-minded thoughts about the true relationships between their domain objects. What were the core logical abstractions at work? What (oh yes!) patterns were at work here?
At the time, we really felt like we were doing good work, and they were thrilled to embark on this road. The experience of most of these companies was a background of hard-to-maintain software and failed projects. What better spoke to the fear of the corporate bureaucrat than an approach that favored more up-front design. If they had failed in the past, it was becuase they hadn't planned effectively. Surely, these dirty just-out-of-college kids sitting in the programmer's chairs couldn't be the ones driving their enterprise software. They were much happier with the thought that a group of gurus in suits with the expensive PDAs and laptops somehow using the invisible hand of an abstract and expensive "design" effort to guide the ship.
When these project collapsed under their own weight, as they inevitably would, we were always able to look ourselves in the mirror and know that it wasn't (thank god!) for lack of a proper design. They had obviously tried to cut corners on the implementation. They had tried to cut out features. They had tried to limit the scope of the effort. No one believed that all business objects needed to inherit from the "DirectedBusinessIntention" class. Whatever. Point was that somehow or another, after thousands or millions sunk into these design efforts, things always seemed to go off kilter.
The best part was that when the management that had brought us in got canned along with us, they landed somewhere else and hired us again! Not only that, but they were a solid project reference!
What a great gig. High pay, high living, no real deliverables (other than diagrams and charts). Want to keep us around so that we can point out why all of the implementation problems are a result of something other than our "design"? You bet! That'll be $3,000 / day.
Today, I live in the world of XP. I roll up my sleeves. I write code. I see real design happen at whiteboards. I see designs get implemented. I see code being released to over a million customers EVERY TWO WEEKS.
Critics point out how flawed XP must be becuase they cut out all of the "design". Surely, this software that's being hacked-together on the fly can't be robust - it must be a maze of hacks that falls apart at the first real requirements change. Yeah, yeah. That sermon's sitting somewhere gathering dust in my book on "Deisgn Patterns". It's right next to my Tufte books.
Turns out that good programmers, much to my suprise, can turn out superior designs through the XP process. Abstractions get built when they become needed - not in anticipation of need. Needs change too quickly - you build only the ones that you need. It's a beautiful process. Design does happen, but it gets naturally prioritized with other requirements. You need to change a large piece of a system? Migrate to another platform? Abstract something to support new lines of business? Great. Figure out how to do it, make a case for it, and do it. Just do it in a couple of weeks.
It works. It really does. It's produced the most beautiful and robust software that I've ever seen a large team produce. If there's any downside, it's that it requires really good programmers. It's not a methodology that is well-suited for a situation that supports people who are, for the lack of a better term, "vocational" programmers, or tool-users. All of the developers in an XP project must be able to tread deeply into all aspects of the system.
So, it's no wonder why the people who still stand in the (nicely polished) shoes that I used to wear have a vested interest in attacking XP. Long-term upfront design efforts were (and still are for some) a lucritive gravy train. These folks will try to defend their position through fear-mongering (which works really well in big IS shops). Wherever there's doubt, there's always some extra money around to do some more evaluation. If the design-elite are really lucky, their sponsors will find some money to perform a methodology-evaluation! And who is really better suited to do a methodology evaluation than the design consultants? I wonder what it's results will show?
Oh, while they're frittering away months evaluating methodologies and designing logical and software constructs which may not be needed and will likely never exist, we'll have gone through dozens of major releases of our software. It's feature-set will have evolved to provide tons of dramatic new features that make us actual revenue.
It's not that I don't miss it. I really do. I honestly felt much of the time that I was better than everyone else becuase only I (and my elite friends) had the cranial mass required to really peer into the soul of our client's busienss and understand. That was a pretty good feeling. The $3,000/day and all of the free steaks and booze were okay too. Still, I'd not go back. It's just too darned rewarding to see my work being used by a worldwide audience - to see the ongoing transition from thought to feature happen in weeks instead of years (or never).
If someone's telling you that XP is doomed becuase it is design-poor, just think about why they're telling that to you.
This seems to be what we're doing.. (Score:3)
We don't do pair programming (I'd like to try it some day), but I do find that development is carried out much in the style of XP, especially on web sites.
The customer identifies what they want. The programmer(s) then examines their demands and tells the customer how long each feature will take. You don't say "impossible", you say "we can do it, but that part will take 50x as long as everything else". Since they're paying, they decide what order they want to do things in, and what they can live without. ("oh, I had no idea this feature is so difficult. Nevermind."). Think 3 month plan.
You deliver what they asked for. The customer reviews the deliverable and reports any bugs or whatever they don't like. This is determined by managers to either be new work or a mistake. Then, the next phase begins anew. Customer submits a list of features, you estimate time to complete. This time around, the features they're interested in may go in a totally different direction after they see what you've rendered.
The biggest problem is that the codebase you're developing tends to gravitate towards many different goals, and thus design decisions you made early on may be irrelevant now. After every 4 or 5 development phases, the customer has to realize that you have to take 3 months and consolidate all of the code you've already written. Otherwise you proceed towards chaos.
This seems to be how our sites go. They happen this way because the customer usually wants a site up immediately and can't wait 2-3 years for their grand vision to take place. It seems to work. They're making money, the code isn't terribly unmaintanable. We just kind of gravitated towards this naturally. I've only started hearing about XP very recently.
You still reserve the right to tell customers a flat out no. You're not aimlessly following their demands. They should trust you (since they're paying you) and in this, they are usually understanding of what you say is a good and a bad idea. The managers are there to translate your statement from "Moron. That's a terrible idea. It'll never work" into something non-offensive.
Re:Uninformed comments (Score:2)
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..."
Re:Err... (Score:2)
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.
Re:Let's just call in Drucker and Covey... (Score:2)
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
Oh yes it can...Re:XP code can never be broken! (Score:5)
But where XP can help recover from this is that the atmosphere for testing is still there. When an integration or enduser break happens, the inputs can then go back to the programmer to create a new test case and fix the code by making that test case do what should have been done.
So its still possible to have broken XP code, but at the same time, the fixing of it should also be easy...
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
Re:Err... (Score:2)
I've got a copy of Extreme Programming Explained in front of me, on the back cover it says:
Re:One way of Pair Programming (Score:2)
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
Re:My Take (Score:2)
Ironically, when I am forced to give a surname in a webform, I enter my name as
Cederic A
~Cederic
Re:My perspective on XP (Score:3)
>> the documentation I'm producing is very well recived by the development team.
Ok, you scared the hell out of me.
I hate it when you get a combination of
- a designer who doesn't developer and
- developers who don't design
Tht developers must be involved in the design. They need to be talking about it, thinking through it, and ultimately making the decisions about it. If they're not, they wont buy into it, they have less chance of understanding it, and the likelihood is a less well written piece of software.
Obviously keep someone around who has good design skills. Make them available as a tutor, a guide, a reviewer or a consultant to the developers. But let the developers create the design, reach concensus on the best approach and then go ahead and write it.
Speaking personally about the project I am just finishing, the developers on the project thought through the architecture, bounced a few ideas off the other users of the final solution (it's a technology solution, so good integration was an essential) and then we sat down and thought about the OO design of the main software deliverable. And a couple of hours later we had a piece of paper with pencil scrawls on it, which got pinned on to the board of our pair programming area.
That piece of paper is still there 3 months later, still describes 7 of the 8 major components in the system, depicts their relationship accurately enough that it's not technically wrong, and we're only just next week going to redraw the diagram so we can hand the code over to the support team.
Now I'm not pretending that the only design we did was on a single piece of paper. But the rest of the design was discussed initially in the pair doing the programming on that area, and if necessary by the team as a whole. There were a whole ton of issues that were resolved in this way, including performance considerations, security concerns, and a lot of the run of the mill "so just what does this object do?" type questions. And swift decisions were made, only one of which has so far proved wrong. [That decision was how on much functionality to include in a base class. We abstracted too far and need to refactor a base class and its immediate specialisation to create a single class - hardly a major design flaw.]
Incidentally the system isn't the simplest I've ever written - securely handling financial transactions in a time critical environment for several hundred concurrent users.
So to get back on topic, had we been developing to documentation provided by another designer, I'd have quit the company by now and we wouldn't have any software to deliver. Instead, by using experienced software engineers to assist and guide and making sure the development team knew their design patterns, we have created a fine piece of software. Trust your developers, they're better than you think.
~Cederic
Re:Programmers write the Unit Tests? (Score:3)
Programmers should always write unit tests. Most don't (in my experience) but they should.
However, in XP a programmer never tests his own code. TWO programmers test THEIR code. Which means that while one is writing it, the other is sat there thinking of other ways to break it. And at the unit test level, this is highly effective.
System level testing (I'm going to avoid the "what is system/integration/uat/etc testing" debate) still needs to be done, and should not be done by the programmer responsible for the code. But in XP those tests are determined and designed by the customer, not the developer.
~Cederic
Re:My Take (Score:5)
A brief response:
1. Irrelevant. Describe the methodology and what it means and achieves. Call it XP right through this. Sell it well enough and when they do find out what XP stands for, they'll only find it amusing, not off-putting.
2. We should all be doing these things, but I've never seen them done properly by someone that hasn't read XP books. And I don't know many people that have.
3. I am continually annoyed, scared and depressed by the comments on designing up front. For $40m projects doing air traffic control then sure, you want some pretty sweet documentation. But for 98% of business systems you need enough to get to your first deliverable. And that's not much. The design needs to accommodate the immediate requirements, and if you follow design patterns and don't actually close off expansion capability, then you can adapt to the changes needed for further deliverables. XP isn't about diving on in and coding, it's about thinking how to deliver what is needed. And if future capabilities aren't needed now, just don't spend time writing them - it's quick, cheap and easy to change code.
4. Well written code is far more useful to me than bad documentation. And in a business environment, working on code more than a couple of months old, ALL documentation is bad documentation - it is invariably out of date, imprecise and often irrelevant. Whereas the code tells you very accurately what is happening.
This doesn't mean the occasional class diagram or process flow wont help, but any member of the development team should be capable of drawing them up on a whiteboard without prompting, and that's the correct place for them. Documentation that isn't updated but is referred to will cause more bugs than having none in the first place.
Bear in mind of course that if you're properly following XP, and you write your unit tests to the same standard that you adhere to for your live code, then the unit tests provide a fantastic resource for seeing example usage of the live code. And examples are immensely more useful than documents.
5. You put forward a very negative and close-minded view. I'm often irritable, I swear at my computer let alone other people, I am very opinionated and disagreeable and I love an argument. Worryingly, so is the guy I've been pairing with for the past few weeks. And yet we're now turning out code much better than either of us managed individually, and we're working very efficiently. And we're also very keen to continue pairing because there are so many benefits it would be silly to stop. If someone's personality prevents them pairing them it's almost certainly going to prevent them working with the team as well, in which case most businesses would be better off with someone else - a good team provides more than the sum of its components.
I'm sure a lot of people will keep using XP, and that a lot wont go near it. And I'm convinced that many of the practices should be kept. But I think discounting it because you don't like the name and are scared of pairing with someone else is highly unprofessional and closed minded.
~Cederic
The sleep of reason(design) begets monsters (Score:2)
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.
Extreme programming is a process not a result (Score:2)
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.
Ok, then why not try XP? (Score:2)
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
Re:The sleep of reason(design) begets monsters (Score:2)
Simple. When the customer stops paying you.
Re:What exactly is extreme about it? (Score:2)
If its so common sense, then why do so few people do these things?
Re:Understand before you speak (Score:2)
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.
Re:XP is the most stupid thing sinse... (Score:2)
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.
Re:XP is the most stupid thing sinse... (Score:2)
Some of XP can work. Obviously pair programming is a problem with just one person. But iterative cycles do work well.
Re:Experiences of extreme programming? (Score:2)
Re:XP code can never be broken! (Score:2)
Man, that's a badly designed book.
Quick Q: Who is chromatic? (Score:3)
What's even weirder is that even his resume [wgz.org] doesn't contain his real name!
Unless this person legally changed his name to 'chormatic', this is just a bit too eccentric for my taste. Anyone got some insight?
PS: I'm asking this because I'd like to know who exactly am I criticizing when I'm placing comments on someone's reviews.
Re:References (Score:2)
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.
--
Why have I never heard of this before? (Score:2)
;-)
Take a look at his home page now... (Score:2)
Re:Why have I never heard of this before? (Score:2)
In fact I counted 4 previous articles on XP.
Re:The sleep of reason(design) begets monsters (Score:2)
That's what the unit tests are for.
Re:XP (Score:2)
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? ;^)
Re:XP (Score:2)
Re:XP (Score:2)
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.
Re:XP (Score:2)
Re:XP code can never be broken! (Score:3)
The book wasn't designed. He just kept adding chapters until it passed all the tests. :^)
Here's what really happens... (Score:2)
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.
Trimming at the edges (Score:2)
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.
Is XP a recipe for bad software? (Score:2)
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...
Re:AAAARRRRRGHHHH!!!!! (Score:2)
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.
Re:My perspective on XP (Score:2)
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?"
Re:My perspective on XP (Score:2)
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.
Re:My perspective on XP (Score:2)
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.
Re:My perspective on XP (Score:2)
"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.
Slashcode process? (Score:2)
Re:Err... (Score:2)
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.
Get a proxy (Score:2)
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 [useit.com], 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.
Sufficient unto the day are the troubles thereof (Score:2)
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 [amazon.com]. 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.
Re:Let's just call in Drucker and Covey... (Score:2)
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.
Re:AAAARRRRRGHHHH!!!!! (Score:2)
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.
Re:This seems to be what we're doing.. (Score:2)
Try it! It sounds ridiculous and takes a little adjustment, but I really enjoyed it once I got the hang of it. My big tip: start slow. Do it for an hour a day for a while and then ramp up.
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.
The XP answer to this is that you do the redesign continuously, whenever a piece of ugliness gets in your way. The trick is to do the redesign in little steps, as suggested in Martin Fowler's Refactoring. But you can only do this effectively with some of the other XP practices, particularly good unit tests, tight teams, and good version control.
bang the drum slowly (Score:2)
[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 [antioffline.com]
References (Score:5)
However, decent references are sorely missing from this story, like for example
the book by Kent Beck [fatbrain.com] and one of the more comprehensive web sites, www.xprogramming.com [xprogramming.com] by Ron Jeffries, with links to a lot of other resources on XP.
Why is it (Score:2)
--
Re:My perspective on XP (Score:2)
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.
My perspective on XP (Score:3)
I did like the idea of generating a test case and coding to it. I think that in a lot of cases regular regression testing can save you big hassles down the raod.
What I didn't like was the "design as you go" concept. I can't imagine this doing anything but biting you in the ass, lots, really hard. A lack of design and forethought can only create a huge mess as soon as you try and extend anything.
I have a theory were this idea comes from. A lot of the design work that goes on in projects is done very poorly. The design as you go approach is a reaction to it. Its' pretty common to have a design team that spins its' wheels, goes off into rediculous tangents and generates reams of paper without seeming to acomplish anything tangible. This is really a common thread in my experience and a lot of other people's I've talked about it with. I think this happens because design work is really hard, its' way too easy to get stuck. Many of the people that work on design teams or as application arcitects have no buisness filling that role.
Good application design is really its' own disipline. I'm working as a design guy in the very early stages of a project right now, the first time I've done this kind of work. To my own surprise I seem to be pretty good at it. I'm able to keep the work moving, hitting the milestones I've set for myself on time and the documentation I'm producing is very well recived by the development team.
I think its' unfortunate that this approach to design is becomming more popular. I think if people made more of an effort to understand the design phase of a project and get the right people working on it they'd be way better off. To many really bright programmers get stuck doing this kind of work as they gain more experience and some of them just aren't any good at it.
Re:XP (Score:2)
In XP you *AND* your partner in crime design the test cases, and write the code.
Pair Programming is a fundamental in XP.
Re:Err... (Score:2)
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.
AAAARRRRRGHHHH!!!!! (Score:5)
http://slashdot.org/search.pl?query=Extreme+Pro
Variations on the same article over and over and over and over and over again. I get the message already, and I'm not going to switch just because it's advertised here three times a week, so kindly *stop it already*.
Err... (Score:5)
So, they're saying, "Figure out what's good and do it," huh? Well, it's good advice, but isn't it pretty much what we're supposed to in the first place?
I've never had someone come up to me and say "Write good code!"
I always thought that the "write good code" statement was implicit. If I'm writing code in any serious fashion, it's going to be the best I can do.
Maybe everyone else has been writing bad code intentionally all this time... They just needed to be told to do a good job! "Well, no one ever SAID 'Write good code' to me..."
Re:bang the drum slowly (Score:2)
Customers are allowed to ask for anything they want. Programmers are allowed to force the customer to refine what they are asking for until the story can be estimated and tested. Programmers then assign an estimate to it, somewhere in the range of 1-3 weeks. Customers can then make intelligent choices about the value of a story versus its cost. As for your second point, how is this customer/programmer relationship different from any other methodology. Someone has to decide what gets worked on. In most methodologies, programmers end up making these decisions, based on what seems cool. In Xp, Business decisions are made by business people. What a novel concept :)
Re:Err... (Score:2)
I don't necessarily argree with that statement. If a coder doesn't understand the business context of the code he's going to write, how will he determine if the specs make any sense. Yes, we should all be given specs that are correct, but we all know this isn't always the case. If I don't know the business context, I could spend weeks writing code that will work to the specs, but won't do anything useful.
My Take (Score:3)
1. Stupid, stupid name. Guaranteed to turn off management and mature programmers. Extreme sports = risky and dangerous. Extreme Programming has the same connotation.
2. Some aspects are just good development practices - frequent unit testing, constant customer feedback, code review - that we should all be doing anyway.
3. Some aspects are worrysome, especially the idea that one shouldn't design up front. As far as I'm concerned, we should always start with a thorough requirements spec and design, but we should always be ready to make changes to the spec and design in response to customer feedback. XP wants us to develop requirements and design as we go - to skip design and jump to the change process. That might work on small projects, but on anything non-trivial it's a recipe for disaster.
4. Another worrysome aspect - XP holds that code should be self-documenting and that other documentation isn't necessary. I've been programming for more years than I care to admit here and I've never seen code that was truly self-documenting. I saw some code recently that was written by someone using XP methodologies and it was as obtuse as any code I've ever seen. I pity anyone who has to go in and maintain XP code a year after it was written.
5. Finally, pair programming might work for some people, but for others it will be a productivity and morale killer. It depends on the personalities of those involved. Personally, I can't think with someone looking over my shoulder.
XP looks to me like the next management/development/whatever fad. It will make a big noise for awhile, lots of projects will be started using it, lots of projects will fail, and in the long run, some of the good parts of it (unit testing, feedback, etc.) will be added to our utility belts and the rest discarded as it should be (esp. the stupid name!).
Disappointed with O'Reilly (Score:2)
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.
Re:Groundhog Day (Score:2)
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 :)
Your Management Skill (Score:3)
I think these comments reflection on your [lack of] Management ability rather than your programmers [lack of] ability. If your Engineers are consistently getting their estimates this wrong, YOU must be at fault.
I can imagine the scenario; after reading the email request from your customer, you print it out and walk over to the guy's desk, hand over the print out and ask how long; you stand over him whilst he reads the email and when he gazes at the roof in though, you hit them with it. How Long ? He um's and arh a little and you repeat a question. They respond, with a figure they know will make you go away.
As you walk away, your think to yourself; these guy's always get it Wrong. So you think to your self, no he can't do it that quickly, so you double (or triple) the estimate and enter in your plan (I'm giving you the benefit of the doubt and assuming you have a plan). Some times you think it's too long; the Customer will never go for it, so lets half it, and enter that in the plan. So not only have you not given the engineer a reasonable chance to consider the question, you ignored his response.
Result, your programmers only ever make the plan by accident, and you believe programmers cannot estimate.
My team, (of which I'm the senior Engineer, not the Manager) has just made three Project plans, with time to spare and exceeded the requirement (by including lower priority deferred requirements). Now this is not because I'm (or anybody else) is some super coding or team leading guru.
It is not even difficult, it just takes discipline. Firstly we clarify and digest the requirements. We chew over the requirements, and a few implementation details, to make sure we understand them. We conduct and document the design at high level. We can usually count the function points, by now, this gives a raw estimate. We factor in detailed design, testing and integration, based on the number of function points to produce an highly accurate estimate. We factor in a contingency; all this takes a couple of days. The customer gets estimate they can believe. They even start to really listen to you, and trust your judgement.
Re:bang the drum slowly (Score:2)
The the customer views the estimates and at that point decides which ones are worth more to them, given their cost/benefit. It is doubtful they will select a story with finite benefit and infinite cost, but they might. It's the customer's choice how they spend their money.
This example adheres strictly to XP. XP is a human process, however, and the programmers may just say "it can't be done". They can't snowjob the customer, though.
Re:Programmers write the Unit Tests? (Score:2)
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.
Re:Also forgets about REFACTORING (Score:2)
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).
Re:Here's what really happens... (Score:2)
You've either studied some XP before or this is a coincidence. It requires that all best estimates are multiplied by the load factor (actually, I think it's called something else now). The suggested method of determining this factor is to start with 3 (the number you stated), then in the next iteration, use the actual load factor from the previous iteration (called "Yesterday's Weather").
Re:XP (Score:2)
Re:Programmers write the Unit Tests? (Score:2)
j
"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."
Not quite as facile as you'd think (Score:2)
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.
--
Re:Quick Q: Who is chromatic? (Score:2)
So?
What's the diff 'tween Chromatic and, say, Marilyn Manson? Or Marilyn Monroe, for that matter? It's just a name.
How about the guy who wrote Programming The Perl DBI [oreilly.com], Alligator Descartes [symbolstone.org]?
And how do we know that Tim Bunce is actually that guy's name? Huh? HUH? HOW ABOUT THAT?
--
The problem extreme programming seeks to solve (Score:2)
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.
Re:Experiences of extreme programming? (Score:2)
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.
XP code can never be broken! (Score:2)
Re:bang the drum slowly (Score:2)
You're quite right. I work as a software architect/designer on a very large ERP system, designed for implementation in the corrugated board industry. The system was originally produced for a company which has really been streamlined over the years, and the software matches that 'model'. In the last few years we started implementing this ERP in other companies (within the same holding). These companies however, are not as streamlined as the original company is, so implemantation is not so easy.
One thing I learned over the years is not listen too hard to what users are saying, because not every user is fully aware of what the motives and the future plans are of the company they work for. And in our case, the holding told us not to deviate from the original model. So now we get into all sorts of discussions with users who are still working in the oldfashioned way; and you don't want that sort of user to decide what your system will look like. I don't really see how an environment like I'm working in could adapt to Extreme Programming. We've got a nice array of architects & designers, and in my view, we couldn't do without them. The article speaks too much about users meeting programmers, as if designing and planning functionality doesn't really exist!OSS Quality (Score:2)
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.
--
Re:The sleep of reason(design) begets monsters (Score:2)
Surely, a prototype does that for you.
documentation is essential to insure the survivability of the implementation.
I don't know about your experiences, but I've yet to work on a project that is more than a year old where the documentation bears any useful relation to the code. 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 developers who wrote the objects, by writing unit test. This is the point of unit tests, that even a year down the line, when new developers come along and tinker with that object, they don't have to go looking through reams of documentation to find the state transition diagram for the class and make sure that they aren't violating anything. They do the changes that they need to do, and if they have broken any state change rules, the unit tests will tell them.
Of course this does rely on someone writing the unit tests properly in the first place, but otherwise you are relying on someone having documented it correctly in the first place, and I'm inclined to believe that most programmers are better at coding than documenting.
The clients will come back and ask for those very features when they see the system in operation.
Again, in my experience, users tend to come back and ask for everything but the changes that you (and they) thought they would. I've lost track of the months (probably years) wasted designing and implementing flexible systems that allow us to easily add features in the areas that they think they will be changing in the next six months, only to find that in six months time the business is heading off in a different direction, and they never ask for that area. For example, I once spent six months taking a system that processed credit applications by applying business rules in a fixed order. Someone wanted to apply some of them in a different order. We could have taken what we had, and extended it to allow them to do it this new way as well. It would have taken a few weeks, but instead it was decided that it would be a really good idea to implement a fully flexible flow with a pretty graphical UI so that it would be really easy for users to add new business processes whenever they wanted. We spent six months making the system as flexible as possible. Everyone liked it, but no one used it. As far as I know in the 6 years since it was written, there was not one system built using a different flow (and I think it was actually dropped from subsiquent versions, because no one wanted it).
Re:Not practical (Score:3)
Why would the non-XP code already have these functions in place, but the XP code wouldn't? If there was a previous requirement to do similar tasks then the code would be in place in XP. If there wasn't a previous requirement, why did you waste time adding it, rather than shipping what they needed earlier? How much other code is in your software that you don't need yet?
It's possible that the functions were more tightly bound into specific objects rather than in nice class hierachies in the XP version, but if the unit tests are in place for the original functions, it shouldn't take too long to refactor the design to make it more generic (by abstacting out the functions that you are actually going to be using in two places rather than ones that you think might be needed in the future). This may sometimes take longer than the equivilent change in a system that has had major design done up front, but in my experience, the that's more than balanced out by the huge savings in upfront design time and writing these functions that someone might use in the future (but usually don't).
Re:Quick Q: Who is chromatic? (Score:3)
>> I'd like to know who exactly am I criticizing...
Why does that matter? Your citicism of TPKAC's 1 work should not be any different simply because you can pin a face to the moniker. If you disagree with chromatic's work, then do so. Remember, the criticism is only effective when it's offered in response to what a person does, rather than who they are.
Clearly, chromatic values his privacy for reasons that have not been documented publically. I can think of several reasons why this might be the case.
He could be a celebrity in certain circles and wants his technical contributions valued on their own merit or without the baggage of his real world identity.
He might work for an agency unpopular in Hacker circles, e.g. the NSA, FBI, CIA, DOD, or other TLA organizations.
He could be a fugitive from a legal authority or extralegel agencies.
He's been the victim of identity theft and wishes to never repeat that experience.
He knows there are some real weirdos online and doesn't want to open his family or home life to the more aggressive wackos.
Maybe he thinks it doesn't really matter who he is.
He could be a conspiracy theorist waiting for the MIB at FEMA to trigger the NWO.
Maybe he's small furry green creature from Alpha Centauri. Or maybe he's Hitler's son.
(And, yes, I'm assuming that chromatic is a he, since our language doesn't have an appropriate genderless pronoun. He could be a she; it's happened before.)
Regardless, I strongly suspect that chromatic wants you to focus on what he does, not who he is.
Cope.
--c
Footnote 1 - The Person Known As Chromatic.
Re:XP (Score:2)
Re:Buzzword compliant? (Score:2)
---------------------------
Re:Good advice (Score:2)
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!
Not practical (Score:2)
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.
Let's just call in Drucker and Covey... (Score:4)
The article assumes that the customer is perfect. (Score:2)
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.
Extreme prototyping (Score:2)
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!
Re:Err...Fast and Cheap and good via backdoor. (Score:2)
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.
eXtreme Programming (Score:2)
It's certainly a small enough book to read at the bookstore café, if one has no intention of buying it.
Dangerous. (Score:2)
"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.
Re:Err... (Score:2)
Coders, essentially, produce code. They don't (or shouldn't) have to understand the business context around that code, except in as far as understanding that process X needs to be fast, and process Y needs good fail-safety etc. Things that are quantifiable to a programmer.
Too many coders get sucked into management. Though admittedly, this is exactly what many of them want...
Anyway, as an aside, XP is about more than just cutting your job down to coding. It's also the techniques for producing good code. And very cool fun to do, too.
"God is dead." - Nietszche
Re:Uninformed comments (Score:2)
Re:Uninformed comments (Score:2)
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.
Uninformed comments (Score:5)
Most comments are pointing out that XP is yet another management buzzword or it's just stating the obvious. Well, it's neither. XP stands against all the principles touted by the waterfall model or the Rational Unified process and shite like that. XP is basically saying "toss out that copy of Rational Rose because you ain't gonna need it". If it doesn't make your job easier (and Rational Rose doesn't, believe me) toss it out. If you're already building five classes to parse a simple parameters file toss it out because you ain't gonna need it. XP points out (quite accurately) that the design for change is only useful if we allow extendibility in the right places. Unfortunately this requires you to analyze your problem domain beyond what's needed to ship your product and most of the time you'll still get it wrong. You'll get it worong because you don't have a crystal ball. You can't tell what the customer will want next. This way you eliminate the whole code design circus and end up with simple code that does what it's supposed to do, no more, no less.
One of the most important aspects of XP is unit testing. XP recommends that unit tests be written before the code that's supposed to pass those tests. This is more important than you think for two reasons.
Reason one: how are you supposed to develop your code if you don't know how to test it? When you write your unit tests you gain insight into the exact functionality of your code.
Reason number two: If you write your tests after you develop the code your tests will most likely only test the scenarios you considered when you were writing the code. Your tests will most liekely be incomplete because they'll have a slant towards your implementation.
Coding in pairs is probably the most prominent and the most controversial aspect of the system. It's important to realise the benefits of pair programming though. No code ownership means people can't get territorial about their code so everyone is free to change it when they need to change it. I've seen shops where changing John's code was considered politically incorrect and often John would take the issue personally. In other words if John wrote the message dispatcher John and John alone would decide on it's shape, form and future directions. XP essentially says that the hypothetical John can no longer pee around "his" piece of code and keep it as a guarded secret because John is no longer the sole developer of the message dispatcher. If John gets territorial about his work, John gets moved on to do something else and somebody else takes over until they start growing attached to the code again. Lather, rinse, repeat.
Besides code ownership and territorial programmers the other issue that XP takes on is coding primadonnas. Most software shops have a standard (sad) working model. One self promoted primadonna coding 70% of the application including the critical subsystems and the other twenty developers working around the edges "helping" the primadonna and trying hard not to get in her way. Our primadonna often isn't even the best coder on the team but surely is the most bullish and opinionated and thus grabs all the exciting work. Everyone else is just supposed to feel inferior and work on some tiny pet project of their own. This is not only grossly underutilises the rest of the team but usually at some point puts the project in jeopardy because the primadonna has now found another company to prey on. Project "gurus" have mushroomed throughout this industry and weeding them out may prove challenging. XP offers a very radical albeit a very promising way of achieving that.
This comment is growing a little long now so I'll shut up at this point. I hope this offers some enlightenment to those who keep on saying that XP is just another waterfall mutilation. It's not. It's a hackers methodology. On the side not however, I to have an issue with the name and the accronym. It's just juvenile.
Re:Experiences of extreme programming? (Score:3)
I would also not recommend using XP if you are using a team of consultants for the short term. What usually happens first when you implement XP is that documentation tends to become poor. This is bad if the developers are leaving your company next month.
Those XP features that I have seen to be most useful are:
"Pair" programming or rather more extensive code reviews whitout having to sit in each other's lap. Two developers are always responsible for a certain area.
Short release cycles (yes 6 weeks is possible for a major B2B site)
Extensive testing with as much help as possible from an automated tool such as a Build Manager, Rational teamtest etc
Heavy focus on feature prioritization. This will involve people who might not be used to prioritization for short cycles.
Also make sure that you do "sunset reviews" (including the entire team) after each cycle to continually gather feedback on how the previous cycle worked out and how to improve the coming cycle.
All in all it is not that "Extreme" but more like common sense.
Peter
Also forgets about REFACTORING (Score:3)
Good advice (Score:5)
--
Programmers write the Unit Tests? (Score:2)
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.
-----------------
Re:Err... (Score:3)
A coder knowing the context is a bad thing. His context ends at the public interface and if he needs more information then something is wrong with the design. If he knows more than the public interface spec then he is likely to use that information (consciously or not) and make assumptions about the environment in which his code will run. In the long run, those assumptions will turn out to be wrong and his code will break.
The most productive environment I ever worked thought about the problem and listed the functions that were likely to be useful in creating the application (we were coding in C).
Once the specific functions were identified, it was considered if they weren't instances of more generic functions. If so, then the generic function was substituted as a requirement.
Then people split into pairs and wrote code to implement those functions without regard as to their application. Since we had a prototype statement and everything had to be explicitly passed in and out, we could. Coding in pairs allowed one person to focus on syntax and typing while the other thought about the algorithm and spotted bugs. If a routine turned out to be more than about 50 lines (without comments) it was mostly likely broken into two routines.
Each "finished" routine was then tested rigorously. Inputs which caused failure had to be fixed or at least caught. All the routines were kept in libraries by religiously using make with ar to keep things synch'd.
Only after all the library routines were written did we go back to the application which was now fairly trivial to write. Using these techniques we were able to write as much as 2,000 LOC of bug free C code per pair per day. Typical productivity was more like 500 LOC per pair per day of bug free code.
By bug free I mean relative to normal standards. Obviously we sometimes found a bug but the rate was something like 1 bug per 100,000 lines of code in the first six months of use, or less. Code that had been in use for more than six months had perhaps 1 bug in a million lines of code and that showed up in the first year. Code older than a year didn't provoke any bugs that might have remained.
Think top down then code bottom up, don't make assumptions about contexts, pass everything explicitly, test continuously (especially unit test - consider making it the last step make does when compiling), use good tools like make, RCS/CVS, ar, or whatever analogues apply in your environment.
Understand before you speak (Score:4)
I just love it when people blurt out erroneous information about a subject/product/project that they have never seen or used.
The main concern people have here is that in XP you don't design. That is a false statement. In XP iterations are encouraged and design, for an iteration, takes place at the beginning of that iteration. Its true in XP you don't design a large application at the beginning of the application, that ends up begin a waste of time. Any one who has ever worked as a programmer realizes that user requirements change on an almost daily basis. This iterative design process allows for change. In fact, one of XPs mottos is "Embrace Change".
The best argument for the use of XP is that it works, better then any other methodology I have ever used. The iterative design process, user stories, unit testing, constant code commitment, pair programming. These concepts brought together in the form of XP produce a balanced environment that tends to produce what the customer wants in the time frame he wants it. In short, it helps us do our job as developers well.
With XP you get well-designed, extensible, modular code. You are also encouraged to reuse it whenever possible.
Is XP a panacea? No, not by a long shot. On of the principle complaints I get when I introduce some of the concepts and procedures to a client is the statement "Oh our coders don't like procedures, they will never do that". This comes back to the fact that if you can't get your coders to follow any procedure, than it is likely that no procedure will work for you.
Although I am a full time coder and like XP, most coders do not. XP, by design, reduces the likely hood of cowboy coders (in the American sense) by design. If XP is implemented correctly it wont be long before almost everyone has a similar level of knowledge, this level is usually equal to the highest pre-XP level.