Someone took exception to me saying:
“I have yet to read a good “Pragmatic Programmer Series” book.”
…with the lines:
“I think that’s a bit of a hard knock of the Pragmatic Bookshelf. I’ve had a number of books which I’ve really enjoyed from them; The Pragmatic Programmer and Practices of an Agile Developer spring to mind.”
Hehe, he caught me! Oh, I didn’t lie—I just never actually finished a single one of their books. 😉 I started reading the Pickaxe book and The Pragmatic Programmer mentioned, but I put them down in disgust.
[But that won’t stop me from peeing on your programming religion after the jump.]
They call this pragmatic?
Speaking of the Pragmatic Programmer, we’re talking about the book whose oft quoted maxim is that a programmer should learn a new programming language every year, right?
Let’s see, I’ve been coding for over 25 years now. I do not know 25 programming languages, and only know about four competently right now.
Learning another programming language is like learning a new language just to help with one’s understanding of grammar—sure learning Latin helped my grammar, but it’s still a dead language. I am much better served by learning new programming concepts that those languages inspire. Even when attempting to learn my historically fun punching bag, Ruby on Rails, I have learned more than a couple of concepts, but the syntax I have already forgotten.
Continuing the Latin analogy: If my goal was to learn to write better, my prose would have been better served reading more Shakespeare and the King James Bible, than learning Latin.
…on to those Agile practices
Agile practices:programming project management::Getting Things Done:life management
It’s nice in theory, but still more about “practice what we preach, but not what we do.” Test first development, pair programming, user stories… geez need I go on? How many times has this shit only been proven to be better than backasswards “software as construction” ISO 9001 software paradigms and been crushed by process-less development before you have to say:
Shit, sure it’s a lot better than the heavyweight bullshit I was taught in misguided books on programming but it’s a whole lot worse than the village idiot approach.
Back to those pithy pragmatic prose
Oh sure the stuff sounds pretty and pithy. But honestly, let’s see the authors put up, or shut up as programmers. What code have they written that follows these maxims religiously? On the other hand, I’ll bring up one website that uses the far more intuitive fast-and-loose approach to development: Facebook.
Want to pull out penises? Let’s get a tape measure.
Real pragmatism
Real pragmatism doesn’t elevate the coder to Olympian heights with petty pronouncements. Real pragmatic programming is about having a destination and getting there programmatically—it may be ugly, but it works; trying it with pithy prose, is ab asino lanam quaerum.
Pragmatic?
My.
Ass.
More Latin bludgeoning
“Quod est, eo decet uti: et quicquid agas, agere pro viribus.”
—Cicero, De Senectute
vs.
“Never whistle while you’re pissing.”
—a way too verbose science-fiction novelist (and this)
Shorter terry chay
“How pragmatically they’ve programmed, to preach pithy prose over plain programming!”
I think we can safely say Kent Beck and Ward Cunningham have proved themselves as programmers. With regard to your comment on ‘fast-and-loose’, that’s the whole point with agile. With a few safeguards in place you really can be fast and loose without leaving yourself open disasters.
Rob,
1) You must defend Venkat Subramaniam and Andy Hunt, not Kent Beck and Ward Cunningham. They’re the writers of the book you are defending. Else why not advocate a different book like Refactoring, or Extreme Programming Explained or Fit for Developing Software or The Wiki Way?
2) Kent Beck’s largest project built using an Agile Process was the payroll system for Chrysler built using XP. I’ll bet you it’s smaller and less complex than Facebook or OS/360. Though these two systems were built generations apart, for vary disparate systems, in very disparate ways, neither were built using an agile process.
3) Agile processes are still a “process,” if you are going to advocate a process (in this case, extreme programming), then you must defend all of it, especially, Test Driven Development. I love testing, but I keep telling people that Test-First, while a good idea (in theory) is a bad practice (in practice) and the linked article shows why that hypothesis should be the null. Kent Beck and co. have the burden of proof—proof that must come from testing against the null (pardon the pun): all other things being equal, are you willing to claim that Test Driven Development will produce better code faster than Test Later Development?
4) There is a world of difference between “best practices” (like “use code versioning”) and unproven processes (like many of the principles that form the underpinnings of many agile processes) and pointless maxims (like many of the suggestions in The Pragmatic Programmer.). That is my point: when we read books of this calibre, we learned far more thinking critically about them than we do in practicing what they preach.
…
As I mentioned, I haven’t read Practices of an Agile Developer (but I can smell the b.s. all the way from the title), but I do know this: Programming is about making choices.
A choice. As in the road not taken. Too often these books talk about the pluses of the path they advocate, but are not honest about the minuses. Go reread The Pragmatic Programmer with the reality that every choice comes with a consequence. Are the authors honest about the consequences in the maxims they tell you to blindly follow?
Then go read Mythical Man Month. Is Frederick Brooks honest about his failings?
See where I’m coming from?
You may not agree with me, that is your perogative. I didn’t make this post for you to agree (I said as much in the beginning when I predicted that even my friends will disagree). Heck I don’t completely agree with me—I actually like some of the principles like in-code documentation, but then again, I’m not denying the entire book, just its methodology of approach. But I wrote this post, as I write all articles in this blog, with the maxim: Write to create context for another to think.
I hope I have created such a context for you.
“Test first development, pair programming, user stories… geez need I go on? How many times has this shit only been proven to be better than backasswards “software as construction”
What don’t you like about TDD? Have you tried it? I can see that you enjoyed writing your blog but I’m not sure what arguments you have?
You gave a link to another blog whose author (pm jones) doesn’t seem to know much about TDD except how to spell it, and he in turn has presented a link where someone going by the name of jacob allegedly “debunks” TDD despite the fact that he hasn’t actually tried it. Perhaps he used psychic powers to shortcut learning and experience.
Wow, so apparently you made it through some of the first chapter and you feel that you can accurately review the entire book? And, of course, you haven’t read any of the other books, but based on their title you can tell that they suck too. You’re awesome.
For others that may come across your dribble and actually make it to the comments, I’ll leave some advice. Read the Pragmatic Programmer. Think about what they tell you and *WHY* they tell you those things. Put it in your toolbox, and when the time comes, if their tools help you, use them. Not all tools are right for every job. Part of being a professional is knowing which tools will work well with which projects.
Ryan,
Attack me personally because I haven’t read the whole book (I have read far more than a chapter), but address none of those arguments I put forward. I mentioned various parts of the book specifically; I mentioned the approach of the book specifically (the fact that each chapter is a prescription with not a single description of a side effect); I mention that the authors have claim that they are pragmatic with few to no mention of actual experiences that pragmatism come from; I mention that “holier than thou” language of the authors and the blind devotion that their language demands; I mention that pragmatism in programming starts with an honest discussion of consequences.
But instead, you, like all religious adherents attack me personally because you are a blind devotee to the book, unable to think critically beyond what your other zealot friends tell you: that it is a good book because it is a good book.
Instead of you, I have both tried and tested most every prescription in this book. Some on my own, and some because this book shares common heritage with other books I have read (and books I have linked above). I have found some wanting (I gave the example of “Design to Test”) and I have some useful (“Build Documentation In, Don’t Bolt It On”).
Because unlike you, I am not a blind devotee and I abhor dogma without reason.
Noel,
Yes, I’ve tried it. Like pair programming, I found it slow to develop in my languages of choice (I’ve tried it in C++, PHP, and Javascript). In the original post, I indirectly link this study:
http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html
I’ve seen its like before.
Remember that processes, like life management tools, are initially very compelling. But in practice they are often found lacking in unanticipated ways. I don’t deny that Test Driven Development, like any prescription, might have benefits (for instance, at least I don’t have to write regression tests later), but I am quick to point out that the biggest deniers of its obvious and obvert shortcomings.
By the way, Paul M. Jones, is very smart and the ad hominem is pretty lame. In particular, he is the author of SimpleTest, one of the only two good unit testing tools for PHP. While I find PHPUnit2 more complete, I find the clarity of code in SimpleTest to be better (no offense, Sebastian). He has been a big advocate of testing (more so than me), and yet he also is against Test Driven Development.
As for your dig on Jacob, whom I don’t know: it is equivalent to saying that I most first be indoctrinated as a Scientologist before I am fit to say it is not the religion for me. You are quick with these ad hominems and careful to avoid actual discussion.
Both of us, unlike you and unlike Noel, are willing to put up our blogs and our resumes to be attacked and analyzed. Both of us have the advantage of the null hypothesis on our side (the burden of proof is, as it should be, on those advocating Test First), and yet, you and others act like we’re the ones saying something radical.
While I don’t deny that more testing in general produces more reliable, more maintainable code. Nor do I deny the principles behind “design by contract”—the “inversion of control” that is demanded. My thinking is that Test Driven Development ignores the pareto principle: that 90% of your bugs will be in 10% of the code. Like many processes it demands egalitarian treatment of the 90 part and the 10 part, when simple practice alights you to which deserves special treatment (and more tests) soonest. This consequence is so simple and so obvious, I am almost embarrassed to point it out!
But feel free to continue with your ad hominems. You only embarrass yourself and prove my point:
Blind devotion and useless parroting is ugly, no matter if it occurs in religion, or programming religion.
If you wish to continue your unexamined life, feel free to do so, just not on my blog. Do it on your own and send me a trackback. I always encourage this discussion to continue and your voice to be heard.
oh wow i thought you were a scientologist, better change my subscription.
just glad i have subscribed to your blog, always a pleasant read. when i was reading the stupendous comments i wanted to jump in and help you against this ignorance, but you did that much better than i ever could. you have even written a longer reply than the original post. live as a software architect must be good, or where do you find this time? 🙂
you spend too much time writing this articles.
with imagination.
Point of clarification: I am *not* the author of SimpleTest. That project is the accomplishment of Marcus Baker. I am the author of (the surely less robust) Solar_Test, a separate entry in the testing field. You may wish to update your otherwise kind commentary. 🙂
Monday was a holiday and I was well rested. 🙂
Sorry about the error, Paul. I always confuse you guys.
Dave sent me this link. 🙂
There’s a big difference between ad hominem and fair criticism. For example jacob X hasn’t tried TDD – that’s not in dispute – and yet he does have a lot to say about it.
A common thread in all of these blogs is the attempt to frame the discussion to match the author’s lack of experience. The onus is wrongly placed on other people to make the effort to teach rather than on them to make the effort to learn. The language used is also a bit of a giveaway. Sneering at imagined dogmatism or religious zeal in a subject of which you have little knowledge is a pretty poor thing to do.
TDD isn’t a new theory passing through an initial peer review stage. I don’t have to “prove” it. On the other hand I’d be glad to discuss TDD with anyone reading this blog who is genuinely curious. Drop by sitepoint any time and I’ll promise you a eureka moment which will change your programming life.
This is the real issue: where can people go in the world of php to learn about this stuff? How can we encourage more php programmers to try it out?
To answer your 90% / 10% comment: the main purpose of TDD is to elicit 100% of the design rather than to “test” – although that too.
PS: P M Jones isn’t a SimpleTest developer.
Noel,
Yours is the very definition of ad hominem: to discount the message because of the messenger. His argument correctly points how the interpretation and the results of the IEEE study are misinterpreted in order to further a cause (test first development), he is quite magnanimous in attributing it to confirmation bias, whereas the evidence strongly implies that the misrepresentation of the study by these Test Nazis is deliberate (i.e. the post did not just stop with the abstract).
They have seen the black and called it white.
And just because Jacob points out that the emperor has no clothes, you say we must discount him because he hasn’t been audited, doesn’t have an e-meter and hasn’t paid for his Operating Theta III level ups!
I have read a number of accounts write about the virtues of test driven development starting with Kent Beck and William Fowler. And yet, outside a couple of isolated use-cases (XP used on simple projects like a billing system for Chrysler corporation), I have not seen it applied to huge projects successfully. It’s largest successes have been in refactoring very delicate parts of testless enterprise spaghetti code rewrites but the size of the project was strictly determined from the outset, and the pareto principle was already applied (it wasn’t the entire codebase that was refactored using TDD, only the most delicate parts).
You still have the burden of proof because the vast majority of projects out there, even in enterprise web space where the TDD zealotry is at its zenith, are not built using test-driven development. And among the most successful large-scale web projects out there, I cannot think of a single one that uses Test-Driven Development throughout the entire codebase. The conventional wisdom—and the bulk of the studies in this area confirm this—is that more tests equals better quality and less productivity and that Test Driven Development encourages more tests.
Indeed, as you point out, TDD isn’t a new theory. And yet, the overwhelming weight of evidence is that it is not close to a magic bullet of proven benefit in certain instances, many of which have been mentioned already. As for SitePoint, why bother? Paul Jones and Marcus Baker are active participants there already and I have a number of people call me out privately and publicly on my blog entries.
As for the question about “Where can people in the world of PHP go to learn about this stuff?” My solution is to say, “If you are going to exhibit blind devotion instead of critical thinking, I’d rather you not stay in the PHP world and go to the Ruby world where your zealotry will be appreciated.” The PHP world has done an excellent job of adopting the most successful programs, practices and products in the web space. I myself have been lecturing for over five years now on unit testing, agile processes, and design patterns in PHP! (I first read most of the The Pragmatic Programmer four years ago.)
…
The 90/10 comment shows the consequences of a choice, a consequence, not mentioned once in that entire chapter of The Pragmatic Programmer. That is not unexpected, today a lot of books on Pattern Literature seen never to mention the consequences of a design pattern choice. This is why there is so much backlash.
If you look at the IEEE study, you’ll find this common sense is exactly confirmed by the study. The overall quality of the control group was slightly better than the TDD group, but not in a statistically significant way. The number of tests written by the TDD group was more than the control group. And therefore (Wow! the pareto principle): The control group was much better at writing more useful tests with no detriment of quality!(*) Common sense (born from experience) strikes again. Who would have thunk? Does that mean Test Driven Development is shit? No, but it certainly shows it isn’t THE shit. (The control group were “Test Last” not “No Test” people.)
As for the Paul Jones comment, I was corrected up above. It’s rather lame of you to further that after what clearly occurred after I moderated his comment. But not to be expected from someone who needs to resort to ad hominem to defend his points.
I have asked each of you, who is being “pragmatic?” Me, who has done TDD and says simply that TDD is probably best applied to situations in software rewrites where quality of the main is valued over productivity of its individuals (medical equipment, financial transactions, but hardly in a release-often, easily-revertible, large-scale, consumer-facing website like Facebook or Tagged :-D) and because it has these consequences (productivity/quality tradeoff, and up-front egalitarian approach to test-writing) is not a best practice to be applied blindly; or the authors of The Pragmatic Programmer who shout at you that “Design to Test” is the very best way of coding everywhere and always—with not a practical example where they’ve actually experienced it, but numerous contrived theoretical suppositions on why you this is the case.
(*) I will point out that there is some weirdness going on in the IEEE paper, when I skimmed it the confusing part is in the “PROD” measurement (which is supposed to be the amount of “effort” taken to complete a user story, but a common sense and more measurable definition of productivity would be the amount of user stories completed in a given unit of time!). The conclusion in the paper is that the TDD-ers had a statistically-significant higher PROD than the control group. It’s hard to understand what is going on in the study because the strong correlation between the PROD rating and the number of tests. Few disagree with the basic statement: more tested code is in general more reliable, and it this is the reason test first design is under consideration at all (it almost always guarantees more tests get written). Go look at the last graph in the paper. It’s very strange (though not surprising).
What I conclude from the study is that TDD exhibits its strongest improvements among the worst programmers (by causing more tests to be written overall), but that it may pull down the quality of the best programmers (certainly enough to make the difference in overall quality between the test first and test last group slightly favor the test lasters); that test-first design seems to decrease the predictive powers of counting tests as a function of code quality; and that another study should be referenced when exploring the general concept of “productivity” (in the allotted time for the user story, I could picture the best of the control group were just idling trying to think up Unit Tests to fill their time).
I went to archive Jakob’s article and I ran across this linked post.
http://scruffylookingcatherder.com/archive/2008/01/31/tdd-or-pout.aspx
Notice how he, quite independently of me, mentioned the pareto principle (he calls it the 80/20 rule, I called it the 90/10, but it’s all the same).
An interesting post worth reading.
(Also, I might note that I originally went straight from Paul Jones’s summary to the actual IEEE paper so I hadn’t had any cause to defend Jakob, but reading his points, I can see that, while he may not have done Test Driven Development, there is no doubt that he’s written more unit tests than many of his detractors and that he has a thorough understanding of many agile processes. I’d say that discounting him on those two counts is more speaks more of the sloppiness of his detractors than on an indictment of him.)
Umm, I didn’t address your arguments because you didn’t read the book. Of course you took my “attack” on you personally, because I was personally attacking you. You wrote a book review without reading the book. I’m going to call you out on that.
If you had read the book, maybe your arguments against the book would hold my interest. I can argue with you about the book all day long, but it’s not going to do any good, because your arguments will not be based on the text, they will be based on what you think the text says, sometimes based on nothing more than the title. What’s the point?
Furthermore, I am not defending the book itself. I am not a devotee nor blind follower of the book or its authors. As I said originally, not everything in that book is going to work, and one needs to use critical thinking skills to determine if their project would be helped or hindered by heeding the authors’ advice.
Agree or disagree, it IS one of the premiere books in our industry, and it’d be a shame not to read it.
Just because I quit the book two chapters from the end, does not mean that I’m not fit to judge both the egotism of the approach and the irony of the author’s use of the word “pragmatic”—all evident in the first six chapters.
I think it’s obvious to everyone who’s slogged this far that I have read more of the book than you, that I have thought more about the concepts espoused the book than you—and even the authors!
I never denied The Pragmatic Programmer is an influential book (so is Code Complete which is also deeply flawed). It is because of that acceptence that five years after it’s publication, I didn’t find a new idea I hadn’t already run across in the first 75%. At the time, I attributed this to the influence of the book—but I’ll admit that I could be wrong and it may be that the writers, like the developers of Ruby on Rails, had nothing to add but clever repackaging.
A whole lot of style in this post, but after reading it I have no idea what you just said.
Good post! It takes a smart guy to see through all the bullshit in this world. There are too many bullshit suckers around who can’t see that the emperor is naked!