This is probably not a terribly original observation on my part, but Extreme Programming is horribly misnamed. I don't view it as particularly extreme: it merely says "follow the good programming practices that you already know about". What, if anything, is extreme is that it tells you how to follow those good programming practices.
The big problem I have with the name, though, is the implementation detail embedded in the name. "Programming" shouldn't be there. XP is about project management, not about programming per se. If you took out the programmers and said "carpenters should review each others work, not build things the customer didn't ask for, get frequent feedback from the customer, etc.", then many people would shrug and agree. If anything, it should be called XPM: eXtreme Project Management. However, since I don't think it's extreme, I suppose we could call it Really Good Project Management, but RPGM just doesn't have the same ring to it.
Re:What XP Ought To Be Called
chromatic on 2003-12-30T01:31:02
They got the Linux kernel wrong, then, as "refactoring" should be called "throwing it all away and starting over from scratch every release" and "automated testing" should be "ask users to debug it for you and berate them for not reading the development mailing list religiously".
:) Lots of open source projects succeed because their leaders are exceedingly brilliant at project management without discipline. Lots more projects succeed because there's a point at which you can throw many, many warm bodies at a problem and get something that works reasonably well.
Please don't misunderstand: I think open source does well at collaboration, pragmatism, and soliciting feedback. If you set aside philosophic goals of freedom (which I hate to do, because they're important to me), the reason it works so much better as a software development model over proprietary development schemes is not because open source developers are brilliant, disciplined, and thoughtful. It's because so much of proprietary software development is shockingly bad.
Re:What XP Ought To Be Called
mary.poppins on 2003-12-30T06:07:50
Free software is worker control. This means:
1) workers aren't forced to work on the boss's bad ideas -- the bad ideas
have to attract the workers on their own (see apache.org java stuff:)
2) no boss deadline pressure
3) no boss backward-compatibility pressure
These three things are, in my experience, responsible for the bulk of stupidity
in boss-run proprietary software organizations.
Now, of course, the lack of these bad things does not guarantee great software
(cough cough perl5 guts cough cough:), but it does at least *allow* it.
Re:What XP Ought To Be Called
jdavidb on 2003-12-30T14:48:39
But how can you say the Perl 5 guts don't have backward-compatibility pressure?
:) Re:What XP Ought To Be Called
Ovid on 2003-12-30T15:51:49
Let's not talk about backward pressure in guts, please. There might be children present.
Re:What XP Ought To Be Called
mary.poppins on 2003-12-30T16:18:18
Of course there is backward compatibility pressure -- but it doesn't compare to
a proprietary shop, where the boss says "We can't lose this big account -- so
don't change anything, anywhere, that might cause them problems."
One of the reasons that proprietary software sucks in general is that the
programmers are first rushed, then told not to change anything. Developers of
free software have much more freedom to say "The next major version will change
things; stick with the old version if you want; fork the project if you want."
Re:What XP Ought To Be Called
chromatic on 2003-12-31T07:23:38
Right, open source software is less affected by economic pressure. That's probably the largest pressure that leads to an immature release, but it's not the only one.
(Sidebar: This weekend, Ward Cunningham and I discussed the idea that open source's biggest advantage is not necessarily improved communication, it's scalability — in the sense that a thousand hackers can throw themselves at a problem and a few might eventually come up with a solution. I'll continue to argue that practicing a little more discipline will help us solve our current problems more quickly and more effectively. Ward points out that we'll find a whole new set of problems then.)
Re:What XP Ought To Be Called
mary.poppins on 2003-12-31T12:39:39
W.R.T. "scalability" -- thousands of hackers are not needed, and generally not
involved. It takes only a few really good ones to solve a particular problem.
And those really good hackers produce much better work when they have control.
In my experience it is proprietary shops that use the "hordes of programmers"
approach, trying to crank out software quickly by throwing lots of mediocre
programmers at the problem. The "wizard in the tower" approach, though
sometimes slower, gets better results.
Now, one could bring up the linux kernel as a counter-example, but even there
there are a few main programmers for each subsystem. Besides, I would wait for
2.6 to work well in practice before holding up linux as an example of good
development methodology.
IME XP really is extreme for old-school big-design-up-front folks. Or for people who think Big Serious Projects require one or more Serious Architects who dictate in the form of The Specification to the Small Developers what Shall Be Done. And then the project is 50% over budget and 66% late, but they keep doing the same thing over and over, because it's what they know. And it's not just old COBOLers either -- for an extreme reaction, just bring up pair programming on any development list or forum that isn't solely populated by xp-folks...
I do think the association with Mountain Dew, bungee jumping and crazy ski guys is unfortunate and causes people to have a bad first impression. Too late now...
Well, not everyone agrees that each of the XP practices is good. A lot of people view pair programming as a waste of one programmer.
Extreme Programming is one set of good practices which have been shown to reenforce one another. There are plenty of other good practices, but if you cherry pick practices and put them together without considering how they interact, you might end up with team that chugs along one half power, belching smoke and leaking oil.
Re:Good practices might not be good together
Ovid on 2003-12-31T22:43:28
The strongest objections to pair programming that I hear usually seem to come from those who have little experience with it and those who prefer to be alone. The objections, in fact, remind me of an interview where the manager told me "we don't want you writing tests because that will slow down your programming." I was offerred the job, but I declined.
Having done quite a bit of pair programming here at work, I've discovered that it can be a bit tough as many programmers are, shall we say, not overly social. However, I've also discovered that a good pair can dramatically improve code quality and save many headaches. One pair tells the other "no, don't do that. We've already implemented it over there." Meanwhile, the other pair says "hey, you forgot to test if that's defined." When we stop pair programming, the team as a whole does seem to crank out more code, but we also wind up with more bugs slipping through, even with our tests. It's been fascinating watching how well our processes have validated many core XP tenets.
This is probably not a terribly original observation on my part, but Extreme Programming is horribly misnamed. I don't view it as particularly extreme: it merely says "follow the good programming practices that you already know about".
That's quite a big "merely" considering how many people ignore good practices on a daily basis:-)
I agree that, in hindsight, XP was a terrible name - but only because of the "dangerous" / ad-hoc / bungie-jumping connotations.
To me the "extreme" was always intended to indicate the level that you take the good practices to:
It's extreme not because of the things you do, but due to the fact that you turn up following the good practices to the max.
The big problem I have with the name, though, is the implementation detail embedded in the name. "Programming" shouldn't be there. XP is about project management, not about programming per se.
Hmmm. Of the practices unit/acceptance test first, pair programming, collective code ownership, refactoring, YAGNI, etc. all seem related to programming to me
Also where does the join between project management and programming live? Where does analysis/design live in that continuum?
Possibly it's a case of reclaiming a term that has come to mean "code monkey who follows instructions from on high" but, to me programming is about creating products for my clients (and having fun of course
Re:Not really (IMHO), at least not for that reason
Ovid on 2004-01-05T16:52:58
Of the practices unit/acceptance test first, pair programming, collective code ownership, refactoring, YAGNI, etc. all seem related to programming to me:-) As from from test first programming, those seem applicable outside of programming.
- YAGNI -- painters don't do extra fancy trimming unless asked.
- Pair programming -- people working in teams to check each other's work.
- Collective code ownership -- rotating accounting personnel through various deparments so they can see the whole business.
- Refactoring -- Multiple similar policies or tasks are consolidated.
:)
Re:Not really (IMHO), at least not for that reason
Adrian on 2004-01-05T22:40:27
I think you're reaching on some of those
:-) For example you get a lot of synergy between the XP practices in programming that you don't get in other fields (it's hard to refactor a damp-proofing layer if you're a YAGNI painter!) I stiill think the XP practices are more about programming than project management.
