Object Mentor Blog: Echoes from the Stone Age

Echoes from the Stone Age

Uncle Bob — Tue, 06 Oct 2009 11:07:29 -0500

The echoes from Joel Spolsky’s Duct Tape blog continue to bounce off the blogosphere and twitterverse. Tim Bray and Peter Seibel have both written responses to Joel, me, and each other.

Here are some stray thoughts…

TDD

Anyone who continues to think that TDD slows you down is living in the stone age. Sorry, that’s just the truth. TDD does not slow you down, it speeds you up.

Look, TDD is not my religion, it is one of my disciplines. It’s like dual entry bookkeeping for accountants, or sterile procedure for surgeons. Professionals adopt such disciplines because they understand the theory behind them, and have directly experienced the benefits of using them.

I have experienced the tremendous benefit that TDD has had in my work, and I have observed it in others. I have seen and experienced the way that TDD helps programmers conceive their designs. I have seen and experienced the way it documents their decisions. I have seen and experienced the decouplings imposed by the tests, and I have seen and experienced the fearlessness with which TDDers can change and clean their code.

To be fair, I don’t think TDD is always appropriate. There are situations when I break the discipline and write code before tests. I’ll write about these situations in another blog. However, these situations are few and far between. In general, for me and many others, TDD is a way to go fast, well, and sure.

The upshot of all this is simple. TDD is a professional discipline. TDD works. TDD makes you faster. TDD is not going away. And anyone who has not really tried it, and yet claims that it would slow them down, is simply being willfully ignorant. I don’t care if your name is Don Knuth, Jamie Zawinski, Peter Seibel, or Peter Pan. Give it a real try, and then you have the right to comment.

Let me put this another way. And now I’m talking directly to those who make the claim that TDD would slow them down. Are you really such a good programmer that you don’t need to thoroughly check your work? Can you conceive of a better way to check your work than to express your intent in terms of an executable test? And can you think of a better way to ensure that you can write that test other than to write it first?

If you can, then I want to hear all about it. but I don’t want to hear that you write a few unit tests after the fact. I don’t want to hear that you manually check your code. I don’t want to hear that you do design and therefore don’t need to write tests. Those are all stone-age concepts. I know. I’ve been there.

So there. <grin>

The Design Pattern Religion

Tim Bray said:

My experience suggests that there are few surer ways to doom a big software project than via the Design Patterns religion.

He’s right of course. The Design Patterns religion is a foul bird that ravages teams and cuts down young projects in their prime. But let’s be clear about what that religion is. The Design Patterns religion is the ardent belief that the use of design patterns is good.

Here’s a clue. Design Patterns aren’t good. They also aren’t bad. They just are. Given a particular software design situation, there may be a pattern that fits and is beneficial. There may also be patterns that would be detrimental. It’s quite possible that none of the currently documented patterns are appropriate and that you should close the book and just solve the problem.

Here’s another clue. You don’t use patterns. You don’t apply patterns. Patterns just are. If a particular pattern is appropriate to solve a given problem, then it will be obvious. Indeed it is often so obvious that you don’t realize that the pattern is in place until you are done. You look back at your code and realize: “Oh, that’s a Decorator!”.

So am I saying that Design Patterns are useless?

NO! I want you to read the patterns books. I want you to know those patterns inside and out. If I point at you and say “Visitor” I want you at the board drawing all the different variants of the pattern without hesitation. I want you to get all the names and roles right. I want you to know patterns.

But I don’t want you to use patterns. I don’t want you to believe in patterns. I don’t want you to make patterns into a religion. Rather I want you to be able to recognize them when they appear, and to regularize them in your code so that others can recognize them too.

Design Patterns have a huge benefit. They have names. If you are reading code, and you see the word “Composite”, and if the author took care to regularize the code to the accepted names and roles of the “Composite” pattern, then you will know what that part of the code is doing instantly. And that is powerful!

Minimizing Concurrency.

In my first Duct Tape blog I made the statement:

I found myself annoyed at Joel’s notion that most programmers aren’t smart enough to use templates, design patterns, multi-threading, COM, etc. I don’t think that’s the case. I think that any programmer that’s not smart enough to use tools like that is probably not smart enough to be a programmer period.

Tim responds with:

...multi-threading is part of the problem, not part of the solution; that essentially no application programmer understands threads well enough to avoid deadlocks and races and horrible non-repeatable bugs. And that COM was one of the most colossal piles of crap my profession ever foisted on itself.

Is concurrency really part of the problem? Yes! Concurrency is a really big part of the problem. Indeed, the first rule of concurrency is: DON’T. The second rule is: REALLY, DON’T.

The problem is that some times you have no choice. And in those situations, where you absolutely must use concurrency, you should know it inside and out!

I completely and utterly reject the notion that ignorance is the best defense. I reject that lack of skill can ever be an advantage. So I want you to know concurrency. I want to shout “Dining Philosophers” and have you run to the board without hesitation and show me all the different solutions. If I holler “Deadlock”, I want you to quickly identify the causes and solutions.

Here’s a clue. If you want to avoid using something, know that something cold.

Sudoku

At the end of his blog, Peter jumps on the pile of bodies already crushing Ron Jeffries regarding the Sudoku problem from July of 2006.

I find the pile-up disturbing. Ron had the courage to fail in public. Indeed he announced up front that he might “crash and burn”. And yet he got lambasted for it by people who hid behind someone else’s work. The responses to Ron’s tutorial blogs were completely unfair because the authors of those blogs had everything worked out for them by Dr. Peter Norvig before they published their screeds. They were comparing apples to oranges because their responses were about the solution whereas Ron’s blogs were about the process.

Which one of us has not gone down a rat-hole when hunting for a solution to a complex problem? Let that person write the first blog. Everyone else ought to be a bit more humble.

Do the people on the pile think that Ron is unable to solve the Sudoku problem? (Some have said as much.) Then they don’t know Ron very well. Ron could code them all under the table with one hand tied behind his back.

Personal issues aside, I find the discussion fascinating in it’s own right. Ron had attempted to solve the Sudoku problem by gaining insight into that problem through the process of coding intermediate solutions. This is a common enough TDD approach. Indeed, the Bowling Game and the Prime Factors Kata are both examples where this approach can work reasonably well.

This approach follows the advice of no less than Grady Booch who (quoting Heinlein) said: “when faced with a problem you do not understand, do any part of it you do understand, then look at it again.“

Ron was attempting to use TDD to probe into the problem to see if he could gain any insight. This technique often bears fruit. Sometimes it does not.

Here is a classic example. Imagine you were going to write a sort algorithm test first:

Test 1: Sort an empty array. Solution: Return the input array.

Test 2: Sort an array with one element. Solution: Return the input array.

Test 3: Sort an array with two elements. Solution: Compare the two elements and swap if out of order. Return the result.

Test 4: Sort an array with three elements. Solution: Compare the first two and swap if out of order. Compare the second two and swap if out of order. Compare the first two again and swap if out of order. Return the result.

Test 5: Sort an array with four elements. Solution: Put the compare and swap operations into a nested loop. Return the result.

The end result is a bubble sort. The algorithm virtually self assembles. If you had never heard of a bubble sort before, this simple set of tests would have driven you to implement it naturally.

Problems like Bowling, Prime Factors, and Bubble Sort hold out the interesting promise that TDD may be a way to derive algorithmms from first principles!

On the other hand, what set of tests would drive you to implement a QuickSort? There are none that I know of. QuickSort and Sudoku may require a serious amount of introspection and concentrated thought before the solution is apparent. They may belong to a class of algorithms that do not self-assemble like Bowling, Prime Factors, and Bubble Sort.

This blog by Kurt Christensen provides all the links to the various Sudoku articles, and sums it up this way.

TDD may not be the best tool for inventing new algorithms, it may very well be the best tool for applying those algorithms to the problem at hand.

Actually I think TDD is a good way to find out if an algorithm will self-assemble or not. It usually doesn’t take a lot of time to figure out which it’s going to be.

"Echoes from the Stone Age" by guided meditation

Mon, 06 Feb 2012 22:43:46 -0600

well i think this echoes from the stone age is already part of our lives.

"Echoes from the Stone Age" by Pflugerville dentists

Sun, 05 Feb 2012 14:13:12 -0600

excellent information on this website and good post. Thanks for sharing the info!

"Echoes from the Stone Age" by Mother's Day Flowers

Sat, 04 Feb 2012 16:23:47 -0600

Sounds like my experiences from working on websites, deserves a share

"Echoes from the Stone Age" by indianapolis super bowl parking

Fri, 03 Feb 2012 02:37:22 -0600

when i was still studying, my favorite subject then that time was science and english but the “History” teacher came it, i feel dizzy and would want to whole period to end too soon.

"Echoes from the Stone Age" by christian louboutin

Mon, 30 Jan 2012 23:27:47 -0600

It is a good post , I like it and please keep writing .

"Echoes from the Stone Age" by deals

Sun, 22 Jan 2012 05:50:39 -0600

great post and a great blog!! thank you!!

"Echoes from the Stone Age" by Microsoft Office 2010

Fri, 13 Jan 2012 20:03:50 -0600

This article is GREAT it can be EXCELLENT JOB and what a great tool!

"Echoes from the Stone Age" by iphone contacts backup

Sat, 07 Jan 2012 20:13:29 -0600

Worry about all contacts in your iPhone will be lost in case of accidental breakdown of the phone? Or wanna transfer iphone contacts information from one phone to another? Now, you get 4Media iPhone Contacts Transfer, a convenient iPhone contacts management tool to help you backup iphone contacts, import/export, restore and manage contacts information in your iPhone to wipe out all your worries and fill your needs on important contacts information security.

"Echoes from the Stone Age" by iPad to Mac Transfer

Wed, 04 Jan 2012 06:29:49 -0600

TDD is a means to an end. Sometimes it’s highly appropriate, sometimes it just creates the illusion of progress while obscuring ignorance of how to actually solve the problem. It would be more useful to focus on when TDD is the right tool (and when it’s counterproductive), rather than asserting that it’s always the best technique.

"Echoes from the Stone Age" by iPhone to Mac Transfer

Wed, 04 Jan 2012 06:24:16 -0600

Great easy way to do a backup of iPhone files to Mac with this program and you can easy recover them from computer.

"Echoes from the Stone Age" by Forex Market Trading

Tue, 27 Dec 2011 12:35:27 -0600

Its been very informative posting. I have got some great tips from your blog. Thanks for sharing such valuable stuff with us.

"Echoes from the Stone Age" by north face khumbu

Sat, 24 Dec 2011 07:18:24 -0600

This article is impressive,I hope that you will continue doing nice article like this.

"Echoes from the Stone Age" by wow enchanting guide

Sat, 24 Dec 2011 00:55:07 -0600

Great post. Bookmarked this site and emailed it to a few friends, your post was that great, keep it up…..............

"Echoes from the Stone Age" by Dan Cross

Mon, 12 Dec 2011 20:45:44 -0600

Uncle Bob, I have read Knuth, and I have read you, and you, Sir, are no Donald Knuth.

Okay, jokes aside….

it strikes me that there are a lot of assertions in your article that are not backed up by concrete data.

For instance, you say that unit tests, and in particular test-driven development, make one go faster. Okay; but where is the data to to back that up? A recent paper out of Microsoft Research showed that TDD did substantially reduce defect rates, but at the cost of slowing down development by 15-35%. (See, e.g., http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx) Does the defect rate reduction and enhanced ability to intuit the effects of changes on the overall system facilitate integration? Change? Enhance ongoing maintenance? Perhaps, but that’s not well articulated by most TDD proponents.

Another misconception I see in some of the comments is the assertion that tests prove correctness. I don’t understand why acknowledging that this is simply not true is so hard for testing proponents and TDD-afficienados. Testing can certainly help one gain confidence in the correctness of the code, but it just cannot prove it (it can, however, prove that code is incorrect). Testing can be, and is, a very effective method for finding (and thus aiding in the repair of) defects, and then adding checks to ensure those defects (or similar classes of defects) do not recur in one’s code. However, it is no substitute for reasoning about one’s code and about the problem domain at hand. And the criticism that it encourages a micro, rather than macro-level view of the code is often valid; e.g., Jeffries’s failure because he gets so tied up on issues of representation.

A related point I’ve seen in many of your books, and from many members of the “agile” and “craftsmanship” communities, is this false dichotomy that seems to say that if one does not follow that one must then be doing the opposite. E.g., the satire in Appendix C of “Agile Software Development: Principles, Patterns, and Practices” which contrasts the “traditional” waterfall development model and CMM with XP. “We can only do design because we are in the design phase.” Now, I’m sure that was exaggerated for satirical effect, but it just comes across as sour-grapes. A more concrete example is placing what seems to be too much faith in, e.g., TDD. One doesn’t have to accept all of the TDD doctrine in order to appreciate the considerable benefits of automated testing.

I think that part of what Seibel said, that is valid, is that these claims would be taken more seriously if they weren’t quite some bombastic. TDD demonstrably does not always make one go faster; programmers who think that TDD slows them down are not all living in the stone age (e.g., Knuth doesn’t seem to see much value in it). And it’s somewhat self-serving to assert that it should be part of the canon of the profession in the same way that hygiene is for the medical profession without at least acknowledging that there are other methods for doing things. Just because one doesn’t use it as a primary method doesn’t mean that one can’t produce high-quality, well-tested software.

To summarize by basic complaint for the TL;DR crowd: there needs to be more empirical data to back up the claims of the agile community, and there needs to be more balance.

"Echoes from the Stone Age" by assurance auto pas cher

Thu, 01 Dec 2011 23:45:30 -0600

Où acheter assurances autos bon marché s’il vous plaît?

"Echoes from the Stone Age" by Cheap Beats By Dre

Thu, 17 Nov 2011 21:07:29 -0600

Very good, I like your article, continue to work hard, I will often come to pay attention!

"Echoes from the Stone Age" by Stereotactic Surgery in Tennessee

Thu, 17 Nov 2011 05:34:36 -0600

This is a really good read for me. Must agree that you are one of the coolest blogger I ever saw. Thanks for posting this useful information. This was just what I was on looking for. I’ll come back to this blog for sure! I bookmarked this blog a while ago because of the useful content and I am never being disappointed. Keep up the good work.

Stereotactic Surgery in Tennessee

"Echoes from the Stone Age" by reverse phone

Wed, 16 Nov 2011 17:44:38 -0600

I read a lot of posts, you know, on just this very topic; and many just leave me feeling as though so much is missing. Not so with this post! What a satisfying read this was! So much so that I read it twice!

"Echoes from the Stone Age" by Photo

Wed, 16 Nov 2011 07:06:03 -0600

I really believe that TDD brings lots of quality to your product

"Echoes from the Stone Age" by Cheap Beats By Dre

Tue, 15 Nov 2011 01:38:09 -0600

bus today, make them Cheap Beats By Dremiserable. One said: “I ??am really unlucky it! I was packed Beats By Dre Studioin the car to flow production.” One said: “I ??called Beats By Dre Soloit bad luck! In I was packed car are pregnant.Beats By Dre Pro Classic joke: I TVU A university studentbeats by dr dre caught by the enemy, the enemy tied him at the poles,just beats solo headphones purple and then asked him: say, where are you? You do not say it electrocuted! Scheap dr.dre beats studio headphones balck/yellowtudents back to the enemy a word, the result was electrocuted, he said: I am TVU.Hot sale beats by dr dre pro headphones

"Echoes from the Stone Age" by Austin Computer Repair

Mon, 07 Nov 2011 23:45:53 -0600

Well I didn’t knew this much about all these! Great informations, I guess I would follow all your posts :)

"Echoes from the Stone Age" by Backlinks

Thu, 20 Oct 2011 05:00:15 -0500

Wow this looks interesting information, I am going to give it a try. Thanks

"Echoes from the Stone Age" by Kayako

Wed, 19 Oct 2011 10:01:50 -0500

I can’t say that I’m using TDD all the time , but still it works for many occasions.

"Echoes from the Stone Age" by Ashley Bowling

Sat, 15 Oct 2011 15:21:20 -0500

thanks great info!

"Echoes from the Stone Age" by cheap baseball hats

Tue, 11 Oct 2011 22:56:26 -0500

http://www.capshoponline.com/