Softpanorama
(slightly skeptical)
Open Source Software Educational Society
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
| News | See Also | Recommended Books | Recommended Links | Recommended Papers |
| Testing | History | Humor | Etc |
I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me. Donald Knuth |
When it comes to ‘extreme programming' (XP) methodology I tend to be extremely skeptical. It looks like a "Viva Viagra" or worse "Vioxx" type of fad, more the symbol of complete corruption of a large part of academic community then anything else. At a basic level of analysis, Extreme Programming is not a technical methodology but something like a new management style + a mall technical cult which promotes it's own utopia. The number of zealots are significant and objective discussion is difficult to this very reason. and please be aware that there are a lot of books on Amazon that is graded 4 or 4.5 stars that are complete and utter nonsense. Actually authors who participated in propagation of this methodology should be treated in a special way and participation of any of those authors in other books is a sure warning sign. I actually do not see any of the authors I respect in the list. Amazon lists approximately 50 books in a search for the term.
At the same time critical book are a sure sign of presence of some level of courage. For example, Questioning Extreme Programming
XP was originated from the work of Kent Beck in Chrysler (Chrysler Comprehensive Compensation System payroll project) and the first book was published in October 1999. BTW Chrysler eventually canceled that project.
The most noise was in 2000-2003. After that it gradually faded and I did not noticed any books about it published in 2008. Probably was replaced with : "agile software development"... Wikipedia even mentioned that extreme programming is a now considered to be a form of "agile development" (that's an interesting term because opposite to agile is probably "stagnant software development :-) and this proximity gives "agile development" term bad breath despite some sound ideas in the agile manifesto (looks like plagiarism of open source software development methodology) IBM is very active in milking this cow via its Rational franchise:
In a keynote presentation and in correspondence afterward, IBM's Per Kroll, chief architect for IBM Rational Expertise Development & Innovation, cited the company's proliferation of agile practices among some of its approximately 35,000 developers.
"I think in general we have 1,000-plus people [using] agile in the IBM community," with an additional 2,000 persons trained in agile practices, Kroll said. He said, though, that he did not anticipate that all 35,000 developers would adopt agile.
On Monday at the conference, IBM's Scott Ambler, practice leader for agile development, spoke on the state of the agile space. Agile development focuses on developing software in iterations of usually two weeks. This allows for more flexibility than the traditional waterfall methodologies.
"Agile is taking many things that we’ve been using for a lot of years before agile was around [and] adding a lot of new things and putting a very good spin on it and making development more human," said Kroll. Concepts like iterative development and continuous integration are not new, but agile accounts for factors like human and collaborative aspects, he said. "We firmly believe, and our executives firmly believe, that the most successful organizations of tomorrow will be the ones [able] to adopt agile principles."
IBM has roughly 150 agile projects, he said. But each team needs to determine its own agile use based on their context. Agile means a lot of things to different teams, he said.
A key factor is that IBM helps customers and its own teams with applying agile complex environments, facing such issues as application complexity, scalability, and compliance issues, said Kroll.
It seems like XP is just rehashing the same idea as surgical team described in the mythical man-month but in some very incoherent and clumsy way ("pair programming", my God what a name -- "cluster disaster" would be much better). "Pair programming" may help to stop programmers from spending to much time reading Slashdot or searching Goggle for things that has nothing to do with the project :-). It might be even cause decline of revenue at eBay. However, they seem to be able to compensate for this in a lot of other ways :-)
While reading each other code is essential, collective ownership diminishes individual responsibility and deliberately creating huge communication overhead that diminishes each programmers productivity. For more talented members of the team it entails a dramatic drop ("state farm effect").
It's also very difficult to get the right balance of personalities in the teams. If you pair a good programmer with a zealot the zealot will be in a driving seat and the results will suffer. We all should periodically reread Brooks famous The Mythical Man-Month. The one will understand that XP does not bring anything new to the table. In essence this is a profanation of Brook's idea of surgical teams in a perverse way mixed with Microsoft idea "one programmer -- one tester". XP did not invent the "daily build" it was practiced by many organizations including Microsoft long before (I know NYC-based Information Builders used in since at least 1992), but made it popular.
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. Programmers like writers are solo beasts - putting two of these dragons behind one keyboard is asking for trouble.
As a methodology XP is pure fantasy. It has been well known for a long time that big bang or waterfall model. And it does not work well. The 'spiral' model (iterating out from the core of a small well understood system) is a much better methodology popularized by Unix and in some form reemerged in prototyping approach.
It is difficult to survive that amount of SE nonsense in a typical XP books. Readers beware.
Zealots defend XP "cluster disaster" as a kind of code review. But one computer and the same cubicle idea is nonsense. It is unclear to me that communication improves it people share the same cubicle. I like that is called Extreme because this is an example of extreme nonsense:
Sure, the name is some PR trick,
but it makes sense because this technique is a reaction to all those new trendy
development process in which (when you push them to the extreme) you are spending
90% of your time in meetings or drawing graphs and then the code is supposed
to magically write itself and work perfectly on the first build because this
technique is so well conceived.
Like any kind of engineering, software engineering needs as much face to face
collaboration as possible.
To a point collaboration is important, but real SE requires careful planning by
a talented architect and clear interface definitions. XP -- almost to the point
of being pathological -- attempts to avoid planning as much as possible by substituting
endless chatter and tremendous time wasting repeatedly re-implementing what could
have been done right the first time. (And yes, I know some things always have to
be reimplementation, but just because mistakes are inevitable doesn't mean they
have to be encouraged.)
Software engineering has an unfortunate tendency towards fanatical adherence to the latest fat that is always sold as a silver bullet. Usually, this involves an implementation language backed by a marketing push (Java); XP seems to be another programming fad built on unscrupulous books marketing (structured programming extremism and verification bonanza was the first). And like verification bonanza before it has found an abundant number of zealots may be due to its potential for snake oil salesmen to earn a decent living at the expense of programmers suffering form it.
But all or nothing is not just an XP problem. Most SE methodologies are close to religions in a sense that they all try to convince you that their way is best, if you deviate you are a heretic and if it all fails then it's your problem for not following the rules. The "prophets" that "invent" a methodology make their money from book publishing as well as teaching people how to do it. There are also a lot cluesee followers, lemming that believe everything that prophets preach.
And the last thing prophets need is some kind of objective analysis or critique. Why would they kill their cash cow even if they themselves understand that they are wrong? In general, SE methodology advocates, like cult leaders cannot afford to correct themselves.
|
|||||||
I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.
Bad Agile in More Detail
I've outlined, at a very high level, one company's approach to software development that is neither an Agile Methodology, nor a Waterfall cycle, nor yet Cowboy Programming. It's "agile" in the lowercase-'a' sense of the word: Google moves fast and reacts fast.
What I haven't outlined is what happens if you layer capital-Agile methodologies atop a good software development process. You might be tempted to think: "well, it can't hurt!" I even had a brief fling with it myself last year.
The short answer is: it hurts. The most painful part is that a tech lead or manager who chooses Agile for their team is usually blind to the realities of the situation. Bad Agile hurts teams in several ways.
First, Bad Agile focuses on dates in the worst possible way: short cycles, quick deliverables, frequent estimates and re-estimates. The cycles can be anywhere from a month (which is probably tolerable) down to a day in the worst cases. It's a nicely idealistic view of the world.
In the real world, every single participant on a project is, as it turns out, a human being. We have up days and down days. Some days you have so much energy you feel you could code for 18 hours straight. Some days you have a ton of energy, but you just don't feel like focusing on coding. Some days you're just exhausted. Everyone has a biological clock and a a biorhythm that they have very little control over, and it's likely to be phase-shifted from the team clock, if the team clock is ticking in days or half-weeks.
Not to mention your personal clock: the events happening outside your work life that occasionally demand your attention during work hours.
None of that matters in Bad Agile. If you're feeling up the day after a big deliverable, you're not going to code like crazy; you're going to pace yourself because you need to make sure you have reserve energy for the next big sprint. This impedance mismatch drives great engineers to mediocrity.
There's also your extracurricular clock: the set of things you want to accomplish in addition to your main project: often important cleanups or other things that will ultimately improve your whole team's productivity. Bad Agile is exceptionally bad at handling this, and usually winds up reserving large blocks of time after big milestones for everyone to catch up on their side-project time, whether they're feeling creative or not. Bad Agile folks keep their eye on the goal, which hurts innovation. Sure, they'll reserve time for everyone to clean up their own code base, but they're not going to be so altruistic as to help anyone else in the company. How can you, when you're effectively operating in a permanent day-for-day slip?
Bad Agile seems for some reason to be embraced by early risers. I think there's some mystical relationship between the personality traits of "wakes up before dawn", "likes static typing but not type inference", "is organized to the point of being anal", "likes team meetings", and "likes Bad Agile". I'm not quite sure what it is, but I see it a lot.
Most engineers are not early risers. I know a team that has to come in for an 8:00am meeting at least once (maybe several times) a week. Then they sit like zombies in front of their email until lunch. Then they go home and take a nap. Then they come in at night and work, but they're bleary-eyed and look perpetually exhausted. When I talk to them, they're usually cheery enough, but they usually don't finish their sentences.
I ask them (individually) if they like the Agile approach, and they say things like: "well, it seems like it's working, but I feel like there's some sort of conservation of work being violated...", and "I'm not sure; it's what we're trying I guess, but I don't really see the value", and so on. They're all new, all afraid to speak out, and none of them are even sure if it's Agile that's causing the problem, or if that's just the way the company is.
That, my friends, is not "agile"; it's a just load of hooey. And it's what you get whenever any manager anywhere decides to be a chump.
Re:Why is it called "Extreme"?
(Score:2) by Eivind Eklund (5161) on Tuesday September 19, @09:38AM (#16137298)
(Last Journal: Friday October 08, @05:53AM) The name comes from introducing some good practices and then doing them extremely ("Turning them up to 11", in the words of Kent Beck).
- "Don't let your programmers be tired" -> "Forbid programmers from working overtime".
- "Do code review" -> "Do code review in real time, by pair programming"
- "Test" -> "Test everything, immedately, by not writing code until you have a failing test"
- "Get customer feedback" -> "Release in very short cycles, and have a customer owner that decide how things should work"
- "Don't overcomplicate the code" -> "Delete all code and functionality we do not need today, and clean up all dirty code immediately"
Eivind.
by Anonymous Coward on Tuesday September 19, @10:17AM (#16137523)
You have some misspellings there... let me correct you:
- "Don't let your programmers be tired" -> "Forbid programmers from working overtime at your own peril as you should realize that a programmer is a real, live adult human being which happens to be a professional and therefore can take care of his own work hours due to the fact that he has been living with himself for quite a few years and knows perfectly well when he's tired and when he's not, and resents being treated like a child by a moronic idiot who just happens to have stepped on enough people to raise up the ladder enough to annoy said programmer".
- "Get customer feedback" -> "Release in very short cycles, and have a customer owner that decide how things should work in your dreams, because in the real world you should realize that your customer doesn't give a s***t about whether you need feedback or not, because he's already told you everything you need in all those prep meetings and impromptu emails, and just wants to sit back and click on the darned button and see things working, so he won't be looking or testing anything you send to him because "it's not done yet" until he thinks "it's done" and then he'll change all those lovely specs you spent some much time tuning the tests to fit into. And your manager will be so desperate to please him that he will say yes to anything he says, because after all, this is Extreme Programming, it's great, it's flexible, we can do anything as long as the tests come out alright, right?"
There, cleaned that up a bit for you.
JARCP
----
Just Another Random Cynic ProgrammerRe:buzzwords(Score:2)
by Ignignot (782335) on Tuesday September 19, @09:06AM (#16137132)
(Last Journal: Thursday October 07, @02:33PM)Seems like a lot of that is just rehashing the same old same old. What's wrong with the programming surgical team described in the mythical man month? Collective ownership seems to be deliberately creating more communication overhead for programmers. In other words, what does XP bring to the table that is useful instead of just different? by seti (74097) on Tuesday September 19, @07:34AM (#16136790)
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.
(Last Journal: Friday July 01, @09:48AM)
Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer. Traditional code reviews tend to be frustrating for the programmers, because the reviewers are in position of authority.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.
Where have you been the last 20 years? The stereotypical programmer, hacking his piece of kernel over night is very endangered species, and rightly so. Like any kind of engineering, software engineering needs as much face to face collaboration as possible.Programmersare solo beasts
(Score:4, Insightful)
by Angst Badger
(8636) on Tuesday September 19, @08:20AM (#16136934)
Pair programming can be seen as a kind of code review, but with the reviewer
in equal position with the programmer. Traditional code reviews tend to be frustrating
for the programmers, because the reviewers are in position of authority.
I've never seen one of those. Every code review I've participated in has been
a collaborative effort between peers. If you treat a code review as a cooperative
effort between programmers, it doesn't have to be frustrating.
Like any kind of engineering, software engineering needs as much face to
face collaboration as possible.
To a point. But real engineering requires planning and clear interface definitions,
and XP -- almost to the point of being pathological -- attempts to avoid planning
as much as possible by subsitituting endless chatter and tremendous time wasting
repeatedly reimplementing what could have been done right the first time. (And
yes, I know some things always have to be reimplemented, but just because mistakes
are inevitable doesn't mean they have to be encouraged.)
Software development has an unfortunate tendency towards fanatical adherence
to the latest silver bullet. Usually, this involves an implementation language
backed by a marketing push; XP seems to be the first programming fad built entirely
on book publishing. But then, no implementation language ever actively encouraged
the kind of passive-aggressive personality that thrives on XP.
by g2devi (898503) on Tuesday September 19, @09:01AM (#16137108)> Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer.
It depends on the personalities. It likely works well if you have a uniform team, but it you have a diverse team (which is a good thing since your weeknesses are compensated by someone else's strengths), it can be very suboptimal. For instance, if you put a reflexive analytical introvert with a shoot from the hip intuitive extrovert, the extrovert will more than likely steamroll over most of the input of the introvert and feel validated because the shoot from the hip extovert thinks that the code has the approval of the reflexive analytical programmer.
In the case of a code review, the reflexive analytical introvert gets to do things the way he/she wanted to do and gets input during the review from the extrovert if there are alternate ways of doing things. More than likely, it's also learning experience for the shoot from the hip programmer to program more safely. In the reverse case, the shoot from the hip intuitive extrovert gets to do things the way he/she wants and gets validation that that code is safe and handles all conditions. It's also likely a learning experience for the reflexive introvert to see that "crazy new techniques" can actually be better.
(Score:1)by
aadvancedGIR
(959466) on Tuesday September 19, @08:09AM
(#16136897)
Agile software development is simply a way to say "code now, we'll get you the specs later"