Object Mentor Blog: An Open Letter to Joel Spolsky and Jeff Atwood

An Open Letter to Joel Spolsky and Jeff Atwood

Uncle Bob — Fri, 06 Feb 2009 20:53:00 -0600

Joel, Jeff,

Here is an open letter to the two of you that I hope we can use in our upcoming StackOverflow #40 podcast. I won’t post it on my blog until we’ve been able to iterate it a bit. I’ve spent several hours on this trying to balance the tone. It used to be a lot longer <grin>.

Dear Joel and Jeff

In the Stack Overflow Podcast #38 you said: “Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles … they all sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly.”

And again later: ”...it seems to me like a lot of the Object Oriented Design principles you’re hearing lately from people like Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture’s sake.”

And yet again: “People that say things like this have just never written a heck of a lot of code.”

And still again: “One of the SOLID principles, (a butchering of the Single Responsibility Principle) and it’s just… idiotic! You can’t build software that way!”

I hope you’ve had time to perform a little due diligence since then, and that you now realize that your statements were unfair, harmful, and were pretty much crap.

I understand that you were trying to make a valid point and that the words just got away from you a bit. I quite agree that a dogmatic or religious application of the SOLID principles is neither realistic nor beneficial. If you had read through any of the articles and/or books I’ve written on these principles over the last 15 years, you’d have found that I don’t recommend the religious or dogmatic approach you blamed me for. In short, you jumped to a erroneous conclusion about me, and about the principles, because you weren’t familiar with the material.

I understand that this was a podcast, and that you were both just jawing. However, your podcasts are a product that you ship to everyone in the world. The content of that product can do great good; but it can also do great and permanent harm. One would think that you’d want to be careful with such a product. Yet in the intensity of the moment you got a bit careless and spewed some crap instead. That’s fine, everybody makes mistakes. But then you shipped it! You shipped a product that had a huge bug in it. You should have had tests!

Could it be that when you said ”...quality just doesn’t matter that much…” you were being serious. Clearly the quality of podcast #38 didn’t matter much to you, since you shipped it without verifying that your information was accurate. As a result, you did unjust harm to me. Were I a more litigious person, we might be having this discussion in court.

Now I’m quite certain that you don’t want to ship bad product. I just think that you’ve been careless with your production process. You haven’t put in place a mechanism that will stop you from shipping crap. So I suggest that you practice Test Driven Development with your podcast. Write down the acceptance criteria beforehand (I suggest lawsuit avoidance would be a high priority), and then review the product against those criteria afterwards. Yes, this will take some time, and there will be a cost. However, it will pay back handsomely because your product will be far better, and you will avoid embarrassments like this one (or worse). And, after all, products deserve and require this kind of care. So do your listeners. This is just simple professionalism. Don’t ship shit. —-——-

Some of the other points we could talk about in the podcast:

TDD for real this time. You guys can just throw your complaints at me and I’ll address them. * For example, I’d like to explain how one would test Joel’s JPeg compression feature.
ISP and SRP, the two principles that Joel butchered.
Mike Connie’s observation (in #39) about interfaces.
How, when, and why to apply Principles and Patterns.
From Stack Overflow: * Large Switch statements: Bad OOP? * JSON is used only for JavaScript? (Rant on XML) * ASP.Net – How to effectively use design patterns without over-engineering!

"An Open Letter to Joel Spolsky and Jeff Atwood" by Olivea Copper

Thu, 08 Jul 2010 05:58:44 -0500

A biker was riding along a California beach when suddenly the sky clouded above his head and, in a booming voice, the Lord said, “Because you have TRIED to be faithful to me in all ways, I will grant you one wish.” The biker pulled over and said, “Build a bridge to Hawaii so I can ride over anytime I want.”

"An Open Letter to Joel Spolsky and Jeff Atwood" by FLV extractor

Thu, 08 Apr 2010 01:22:21 -0500

just have a try ab ha

"An Open Letter to Joel Spolsky and Jeff Atwood" by moncler clearance

Wed, 31 Mar 2010 23:23:20 -0500

Very quietly I take my leave.To seek a dream in http://www.edhardy-buy.com/ starlight.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Kooba Handbags

Wed, 31 Mar 2010 23:22:39 -0500

Living without an aim is like sailing without a compass. with a new http://www.handbags4buy.com/ idea is a crank until the idea succeeds.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Cheap Slow Pitch Bats

Wed, 08 Jul 2009 22:04:26 -0500

I would have to agree.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Baseball Bats For Sale

Wed, 08 Jul 2009 22:03:45 -0500

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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by StoneCypher

Tue, 10 Mar 2009 01:27:02 -0500

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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Amanjit Gill

Mon, 02 Mar 2009 15:06:32 -0600

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() ;-)

"An Open Letter to Joel Spolsky and Jeff Atwood" by Esko Luontola

Thu, 26 Feb 2009 17:04:57 -0600

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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Erik

Thu, 26 Feb 2009 16:16:06 -0600

@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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Erik

Thu, 26 Feb 2009 15:17:15 -0600

@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…

"An Open Letter to Joel Spolsky and Jeff Atwood" by Ravi Venkataraman

Thu, 26 Feb 2009 15:06:18 -0600

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”.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Anon Y Mouse

Thu, 26 Feb 2009 08:47:04 -0600

@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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Philip Schwarz

Thu, 26 Feb 2009 00:56:02 -0600

@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 in interaction diagrams, a static view of the class definitions is usefully 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).

"An Open Letter to Joel Spolsky and Jeff Atwood" by Erik

Wed, 25 Feb 2009 21:54:01 -0600

@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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Anon Y Mouse

Wed, 25 Feb 2009 20:20:01 -0600

@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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Erik

Wed, 25 Feb 2009 15:43:35 -0600

@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 :-)

"An Open Letter to Joel Spolsky and Jeff Atwood" by Anon Y Mouse

Wed, 25 Feb 2009 14:04:56 -0600

@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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Erik

Wed, 25 Feb 2009 07:19:34 -0600

@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…

"An Open Letter to Joel Spolsky and Jeff Atwood" by Anon Y Mouse

Wed, 25 Feb 2009 06:52:35 -0600

@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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Erik

Wed, 25 Feb 2009 04:47:09 -0600

@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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Anon Y Mouse

Mon, 23 Feb 2009 14:14:18 -0600

@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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Brett L. Schuchert

Sun, 22 Feb 2009 18:31:49 -0600

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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by Anon Y Mouse

Sat, 21 Feb 2009 04:15:08 -0600

@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.

"An Open Letter to Joel Spolsky and Jeff Atwood" by http://agileconsulting.blogspot.com

Fri, 20 Feb 2009 18:27:35 -0600

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…