7 ms·

"Joel Spolksy is wrong about my work" - Kent Beck

85 points by bjclark 18y ago

pkaler 18y ago
What has Kent Beck shipped? Follow the advice of people that have shipped code. That is what I took from the Stack Overflow podcast. Seriously, what has Kent Beck shipped? The Chrysler Compensation program is always brought up. But, I understand that the project was cancelled. I'm not trying to troll here. I would have greater confidence in Kent Beck's argument if I knew what he was actually capable of shipping.
- projectileboy 18y ago
  JUnit, for one thing.
  - nostrademons 18y ago
    Eclipse as well.
    - hello_moto 18y ago
      Really? http://wiki.eclipse.org/FAQ_Where_did_Eclipse_come_from%3F http://wiki.eclipse.org/FAQ_Where_did_Eclipse_come_from%3F
hoyhoy 18y ago
Kent Beck's system is awesome if you want to subjugate a thousand programmers working at a bank. In some sense, it is a very successful way of forcing stupid people to build mediocre products under threat of economic violence.
dasil003 18y ago
It sucks to have your life's work strawmanned like this by pop programmer podcast banter. I hope Joel addresses it professionally. XP/Agile/TDD (like any movement) is filled with rabid fanboys who misapply the principles and try to ram them down everyone's throat, but it's rarely the case that the inventors of popular methodologies are filled with the same blind zeal. After all, their ideas were originally informed by first-hand experience.
- patio11 18y ago
  But what happens when you stick inventor of popular methodology A against inventor of popular methodology B? Is the disagreement blind zeal or professional opinions originally informed by first-hand experience? Or is the whole thing just like duct-taping buttered toast to the back of a cat and then pushing it off a high surface? (Toast always ends buttered side down. Cats always land feet first. Thus, if either lands, the universe implodes. I don't even want to consider what happens if the push-cat-off-ledge-or-not decision is made based on whether a radioactive isotope decays or not.)
  - michaelneale 18y ago
    Joel pushed no "methodology" in that sense at all. What I see is Kent Beck, who pushes a methodology which has taken up a religious like following in "IT" or corporate developer circles. Joel just ships software, and judges things in terms of commercial success in the market place.
    - dasil003 18y ago
      You forgot to mention writes persuasively based on a handful of good ideas filled out with trite brain candy.
      - michaelneale 18y ago
        I am not really a fan of Joel's advice, but if I look at the relative successes, I would have to favour Joel (also, listening to him speak now, on that podcast, indicates that in his "old age" he really has less advice, he has mellowed out and realised that there is a lot more variables at play). I think any methodology really boils down to: have good people any they will make something work. That is the only common thread in successful projects/teams/products that I have seen (and others). Its 80% people, perhaps more. Therefore any other tweaking of things are really like premature optimisation. And I like brain candy. Its sweet in a bitter world ;) I think Paul Bucheit said : "Limited life experience + overgeneralisation == advice".
- 18y ago
jwb119 18y ago
classy response from kent beck
- d0mine 18y ago
  Does "classy" mean a rant with no or little content and the only remarkable thing about it is a famous author?
  - demallien 18y ago
    I'm thinking there may have been just a pinch of sarcasm behind the choice of the word 'classy'...
lacker 18y ago
Here's a transcript of the podcast I believe Kent is referring to. Judge for yourself whether Joel "makes comments that make clear his lack of knowledge". http://www.joelonsoftware.com/items/2009/01/31.html http://www.joelonsoftware.com/items/2009/01/31.html I'd like to see Kent respond to Joel's specific points. E.g: The real problem with unit tests as I've discovered is that the type of changes that you tend to make as code evolves tend to break a constant percentage of your unit tests.... So the end result is that, as your project gets bigger and bigger, if you really have a lot of unit tests, the amount of investment you'll have to make in maintaining those unit tests, keeping them up-to-date and keeping them passing, starts to become disproportional to the amount of benefit that you get out of them.
- akkartik 18y ago
  In this sort of situation test coverage is actively harmful. You want to write lots of tests at a fine grain, and only test 'happy paths' above that level of abstraction. When I layer my tests I rarely end up with thrashing tests. Multiple tests often fail, but it's easy to figure out which test to focus on. And fixing the right test case fixes them all. Even if it makes sense to write a test for menu placement, it rarely makes sense to write more than one.
- joe_the_user 18y ago
  I've generally had some antipathy to Joel Spolsky, seeing him as more management oriented than programmer oriented. But I have to say that he seems both right and honest here. TDD is great if you use it appropriate along with good design - but "tests for everything" is just ideology. As he says, it's like the old OO schema, where you created these ridiculous inheritance trees and unnecessarily complex diagrams and such.
  - dws 18y ago
    If Spolsky is going after "tests for everything", his target is Robert Martin, not Kent Beck. Beck freely admits that he doesn't test everything. Pulling Beck into the argument feels like a cheap debate trick.
  - 18y ago
deleted 18y ago
[deleted]
illume 18y ago
Guru fight! Which one is right? Neither!
andreyf 18y ago
What a well articulated ad hominem flame! So much confidence, and yet, no content. Now that is art! sigh http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html
dangrover 18y ago
Epic rebuttal fail.
jwr 18y ago
I found Joel Spolsky's opinions to be all over the spectrum. Sometimes he posts well-researched pieces with intriguing conclusions. Sometimes he writes uninformed rants, which show his lack of understanding of the subject matter. This is not a problem if you carefully apply your own measure to whatever he writes.
- Hast 18y ago
  I'd say that his ideas on management are interesting and informed. But when he starts talking development or technology he quickly becomes uninformed and poorly researched. The discussion they had a number of episodes ago regarding MVC "patterns" made it clear that they had no fucking clue what they were talking about. And when Wikipedia didn't give a fast answer they began guestimating instead.
darkhorse 18y ago
I'm surprised nobody has mentioned Spolsky's significant bias in this argument: His company makes bug tracking software! Of COURSE he wants to cast unit testing in a bad light - done properly, it could put him out of business.
- discojesus 18y ago
  I sincerely doubt anyone who runs a company that makes bug-tracking software loses any sleep about software bugs being eliminated forever. Regardless of what happens in the software industry, to-do lists ain't going away any time soon.
raganwald 18y ago
A note to all the people arguing about whether TDD is a good idea or not: You are arguing about the colour of the bikeshed. The problem with Joel and Jeff's podcast isn't that they disagree with TDD. If you poll 100 random smart people on the subject, you will get a continuum of answers. The problem is that they then made a sweeping generalization about Kent Beck and Robert Martin's experience and competence based on their disagreement. The old, "If you don't develop software exactly as I do, you are an idiot" line. I think Kent is right not to argue the fine points of TDD, because that isn't the issue. The issue is that his competence and experience were attacked on the basis of advocating TDD, and his response is to suggest that J&J are unaware of his experience. If someone wants to suggest that Kent is a very experienced guy but they don't think TDD is a good idea for their project, I'm sure Kent is fine with their stance on the matter.
huhtenberg 18y ago
To quote from http://www.yafla.com/dforbes/Coding_Horror_Strikes_Again http://www.yafla.com/dforbes/Coding_Horror_Strikes_Again: Coding Horror is an entertaining, sometimes even educational blog. Be careful diving in headfirst, though, as the technical depth is generally so shallow you'll be hitting the bottom before you've even broken through the surface tension. Based on what I have (managed to) read at CH I find this description to be fairly accurate.
- unalone 18y ago
  That's Jeff Atwood, not Joel Spolsky. Unless I'm mistaken about something.
hello_moto 18y ago
It's quite interesting to see two kinds of technical guys arguing against each other. On one side, we have the product guy, on the other, we've got the consulting guy. You've got Joel, Jeff, Paul Bucheit on the product side saying that "Yes, automated testing and some of the OOP principles are great, but let's not go as far as Uncle Bob" Check out the SOLID principles. Some of the principles are alright, but when Uncle Bob explained that Rectangle class thing, I don't know what to say other than I just changed my mind leaning toward not to buy his "Clean Code" book. On the other side, you've got Kent Beck, GoF, Uncle Bob, Martin Fowler, etc. (and possibly Gilles Bowkett). They're what you would consider "war-proven": they've done numerous "IT projects", leading a team of corporate developers, probably making a website for clients, and etc. I don't mean to be rude (and perhaps this is an overgeneralisation), but I haven't heard any software product made by the consulting group. Yes, they wrote code, but the code is based on requirements given by some clients that: 1) Change the requirements frequently 2) Keep cutting costs 3) Ask for more 4) Cut more time There's a huge different between writing code for commercial software that you steer versus writing code driven by someone else who knows almost nothing about software development but knows a lot how to save money. Would you TDD-ed your UI code? If you wrote API, yes, I can understand you do heavy unit-tests. A side note for having your own unit-test framework: 1) Developers shouldn't write them 2) Developers should provide minimal to enough unit-tests 3) Go hire your own test team to do the rest Developers aren't meant to be full-time testers. Testers aren't mean to be a full-time developers. What I'd like to see is a team like this: 1) Joel becomes the product manager 2) Paul Bucheit becomes the software architect 3) Jeff, Kent Beck and Martin Fowler do the coding 4) Robert Martin and those infested TDD people can build a full-blown suite of unit-test frameworks, acceptance test and etc. Microsoft has a category for the people in (4), it is "SDET". For those of you who think developers must write a comprehensive TDD (not just a minimum or "just to pass"), here's a challenge to you: why don't you try and be SDET. You'll see some of the serious full-blown test code, black-box, UI test code, UI automation and a serious CI process. I'm sure the experience will make your TDD and unit-test code look pale in comparison. Google seems going to that (MS) direction slowly.

85 points by bjclark 18y ago

What has Kent Beck shipped? Follow the advice of people that have shipped code. That is what I took from the Stack Overflow podcast. Seriously, what has Kent Beck shipped? The Chrysler Compensation program is always brought up. But, I understand that the project was cancelled. I'm not trying to troll here. I would have greater confidence in Kent Beck's argument if I knew what he was actually capable of shipping.

projectileboy 18y ago
JUnit, for one thing.
- nostrademons 18y ago
  Eclipse as well.
  - hello_moto 18y ago
    Really? http://wiki.eclipse.org/FAQ_Where_did_Eclipse_come_from%3F http://wiki.eclipse.org/FAQ_Where_did_Eclipse_come_from%3F

hoyhoy 18y ago

Kent Beck's system is awesome if you want to subjugate a thousand programmers working at a bank. In some sense, it is a very successful way of forcing stupid people to build mediocre products under threat of economic violence.

dasil003 18y ago

It sucks to have your life's work strawmanned like this by pop programmer podcast banter. I hope Joel addresses it professionally. XP/Agile/TDD (like any movement) is filled with rabid fanboys who misapply the principles and try to ram them down everyone's throat, but it's rarely the case that the inventors of popular methodologies are filled with the same blind zeal. After all, their ideas were originally informed by first-hand experience.

patio11 18y ago
But what happens when you stick inventor of popular methodology A against inventor of popular methodology B? Is the disagreement blind zeal or professional opinions originally informed by first-hand experience? Or is the whole thing just like duct-taping buttered toast to the back of a cat and then pushing it off a high surface? (Toast always ends buttered side down. Cats always land feet first. Thus, if either lands, the universe implodes. I don't even want to consider what happens if the push-cat-off-ledge-or-not decision is made based on whether a radioactive isotope decays or not.)
- michaelneale 18y ago
  Joel pushed no "methodology" in that sense at all. What I see is Kent Beck, who pushes a methodology which has taken up a religious like following in "IT" or corporate developer circles. Joel just ships software, and judges things in terms of commercial success in the market place.
  - dasil003 18y ago
    You forgot to mention writes persuasively based on a handful of good ideas filled out with trite brain candy.
    - michaelneale 18y ago
      I am not really a fan of Joel's advice, but if I look at the relative successes, I would have to favour Joel (also, listening to him speak now, on that podcast, indicates that in his "old age" he really has less advice, he has mellowed out and realised that there is a lot more variables at play). I think any methodology really boils down to: have good people any they will make something work. That is the only common thread in successful projects/teams/products that I have seen (and others). Its 80% people, perhaps more. Therefore any other tweaking of things are really like premature optimisation. And I like brain candy. Its sweet in a bitter world ;) I think Paul Bucheit said : "Limited life experience + overgeneralisation == advice".
18y ago

jwb119 18y ago

classy response from kent beck

d0mine 18y ago
Does "classy" mean a rant with no or little content and the only remarkable thing about it is a famous author?
- demallien 18y ago
  I'm thinking there may have been just a pinch of sarcasm behind the choice of the word 'classy'...

lacker 18y ago

Here's a transcript of the podcast I believe Kent is referring to. Judge for yourself whether Joel "makes comments that make clear his lack of knowledge". http://www.joelonsoftware.com/items/2009/01/31.html http://www.joelonsoftware.com/items/2009/01/31.html I'd like to see Kent respond to Joel's specific points. E.g: The real problem with unit tests as I've discovered is that the type of changes that you tend to make as code evolves tend to break a constant percentage of your unit tests.... So the end result is that, as your project gets bigger and bigger, if you really have a lot of unit tests, the amount of investment you'll have to make in maintaining those unit tests, keeping them up-to-date and keeping them passing, starts to become disproportional to the amount of benefit that you get out of them.

akkartik 18y ago
In this sort of situation test coverage is actively harmful. You want to write lots of tests at a fine grain, and only test 'happy paths' above that level of abstraction. When I layer my tests I rarely end up with thrashing tests. Multiple tests often fail, but it's easy to figure out which test to focus on. And fixing the right test case fixes them all. Even if it makes sense to write a test for menu placement, it rarely makes sense to write more than one.
joe_the_user 18y ago
I've generally had some antipathy to Joel Spolsky, seeing him as more management oriented than programmer oriented. But I have to say that he seems both right and honest here. TDD is great if you use it appropriate along with good design - but "tests for everything" is just ideology. As he says, it's like the old OO schema, where you created these ridiculous inheritance trees and unnecessarily complex diagrams and such.
- dws 18y ago
  If Spolsky is going after "tests for everything", his target is Robert Martin, not Kent Beck. Beck freely admits that he doesn't test everything. Pulling Beck into the argument feels like a cheap debate trick.
- 18y ago

deleted 18y ago

[deleted]

illume 18y ago

Guru fight! Which one is right? Neither!

andreyf 18y ago

What a well articulated ad hominem flame! So much confidence, and yet, no content. Now that is art! sigh http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html

dangrover 18y ago

Epic rebuttal fail.

jwr 18y ago

I found Joel Spolsky's opinions to be all over the spectrum. Sometimes he posts well-researched pieces with intriguing conclusions. Sometimes he writes uninformed rants, which show his lack of understanding of the subject matter. This is not a problem if you carefully apply your own measure to whatever he writes.

Hast 18y ago
I'd say that his ideas on management are interesting and informed. But when he starts talking development or technology he quickly becomes uninformed and poorly researched. The discussion they had a number of episodes ago regarding MVC "patterns" made it clear that they had no fucking clue what they were talking about. And when Wikipedia didn't give a fast answer they began guestimating instead.

darkhorse 18y ago

I'm surprised nobody has mentioned Spolsky's significant bias in this argument: His company makes bug tracking software! Of COURSE he wants to cast unit testing in a bad light - done properly, it could put him out of business.

discojesus 18y ago
I sincerely doubt anyone who runs a company that makes bug-tracking software loses any sleep about software bugs being eliminated forever. Regardless of what happens in the software industry, to-do lists ain't going away any time soon.

raganwald 18y ago

A note to all the people arguing about whether TDD is a good idea or not: You are arguing about the colour of the bikeshed. The problem with Joel and Jeff's podcast isn't that they disagree with TDD. If you poll 100 random smart people on the subject, you will get a continuum of answers. The problem is that they then made a sweeping generalization about Kent Beck and Robert Martin's experience and competence based on their disagreement. The old, "If you don't develop software exactly as I do, you are an idiot" line. I think Kent is right not to argue the fine points of TDD, because that isn't the issue. The issue is that his competence and experience were attacked on the basis of advocating TDD, and his response is to suggest that J&J are unaware of his experience. If someone wants to suggest that Kent is a very experienced guy but they don't think TDD is a good idea for their project, I'm sure Kent is fine with their stance on the matter.

huhtenberg 18y ago

To quote from http://www.yafla.com/dforbes/Coding_Horror_Strikes_Again http://www.yafla.com/dforbes/Coding_Horror_Strikes_Again: Coding Horror is an entertaining, sometimes even educational blog. Be careful diving in headfirst, though, as the technical depth is generally so shallow you'll be hitting the bottom before you've even broken through the surface tension. Based on what I have (managed to) read at CH I find this description to be fairly accurate.

unalone 18y ago
That's Jeff Atwood, not Joel Spolsky. Unless I'm mistaken about something.

hello_moto 18y ago

It's quite interesting to see two kinds of technical guys arguing against each other. On one side, we have the product guy, on the other, we've got the consulting guy. You've got Joel, Jeff, Paul Bucheit on the product side saying that "Yes, automated testing and some of the OOP principles are great, but let's not go as far as Uncle Bob" Check out the SOLID principles. Some of the principles are alright, but when Uncle Bob explained that Rectangle class thing, I don't know what to say other than I just changed my mind leaning toward not to buy his "Clean Code" book. On the other side, you've got Kent Beck, GoF, Uncle Bob, Martin Fowler, etc. (and possibly Gilles Bowkett). They're what you would consider "war-proven": they've done numerous "IT projects", leading a team of corporate developers, probably making a website for clients, and etc. I don't mean to be rude (and perhaps this is an overgeneralisation), but I haven't heard any software product made by the consulting group. Yes, they wrote code, but the code is based on requirements given by some clients that: 1) Change the requirements frequently 2) Keep cutting costs 3) Ask for more 4) Cut more time There's a huge different between writing code for commercial software that you steer versus writing code driven by someone else who knows almost nothing about software development but knows a lot how to save money. Would you TDD-ed your UI code? If you wrote API, yes, I can understand you do heavy unit-tests. A side note for having your own unit-test framework: 1) Developers shouldn't write them 2) Developers should provide minimal to enough unit-tests 3) Go hire your own test team to do the rest Developers aren't meant to be full-time testers. Testers aren't mean to be a full-time developers. What I'd like to see is a team like this: 1) Joel becomes the product manager 2) Paul Bucheit becomes the software architect 3) Jeff, Kent Beck and Martin Fowler do the coding 4) Robert Martin and those infested TDD people can build a full-blown suite of unit-test frameworks, acceptance test and etc. Microsoft has a category for the people in (4), it is "SDET". For those of you who think developers must write a comprehensive TDD (not just a minimum or "just to pass"), here's a challenge to you: why don't you try and be SDET. You'll see some of the serious full-blown test code, black-box, UI test code, UI automation and a serious CI process. I'm sure the experience will make your TDD and unit-test code look pale in comparison. Google seems going to that (MS) direction slowly.