"Perhaps the sentiments contained in the following pages, are not YET sufficiently fashionable to procure them general favour; a long habit of not thinking a thing WRONG, gives it a superficial appearance of being RIGHT, and raises at first a formidable outcry in defense of custom. But the tumult soon subsides. Time makes more converts than reason." Common Sense, by Thomas Paine - 1776
The topic of this posting will be "The Agile Method and Other Fairy Tales", by David Longstreet.
http://www.softwaremetrics.com/Agfa/Agile%20Paper.pdf
Mr. Longstreet gives an impressive background of travel and study of software organizations in many varied fields and marketplaces. I declares that he has "been dedicated to the idea of improving software productivity and quality...consulting and studying software organizations".
I have twenty three years experience in software development. I have always been involved with the improvement of software quality and productivity. My level of involvement is "applied", that is, I am a Computer Scientist and Software Engineer. I apply ideas for improvement and I stay around to live with the results. I have a vested interested in improving software development because those improvements directly affect me. I have developed software on the family dairy farm to manage accounts payable and production. I have delivered software for the Department of Energy to visualize magnetic fields, and to render 3D data visualizations from scanning/tunneling microscopes. I have written coding standards and guides which were adopted by the entire Computer Science department at the National Laboratory where I worked. I have delivered software for EMail applications, real-time stock market analysis, record managers for high performance indexing engines, eCommerce systems, new specialized GUI controls, charting packages, and many many other high quality and working systems. I can produce references if someone wants to question the veracity of my statements.
I have not limited myself to just studying the software industry. I am an award winning Dairy farmer and have been recognized for my techniques in raising dairy calves. I have traveled and performed voluntary service. I have studied Gothic Architecture and Renaissance Art, and I have traveled in Western Europe to see the actual works. I study languages and culture. I have done in-depth research on the Biblical Prophet Abraham and I currently study the Qur'an. I collect HO scale electric trains and I change the oil in my automobiles. I played the Cornet and Saxophone and I have proven myself to be a fairly good artist. Like everyone I have met, I am not a one-dimensional person.
I have developed software in 68000 and VAX assembly, Pascal, FORTAN 77, Ada, APL, Object C, Object Pascal, C, C++, Java, HyperTalk, C#, various scripting languages, and SQL stored procedures. I have managed teams of developers. I do not limit myself to my department either. Everyone knows that I will speak up in other departments and I am not afraid to go to the CEO or the Board. As a matter of fact, I have been demanding on many organizations and I have had no fear of any position.
I state all of this because Mr. Longstreet does so at the beginning of his paper and then later in the paper describes Agile users as one dimensional. Even with all of my experience there are many things to learn.
Like Mr. Longstreet, I was very skeptical of eXtreme Programming (XP) when I first heard of it. I started writing a paper, XP eXposed. As I studied XP and then applied parts of it I started to see what Kent Beck was describing. Soon I abandoned the paper and started applying parts of XP and I found value in XP.
I will now take some quotes from Longstreet's paper and make some comments:
"I have come to the conclusion that software developers cause most of their own problems. The root cause of most of the problems facing software development is actually caused by software developers themselves. They are creating their own complexity and chaos."
This argument is flawed and is known as an appeal to consequences of a belief.
"Agile methods want continuation and formal acceptance of the status quo... Up to this point in time software development has been a Wild West endeavor... IT has been sloppy. There is nothing new with Agile, because it only tries to formalize sloppiness."
This argument is flawed and is known as an appeal to ridicule, spite, and ultimately the argument turns to an appeal of tradition.
"I am bringing a level of professionalism and rigor to the software industry, and I hope you join me."
This is a setup for the well known fallacy known as an "appeal to authority".
"An Agile proponent will argue there is limited value in requirements specifications because the requirements are ever changing."
There may be someone that Mr. Longstreet views as an Agile proponent that has argued this point. That does not make it so. Use Cases and User Stories are the two approaches I am most familiar with and both are taught and used by Agile proponents. I personally believe that some of the confusion is with the roles of XP and the idea of Agile.
"'I think it's fair to say that customer practices are not addressed in Agile methods.' It is clear that understanding what the customer wants or helping the customer figure out what they want is not really part of Agile, and in turn not part of software development."
Mr. Longstreet is quoting someone from an online users group. Such methods of fact finding are laughable. This statement is a hasty generalization, and hearsay.
"It is clear that understanding what the customer wants or helping the customer figure out what they want is not really part of Agile, and in turn not part of software development."
I believe this is a fallacy of composition.
"Perhaps it is the statistician in me, but I do not believe anything is random. Nothing occurs by random and nothing occurs by chance."
This is an appeal to authority.
"The Agile argument is based upon the idea that systematic study does not work for
software development. They believe 'most software is not predictable.'"
This is on the border line of the fallacy of "confusing cause and effect". Also this is a false dilemma.
"Every single time a development project is done, it is done differently. Documents are not cataloged and organized. There is no consistent usage of terms and symbols between projects, within projects, and even within single requirements
documents."
This is a distortion and thus a Straw Man argument.
Discussing pair programming Mr. Longstreet states, "The idea is that one programmer writes code and the other programmer stands over his shoulder and watches for mistakes."
This is a complete falsehood. He goes on to say, "I am not sure what problem pair programming is trying to solve. Most of the issues with software development are related to incomplete requirements, not coding."
The first part of his statements on pair programming is a Straw Man. Also his statement that most issues are related to incomplete requirements is confusing cause and effect, and is an appeal to consequences of a belief.
"Incomplete requirements are the biggest issue facing software development. I guess it is clear to the Agile folks that it is only logical to spend more time coding instead of cleaning up requirements or writing concise requirements in the first place."
As with many of the statements this one is of questionable cause and confusing cause and effect.
"They believe trial and error is the best method to gather and communicate requirements."
This is an appeal to ridicule, as is this statement:
"Agile proponents believe discipline is not necessary and inhibits productivity."
"Again the basic premise of Agile Methods is there is nothing I can do about my environment. I am a victim of my environment. I am a victim of circumstances. I can’t plan I can only react."
This is simply an example of poisoning the well. The fallacy goes like this:
- Unfavorable information (be it true or false) about person A is presented.
- Therefore any claims person A makes will be false.
I am only half way through this paper. I find it filled with falsehoods based upon poor research. Mr. Longstreet assumes an authoritative position at the beginning of his paper by stating his experience and declares that he specializes in non-biased scrutiny of people, processes, and businesses. He claims that multi-disciplinary study is a key component to his authority. Yet with these statements there is an obvious lack of research done concerning the current body of knowledge on the subjects of Agile and XP.
For those that are the authors of Agile methodologies I invite you to make concise statements defining your Agile Method. For Mr. Longstreet, I challenge him to clean up his paper and to cite sources and remove the unnecessary fallacies.
Subscribe to:
Post Comments (Atom)
8 comments:
Nice, Geoff. Very nice!
I wrote a critique of this article a while back. I think it complements yours. See The Agile Method and Other Fairy Tales: QED.
Conflicting points in David Longstreet's paper.
"The root cause of most of the problems facing software development is actually caused by software developers themselves. They are creating their own complexity and chaos."
"Most of the issues with software development are related to incomplete requirements, not coding."
So, which is it? David may be correct about Empircal Process Control (and I found the house painting example hilarious even though it is a completely flawed argument). Anyway, seems he's just trying to bash Agile.
Thanks for the post. Funny thing is that reading Longstreet's paper actually caused me to consider that Agile development is a good solution to the difficult issues of many projects, simply because his arguments were so off base. Why can't some folks consider that the best approach depends on the context?
Mark,
Software developers need to gather requirement using ethnological techniques. They need to be active not passive. Software developers need to adopt the techniques utilized by industrial designers and study the core business.
The inability of "users" to tell software development what they want has nothing to do with the intelligence of either the user or the software developer. It has nothing to do with how good a developer is at asking questions. Typically customers lack the vocabulary to explain what is wrong and what is missing.
Instead of relying on what "users" say they want developers need to go their users jungle and study them. Often what a user says they want is not what they need. This is not unique to software development.
Sitting in a conference room and asking, "what do you want" is one of the worst ways to gather requirements. Gathering requirements by a trial and error method (code/test) is not as effective as studying the customer.
Tom Kelly, an industrial designer, does a good job outlining the problem in his book, The Art of Innovation.
I provide two footnotes to support my position on pair programming. The first reference comes from Agile Software Development by Robert C. Martin. Martin writes while one person codes, “the other member of the pair watches the code being typed looking for errors and improvements.” Another reference is from Agile & Iterative Software Development A Managers Guide it reads, “The observer is doing a real time code review and perhaps thinking more broadly than the typist, considering test and so forth.” The Wikipedia definition of “Pair Programming reads, “One types in code while the other reviews each line of code as it’s typed in.”
I am not sure why Geoff is calling this a strawman argument. My argument does have some merit maybe it is not the argument Geoff wants me to make about pair programming. I think I need to add a sentence that reads, “Besides checking for errors the observer typically daydreams about the meaning of life and what they watched on TV last night.”
I love the idea where “one member controls the keyboard and the other controls the mouse.” (see page 13, Agile Software Development, Robert C. Martin). Perhaps this would work for one-armed programmers.
I am working on two new articles, “Agile and Jello: Two things you can’t get your hands around” and “Agile & Atkins Fads that leave you feeling empty.”
The link to the article can be found at
http://www.SoftwareMetrics.Com/Agile
I will tackle Geoff's comments one by one. Here is the paper that Geoff talks about but fails to include a hyperlink to http://www.SoftwareMetrics.Com/Agile.
1. Pair Programming - read previous post. Geoff writes my opinions are "complete falsehoods" Kinda of harsh since in my paper I provide footnotes with page numbers, books etc.. (see previous post).
2. Code/Test = Trial and Error Code/Test sounds more dressed up and better than trial and error.
2. Customer Practices - Geoffs writes that what I write is hearsay I am quoting from the XP Extreme Programming Group (this is also footnoted in the paper). Geoff gets the quotes right, so if anyone wants to find out who these folks are making these statements they only need to search them out. Some are authors of books and papers.
3. Geoff uses appeal to authority a bunch of times. I had to look up the definition of appeal to authority. I would suggest he check out my client list at http://www.SoftwareMetrics.Com/client.htm. I also teach graduate level statistics and quantitative analysis to those getting MBA's and graduate psychology degrees. I speak at conferences around the world and I referee journals and conference proceedings for the Academy of Management.
Now I am no dairy farmer, but I think my background and experience makes me qualified to speak on the topic of software development (even Agile). If I started talking trash on the GB Packers, Wisconsin Cheese, or Dairy Cows, then I guess the Appeal of Authority would work.
I hate to burst Geoff's logical bubble, but even those that may disagree with him can still be an authority in the field. I am puzzled why he uses this argument on several occasions. It is like being in a debate and the person saying, well, you are just not qualified to talk on this subject...what? I guess only those people that agree with Agile (and Geoff) are qualified to speak on the topic of Agile.
4. Dude, Geoff, buddy... I worked hard on a lot of the paper and you and so many other Agile types don't even bother to comment on the best parts. I am hurt. I even went and read Ogunnaike ( to to Agilistas as Ogannaike) book on Process Dynamics Modeling & Control, I even explain what is meant by "empirical modeling v. theory & how Agile misuses the terms. I even use some big words like "stochastic." I know it is not logic, but I provide a mathematical proof from set theory.
I even write about Queuing Theory and quote from some books and papers. I think my paper has 20 footnotes and references.
I think people are capable of reading the paper and making determinations if the paper has merit or if I have enough background to comment on the topic of software development and specifically Agile.
http://www.SoftwareMetrics.Com/Agile
I know if is not popular to speak against such a wonderful fad as Agile, but often the one opposing voice is the right voice. Clearly Agile is the fad of the day for software development. This too shall pass.
David Longstreet
Software Economist
www.SoftwareMetrics.Com
Responding to David Longstreet's post on 3/20/2008 12:43 PM...
For those that may be wondering, a Straw Man argument is a distortion of an issue and then an attack on the distortion and not the original issue.
"The idea is that one programmer writes code and the other programmer stands over his shoulder and watches for mistakes."
The distortion is "stands over his shoulder" which invokes images which many would find ridiculous.
David says he should add:
"Besides checking for errors the observer typically daydreams about the meaning of life and what they watched on TV last night."
This is the very problem with the original paper. These are the very types of statements that make it difficult to take the arguments serious.
It seems that David truly has beliefs that Agile is some sort of scam because it seems evident in such mocking as "Perhaps this would work for one-armed programmers."
Since David would prefer to add his day dreaming comment to the his definition of pair programming let's look at the rest of the definition from Wikipedia:
Pair programming is a software development technique in which two programmers work together at one keyboard. One types in code while the other reviews each line of code as it's typed in. The person typing is called the driver. The person reviewing the code is called the observer[1] or navigator. The two programmers switch roles frequently.
While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.
I am not the author of XP nor Agile. I am not going to defend Agile, however I am going to defend my critique of David's paper.
I stand by my evaluation that the paper needs improvement by removing logical fallacies and polishing the paper with concise and accurate details, facts, and statements.
David Longstreet said in his post on 3/20/2008 1:34 PM:
Pair Programming
I think the two programmers are supposed to touch
hands like professional wrestles do in a tag team-wrestling match.
David, why do you make such a statement? If it is supposed to be humorous then I missed it. I read the paper as if it is to be a professional critique of XP and Agile.
David, please prove the following:
Code/Test = Trial and Error
And after that please show how your proposed method of development does not experience any trial and error aspects.
Geoff uses appeal to authority a bunch of times. I had to look up the definition of appeal to authority. I would suggest he check out my client list at http://www.SoftwareMetrics.Com/client.htm. I also teach graduate level statistics and quantitative analysis to those getting MBA's and graduate psychology degrees. I speak at conferences around the world and I referee journals and conference proceedings for the Academy of Management.
David, there you go again appealing to authority. It's not that your findings are right or wrong, it's that the argument doesn't hold solely because you say so.
I hate to burst Geoff's logical bubble, but even those that may disagree with him can still be an authority in the field. I am puzzled why he uses this argument on several occasions.
I don't have a bubble. ;-)
We both have declared ourselves authorities in software development. But that declaration alone is not sufficient.
I see you have figured out that the opposite to the Appeal to Authority is the Ad Hominem, but I still feel you miss the point.
David, I am sure you worked very hard on the paper. I feel most know I do not intend to cause you any hurt. Maybe I should take a new approach. David, I suggest you try this, take your paper and submit it to the IEEE or some refereed publication in the Software Industry. I wonder how well your style and references would hold up.
David says, "often the one opposing voice is the right voice".
Sometimes it is true that the voice opposing the common view is correct. This could be taken as an argument in favor of Agile since Agile Software development is in the minority the last time I checked.
Regardless, I am glad David responded to the blog. His manner reads as polite and concerned.
Geoffrey Slinker
Dairy Farmer, Retired.
Post a Comment