Slashdot Mirror
Beck and Andres on Extreme Programming
narramissic writes "In recent years, Extreme Programming (XP) has come of age. Its principles of transparency, trust and accountability represent a change of context that is good not only for software development but for everyone involved in the process. In this interview, Kent Beck and Cynthia Andres, co-authors of 'Extreme Programming Explained: Embrace Change,' discuss how XP makes improvement possible."
I was hoping for something a little closer to Extreme Ironing.
That would have been cool.
This is too extreme even for slashdot...
In my opinion, extreme programming is extremely overrated. Some of the ideas, such as test-driven development (although this concept is not restricted to XP), work well. Others, such as pair programming just do not work in my opinion. Programmersare solo beasts - putting two of these dragons behind one keyboard is asking for trouble.
Coca-Cola, sometimes War.
agile approaches, agile software development in project management movement, open and honest communications
So what's this about, apart from the management-speak?
I feel like I read half dozen pages with barely any content.
I can explain it for you, but I can't understand it for you.
*skims article*
XP blah blah trust blah improvement blah Embrace blah
*kicks in knee-jerk anti-M$ flame*
I can explain it for you, but I can't understand it for you.
I find this funny as the programming behind Windows XP relate to none of these.
In the not too distant future, next Sunday A.D.
Thank goodness Slashdot's there to help publicise not only ground breaking new books, but even new editions. I really wouldn't want to miss the opportunity to discover why I need to buy book v2.0.
Does anyone remember when Slashdot wasn't quite so heavily infected by the insideous PR virus?
http://developers.slashdot.org/article.pl?sid=01/0 4/03/1633250&mode=thread
The more you regulate a company, the worse its products become.
To me, the word "extreme" sounds like they program in assembly 24x7 for one week straight, or they program with laptops, while running away from a pack of wolves or something. But apparently it's not like that. So what makes it so "extreme"? Did they come up with that name when they were discussing their interests with their jock-friends?
"Oh yeah, I'm in to pretty extreme things. Currently I'm doing base-jumping and ultimate-fighting. How about you?"
"Well.... uh.... I'm in to.... EXTREME programming"
"Whoa! Radical!"
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Kent Beck hits the proverbial nail on the head with this zinger (which I'm sure is certain to stir up quite a few):
... I think programmers are, or at least can be, adults and can and should, for the good of development and themselves, act that way."
"It's not all about programming. It's not all about programmers. Programmers aren't somehow special and to be protected and coddled. I used to say often that programmers were children. They liked not to be yelled at and to have more toys
The above quote sums up almost every problem that I have seen over the past 10 years with the various development shops I've been a part of.
If it doesn't involve fire or razorblades it's not extreme. I hate the way the word has lost it's meaning these days...
Never underestimate the power of stupid people in large groups.
Xtreme Programming: Never have so many invested so much on a proposition backed by so little evidence.
I'm awake! The answer is BONK!
IMO real extreme programming should involve at least 3 of the following:
ccalam - acoustic versions of new songs.
When are slashdotters going to figure out that eXtreme Programming (sometimes called XP) has nothing at all to do with Windows XP? They happen to share a two-letter abbreviation, but that's it.
XP != Windows.
You just found out what the "extreme" in "extreme programming" refers to.
IRAQ.
Although I am a proponent of some XP concepts and feel certain concepts can help with software quality and delivery time, this article does not highlight any of them. This article is nothing more than "blah blah blah, XP is great, now go and buy my book". How on earth did the editors let this one in.
I don't understand this. You write the test before you write the code? This doesn't work in real life because, as every experienced coder will know, the goal posts get shifted at the last moment, usually a week before the product's supposed to go live.
Summation 2
It looks like it's had the curse of consultants beat it down with their theory and "improvements"
Cliff Claven
K.E.G. Party Chairman
Founding Leader of: Koncerned for Egalitarin Governance
Personaly I miss the days of eXtreme Obfuscation, when multi-year projects, even entire careers, could be made of producing and deciphering intentionally and inadvertantly obfuscated code. Especially when you really had to dig through 4 foot high stacks of 14 7/8 x 11 green bar source listings and associated core dumps just to figure out that some asshole was relocating buffers on a vector just to fsck with the person coming along behind him.
Perhaps XP should point out a few outstanding successes instead of perpetual promising of improvement. So far, in my experience, the net result is pretty abysmal performance and several extreme failures.
This eXtreme-whatever fashion really has to end. It's just the new buzzword, but it has been way to far this time. Everything from candy and books to programming and movies are X.
We don't need EXTREME things, why don't you try with creative, different, innovative things?
People lives such boring lifes, and they have been buying shit for so many years that all the usual lies used to sell are not longer valid, so we have to go the the limits, THIS time there really is something new!. Bullshit.
All this stuff is the Paulo Coelho of Programming. Bullshit literature for those not manly enough to just code C/C++/Perl/Python/PHP. This are real languages, and they have all we need. But we are in the reign of Coelho's bullshit books; and so, something being just good is not enough anymore. It has to be different to everything else in every way possible, it needs shinny mirrors all over it, and it needs to be easy, it must "change your life", and "take you to new levels".
I'm tired of this world, that's why i don't live in it.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
"The XP books make very clear that it's either all or nothing. They don't claim that pair programming by itself is always useful, they just claim that this whole set of techniques taken together is useful. If you're going to do all the other things XP says, XP says you should combine it with pair programming."
This is just good marketing. By making this "all or nothing" claim, XP has a built-in excuse that you are invoking here. Ever noticed that you hear the phrase "because you're not doing it right" more often with XP than with other approaches?
Because all the programmer I know around are quite adult, responsible, and do not care for the latest toy. But they do care that they are given enough time to implement features, taht the features are correctly documented, that the spec are there etc... And in the last 6 years I was there, those point were not met, and usually the manager were responsible for a reason or another, but never beared the responsability.
To sum up, to define the programmer as "child", is really disapparging, and far far away from reality of the average software developpement shop. Most are average guys which want to do a correct job, but are put in impossible situation by management.
No if the quote would be applied to manager "manager are like child, they like to play and win, but do not wish any responsasbility in tehir action".
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
"It's not all about programming. It's not all about programmers. Programmers aren't somehow special and to be protected and coddled."
As a programmer, I agree 100%. I expect to work and be treated like any other professional.
NOT as a lab rat for "extreme programming" or whatever buzzword-laden feelgood bullshit management scheme comes along this week.
You wouldn't go to a painter and say "I want you to make me a painting. It doesn't matter what it consists of yet, we'll worry about that later. Just start out with a box or something and we'll meet every day and figure it out from there. And just to make damn sure you can't get anything done, I've hired another painter whose role is to sit around and annoy you." So why does that make sense for programmers?
There is also one good tool called Petra supporting extreme programming prototyping http://petra.cleverlance.com/ We use it and love it.
That was the most sensible post I've seen here so far.
Ian Ameline
Most people have moved onto other agile methods like SCRUM. XP had a lot of hype, by its authors mainly, and now many of its techniques have proven to unusable and have no value. I know of at least 1 300 billion dollar company that tried it and left it behind because it was wasteful in many ways.
Agile Programming is like a late night infomercial without the "these results are not typical" disclaimer.
I'm not a real engineer, but my layman's understanding is that the engineering equivalent of formal methods involves the mathematical calculation of loads and stresses.
E++99:
:)
Mikkeles did answer citing Structural engineering - analysis of components and connections based on the science of strength of materials, and Aeronautical engineering - design is based on computer simulation of air flows over wings and fuselage, then confirmed by testing, which is not antiethical to formal methods of physical components.
As I was suspecting, those are valid engineering examples, but neither exhibit formal methods as such. They use analytical methods, which are fine and efficient, but which are nowhere near formal methods as I know them. And neither are more "real engineering" than SW engineering; they are reality engineering if one so wishes to differentiate them from SW.
In fact, SW is the only engineering where formal methods might be considered, and SW engineering can be just as reality oriented as structural engineering. Indeed, structural engineering could barely be achieved today without SW.
However, I would venture that possible stresses on a bridge can indeed outnumber possible interactions with some SW. It just depends on how close to reality you want your real structural engineering to be. Finite elements, paradoxically, can always be broken in smaller pieces.
Chip design is a good example of such uses in "real engineering". The whole semiconductor industry is permeated with "strongly formal" tools implementing different types of formal methods at their core. These vary hugely, from loose fuzzy logic design aids to stronger expert system parameter, timing and topology validation, to the full blown formal methods that a language-based computer scientist would recognize.
And it's been going on for decades. The FPU of the well-known transputer CPUs from the 80's were designed using formal methods.
If integrated circuits were crafted using our current manual programming methods, 99% of computers would be dead 99% of the time.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Hello. I have a delivery for you.
*WHAM* <-- sarcasm cluebat
You're welcome.
shana
As a non-layman, highly SW-based, real enough engineer (and other than that an almost normal person), I would not parallel, for instance, structural analysis in civil engineering with formal methods in SW engineering. "Formal method" is the name of a specific kind of SW analysis tool, based on mathematically proving the software, not taking stress scenarios into account (stress simulation for SW is called "testing" :) ).
Taken as is, XP can work very well - for teams that are already strongly of that mindset.
However, typical development teams are not staffed by management based upon styles, ideologies, or personalities. It is often by things such as where they sit (seriously) and whether or not they just finished something. A group of 5 "resources" are put together and told to work. If you take 5 random people and try to get them to use XP well, I can pretty much guarantee things won't work terribly well. To be fair, any process is going to have trouble with the typical staffing methodology prevalent in the marketplace.
If you get a bunch of people who lean towards the XP style, use XP. Great. If not, use a different model. Tailor your process to the people. A process can be changed easily, people's personalities can not.
First a disclaimer: I worked on an ADP project that involved Intelliware - an XP shop to build a mutual fund prospectus preprinting system (system that collected information from different mutual fund vendors, and used customer information to decide what and when to print and to mail to that customer.) This was a second iteration of the project. The first iteration had to be scrapped, because the same vendor provided a solution that did not scale to the task, when major Canadian banks came online.
My impression from the entire excercise, (which included daily standup meetings, story cards, paired programming, unit testing, end of the day documentation.) The process became very very wasteful. I personally saw that putting 2 contractor programmers, each at 90/hr at one workstation does generate dialog between the programmer, where both have to generally agree on the approach to any given problem but I did not see any performance improvement achieved by this approach over havin one 90/hr contractor doing the same thing. Since the requirements of the system were still being 'refined' and since there still were deadlines to achieve, the pair had to produce as much code as possible in a very short time period and various bugs still slipped through the process (most of which admittedly were caught by the unit testing, but unit testing.)
The daily standup meetings were mandatory of-course even though most people loathed those. There still were 'overal architects' on the process, and due to the politics of this specific vendor they forced a custom server solution upon the customer (even amid my vivid objections. I was trying to get the vendor to use existing server and framework solutions, unfortunately my voice was not heard, there was no will to prevent the imminent demise of the project by concentrating on the problem at hand and not getting ourselves into a proprietary application server territory.)
Basically the project was not delivered on time (and as I at the time predicted) went over the original time estimates by about a year. I was forced to leave 3 months into the project because I became to frank with the department director. 3 months after I left, Intelliware was forced out the door as well. The project was partially delivered within the time that I estimated, the department director had to leave the department as well.
I do not get any warm and fuzzy feelings about anyone promoting XP, I right away start looking for ulterior motivations. My personal feeling is that people who do not want to carry any responsibility for the project, for the code, for the requirements welcome XP (or can be easily swayed to accept that methodology.)
In XP noone is really personally responsible for anything, and that attracts people who want to have it easy. Documentation is shunned upon, any forward thinking is met with contempt. Any questioning of the process/methodology is considered a heretic. Sweat shop mentality dominates XP, and it is not surprising, considering that it takes 2x as many people to deliver the same solution for 2x the money. Obviously there is a drive for those, who are actually producing code to work as fast as possible without any room for thought.
I did however find that unit testing is a very good approach to testing and that wiki style documentation is excellent if used properly.
You can't handle the truth.
So, no improvement ever happens without XP? Somehow, I doubt that.
I think this goes beyond "extreme" to "hyperbolic".
Maybe you follow the commandments of XP to the letter, maybe you spend countless hours in waterfall meetings ... regardless, I think considering XP, if nothing else, makes software development's collective weaknesses more apparent. I'm not saying that XP solves those problems. Instead, it just throws them into a sharper relief.
... well ... my advice (coming from a relatively competent programmer and project manager) is learn to think for yourself and to constructively pressure your management for the latitude to experiment.
... but to be fair, I've felt like a walking buzz word whenever I've attempted to pitch and/or defend it. If I could change one thing about it ... I'd change the name. What's next ... Pimp my Test Harness?
And in the sense that XP *does* propose a solution
XP makes some good points
Please don't confuse the two. XP is a process only, and it is to be implemented for programmers. Software Engineers design systems and plan out the project which programmers will use. Software Engineers also choose to use XP or other better suited processes.
Now, I am not against some of the agile methods out there, but XP is all hype. The only people who have gotten the process to work aren't really working on real-time systems, or an operating system, or any porject that is of significant scope.
A lot of business management books work that way.
1. Take something obvious or counterintuitive (Doesn't matter if it will really work or not)
2. Label it with impressive sounding phrases
3. Copyright a bunch of specific steps (methodology) to do the obvious
4. Write and publish a 400 page book about the methodology steps using your new phrases
5. Sell it to PHBs and incompetents
6. Profit!
7. When complaints about non-success arrive, arrange seminars at hundreds of dollars per seat.
8. Give Seminar
9. More Profit!
Hmmm, since I have all of the steps down, maybe I should write a book...
Having been through employers who tried both XP and Scrum (not Beck but similar), the only positive thing I have to say about either is that if your developers really suck, teaching them XP and/or Scrum will allow you to keep much closer tabs on their lack of progress. Otherwise, like most "new" methodologes, it's a way for people to teach classes and sell books.
The problem now is that all the good developers from the 90s are married and enjoy spending time at home with their rugrats, and have the "just a job" mentality. You know, go to work, work, go home, don't work.
They've got some nerve.
These are exactly formal methods: a description of the design as a collection of mathematico-logical relations which, when solved, indicate that (in structural designs) the stresses and strains (deflections) do not exceed specified values.
Testing generally consists of checking that the parameters assumed (e.g., 28 day compressive strength of the concrete) are correct. The relations are normally checked directly against strength of materials only for new and inovative designs (e.g., thin shelled concrete designs, though they are now much more common than when I last dealt with this.) There will also occasionally be load tests performed, especially if unexpected cracks appear!
Great minds think alike; fools seldom differ.
"Extreme" has lost its meaning in the same way that "Alternative" has. And pair-programming has always been eighth-grade gay, no matter what anyone says.
Test-first? Yeah, sounds great on paper. In reality, it gets steamrollered by feature requests. And besides, no one really cares if the software works or not, because if it doesn't, it just gives the user an excuse to not work for the whole day, or to take an early 3-day weekend. (at least for most software. the statement probably doesn't hold for users of medical or avionics software.)
The current state of programming is more like finger-painting than engineering. It's messy, hands-on, and only a mother could love the results. And it is performed by children dressed up in the bodies of adults.
The solution? Simple. We only need to be just clever enough to figure out how to implement AI. Then we can let the machines take over. Let *them* figure out all the hard stuff, so we can get back to playing WoW. And I for one will welcome our new programming overlords.
The key lies in the "specified values". For any "real" engineering, you'll have those arbitraries in formal methods. OTOH, formal methods in SW engineering do not suffer arbitrary matters. SW-related 'formal methods' carry a specific sense of *absolute* correctness while the 'formal' methods described here for, erm, 'concrete' engineering do not.
If you want a SW equivalent to what you name formal methods (and which I have been taught to call mathematical or analytical methods, but not formal), then you should look into SW metrics. They also have a mathematical structure, and also carry adequate arbitrary constraints, e.g. 'cyclomatic complexity should remain below 7' or whatever.
They are not arbitrary, they are the properties of the building materials. In the same way, there is no absolute correctness in the SW formal methods; it depends on the questions asked. For example: a proof that communicating threads never deadlock. Absolute correctness would imply that the code is both complete and consistent, completeness being the tricky part. Normally, the code can only be proved viv-a-vis a specification, which is mostly arbitrary, but must be consistent.
Great minds think alike; fools seldom differ.
I enjoyed XP while working at school until I realized that they were just using me to get good grades. Putting it the workplace gives way for the unresponsible to jump on the coat-tails of the responsible.
There are tools to help with formal methods, but don't mistake the tool for the method. It's simply the case that without their tools, formal methods are impractical on nontrivial systems. The parallels that I was thinking of between formal methods in software engineering and mathematical calculation of loads and stresses are these:
Do you believe that software engineering is real engineering? I'm open to the idea (that's its goal), but I see a huge discrepancy in quality of results.
The three analogies you draw are correct, but they do not allow concluding to identity. As I pointed out, loads and stresses are necessarily based on experimentally measured input (e.g., IIRC, the Young modulus) while formal SW proof methods have no experimental pseudo-constants involved.
Apart from that, yes I do believe SW engineering is truly engineering, and at the same time, just as I would say "painting is an art, yet only few paintings are", I would partly agree that current software quality is awfully bad. But partly only.
While a fault in a bridge design will only affect the designed bridge, a single fault in some software will induce errors and misbehaviours in every instance of the software, more so if the software is in very common use, thus faults in somesoftware are more likely to get bad publicity.
Now software is not the only thing that gets mass-produced and therefore not the only kind of product for which a design flaw will induce a massive count of errors, yet it seems like it does actually fail much more than, for instance, TV sets.
One (among several) reasons is that, while only few bridges are engineered by people without a sound background in civil and mechanical engineering, software frequently gets done by people with less-than-perfect skills (you don't get a rookie to build a bridge, do you? Well, you can get a rookie to write code).
The SW engineering field is real engineering alright... but many SW designers are not engineers.
I actually found it far more tedious and mind-numbingly boring then dedicated code reviews myself.
Were you sitting with equal access to the screen and keyboard? Was control changing hands at least every ten minutes, and hopefully every five? Were you doing test-driven development? If not, I'm not surprised. Done right, I think it's much more fun, and much more productive.
It shows people why they should use Linux or OS X.
duks
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
I get sooo tired of hearing that xxx is not a silver bullet, but it's really great and we should all use it anyway. We have plenty of holy water and crosses, if you don't have any silver bullets today please don't come back until you do.
evolution