The Gospel According to Uncle Bob


Update: video of the presentation is here, video of the Q&A is here.

We had Robert C. Martin, aka 'Uncle Bob' come to the Feb. Chicago Alt.Net Group meeting, where he gave a talk and then answered questions from the group.  We had a good crowd, about double our normal attendance, as a number of non-.NET people were there, but we got a few new faces who look to become regular members.

He was 'dry-running' his upcoming SD West talk (which he was reading off guessed it, index cards), and it was very entertaining, somewhat informative, and somewhat less convincing (to me).  Sergio should have the video up...eventually.  Here's my brief rundown (a very rough paraphrase of things I remember/found interesting) and some random comments.


After 10 years, why are we still talking about Extreme Programming (XP)?  Well, we aren’t.  What are we talking about?  Scrum.  How did this happen?

10 years ago, Beck’s book came out.  It had two fundamental flaws in it.  It had ‘Programming’ in the title, and also ‘Extreme’ in the title.  All of the geeks were thrilled, but the business people were horrified.

Shortly thereafter, there was the great meeting of the minds that produced the agile manifesto.  Also, something happened that was a good thing (but which had some bad consequences down the road).  Someone stripped the ‘geek’ out of agile and called it Scrum.  Scrum is a pure subset of XP and focuses on the ‘business’ concepts.  If you are doing XP, you are doing all of Scrum, but if you are doing Scrum, you aren’t necessarily doing XP.

And this was good.  The business people suddenly liked the sound of this ‘agile’ thing, and it took off.  Especially because of the concept of Scrum Certification.  Agile adoption within the corporate world spread like wildfire.  Agile is everywhere.

But along the way, something happened.  Teams that took on Scrum discovered that their velocity took off.  For about a year.  And then they noticed that it started to level off, and steadily decline.  Why was this?

Scrum’s focus is on delivering features, features, features.  But, Scrum left out the technical practices of XP that allowed it to be maintainable for the long run, things like TDD and pair programming and refactoring.  When all of your work is focused on delivering the next feature (or set of them), you end up with a mess that makes it harder to introduce change down the line.

Why is TDD so important?  Consider common complaints about TDD: “It takes too long…we have deadlines…we don’t need to write tests for every single piece of functionality”.

Well, imagine that you are a patient undergoing open heart surgery.  In this situation, the surgeon has a definite deadline.  If you stay on the external support systems too long, you will die.  How do you want the surgeon to behave during this time?  The last thing you want is for him to cut corners, to introduce hacks (I had to introduce that bad joke-jdn).  You want a professional, a craftsman.

Software developers need to learn to be craftsmen, to stop cutting corners, to stop introducing hacks, all under the excuse of meeting deadlines.

TDD allows you to have a suite of tests that, except for the ‘red’ part of ‘red-green-refactor’, will always pass a build.  At any given time, you can stop coding, and the build will pass.  You can introduce change, and the build will pass (well, the tests might fail, but you know when and where).  You might have to debug once in a while, but you will know when and where.  Once you internalize the discipline of ‘red-green-refactor’, you will be empowered to make changes because your tests will give you the confidence to do so.

And when do you refactor?  All the time.  It is not ‘we will refactor during the next iteration’ but a constant process.  It isn’t just ‘feature, feature, feature’, but tested and refactored feature after tested and refactored feature. 

The people who criticized XP in the beginning (“It will lead to a mess”) were right but for the wrong reason(s).  By bringing XP back into Scrum, all will be restored.

Too many people who aren’t craftsmen have been let into software development, but there is a surge of momentum behind the idea of craftsmanship.  Lawyers have the Bar, doctors have the AMA, software developers need something similar, but perhaps the better model is karate.  One gains a black belt by going through stages of qualification, learning from mentors.  Only those actually qualified at whatever level can claim it.  Software development needs the same.  Perhaps some authority to grant those ‘qualifications’ in some fashion.  This problem is being tackled and will be addressed in the next couple of years.

Random Comments

That’s off the top of my head.  I think I’ve done a good job of paraphrasing it, but watch the video when it comes out (I’ll update the post when I know).

I’ve never heard Martin speak before, but it was a good presentation.  The title of this post is deliberate, of course, and he was definitely ‘preaching to the choir’ on this topic.  But I have some questions about it.

I’m pretty sure that as a historical tale, it was a little tall (and to be fair, I’m sure he would accept this…it’s an hour presentation with 30 minutes for questions, with a pedagogical purpose).  I have no doubt there would be others, including those who were at some of the various historical events, who might think it wasn’t exactly a documentary.  But let’s leave that aside.

His more sweeping pronouncements about the acceptance and proven quality of Agile within the Corporate world and software development are as much wishful thinking as fact.   Both of these things are open to question.

I can give one anecdotal example.  I was skimming through a lot of background material before the group meeting, and I found prominently noted a case study that involved XP.  And it involved a very large, prominent client.  A Fortune 10,20,whatever these days sort of client.  A client I myself was familiar with.  There it was, listed that this client ‘did XP’, and successfully no less.  Hmm, strange, my experience with that client was that it was the antithesis of agile, in any form.

This is the sort of confirmation bias that Yegge pegged perfectly.  Someone, in a very large corporation, did Agile, somewhere.  Therefore, that corporation does Agile and accepts it.  Uh, no.

Similarly, as he went through the various pieces of XP that he went through (TDD, Pair Programming, Continuous Integration, etc.), he painted the rosiest possible picture of how each worked to promote quality.  Again, I’m not going to criticize this too much…when I was presenting philosophical papers in that previous career, you present a defense of what you are presenting, a strong case for it.  Really honest and secure believers will mention the possible criticisms, but it depends on the forum.  For people who are interested/knowledgeable in BDD, I would suggest you watch how he presents TDD and find how many times you will find yourself saying, “Well, yes, but…”.  I’m not even sure if I like BDD, but that was my reaction (coders creating APIs without business specifications was what I was imagining).

But, again, it was a dry run for a certain sort of presentation for a certain sort of audience.  You can’t really say much about that.  Although I will add that the XP books were produced by people who came out of the C3 project which was a failure.  XP is clearly not proven, and the people who support Agile have a financial interest in it (e.g., Ron Jeffries blue convertible, by the way, James Bach is right).  And Martin’s example of something about Pair Programming that was proven by Keith Braithwaite (“without a counter-example” no less) is something I couldn’t find anywhere, the only thing I found quickly was this, a mixed bag.   Updated: thanks to Keith for fixing my faulty memory on this one.  What Martin was talking about here involved unit testing and cyclomatic complexity, more information can be found in the presentation here, and at his blog here.

The craftsmen thing gives me pause though.  A *lot* of pause.  The analogies used in the meeting sure sound nice.  Karate was Martin’s example, another questioner talked about orchestras.  You become 1st chair violin in the NY Met Philharmonic through a long process, etc. etc. etc.  How could you disagree with that?  Well, let me give you another analogy.

It was obviously not a pure .NET audience, since the term used was not ‘Mort’ but ‘Grunt.’  What do we do with the fact that the ratio of craftsmen to grunt is (to use the suggested ratio from the meeting) 1:10?  You get rid of the grunts.

When I think of that, the analogy that I think of is the Khmer Rouge.  A small group of self-appointed elites that want to ‘purge’ the unworthy.  Now, obviously, I don’t think that the people who are in favor of ‘craftsmanship’ want to kill anyone, not literally.  It is an analogy.  But I do think they would like to be able to end the careers of the grunts within software development (if you watch the videos, when you hear someone suggesting shooting the grunts, that is me, BTW).  And within the alt.NET movement, I can think of various obvious examples of people who would want to be part of the elite so that they could make their decisions on the basis of ideological reasons.

Besides the fact that I think the qualifications and motivations of some people within the ‘craftsmen’ movement are suspect (though I would have no reason to include Martin in this group from anything in the presentation), there’s a sort of hopelessly naive spirit behind it.  It’s a lot easier to have limits on orchestras and karate masters because there just aren’t that many of them.  But you need a lot of software developers.  To use another analogy, there are, unfortunately, a *lot* of lousy teachers out there, but in large part, that is because you have to have a lot of them.  There aren’t that many lousy 3rd basemen in MLB, because there aren’t that many you need.   

But anyway…

Regardless of all that, it was a great night.  The short planning meeting afterwards produced a number of good ideas.  I hope that we will be able to do a Code Camp this year, in particular.

posted on Thursday, February 12, 2009 7:00 PM Print
# re: The Gospel According to Uncle Bob
Derik Whittaker
2/13/2009 3:49 AM
Sounds like a good meeting. Wish I could have been there, but I was 35k feet up on a 10 hour flight.
# re: The Gospel According to Uncle Bob
Kirk Horne
2/13/2009 3:50 PM
Great, thoughtful post John.

I have to admit I am pretty much a gushing fan of Uncle Bob et. al. at this point, after having gone through "that" phase of denial/resistance to the "academic" SOLID principals and the bass-ackwards practice of writing tests before code, letting the tests drive the design etc. Eventually trials and experience proved there was substance and it goes beyond any financial desire to sell books, consult, etc.

Still you raise a good point - some of his "black and white" depictions are in reality not so clear-cut.

FYI - I much prefer these types of posts to your music critiques - sorry :)
# I haven't proved anything about Pairing
Keith Braithwaite
2/19/2009 1:56 PM
I haven't proven anything about Pair Programming, and Bob doesn't claim that I do.

I have demonstrated (and not proven) something about unit testing, specifically that open source software that comes with a large suites of automated unit tests has a distribution of cyclomatic complexity per method more strongly biased towards the low. I also have some anecdotal evidence from TDD practitioners that the metric I used to find that out "goes in the right direction" when they refactor.

You can find the results in this presentation and the story behind it in these blog posts There'll be an update in April or so.
# re: The Gospel According to Uncle Bob
2/19/2009 2:16 PM
Thanks Keith! Post updated.
# re: The Gospel According to Uncle Bob
Keith Braithwaite
2/19/2009 3:07 PM
My pleasure. Without your comment I wouldn't have sat through Bob's talk which was 1) interesting and 2) about software development for a change (sorry Bob ;) so I think we're even.
# re: The Gospel According to Uncle Bob
2/19/2009 8:44 PM
Cool. Sorry about the mis-characterization (damn reviewing from memory...must be getting old). I will be interested to see if the correlation you've noted remains as the source of examples increases.
# re: The Gospel According to Uncle Bob
Keith Braithwaite
2/20/2009 7:08 AM
It will. I want to look for similar patterns (or their absence) with other "complexity" measures. I already know that the same analysis for the textual length of methods is much less clear cut.
# re: The Gospel According to Uncle Bob
Steve Freeman
3/16/2009 10:56 AM
"C3 was a failure" This story goes around a lot, I think because the project was cancelled. The reality I heard is more complex: they actually delivered and paid employees for some time, they failed to have someone watching the organisation and management changed above them, in the end they were blown out by an ERP implementation which made them irrelevant.

I'd agree that XP is not proven everywhere, but there are now a great many examples to show that it works very well in at least some circumstances.

And finally, perhaps orchestras are the wrong example, except for a few very high-tech situations, but it took us years to find a plumber we can trust, and we'd have done better simply to do without some of the previous ones we hired. There are many good developers in the world, but how many do you know that fit into the second category?
# re: The Gospel According to Uncle Bob
3/16/2009 9:03 PM

re: 'Failure'. That's a fair enough point, but it is hard to see how it could be categorized as a success.

I also agree with you that there is evidence through examples that XP can work, even work very well, in some circumstances. Pair programming is the example, though, that I often used. I've done it with people who were enthused and excited about it and it went well, then in another case with someone not so enthused about it. It is, indeed, all about the circumstances.

Thanks for the feedback.

Post Comment

Title *
Name *
Comment *  
Please add 3 and 6 and type the answer here: