We Tried Baseball and It Didn't Work
xprogramming.com
xprogramming.com
Perhaps--and this is pure conjecture--the biggest problem the industry has is that people rarely take a process or methodology and apply it as written, but insist on customizing it for their convenience and according to their conjecture even when they have very little experience with it in practice.
Hmmm. Perhaps the biggest problem the industry has is that processes and methodologies are written by people who are poor programmers?
Think about it. No methodology is written by great programmers, great managers or great product designers. Why should people use them "as written"?
Taking all the "agile" methodologies as an example, All the signatories of the Agile Manifesto put together never coded up any great software. The same applies for CMMi or RUP or whatever.
XP starts from a failed project at Chrysler. They are essentially process consultants who are good at thinking up processes. Implementing their reccomendations "as written" would be insane, just as trying to run a company as per the prescriptions in latest management fad book as written would be insane.
Come to think of it there are similarities to management books. Comparatively few of them are written by great businessmen. Most of them have written by people who've never run a business in their lives.
I don't get it. Logically no one should pay any attention to such methodologies or books. But people do, to the point where software methodologies and "Who moved My cheese" books are multi billion dollar industries.
XP is not great for a lot of things and a lot of people; it demands a lot from folks, and especially a lot from management, which causes problems in implementation. The on-site customer, which is important, is a constant stumbling block. They may have fiddled with it since, but the XP I remember watching take shape on the original C2 Wiki was very simple, sometimes to the point of being obvious, and not especially flexible within its bounds. But I give it a lot of credit for a lot of things--the current culture of unit testing grew out of that, and simple, incomplete but useful testing libraries have done more to help than anything else I can remember in the last ten years.
The seventeen signatories of the Agile Manifesto The were: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas.
Who among these (aside from Ward) has contributed original/brilliant software? Most of them are good communicators and developers of average skill.
I have used JUnit I don't think it is particularly mind blowing software, just as I don't think Java is a particularly great language. Your opinions differ obviously. So yes, as heretical as it may sound to your ears, I consider Kent Beck only a so so programmer. You should read his book "Test Driven Development By example" to see a sample of his terrible code and "design" sense. Compare it with something like "Paradigms of Artificial Intelligence Programming" or "C interfaces and Implementation" to see how great software design is done.
I'll burn at the stake for such blasphemous beliefs to be sure, but that's ok.
All that said it is interesting to note that Ward is the least strident is marketing his methods as a methodology or claiming that XP/agile is the ultimate way to develop software. The loudest are people like Bob Martin and Ron Jeffries, who are the least impressive as programmers. Ken Scwaber is the man behind the Scrum scam.
So my hypothesis still holds. The very best programmers don't set themselves up as methodology consultants, even within the ranks of the methodology consultants. ;-)
"But I give it a lot of credit for a lot of things--the current culture of unit testing grew out of that, "
If you think unit testing didn't exist before XP, you are wrong. Good programmers have ALWAYS unit tested their code, well before Java or JUnit. And a lot of people think XP is utter hogwash. The strength of your belief in its goodness doesn't counter that.
[1] http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/... (it's not a gang-of-four-type patterns book, more like a style guide.)
Each seems to have figured out a way that works for them and their world.
Now, I've only read through 4 or 5 of the interviews, so maybe this a fluke, or perhaps I've remembering what I want to believe, but about the only theme running through the descriptions of how they work is, "Think carefully about what it is you're trying to do."
If you think that's insane, let me tell you about this book written by a guy who translated a book written by a guy who knew a guy who knew twelve other guys who knew a carpenter...
People are searching for answers wrapped up lists of ten or fewer commandments. See also Paul's essay on essays that are lists and why they are both easy to write and popular with readers.
You have a great point there. Whether the Jewish carpenter ever existed or not, the book with the stories about him and his disciples provided something that people needed and liked to believe in, rationality be damned. Of course other people had different and contradictory books, all claiming equally fantastical fiction as "THE Truth", and then they could fight one another about which of their books was "The One True Word Of God" with nary a piece of evidence any way.
Maybe the need for (sw dev and business) methodology comes form the same part of the brain - irrational and needing comfort in the face of an unpredictable world. A sham that nevertheless makes you feel secure. Interesting.
And the people who'd write these up would be skilled manipulators or perhaps deluded themselves. Faith (in the sense of needing to believe something without supporting evidence because something "feels" right is the key to understanding this.)
Thanks.
Interestingly enough, the solution to that was to have the emperor sit everyone down and make a canonical version. Perhaps management theorists need a Constantine?
There are two basic approaches to software development:
Rules oriented - where you follow a set of rules or a methodology religiously, to the letter and without question and just assume that the results, whatever they are, must be acceptable.
Results oriented - where you aim to produce the best results in the shortest possible time and use whatever methodology or rule set that helps you achieve this aim.
One requires blind obedience, plus, from what I have seen on more than one occasion, an unerring ability to invent interpretations of those rules that are so obscure and perverse that they do nothing but increase complexity and decrease productivity.
The other requires intelligence and skill, the ability to know which rules and methods to adopt, when and how to adapt them to fit a particular purpose, and when to reject them in favour of something better.
- Tony Marston
Whether it is possible for other teams to actually pull XP off is harder to say.
And they then don't understand why the clients are unhappy with the system when it is delivered.
It's a nicely written bit of prose, but as satire, it's very weak. He doesn't seem to so much reference actual targets' arguments and cast the other side as ridiculous as throw out the central "They're dumb, and they don't get it!" claim and reiterate that at increasingly odd and tenuous length.
I don't have a dog in this fight, so maybe it's just a matter of a piece not meant for anyone but those who already cleave to his POV on the issue.
Just replace some words to make it about Cricket.. The post is so content lite it could be made to be about anything with minor modifications. It says nothing useful while seeming profound.
You might be surprised ;-)