An Open Letter to Joel Spolsky and Jeff Atwood

Minhajuddin 12 minutes later:

• • Wow, I am eagerly waiting for podcast #40, Expecting a lot of fireworks. But most importantly I want Uncle Bob to win and remove some misconceptions about TDD and other stuff.

  • I don’t think that Joel is that dumb a guy to not understand the advantages of TDD, maybe he is doing this just to get some attention around the stackoverflow podcasts.

  • But, I really think Jeff and Joel shouldn’t resort to this kind of cheap tricks to get the attention of others. That brings us to the question, Are they “Jumping the shark?”

Jim Anderson 14 minutes later:

• • It should be interesting. Do you know when the podcast will be recorded and published?

Chad Myers 21 minutes later:

• • Well… that should set the tone pretty well going into the podcast! Make sure you don your flame retardant suit because it should be quite warm in there! :)

  • Seriously though, I agree with the sentiments and I hope you do take them to task (albeit with patience and labor) because, you’re right, some of the things they said are simply indefensible and demand recourse from professional software developers trying to raise the level of practice and engineering in our craft. Podcasts like #38 are simply harmful and embarrassing and make programmers look even more like idiots to non-programmers than we already do in many cases.

  • Good luck and remember just to stay on topic and don’t let them draw you down into their ridiculous arguments. Remember, you literally wrote the book on this stuff…

Chad Myers 21 minutes later:

• • Well… that should set the tone pretty well going into the podcast! Make sure you don your flame retardant suit because it should be quite warm in there! :)

  • Seriously though, I agree with the sentiments and I hope you do take them to task (albeit with patience and labor) because, you’re right, some of the things they said are simply indefensible and demand recourse from professional software developers trying to raise the level of practice and engineering in our craft. Podcasts like #38 are simply harmful and embarrassing and make programmers look even more like idiots to non-programmers than we already do in many cases.

  • Good luck and remember just to stay on topic and don’t let them draw you down into their ridiculous arguments. Remember, you literally wrote the book on this stuff…

Hadi Hariri 22 minutes later:

• • @Minhajuddin

  • “I don’t think that Joel is that dumb a guy to not understand the advantages of TDD, maybe he is doing this just to get some attention around the stackoverflow podcasts.”

  • There’s a minor issue with that. Those that understand TDD/SOLID and understand the benefits could make this out to be a way for him to attract attention. Unfortunately not all those that listen to the show know this for a fact. And when you have such a high audience, you need to be careful with your words.

Minhajuddin 36 minutes later:

• • @Hadi Hariri

  • It’s true that many of the folks listening to the show might not be fully aware of TDD. And I hope that Uncle Bob is going to use this opportunity(if I can call that after all the things Joel said) to give them a glimpse of the bliss of TDD and Agile. But, I can’t restraint my words after thishttp://www.threeriversinstitute.org/blog/?p=29#comment-7

Denis 43 minutes later:

• • I enjoy the StackOverflow podcast and I’m a fairly active member on the site as well. I will say that my reaction to some things said by Joel and Jeff ranges from “meh” to outright cringing. There is a great deal of valuable information as well and I think that the good outweighs the bad (by a considerable margin).

  • The comments regarding you in the podcast actually made me mad. I thought it was unfair to characterize your work and your credibility without much thought, investigation or a sense of fairness. It’s one thing to disagree while it’s another to be so cavalier while disrespecting a fellow professional.

  • TDD is not as simple is sounds and it’s very important that it be done correctly or it will be counter-productive (as it true with most things, of course). And to be fair, I don’t think Joel actually understands TDD (based on his example of the JPEG compression). Perhaps after understanding TDD properly he will still feel that it’s often overkill but it would be nice to argue against it with a better understanding and without using straw men.

  • While I appreciate your understandable feelings towards this very personal and direct attack (though I don’t believe Joel and Jeff would see it as such) I think your comments from the legal angle are, perhaps, premature and counterproductive to a good discussion. This isn’t to say I don’t understand your position – I would feel the same way. Your reputation is not only important personally but also economically. The good news is that I suspect that most people will feel the same way.

  • The S.O.L.I.D principles, TDD and agile are not the answer to everything (i.e., still no silver bullets) but I know from experience that a good understanding of these ideas helps to deliver better products more quickly. Quality and Time To Market are very much not at odds with one another.

  • I look forward to the upcoming podcast as I think it will only serve to benefit any one listening.

Denis about 1 hour later:

• • I enjoy the StackOverflow podcast and I’m a fairly active member on the site as well. I will say that my reaction to some things said by Joel and Jeff ranges from “meh” to outright cringing. There is a great deal of valuable information as well and I think that the good outweighs the bad (by a considerable margin).

  • The comments regarding you in the podcast actually made me mad. I thought it was unfair to characterize your work and your credibility without much thought, investigation or a sense of fairness. It’s one thing to disagree while it’s another to be so cavalier while disrespecting a fellow professional.

  • TDD is not as simple is sounds and it’s very important that it be done correctly or it will be counter-productive (as it true with most things, of course). And to be fair, I don’t think Joel actually understands TDD (based on his example of the JPEG compression). Perhaps after understanding TDD properly he will still feel that it’s often overkill but it would be nice to argue against it with a better understanding and without using straw men.

  • While I appreciate your understandable feelings towards this very personal and direct attack (though I don’t believe Joel and Jeff would see it as such) I think your comments from the legal angle are, perhaps, premature and counterproductive to a good discussion. This isn’t to say I don’t understand your position – I would feel the same way. Your reputation is not only important personally but also economically. The good news is that I suspect that most people will feel the same way.

  • The S.O.L.I.D principles, TDD and agile are not the answer to everything (i.e., still no silver bullets) but I know from experience that a good understanding of these ideas helps to deliver better products more quickly. Quality and Time To Market are very much not at odds with one another.

  • I look forward to the upcoming podcast as I think it will only serve to benefit any one listening.

Daniel Meyer about 1 hour later:

• • Minhajuddin, You have to be careful assuming that that comment-7 is really Joel Spolsky though, right? Anyone could post with his email address and web address (both public information, right?) and appear to be him.

Bob G. about 2 hours later:

• • While I land more on your side, I would look at your “having this discussion in court” statement as a very silly. There was nothing libelous or slanderous in the statements Joel or Jeff made. They made opinions. Design patterns and principals are opinions about software development, there are no facts involved. The opinion was made about the principles not about a specific person even. If I said you were a terrible programmer, that is not slander, but an opinion. If I said you like to physically assault people, that could be slander (assuming you don’t like to assault people) because I would be making what appears to be a factual statement (not based on opinion) but which is actually false and which would bring about a negative opinion of you. So to make statements of litigation ruins the rest of your argument. The fact that you were hurt by these words is understandable, but it doesn’t make it illegal.

Daniel Fernandes about 2 hours later:

• • I would agree with what you said regarding the SOLID principles in that the SRP principle is the one that is the most difficult to agree upon due to its inherent subjective nature and the fact that it’s in direct contradiction to core OOP principles such as Encapsulation. Under-usage of SRP and over-usage should IMHO be considered harmful. On one end of the scale we’re maybe talking a class that just does about anything in a system and on the other end we’re talking a class that is more a pure function than anything else. I’ve come across so many IoC tutorials where a developer would refactor some class just because of the most trivial extra operation this class needed to do. And at the same time I’ve come across code in the open source community that are revered by a lot of us and where core functionality was implemented with classes one would argue in direct contradiction to SRP. For an example have a look at SessionImpl in NHibernate or probably Hibernate, too.

  • Like with anything else in life, one has to take principles with great care to avoid entering into a dogmatic war.

  • And who cares anyway! To all this I just say YAGNI! (feeble attempt to humour).

  • Daniel

Buckley about 3 hours later:

• • Although I would like to say that I practice TDD I must admit that I don’t. Doing TDD right is not easy and it takes a while to get used too. I have been in maintance mode for the last couple of years and the time it takes understand the code of someone else can be soo long that I am satisfied with killing the bug or implementing the feature withoug writing test. This is my bad but frankly I don’t have the time to write the tests. I know from my own experience that one can build an awesome V1 product without TDD but it goes without saying that good tests help to make V2 an even better product and that V1 can be refactored with confidence.

  • However, the next guy whos has to maintain the product will find it ablessing if good tests are in place. Since I am in maintance mode thats me. Or it could be that she will just throw the tests away … either because she doesn’t get TDD or that she feels that the failed tests are not worth repairing. The whole team and the pleople that will eventuely become the new team will have to embrace TDD to make it a factor of success. IMO if you are a professional you should take time to learn TDD and discuess it with your collegues too. I hereby concluded that I am not a professional but just a nomad cranking out code as fast as I can. But I am slowly maturing an will eventualy leave my bad habits. I know that there is a better way.

  • As for bashing the SOLID principles that’s just ridiculous. They form the basis of good OO design and people who don’t embrace these principles shouldn’t be allowed in our business anymore. It’s not those principles fault that they are indicated with smart sounding acronyms. The ideas behind them are solid and only in the minority of cases should they be abandoned.

Phil Bennett about 3 hours later:

• • You could sell tickets to the next podcast :) I would double check with Joel that he actually did leave that comment on Kent’s blog – I am dubious. Either that or Joel is being downright stupid.

Alan Stevens about 3 hours later:

• • I like the tone. You don’t pull punches, but you stay on message. I can’t wait to hear how the podcast turns out.

  • ++Alan

James Brechtel about 3 hours later:

• • Really looking forward to the podcast. Long time fan of Joel’s writings, but he was way off base here.

  • I think it’s podcast #41 though. #40 already seems to be posted according tohttp://blog.stackoverflow.com/2009/02/podcast-40

James Brechtel about 3 hours later:

• • Really looking forward to the podcast. Long time fan of Joel’s writings, but he was way off base here.

  • I think it’s podcast #41 though. #40 already seems to be posted according tohttp://blog.stackoverflow.com/2009/02/podcast-40

Eduardo about 3 hours later:

• • Go Uncle Bob, Go!!

Robert Kozak about 4 hours later:

• • I really enjoyed your post. I didn’t hear the podcast but I did catch a rant about it on another blog I follow.

  • I am glad you crafted your response in the manner you did. It was on point and with a slight humorous tone underlined with slight frustration and annoyance.

  • Often times I have argued strong principles with other developers who think they understand what they are saying and it can be frustrating when people just don’t get it. Maybe it comes with experience in designing vs. coding.

  • As far as I am concerned if you just code without learning the proper design principles you will continue to make the same mistakes every time.

  • Again, great post. Its a keeper.

roger.pence@gmail.com about 7 hours later:

• • Uncle Bob—

  • I have listened to your podcast with Scott several times and it is one of the few that I’ll keep for a very long time. It was great—the message was clear, important, and well delivered.

  • All of which are attributes of your corresponding post to Joel and Jeff. This isn’t the first time they’ve chased each other off the edge of the cliff! And it won’t be the last (it was for me a long time ago).

  • I’m in your corner. Don’t stop teaching! rp

Ariel Valentin about 7 hours later:

• • I really hope they take you up on the offer. I think its great that you are willing to have an open discussion with people who disagree with your position. From what I heard your interactions with Jim Coplien made for great presentations at Deep Agile! This will be classic!

Adeel Alvi about 10 hours later:

• • Uncle Bob

  • I am big fan of you and Scott Hanselman and i think there is a better way of expressing difference of opinion.

  • Keep going Uncle Bob you are doing a marvelous job.

Sebastian Kübeck about 13 hours later:

• • @Bob G.: You are right. That was too much….

  • @Daniel Fernandes: SRP means a single responsibilty and not less! See: http://butunclebob.com/ArticleS.DavidChelimsky.SingularResponsibility

Andres Kievsky about 17 hours later:

• • And that’s why I call his blog Joel on Crack

MadVillain about 18 hours later:

• • Wow. The remarks about bringing this to court make you look like a petulant child. Your remarks have all the drama of a teenager telling his parents he’s going to call child services on them.

  • Threats like this have no legal basis at all and really distract from the issue. If you really had an issue with Jeff and Joel (and trust me, I’m no fan of them myself), the adult way to handle the situation would be to send them an e-mail and confront them personally. And then end it. The myspace-style rant is great for inviting drama and inflating your own sense of self-importance, but does little to actually solve your feud.

John Stoneham about 19 hours later:

• • Bob – agreed with previous commenters on the court reference, I think it bears removal for giving a poor impression.

  • You said in the letter you wouldn’t post the letter until you’d iterated it with Joel and Jeff. Should we assume you’ve already done so? Or did you mean ‘we’ to refer to you and Kent?

  • Can’t wait to hear #40.

Ted about 20 hours later:

• • What’s with this whole TDD/SOLID and Podcast stuff?

  • Just because you practiced TDD does not make your code clean nor high-quality.

• Let’s face it, most TDD practitioners are “DEVELOPERS”. You are not “QA”, “TESTER”, “SDET”. What do you know about various testing techniques, testing principles, testing metrics, how to test, etc?

  1. Do our field a favor TDD-er, do the following:

     1. How We Test Software at Microsoft

     2. Go to MS and apply for SDET position (or Google)

     3. Read more books about Software Testing

     4. Ask yourself if you wrote great TDD code or not

• • Now for the last question, if the answer is “Yes”, then you’re a Tester. If the answer is “No”, then you’re a developer. And obviously, if you are a developer, you suck at TDD.

  • It’s just how the brain is wired or perhaps it’s in your training. Developers are almost always bad testers, vice versa.

Erik about 22 hours later:

• • @Ted: Your comment only shows your infatuation and your cluelessness… Just pathetic. Hope you’re a Joel/Jeff fanboy – it would at least be some sort of an excuse ;-).

  • @Uncle Bob: when I saw you mention “discussion in court” in your post, I couldn’t help but thinking “Well, that’s probably what makes the US so great…” :-(. As far as the core of the issue is concerned, I’m definitely on your side though.

Jeff Anderson about 22 hours later:

• • Ted,

  • sorry but your post is crap.

  • I lead extremely large teams with both testers and developers. And have plenty of experience in both development and testing.both

  • I have a huge influence on the methods and practices employed by both.

  • TDD emphasizes that developers need to think more like testers. And give them a path to doing so. Good tests need design, they need interfaces, and they need abstraction. Typical testers are your wallet doing this.

  • Good tests also need to be anal, test all kinds of boundary conditions, and be complete. Developers have a problem with this level of discipline.

  • Testers on my teams evolve to “developer-testers” and learn to think like developers when applying tests.

  • Standard testing/QA approaches result in testing quality in only the most superficial way, i.e. whether it works or not, that is not quality, that is just testing for obvious failure.

Peeps 1 day later:

• • I believe the lawsuit comments should have been caught in your test. Otherwise I look forward to how beavis and butthead handles your retort!

Lawyer 1 day later:

• • Really? Your response is to threaten a lawsuit because you are annoyed with what they said? No court would hear such a ridiculous suit. In addition, it makes you sound defensive (in a bad way).

  • Argue, state your opinion, point out fallacies… by all means. But your comments about how you are going to sue them make you seem ridiculous.

Daniel Fernandes 1 day later:

• • @Sebastian Kübeck What I am saying is that SRP as a principle is important but should be dealt with care. In terms of class design, at one extreme one can think we have a function/class, for instance an Extension Method in C# although with state this time, and on the other you have a class that does a lot of things. As Bob said it himself, not all SOLID principles should be taken religiously otherwise you will end up with a truly ugly system with a plethora of classes that barely do anything. And I said, have a look at well respected open source projects and you will see that a lot of those break “pure” interpretations of SRP.

  • Daniel

JamesK 1 day later:

• • @Jeff Anderson

  • “Good tests also need to be anal, test all kinds of boundary conditions, and be complete. Developers have a problem with this level of discipline.”

  • That’s why your developers aren’t the best testers.

  • “Testers on my teams evolve to ‘developer-testers’ and learn to think like developers when applying tests.”

  • Yet your testers aren’t (and probably won’t be) the same level at your developers.

  • “TDD emphasizes that developers need to think more like testers.”

  • Not quite, they need to think a bit more defensive not be like testers. Good testers have learned all sorts of testing techniques. Good developers have learned all sorts of development techniques.

  • If your testers are as good as your developers, why not make them the developers? I heard that usually people need more “able developers”? And if all of your developers are as good as testers, why not utilize them as both? what’s with the separation?

  • Ted might come a bit strong, but he has a point: your developers will never write the best TDD code around; that’s your testers’ job.

  • I wrote some tests just to make sure when I re-factor my code, things don’t blow up. It saves time. But I know TDD won’t guarantee the quality of my product. Far from it.

Chris Marisic 1 day later:

• • Signed,

  • Chris Marisic

Erik 1 day later:

• • To various commenters who want to leave TDD to testers: TDD is also a lot about design. Want to leave that to testers too?

  • Please try to have a clue of what you’re talking about!

  • But: TDD is certainly not a silver bullet. I’m using TDD for some time now but I wouldn’t like to work without a QA after me. TDD doesn’t make my designs perfect (what is perfection anyway?) etc. But TDD made my designs testable (i.e. better in my eyes) and refactorings most of the time very easy (I don’t know how Joel/Jeff can think a code change can break 10% of the tests – I’ve definitely never seen anything like that happen in my TDD years. It would be the proof of a disastrous design of the application in my eyes)...

  • Sure if you’re a development genius you might not need TDD. But how many of us are geniuses? How long does a genius work on a project before he finds it boring? Is is always simple to maintain the work of a genius? Which percentage of the software delivered in this world is the product of a genius?

• TDD is in my eyes a very helpful discipline (http://en.wikipedia.org/wiki/Discipline). It certainly has downsides etc. But

  • 1. Know what you’re talking about

    2. Avoid insinuating that we’re stupid to use TDD – a flame war has never made anybody smarter.

    3. Provide sound arguments when criticizing it

    4. Offer alternatives that at least solve the same problems and cost similar or less.

• • Then you might convince me – ‘cause I’ve no religious feelings about TDD, just want to use the best tool I can find for my purpose :-)

  • On a philosophical note: I do believe that “anything goes” (http://en.wikipedia.org/wiki/Paul_Feyerabend) but that certain paths lead to success more often than others – at least for me. That’s why I’m using TDD these days.

  • Last but not least: if “quality really doesn’t matter that much, in the big scheme of things” (Jeff in Podcast 38 – note that he says that he feels sad about it) is true – and many people in IT do act as if it were true – I fear we’re doomed (for example to take more and more time fighting an ever increasing number of growingly complex bugs that will affect our daily life in very unpleasant ways in the end…)

Alek Davis 2 days later:

• • “Were I a more litigious person, we might be having this discussion in court.” Unlce Bob, whatever you’re smoking, please stop it right now. (DISCLAIMER: This was a joke. Please do not sue me.)

  • Seriously, Uncle Bob, please grow up. Joel and Jeff did not attack your person. They disagreed with you on certain points, and explained why.

  • Nobody claimed that TDD was inherently bad (I’m pretty sure that both would agree that TDD is an appropriate application for the JPeg compression feature and similar situations). The main argument was to not use TDD (or any other methodology) indiscriminately. In some projects, TDD should be used extensively, and in other projects TDD offers marginal benefits. The main point Joel was trying to bring across was the idea that people should think why they do this or that (like writing unit tests). How can you argue against this?

  • Regarding Jeff’s blurp about irrelevancy of code quality, I cannot speak for him, but I doubt that Jeff does not care about code quality. Good software cannot be of poor quality. I suspect that he was arguing against spending disproportionate amount of time trying to achieve the highest code quality. Let’s say that you spend 4 weeks out of 8-week development cycle writing unit tests. If this really helps you improve code quality (and I assume you have data to quantify this), sure, go for it. But if you spend half of your development time writing unit test just because you have to write unit test, you may be wasting your time, and you would rather spend it implementing new features, addressing existing bugs, etc.

  • Finally, it seems to me that if we bypass the emotional and dogmatic aspects of the argument, Uncle Bob, Jeff, and Joel will probably have a lot to agree with (e.g. practical application of SOLID principles and TDD). Maybe we’ll hear it on the next StackOverflow podcast.

Richard 3 days later:

• • Even if that what Joel said was massively exaggerated, there is a core of truth. Maybe you could learn from those statements what has gone wrong in teaching those “principles”.

  • Then: “However, your podcasts are a product that you ship to everyone in the world.”

  • If this is irony, it’s not that funny IMHO. Not everything can be put in a model and then apply a method on it. A conversation is not a product like a shoe or a computer program.

Jonathan 3 days later:

• • I look forward to discussing SOLID and other things on the TalkWare podcast.

  • With regards to all of the hupla -

  • I wouldn’t give them the satisfaction of all the publicity, really.

  • Debates are good, but I find sometimes debating with a certain type of person, leads no where. We have to rise above cynical, closed minded and short sighted viewpoints. I am not referring to who is right on either side of the debate. I refer to how it was said and the kind of language used to communicate that opinion is just stupid and obviously provocative.

  • But I think it actually demonstrates a larger point.

  • A Certain Personality Trait that is detrimental to projects.

  • There are people who are trying to “give” to the community, and people who just “take and criticize” if its not good enough. This personality trait is everywhere.

  • A large part of projects fail, because of these self-centered traits. The ones who stick to their guns no matter what, the ones who resist coding standards, treat discussions as competitions to win, or hate Design Patterns for who knows why, resists a technology, just because its become a buzz word. I am sure you know the trait.

  • I have worked in a few teams with people of this nature, and ultimately it ends up being a late project. Maybe you don’t agree, but I have learnt to leave these people be, and concentrate on the more agile minds instead.

  • I have assigned these people with more isolated solitary tasks, which actually suits their loner mentality anyway. You just have to deal with each personality differently.

Steve Py 4 days later:

• • Just step down from the soap box. Step down before this turns into a “You can’t handle the Truth!” rant. For someone that claims not to be dogmatic, that sure sounds like preaching. But hey, that’s my opinion.

  • Frankly the blog comments are somewhat more entertaining than the letter. It reminds me of something I read in Dilbert way back. The problem with success (in his case a project with funding, but I think the message still applies) is it attracts suck-ups and jealous people that wank to huck bricks at you. The key to success is to keep a protective ring of suck-ups handy to block the bricks.

Chris 5 days later:

• • Jeff Atwood responds (and claims Uncle Bob has really big ears).http://www.codinghorror.com/blog/archives/001225.html

Mike Woodhouse 6 days later:

• • The podcast is downloading as I type – I’m looking forward with almost indecent excitement to hear the outcome. Kudos to J&J for having you on the show – I’m curious to see if they will see that there may be no incompatibility between their stated goals: delighted customers, and the principles they seemed so amused to dismiss. In my limited (30 years) experience, I’ve tended to discover that the more I know, the more likely I am to deliver satisfaction. I still lacked the nerve to pose a question asking when they realised they knew all that was necessary about the software development process…

  • I should say in fairness that Stackoverflow is still the only podcast that I regularly wish I could join in on – it’s by far my favourite. I have just over an hour before the commute starts and I get this week’s fix.

Steve 6 days later:

• • In defense of Joel’s comments, you don’t write a lot of code these days, Bob, and your advice and books do reflect that. Your recommendations also do sound extreme and dogmatic (didn’t you used to say that someone who doesn’t test 100% of their code should be fired?).

  • So you do use emphasis to get people’s attention and traffic to your site. It’s the Internet, it’s business as usual.

Console 6 days later:

• • Wow – I have to say that if there is so little technical merit to the TDD approach that has to be defended by lawyers and threats of litigation then it just proves Joels point.

  • I had a lot more faith in TDD before I read this open letter.

unclebob 6 days later:

• • Steve 6 days later:

    • In defense of Joel’s comments, you don’t write a lot of code these days, Bob, and your advice and books do reflect that.

  • You may look on github/unclebob to see just how much code I have written in just the last few months.

    • Your recommendations also do sound extreme and dogmatic.

  • Which ones?

    • (didn’t you used to say that someone who doesn’t test 100% of their code should be fired?).

  • Not that I can recall. Can you show me the quote?

StrawMan 7 days later:

• • “Seriously, Uncle Bob, please grow up. Joel and Jeff did not attack your person. They disagreed with you on certain points, and explained why”

  • Alek, this was not just a simple disagreement on a point of debate.

  • When you say something like “sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code”...

  • ...you’re no no longer debating. Put it this way, would you argue this in a school debate… ? Would you say “The other team obviously have no idea what they’re talking about and sounds like they didn’t even do any research before they came”?

  • You wouldn’t because this is not a debate point, it is a personal attack. If the person being attacked has a reputation invested in the industry, then it’s rather serious.

  • And so you attacked as well…. “Just grow up!”.

  • All this attacking and you’re satisfied that everyone is just “disagreeing on certain points”.

  • I’m a little shocked at the lack of clear-thinking from people who are probably all computer programmers (?). I thought we’d have the strongest sense of logic.

Pawel Lipinski 7 days later:

• • I know it’s mean of me to say that, but Joel Spolsky is creating a bug tracking software. So the more bugs in the world, the more copies he sells. This is the only reasonable explanation of his irresponsible statements. Such an influential figure should never say things like this.

Ravi Venkataraman 7 days later:

• • I find it interesting the Uncle Bob claims he is not dogmatic. No person who is dogmatic will ever think that he is, they all think they are fair and open and broad-minded. It is for others to inform them whether they are being dogmatic or not.

  • In Uncle Bob’s case, knowing his political views from previous blogs and his obstinacy in the face of mounting evidence against his views, I find it ironic that Uncle Bob does not realize how dogmatic he actually is.

  • I read the transcript of Joel’s podcast and I see that Joel and Jeff think they have valid reasons for making their statements about quality and TDD. While disagreeing with them on quality, I understand that my opinion is based on what should be, not what currently is true in the software world. As for TDD, it is a tool to make the average developer write better code; it is a poor design tool. And regarding the SOLID principles, there is nothing here that other authors have not written about before Uncle Bob. Bertrand Meyer’s tome comes to mind as an earlier example of these ideas.

  • I understand that being a high-level consultant requires one to put old wine in new bottles from time to time. The Uncle Bobs and Martin Fowlers of this world are quite adept at doing so. Since they believe in what they are doing, and their customers seem to like their offerings, good for them. But it does not follow that every other thinking software practitioner has to agree with them.

  • Disagreements, even sharp disagreements, are the lubricant that drives critical thinking and leads to innovation. To attempt to stop disagreements by veiled threats of lawsuits is not conducive to vigorous discussion. And by no means are such veiled threats a sign of open-mindedness. These are the sure signs of a dogmatic person.

  • Additionally, as shown in an earlier blog article, appeals to authority (even if that authority happens to be oneself) are not valid reasons for claiming that TDD is agile. Just because you happen to be one of the founder-members of the Agile concept, it does not follow that you will always be correct on what is Agile and what is not. Using that logic, one could argue that as the discoverer of the theory of Evolution, everything Charles Darwin said about evolution must be true; and this is clearly not the case since he wasn’t even aware of DNA or molecular biology or many of the fossils that we have today.

  • Let us talk about the merits of TDD, why quality is not seen as a plus in the marketplace, why OO principles are good, and so on. Let us not allow these discussions to degenerate into flame wars. Let us not strike back reflexively when somebody disagrees with us. Let us all grow up and show a bit more tolerance for divergent views.

  • More discussion on the topics, less on the personalities would be better.

Chris 7 days later:

• • “I know it’s mean of me to say that, but Joel Spolsky is creating a bug tracking software. So the more bugs in the world, the more copies he sells.”

  • This is just about the most ridiculous thing I’ve ever heard. Just how exactly does Joel benefit from increasing the number of bugs. Do you think FogBugz is licensed by the number of bugs a team has?

adasilva@twcny.rr.com 9 days later:

• • Oh puhleeze Uncle Bob. Did your ego get bruised tto much?

John MacIntyre 9 days later:

• • Uncle Bob,

  • I’ve been a big Joel Spolsky fan for almost 10 years, and more recently Jeff Atwood. I really like thier blogs, podcast, and StackOverflow website. I heard episode # 38, episode # 40, and now read this response (slightly out of order).

  • For what it’s worth; from what I’ve seen you been a class act in handling this.

Pawel Lipinski 12 days later:

• • @Chris: Come on! I wasn’t serious about Joel willing to sell more by saying this. Maybe I should’ve put ;) somewhere there…

  • But as a matter of fact, it isn’t that ridiculous. Were there no bugs -> bugtracking soft wouldn’t be needed. The less problems with quality, the less investment in bugfixing support tools.

  • But obviously I don’t believe that was the case.

Evans 12 days later:

• • This is interesting – I can’t believe Joel is dumb a guy not to understand what TDD is and how it works.

  • As someone said sometime ago, he’s always on the look out for new ways to get our attention :)

  • I will have to look out for the podcast.

Echostorm 14 days later:

• • Clearly suing Jeff and Joel for dissing TDD is the only reasonable action here. We all know that coders who don’t use, nay like, TDD are terrorists.

Tottinger 14 days later:

• • Echostorm: no, for saying Bob doesn’t really do technical work anymore. Claiming that a person doesn’t deserve their reputation is worse than not liking a practice or two. Bob codes. He codes quite a lot, and has as long as I’ve known him.

http://agileconsulting.blogspot.com 14 days later:

• • it took me years to gradually get into and fully embraced TDD.

  • Saying TDD is a poor design tool is ridiculous…

  • you will certainly run into challenges the first couple times you try it,

  • This Friday I just gave a demo of how we are using fitness, NUnit, and soap UI to create “executable requirements” and he almost cried with excitement…

  • I could be politically correct about this, but IMHO people who can’t see the value in this approach could do with a couple of good slaps…

Anon Y Mouse 14 days later:

• • @agileconsulting: TDD is not a design tool. You can’t come up with your class diagrams using TDD. You can’t come up with sophisticated algorithms with TDD alone. No matter what you say, it is not a design tool.

  • To want to slap somebody who expresses an opinion different from you is the height of sophistication, I presume.

  • Is that how you treat your colleagues who disagree with you? I am sure that would make you extremely popular.

Brett L. Schuchert 16 days later:

• • Anon Y Mouse wrote:

  • @agileconsulting: TDD is not a design tool. You can’t come up with your class diagrams using TDD. You can’t come up with sophisticated algorithms with TDD alone. No matter what you say, it is not a design tool.

  • Class diagrams are not a goal. They are at best a tool for understanding and communicating. Class diagrams don’t execute and so they can only indirectly add value.

  • TDD is a design technique and it’s as much of a tool is as rational rose, albeit in a very different style.

  • As for not being able to come up with sophisticated algorithms, you could not be more wrong. If by sophisticatedly you actually mean unnecessarily complex, then that’s not a very good goal, is it?

  • If by sophisticated, you mean exactly what a situation calls for and is also able to be changed, then I disagree.

  • You must have very limited experience with TDD. As for algorithm design, have you actually done that? Have you created an algorithm and then actually performed basic analysis on it (e.g., big-O analysis)?

  • I am NOT saying TDD is the only way to create sophisticated algorithms. That’s demonstrably false (think of quantum computing sorting/search algorithms based on wave collapsing). However, you are clueless about TDD based on your comments.

Anon Y Mouse 17 days later:

• • @Brett: Use TDD to come up with the Quick sort algorithm, please. Using TDD only, you limit yourself by giving up on many possibilities. TDD is no substitute for thinking about a problem.

  • Class diagrams are design. TDD is after the fact of class diagrams, after the hierarchies and relationships are defined. I can’t test a class that is not part of my design, whether the design is explicit or implicit. This does not mean that the class hierarchies are written in stone;they can, and do, change over the course of development.

  • Rather than accusing me of having limited experience with TDD, or not having done big-oh analysis, please answer the first question I asked above.

Erik 18 days later:

• • @Anon: Use class diagrams to come up with the Quick sort algorithm please. Who said you should limit yourself to TDD? Don’t you imply you should limit yourself to class diagrams for design? That only class diagrams are design? I can’t help but thinking you really have no clue about TDD when I read your comment.

  • Note: I worked many years with class diagrams (the big design upfront days…) and now mainly with TDD.

  • I still can start with a high level class diagram to discuss the general design ideas with colleagues – but I’m happy to throw it overboard when starting to implement in a TDD manner. And happy to generate them again from the code to give an overview of what I achieved later on.

Anon Y Mouse 18 days later:

• • @Erik: The claim was that TDD was a design tool. Show that it is. Yes, class diagrams are a part of design, not the final or sole component, but some sort of design nevertheless. TDD is not design, you can call it what you want, it doesn’t make it so. Design requires one to use the grey cells, not blindly start with TDD and claim that you are doing design.

Erik 18 days later:

• • @Anon: I can’t see how I could prove you wrong if you don’t want to believe me that I do design with TDD. I do use my grey cells doing TDD. There is definitely nothing blind about it.

  • The difference is that I do the design and implement it in a fast feedback loop. I don’t draw nice pictures, project them on the wall with a beamer and discuss about them for days and then throw them over the wall to implementation slaves (I’m definitely not kidding: there seem to be enough companies where management think this is the way software should be developed!).

  • If you don’t see that, you simply don’t understand TDD, I’m sorry.

  • All I say of course doesn’t mean that TDD is the only way to go, that drawing UML diagram is bad or obsolete. Or that TDD is a silver bullet.

  • In the end I can only speak for myself: TDD helps me. Doing better design. Yes even better design than at the time where I started with the big upfront design that didn’t fit after a few hours implementing. And that was obsolete after a few days because hardly anybody cared to keep it current.

  • TDD may not be the way you feel comfortable with – that’s OK. Stick to your design tools if it makes you feel more efficient for your purpose.

  • But please avoid bashing TDD with little knowledge about it. There’s certainly room for informed criticism of TDD. Provide some and I’d be happy to hear it – so that I learn about the weaknesses of my current tool of choice…

Anon Y Mouse 19 days later:

• • @Erik: You keep claiming that TDD is a design tool. Yet you show no evidence for it, except by assertion. Show me a design that has come out of TDD that could not arise from pure thinking or by doing research.

  • I’ve shown a simple example, quick sort algorithm, which can’t arise from TDD. Any non-trivial algorithm is unlikely to be uncovered by TDD. There is no substitute for thinking about the problem. Anybody can use TDD to write average code. For top quality code and design, you need to make use of the tools appropriate for the situation. No single tool or technique will solve all your problems. TDD alone is not a panacea.

  • Knowing TDD’s limitations, I refuse to call it a design methodology. For testing, yes, TDD is a good option, but one among many. For design, TDD is not my choice and will never be, since I know and understand its limitations. Therefore, I will not call TDD a design tool, and will object when somebody does so.

  • If this means that you think I don’t know or understand TDD, so be it.

Erik 19 days later:

• • @Anon. I don’t have the feeling I claimed that TDD is a design tool or a design methodology. I’m claiming that, based on my experience, TDD allows you to produce sound and testable designs – and, again in my experience, much better designs than many I’ve seem born on paper. TDD is a way to discover and explore design if you will. The design is being born in your head and tested – interactively. Of course if you have no clue about design, nothing’s going to come out of it – but neither will from any other design tool or methodology. A fool with a tool etc. (and a fool with a methodology is public danger in my eyes).

  • I do think you need some sound experience with design to use TDD efficiently. I don’t think that TDD teaches you design – but it provides you feedback about your design and that’s make it so appealing to me. I’m implementing and testing my design – and I have lots of unit tests that allow me to adapt my design later on. Design on paper doesn’t care.

  • QuickSort comes from human genius – not from tools, not from design methodology. TDD would at least have allowed to verify that the algorithm behaves as expected – and then the mathematical proof would have had to follow… Class diagrams wouldn’t have provided more help I think.

  • At least we agree that TDD is not a panacea – and I still think you misinterpret TDD. But we can both live with that – and hopefully continue to improve our designs, whichever way :-)

Anon Y Mouse 19 days later:

• • @Erik: There was a claim made by you in a comment that TDD was a design tool. I’m disagreeing with that. If you claim that TDD is design, I’m saying that is wrong.

  • Whether or not it reflects on my design skills is irrelevant, so please stop bringing that into the argument. What makes you think that I couldn’t run rings around you as far as design is concerned? I may be able to do that, or not. Either way, it is irrelevant to the discussion.

  • TDD is simply one of many testing methodologies. and not necessarily the best one at that.

Erik 19 days later:

• • @Anon It’s simply wrong that TDD is only a testing methodology. You don’t want to hear what I am saying and I’m apparently not capable of understanding what you want to tell me.

  • TDD questions my design interactively – and this helps me, probably far better than some design tools like Rational Rose (and this was part of Brett L. Schuchert’s argument), to improve my designs, my understanding of my designs.

  • For some reason I don’t know, you dislike TDD. That’s OK with me. I dislike Rational Rose. I had colleagues who were enthusiastic about it – which I couldn’t understand considering the pain it was to use.

  • I certainly don’t care if you’re better at design software than me or vice-versa and agree that it has nothing to do with the issues we’re debating here anyway – I don’t know what I wrote that made you think I am feeling better than you at anything.

  • Just to repeat it again: I’m basically saying that I have improved the quality of my designs by growing them interactively using TDD more than by taking additional time to draw design diagrams. You think I’m wrong. That’s great. The world of software development remains an interesting place to exchange opposite points of view.

  • But I didn’t hear a fact from you that gives me reasons to question the positive experience I had with TDD so far or to think that what you have to offer is better: I only heard class diagrams, hierarchies and relationships – I went through these some years ago and wasn’t really impressed. And you didn’t give me any useful hint why you have such an bad opinion of TDD.

  • And all I’m saying here doesn’t mean that I think TDD is the solution, the only way to go for software development and that people not sharing my views on this issue are bad developer/designer/professionals. I deeply believe that 1) there is no/will never be one true way, 2) you need to master many different techniques/technologies/methodologies to continue to improve your skills. But I do think TDD is one of the techniques that help you improve.

  • In a different direction: I’d be interested to hear your opinion about a better testing methodology than TDD – as I certainly don’t believe that TDD is the last approach to software development I will ever use.

Philip Schwarz 19 days later:

• • @Anon Y Mouse

  • You said:

  • TDD is not a design tool. You can’t come up with your class diagrams using TDD. ... 

  • Class diagrams are design. TDD is after the fact of class diagrams, after the hierarchies and relationships are defined. ...

  • You seem to see class diagrams as an essential part of design. 

  • You don’t have to draw class diagrams to do design. 

  • Also, while you mention class diagrams, you don’t mention sequence diagrams at all.

  • As Craig Larman says in Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process: 

  • A critical ability in OO development is to skillfully assign responsibilities to software objects. ... 

  • Why? Because it is one activity that must be performed – either while drawing a UML diagram or programming – and it strongly influences the robustness, maintainability, and reusability of software components. 

  • Of course, there are other important skills in OOA/D, but responsibility assignment … tends to be a challenging skill to master (with many “degrees of freedom” or alternatives), and yet is vitally important. On a real project, a developer might not have the opportunity to perform any other modeling activities – the “rush to code” development process. Yet even in this situation, assigning responsibilities is inevitable. ... 

  • Object-oriented design is concerned with defining software objects – their responsibilities and collaborations. A common notation to illustrate these collaborations is the sequence diagram(a kind of UML interaction diagram). It shows the flow of messages between software objects, and thus the invocation of methods. ... 

  • In addition to a dynamic view of collaborating objects shown ininteraction diagrams, a static view of the class definitions isusefully shown with a design class diagram. This illustrates the attributes and methods of the classes. ... 

  • You can think about assigning responsibilities to objects while coding or while modeling. Within the UML, drawing interaction diagrams becomes the occasion for considering these responsibilities (realized as methods).

Anon Y Mouse 19 days later:

• • @Phil: I clearly mentioned earlier that the class design must be there, explicit or implicit. I’m assuming an OO type development based on Java type languages (Java, C#, C++), not database design (data models).

  • But you are emphasizing my point when you talk about sequence diagrams, activity diagrams, etc. Those, too, are a part of design. Implicitly or explicitly, they are present before coding starts. You can’t just start writing tests without some idea in mind.

  • When coding, the good programmers do top-down and bottom-up programming simultaneously, keeping several different abstraction layers in mind all at once. TDD focuses on the lowest level of abstraction, the class, to the exclusion of higher level concepts, expecting that the “design” will somehow arise out of the tests. Such designs will necessarily be narrowly focussed on the particular sub-problem at hand, and not on an understanding of larger abstractions that may produce better design. To expect elegant software designs to arise from TDD is wishful thinking.

  • The Pragmatic Programmers advised us never to build an application, but to build a framework. Using many layers of abstractions simultaneously, I end up building frameworks in the same time (or less) as others need to build an application. To me, therefore, TDD is not a design tool. It limits my design choices, it restricts my design, it leads to less flexible software than I could otherwise build.

  • A testing tool, yes, TDD is that indubitably. A design too, no, not for me.

Ravi Venkataraman 20 days later:

• • For those of you who feel that TDD is a design tool, here are a couple of links to articles by two people prominent in their field, one well known to the general software world, the other not as well known.

  • The more popular author tried to create a Sudoku solver using TDD, and, I believe had to give up. (http://www.xprogramming.com/xpmag/OkSudoku.htm)

  • The less popular author’s work is here: http://www.norvig.com/sudoku.html. Notice the clarity of though in Peter Norvig’s article, and the wonderful explanations and tests that he ran after coding, not before.

  • Ron Jeffries is a reasonably well known author, at least in Agile circles. Yet he makes a mess of this not very complex task when using TDD.

  • Please tell me how you can consider TDD as a design tool in view of this simple example.

  • Norvig, whose writings I love, is a true master of software development. I feel that the other popular folk in the Agile world, like Uncle Bob, Ron Jeffries, Martin Fowler, etc., are simply no match for Norvig, completely out of their league when confronted by such penetrating insight into problems that Norvig shows, such clarity of thought and simplicity of design as seen in his writings.

  • The software world would be a much better place if they took inspiration from Norivg’s work rather than those of current “thought leaders”.

Erik 20 days later:

• • @Anon: I agree on most points with you – but I nevertheless have a different view on TDD.

  • Like you, I don’t believe that TDD replaces a thoughtful design. Even if I heard it a few times, I cannot believe that an overall design/an architecture can spontaneously emerge from a pure TDD approach.

  • But TDD tests the design, TDD allows to get feedback about how the design runs – and this is invaluable in my eyes. Design on diagrams is just theory.

  • TDD and Agile are about feedback, fast feedback.

  • In the classical design approach I went through earlier in my career feedback took the form of long discussions about the diagrams – and the result was often that the design wouldn’t fly. But as it was the result of a long a painful process, you weren’t allowed question it – and either you implemented the inappropriate design or you ignored it… That’s where I’m coming from…

Erik 20 days later:

• • @Ravi

  • I think Peter Nordvig could have written his program using TDD without any damage for the quality of the outcome.

  • I have the impression that Ron Jeffries had no real interest in solving Sudoku, while Peter Nordvig had a real motivation: “I wanted to convince [my wife] that the problem had been solved and didn’t need any more of her time.”

  • So what? The problems and the individuals matter. Hardly unexpected. TDD or any other approach doesn’t change that. You can design without TDD. Nothing new either. You can fail with TDD. Hardly a proof that TDD is worthless.

  • I would put things as follows: TDD helps sharpen your designs (be there on paper or in your head). Is it therefore a design tool or not? I’d tend to say no – but I’d understand someone answering yes. But if someone were to tell me that an architecture can emerge from “pure TDD” – only by coding in a TDD manner, without thinking about the big picture of the design (this is hardly possible, but let’s pretend) – then I’d demand hard evidence and real world success stories.

  • I’m willing to learn from TDD, Peter Nordvig, Hoare (Quicksort), Robert Martin and many others.

  • Last but not least: thanks for the links.

Esko Luontola 20 days later:

• • Here is an example of an algorithm that I wrote using TDD:http://www.orfjackal.net/temp/DiagramOfNinePlaces.zip

  • Some years before writing that, I had written a program for solving the Eight Queens Problem, and I recognized the Diagram of Nine Places to be similar to it. I had in my mind a rough idea of the algorithm which would solve the problem, so I begun writing a class with TDD which would be needed in solving it.

  • The class “Diagram” was written fully using TDD and it checks the constraints that are involved in the algorithm. After that was done, I wrote the about dozen lines of code in class “DiagramOfNinePlaces” which bind it all together. There was no point in writing a test for that, because I did not know what the expected result was, but I could easily verify the result after seeing it. (If the last lines of code would have been much more than ten lines, then I would have split it into smaller pieces and used TDD.)

  • —

  • In my opinion, TDD is a design tool, because it helps you to do design. It gives fast feedback about your design, that whether the code works as you meant it to work, and how maintainable the code is (because you modify the code many times before the program is finished, instead of writing it all at once, so basically all the time you are maintaining an existing program instead of writing a new program).

  • TDD is a design tool. TDD is not a designer. You are the designer, so it’s your job to think about the design. TDD does not think about the design for you, but as a tool it helps you to do your design by giving fast feedback of the design.

Amanjit Gill 24 days later:

• • I think there are very few metrics about good OOP programming, and SOLID makes a lot of sense to me. Its really the question: What is good OOP. Its about Craftmanship. But Joel is only about shipping products. Breakneck requirements, shipping in time and nice UI.

  • Therefore I guess Joel’s software isn’t the greatest OOP by these standards but still a good product in the customer sense….

  • Joel simply isn’t an object oriented programmer,thats the point. Hes all about memset() ;-)

StoneCypher about 1 month later:

• • Honestly, anyone worth their salt sees right through what Spolsky says. Therein lies the rub, though: Spolsky isn’t worth his salt. That’s the underlying fault with your should-be-completely-reasonable plea:

  • .

  • “And, after all, products deserve and require this kind of care. So do your listeners. This is just simple professionalism. Don’t ship shit.”

  • .

  • One thing that quality engineers tend to struggle with is their inability to understand what it’s like for the other 90%. He can’t refuse to ship what he can’t identify.

  • .

  • He’s not writing shit because he’s aware of how full of crap he is. You cannot request from a man to hold to the standards and the judgement he doesn’t have.

  • .

  • And, since all Spolsky does these days is write an overpriced second rate bug tracker and fap about the design decisions in an embedded scripting language that only he remembers as good (the phrase “it took 35 man-years to build, and two man-years to replace, with a product that was much stabler and adhered to existing APIs” comes to mind), you’d better believe he’s not going to give up his internet pseudo-fame and the adoring throngs of freshman python weenies.

  • .

  • It’s all he’s got, really, and he isn’t smart enough to understand why he’s doing damage to his readers. You can lead an idiot to the smart-or-silence princple, but you can’t make him think.

  • .

  • Incidentally, SOLID is in many ways a partial reinvention of PSP/TSP principles. SOLID’s got a lot of stuff PSP/TSP doesn’t (and vice versa), but a lot of the missing stuff on either side of the fence is compatible, and PSP/TSP have the benefit of use in huge teams on huge projects for decades, so it’s pretty well understood. Have a look: there may be valuable cross-pollenation of ideas.

Baseball Bats For Sale 5 months later:

• • It does seem easy to spot people that have learned most of what they know from books and discussion and not actually doing something. Those types of people tend to extort odd systems that look good on paper but are funstionally flawed.