We Tried Baseball and It Didn't Work(xprogramming.com)
xprogramming.com
We Tried Baseball and It Didn't Work
http://xprogramming.com/xpmag/jatBaseball
22 comments
"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,"
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.
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.
Ward Cunningham has "never coded up any great software"? Ever used a Wiki? Hypercard? Kent Beck "never coded up any great software"? Ever used JUnit? Oh, but those are too small to be great, I'm sure.
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.
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.
I thought HyperCard was created by Bill Atkinson, but hey maybe Ward did write it and he DOES deserve credit for WIki and I was wrong to lump him with the rest.
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.
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.
No idea about his programming skills, but I have read Kent Beck's Smalltalk Best Practice Patterns and it is pretty useful and it was often recommended to both Smalltalkers and non-Smalltalkers.
[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.)
[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.)
Ward wrote the first prototypes of his Wiki using HyperCard, so you could say that Ward wrote and created HyperCard stacks, but he didn't create HyperCard itself.
I've been working my way through Coders at Work, and have been struck by the variance in opinion on assorted methodologies (either by direct statement, or by omission or allusion). The one consistency is that few of the interviewees seem deeply interested in what are otherwise hot topics.
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."
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."
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.
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.
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.
"If you think that's insane, let me tell you 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 Jewish Carpenter..."
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.
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.
"Of course other people had different and contradictory books, all claiming equally fantastical fiction as 'THE Truth'..."
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?
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?
Of course that 'solution' eventually led to the great schism and many different versions (king james, etc.). So maybe the deeper truth is that people enjoy arguing?
[from http://www.tonymarston.net/aboutme/thoughts.html]
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
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
As you point out, there's a tension between a methodology that cannot fail--only be failed--because in practice it is impossible to use and yet the need to actually do things the methodology says if you want to really test it. XP, being a very high discipline methodology, is particularly vulnerable to this; the literature is full of people who claim to have tried it and when you press them they threw out all the parts that make it work, and this post was born of Jeffries' irritation by this.
Whether it is possible for other teams to actually pull XP off is harder to say.
Whether it is possible for other teams to actually pull XP off is harder to say.
If the man could code as well as he writes these pseudo parables...
I've seen this happen time and again, where developers or project managers will decide to "improve" some part of the clients business process rather than just do what they were asked to do. It's almost a "we know better than you" attitude.
And they then don't understand why the clients are unhappy with the system when it is delivered.
And they then don't understand why the clients are unhappy with the system when it is delivered.
This is downright Swiftian...if Swift had spent his most famous bit of satire rambling about prices for beef at Irish butcher shops he'd visited.
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.
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.
I thought the article was about Cricket
"I thought the article was about Cricket"
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.
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.
He's not trying to sound profound. It is satire.
"It is satire."
You might be surprised ;-)
You might be surprised ;-)
What would I be surprised about? I know the conversation on the mailing list that spawned it. I've met the guy. It's satire.
id like to come up with a caring and clever response, but all i can think to say right now is "you must be doing something wrong."
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.