The Artima Developer Community
Sponsored Link

Weblogs Forum
Joel vs Bob and Kent. Different strokes for different folks.

44 replies on 3 pages. Most recent reply: Mar 8, 2009 11:38 PM by Jeff Ratcliff

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 44 replies on 3 pages [ 1 2 3 | » ]
David Vydra

Posts: 60
Nickname: dvydra
Registered: Feb, 2004

Joel vs Bob and Kent. Different strokes for different folks. (View in Weblogs)
Posted: Feb 18, 2009 6:05 PM
Reply to this message Reply
Summary
Recently you may have noticed noise about Joel Spolsky vs Bob Martin and Kent Beck. I came to a conclusion that may surprise those of you that know of my background in the Agile/TDD community.
Advertisement

Recently you may have noticed noise about Joel Spolsky vs Bob Martin and Kent Beck. After reading some of the available online material, I came to the conclusion that may surprise those of you that know of my background in the Agile/TDD community.

Joel can say what ever he wants because his company ships products that folks buy and he is hiring! I have personally tested both FogBugz and Copilot and concluded that in many ways both products are leaders in their space. Joel has a complete formula for how to recruit bright folks and help them ship beautiful and quality software. His formula and tool chain is different from many Agile shops who also hire bright folks and ship on time. So we just have different schools of thought here. That's all. Or is it?

Code and tool chains have a significant impact on software evolution and sustainability. For example, its much easier to find developers who can maintain well-factored, unit-tested Java or C# code. From what I can see this is not an issue for Joel. According to his blog, Fog Creek uses an in-house cross-platform language called Wasabi and I am sure its a well-reasoned decision that has worked well for them especially in light of their ownership structure and low turnover. While at Plumtree Software, I have been involved in the creation of a Java to c# translator used for that very purpose. We ran the project using Scrum and TDD and it has worked very well. Later, Plumtree was sold to BEA and eventually to Oracle which makes me believe that our approach of using a popular static language paid off well from a management perspective.

A note on the actual argument: I don't think that following SOLID principles and TDD (within reason) add much extra time - if any- to the overall development cycle. This claim has been widely supported over the years.

A note to Agilistas: for many projects to succeed you need qualified specialists skilled in usability, scalability, concurrency, DBMS tuning, etc. Being 'agile' does not mitigate the need for those specialists. If your project needs them and you lack them, you may still ship crap from the perspective of the user.

Lastly, I do encourage developers who have not used SOLID or TDD to pair-program with some who has mastered these skills for a few hours and make up your own mind based on an actual apprenticeship experience.

The beauty of our industry is that there are many ways to succeed and there are many ways to account for value.

Links to read:

http://www.joelonsoftware.com/items/2009/01/31.html

http://www.threeriversinstitute.org/blog/?p=29

http://blog.objectmentor.com/articles/2009/02/06/on-open-letter-to-joel-spolsky-and-jeff-atwood


Bill Venners

Posts: 2244
Nickname: bv
Registered: Jan, 2002

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 19, 2009 12:56 PM
Reply to this message Reply
I checked out the links and it is unfortunate that the attacks got personal, because the differences in the ideas or attitudes are important and useful to debate. It reminded me of a similar, but less personal debate we had four years ago here at Artima, which involved Uncle Bob. It started with this post:

http://www.artima.com/weblogs/viewpost.jsp?thread=91774

It continued with this one:

http://www.artima.com/weblogs/viewpost.jsp?thread=95622

And a year later I touched on it again here:

http://www.artima.com/weblogs/viewpost.jsp?thread=153973

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 19, 2009 4:05 PM
Reply to this message Reply
I was looking through some blogs yesterday and I came across this.

http://scruffylookingcatherder.com/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx

The part that really struck me was:

"The lack of any other correlation here is pretty pronounced any way you care to slice the data. Having a big clump in that upper left quadrant is troubling enough but then having the "Test Last" group almost double your "Test First" group in the over 90% quality range is something that should be noticed and highlighted."

In other words, he's suggesting that the study showed higher quality for the test last group than for the test-first and structured their conclusions to gloss over that.

I also saw a presentation off of InofQ (I think) where the speaker presented some figures stating that unit tests caught a maximum of 50% of defects. Compared to the other types of testing, it was in the bottom of the pack.

I think unit tests are valuable but from my own experience, the benefits seem oversold and the costs understated. I've seen a number of projects that never were completed but had all kinds of unit tests and I've seen hugely successful projects where there were no unit tests.

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 5:40 AM
Reply to this message Reply
The link to the final podcast #41 with Joel, Jeff and Uncle Bob is missing. As well as reactions from Ron Jeffries and others...

http://blog.stackoverflow.com/2009/02/podcast-41/
http://www.jroller.com/sebastianKuebeck/entry/uncle_bob_vs_jeff_and
http://www.jroller.com/sebastianKuebeck/entry/uncle_bob_vs_jeff_and1
http://www.jroller.com/sebastianKuebeck/entry/large_numbers_of_failed_tests

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 10:11 AM
Reply to this message Reply
In looking at the solid principles:

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

I don't see the work 'test' anywhere. What's is the link between SOLID and TDD?

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 10:42 AM
Reply to this message Reply
Have a look at the three rules of TDD on this:

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 11:58 AM
Reply to this message Reply
My problem with the "you must write the test first" dogma is first, that it is dogma, and second, that the test code defines the API for your objects. This is seldom correct.

For example, many simplistic tests set something and then get something. So your object looks like a bean. But a more rational design might be to make the object immutable for thread safety. And maybe instead of a raw get of individual fields, since this is an SOA project, in practice you "get" all the info via XML. Since you wrote the test first

1) it implies that there is a need for a setter, some other coder coming along might say "gee, maybe there's a requirement for a setter, I can't change that"
2) it also implies the need for a getter
3) at best, when you decide to change the tests, you waste time refactoring both the code and the test.

By raising the activation energy to better design and refactoring, a dogmatic "you must write the test first" is, IMO, wrong.



One anecdote. A friend and TDD fanatic at work gave an excellent workshop, where we were converting roman numerals to decimal. There are tons of test cases, since there are a lot if "illegal" roman numeral inputs you need to catch (e.g. IIX is illegal).

Afterwards, I googled for code. I found some code to do the opposite, convert decimals to roman numerals. There are almost no test cases, since the test for a valid input is simple.

The take home message is that if you can somehow redesign your problem to eliminate bad input, the need for tests drops by orders of magnitude.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 1:08 PM
Reply to this message Reply
> Have a look at the three rules of TDD on this:
>
> http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

I know what TDD is. I asked where the association between it and SOLID comes from. It seems to be assumed but not documented.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 1:26 PM
Reply to this message Reply
> <p>Recently you may have noticed noise about Joel Spolsky
> vs Bob Martin and Kent Beck. After reading some of the
> available online material, I came to the conclusion that
> may surprise those of you that know of my background in
> the Agile/TDD community.</p>

I don't know of your background, and I don't know what your conclusion is here, either.

I didn't notice the noise until this blog post (I check artima almost daily, stack overflow rarely and gave up on Kent Beck years ago), because most of it IS noise, and usually not worth wasting the brain cycles on. In my opinion anybody that uses the word "lawsuit" when talking about somebody expressing their opinion isn't really open to thought or discussion about their closely held belief.

I've read and corresponded with Joel a bit. I'm guessing that the words didn't "get away from him a bit", either. Joel's proven he's pretty good at marketing himself. I'll assume that the podcast wasn't scripted down to the word, but he probably had a darn goo idea what he wanted to say, has plenty of experience, isn't afraid of expressing his opinion and hasn't minced words often from what I've seen, heard and read.

And if opinions are bugs, Uncle Bob is in dire need of a de-lousing. I'm sure most of us here (me included, obviously) are, too.

> <p>Joel can say what ever he wants because his company
> ships products that folks buy and he is hiring! I have
> personally tested both FogBugz and Copilot and concluded
> that in many ways both products are leaders in their
> space. Joel has a complete formula for how to recruit
> bright folks and help them ship beautiful and quality
> software. His formula and tool chain is different from
> many Agile shops who also hire bright folks and ship on
> time. So we just have different schools of thought here.
> That's all. Or is it?</p>
> <p>Code and tool chains have a significant impact on
> software evolution and sustainability. For example, its
> much easier to find developers who can maintain
> well-factored, unit-tested Java or C# code. From what I
> can see this is not an issue for Joel. According to his
> blog, Fog Creek uses an in-house cross-platform language
> called Wasabi and I am sure its a well-reasoned decision
> that has worked well for them especially in light of their
> ownership structure and low turnover. While at Plumtree
> Software, I have been involved in the creation of a Java
> to c# translator used for that very purpose. We ran the
> project using Scrum and TDD and it has worked very well.
> Later, Plumtree was sold to BEA and eventually to Oracle
> which makes me believe that our approach of using a
> popular static language paid off well from a management
> perspective.</p>

I know many, many people that would say software may be able to evolve and be easily maintained in spite of being written in C# or Java, not because of it. Given Joel's description of Wasabi and what it is capable of, I think for his particular domain set that code is probably more maintainable than the equivalent in just about any statically typed language. Also, Scrum and TDD are independent of language and tool choice. I think maybe you are confounding the two? I certainly don't see how you can attribute the success of the translator to any one part of the project. Probably a combination of smart people and good timing had more to do with it than the methodology or tools, but that's nothing more than my completely unfounded opinion. You solved a particularly painful problem, which is no small feat, however you did it.

> <p>A note on the actual argument: I don't think that
> following SOLID principles and TDD (within reason) add
> much extra time - if any- to the overall development
> cycle. This claim has been widely supported over the
> years.</p>

I've seen many claims that the claim was widely supported. There seems to be little hard evidence one way or the other, though. I would be glad to see some.

> <p>A note to Agilistas: for many projects to succeed you
> need qualified specialists skilled in usability,
> scalability, concurrency, DBMS tuning, etc. Being 'agile'
> does not mitigate the need for those specialists. If your
> project needs them and you lack them, you may still ship
> crap from the perspective of the user.</p>
> <p>Lastly, I do encourage developers who have not used
> SOLID or TDD to pair-program with some who has mastered
> these skills for a few hours and make up your own mind
> based on an actual apprenticeship experience.</p>

I think an actual apprenticeship takes more than a few hours. I've sat with hours for people doing these sorts of things and it isn't how I work. Pair-programming usually makes me want to cry. And how does one deem having "mastered" SOLID or TDD. Is there a special belt or robe a master wears, trials he must endure? Is there a proverbial pebble to take from the hand? Or do we just believe the marketing copy on the web site, brochure, magazine by-line or book acknowledgment/forward/introduction/afterword?

> <p>The beauty of our industry is that there are many ways
> to succeed and there are many ways to account for
> value.</p>

To me that is actually one of the pain points of the industry, especially the "account for value" part. What is valuable to the person writing the code is of little value to the user of the code and sometimes what is of value to the developer and the user is not of any value to the person paying for the software. I've been amazed many times that different stakeholders can take such different views to a single project. Different groups look at the same deliverable and some will proclaim it an achievement beyond compare and others will say it is a dismal failure. One need look no further than Extreme Programming's poster child, C3, to see this effect. You read the books and it was great! And yet the project and the system got shut down because it didn't do what it was supposed to do. Who's right?

Generally speaking, the more I see and read about TDD, the more it seems to me that it is trying to formalize and codify what Paul Graham and others refer to as exploratory programming or bottom up programming. The difference being that most people that intuitively practice this style using dynamic languages just get something working, figure out it works, and move on. The tests are done in the top level and then thrown out. If it is important sometimes they are kept around, but most of the time the tests are tossed when no longer necessary. My observation of the results of this formalization process is that you get a lot of people that are more interested in following the letter of the law and not its spirit.

If TDD and its ilk work for you, great. Use them. But to state as fact that it makes software better, allows it to be developed faster, with less bugs, doesn't have morning breath and whatever other claims Agile and TDD proponents make aren't supported by any evidence from what I've seen. The evidence is ambiguous at best and in some cases, like the link James has above, the evidence seems to favor the tried and true software practices that are 30+ years old, regardless of the "conclusions" reached by the people selling the methodology.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 2:56 PM
Reply to this message Reply
> One need look no further than Extreme Programming's poster
> child, C3, to see this effect. You read the books and it
> was great! And yet the project and the system got shut
> down because it didn't do what it was supposed to do.
> Who's right?

In my personal opinion, most software development methodologies have pretty minimal effect of the chances of success. That isn't to say there aren't some bad approaches that will guarantee failure but any approach that can produce successful software is roughly equivalent to any other such approach.

What really determines whether a project will succeed are (in decreasing impact but all are crucial):

1. Are the requirements known/documented correctly such that all parties involved have the same understanding of them?
2. Are the owners of the requirements validating the system?
3. How thoroughly has the system been tested against in realistic scenarios.
4. How able are the designers / developers.

That's it. Whether I test first test last or test middle is just rearranging the deck chairs. It has no discernible effect on whether the ship will sink or not.

I think technical people tend to focus on development methodologies and tools partly because that's what we are supposed to do and partly because it's what we understand and have some control over. The 4 things above all fall under management in most organizations.

That's why I think it's so hard to get objective data on development processes that shows anything. The success of a given project is only weakly associated with the development process. In order to get meaningful data telling you which approach is better, you'd have to constrain the data to those projects where the 4 things above are true and if you did, you probably won't have a statistically significant sample.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 3:02 PM
Reply to this message Reply
"The evidence is ambiguous at best and in some cases, like the link James has above, the evidence seems to favor the tried and true software practices that are 30+ years old, regardless of the "conclusions" reached by the people selling the methodology."

I assume the tried and true you refer to is the so-called Waterfall Method. Take a gander at "Iterative and Incremental Development: A Brief History" published in IEEE's Computer, June 2003.

Reading it made me a little furious that we wasted so much time going the route of the Waterfall.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 3:08 PM
Reply to this message Reply
> 1. Are the requirements known/documented correctly such
> that all parties involved have the same understanding of
> them?
> 2. Are the owners of the requirements validating the
> system?
> 3. How thoroughly has the system been tested against in
> realistic scenarios.
> 4. How able are the designers / developers.

Great list. To flush out 2. a bit, the owners/users must be involved daily. They can't flit in and out when they have time. The organization has to commit to letting the owners/users work on the project as a primary responsibility.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 20, 2009 4:51 PM
Reply to this message Reply
> "The evidence is ambiguous at best and in some cases, like
> the link James has above, the evidence seems to favor the
> tried and true software practices that are 30+ years old,
> regardless of the "conclusions" reached by the people
> selling the methodology."
>
> I assume the tried and true you refer to is the so-called
> Waterfall Method. Take a gander at "Iterative and
> Incremental Development: A Brief History" published in
> IEEE's Computer, June 2003.
>
> Reading it made me a little furious that we wasted so much
> time going the route of the Waterfall.

I read what I could find. My IEEE membership expired a while ago. It's a good read. I didn't have waterfall specifically in mind. As the paper notes, once upon a time what we do was just called "Software Development". And it specifically narrows in on Iterative Development. While iterative development is a cornerstone of agile methods, you can do iterative development without taking everything from <pick-your-favorite-agile-methodology>. The first thing the Agile Manifesto says it values is "Individuals and interactions over processes and tools" and yet we have an entire industry coming up with processes and tools and telling me if I don't use said processes and tools, I'm doing something wrong. Am I the only one that sees the irony there?

I think we all know that Waterfall has its issues. The issues are pretty well documented and understood. I would put this in contrast to most Agile methods where when legitimate criticisms are brought up, most hardcore Agile proponents dismiss them and tell people that they are doing it wrong. I've gone into painful detail on many occasions here and elsewhere about the shortcomings I see in most Agile methods. They reduce down to 3 main things.

1: Lack of deliverables that decision makers outside of development can act on. As much as it would be nice for "Business people and developers [to] work together daily throughout the project", I think we are all pretty well aware that this does not happen. The opportunity cost is simply too high. You need to do something to mitigate the issues that arise due to the common occurrence that the person writing the code is not an expert in the domain they are programming to. I'm wondering what that 'something' is since documentation and meetings are universally considered bad in the agile world and stakeholders aren't willing to part with a business person to hold the developers hands throughout an entire software development cycle (which can take years) from design to coding to testing to coding to testing to.... delivery.

2: A lot of conflicting advice. This is most obvious to me in XP where on one day I've read that in order to follow XP and have it work, you need to follow all the ruebricks. To the letter. Leave one out and you're doomed. Later I read that mindlessly applying all of them was wrong and you need to adapt them to your own process. Other methodologies wearing the Agile moniker have suffered from the same problem in what I've read. Most Agile methodologies to me appear to be a very long winded way to say "Don't be stupid."

3: Strongly encouraging a "shoot first, ask questions later" mentality. There is a very strong emphasis on coding the smallest thing that could possibly work, don't worry about documentation and strong disparaging of Big Design Up Front. The thought being that somehow if you write enough code that a decent design will just magically appear, I guess. I think the best example of this I have ever seen was somebody comparing Peter Norvig's solution to sudoku vs. Ron Jeffries trying to write a sudoku solver.

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 21, 2009 2:59 AM
Reply to this message Reply
To SOLID and TDD:
Sorry, I didn't really answer the question. You can use the SOLID principles with or without TDD. With TDD it is probably easier to implement them as you adapt your code continuously to meet this principles.

> In my personal opinion, most software development
> methodologies have pretty minimal effect of the chances of
> success. That isn't to say there aren't some bad
> approaches that will guarantee failure but any approach
> that can produce successful software is roughly equivalent
> to any other such approach.
>
> What really determines whether a project will succeed are
> (in decreasing impact but all are crucial):
>
> 1. Are the requirements known/documented correctly such
> that all parties involved have the same understanding of
> them?
> 2. Are the owners of the requirements validating the
> system?

You might have a look at this...
http://www.infoq.com/news/2009/02/alignment-trap

BTW: Knowing and documenting requirements is just one part of the story. The important part is to prioritized them according to their business value.

> 3. How thoroughly has the system been tested against in
> realistic scenarios.

You are perfectly right with this.

> 4. How able are the designers / developers.
>
+ what do you do to help them improve their skills.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Joel vs Bob and Kent. Different strokes for different folks. Posted: Feb 21, 2009 3:12 AM
Reply to this message Reply
It has always been a weakness of TDD that tests are written to catch the bugs that you've already thought of. The code is then written in light of such tests. That's fine but by definition, the bugs that catch you out are the ones that you never thought of.

Flat View: This topic has 44 replies on 3 pages [ 1  2  3 | » ]
Topic: The Adventures of a Pythonista in Schemeland/18 Previous Topic   Next Topic Topic: The Adventures of a Pythonista in Schemeland/17


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us