Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

threeriversinstitute.org

Post reply on HN
Print view View original

21–30 of 100 posts

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

#21

Post by anuraggoel »

lacker wrote: post #4

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

I think what Martin and Kent are really objecting to is this (from the same podcast):

"They've just gone off the deep end, and I don't think these people write very much code if they're coming up with these principles, to be honest, it doesn't even make sense."

It probably wasn't meant that way, but it was taken as an unnecessary personal attack (despite Joel's frequent 'don't listen to me' implorations)

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

#22

Post by plinkplonk »

anuraggoel wrote: post #21
lacker wrote: post #4

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

I think what Martin and Kent are really objecting to is this (from the same podcast): "They've just gone off the deep end, and I don't think these people write very much code if they're coming up with these principles, to be honest, it doesn't even make sense." It probably wasn't meant that way, but it was taken as an unnecessary personal attack (despite Joel's frequent 'don't listen to me' implorations)

".. and I don't think these people write very much code"

and why is this objectionable? Joel Spolsky thinks some agile "gurus" don't write much code.

Fwiw, I know at least a couple of these "guru" (note the quotes) folks who don't write production code and haven't done so in years and make their living telling other people how to write their code !

The correct way to counter this is to point at (open source) code they wrote (Bob Martin does this by pointing at the Fitnesse code base, so he got this part right imo), or if it is not possible, just calmly assert that Spolsky's thinking is wrong and leave it at that.

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

#23

Post by jacobscott »

joe_the_user wrote: post #8
lacker wrote: post #4

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

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

If you are:

* selling software people pay money for

* writing software people install -- that is, /not/ web stuff

Then under what circumstances would it make sense to ship untested code? When is there a difference between code that has unit tests, versus that with only end-to-end tests?

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

#24

Post by zaius »

nostrademons wrote: post #11
lacker wrote: post #4

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

In this case, I think Kent's right. Joel's doing it wrong. You should never have 10% of your unit tests depend upon the location of a menu. You should have one unit test that depends upon the location of the menu, and everything else should be isolated by stubs, shunts, mocks, whatever. Otherwise, they aren't really unit tests, because they're testing more than a unit. I didn't realize how wrong I was doing it until…

As someone who is relatively new to the world of testing, I think I finally understand the point of stubs/mocks/etc. Thanks!

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

#25

Post by dnene »

paul wrote: post #14
lacker wrote: post #4

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

I think I agree with everything Joel said in that post. These crazy rules people come up with for "proper object oriented" programming remind me of extreme religious rituals. You have to observe all these stupid little rules or else your code will become impure you and will spend an eternity in code maintenance hell. I'll make a somewhat heretical claim even: Unit test are 20% useful engineering, and 80% fad. They ar…

I have the deepest respect for you and your writings, but exactly how much maximum code coverage have you achieved and sustained for at least a month using automated unit tests ?

Just wondering how long you've visited the region you're writing a travel review about.

Unit tests are about confidence in the software. Automation is the mechanism for sustained confidence. Engineering (and / or fad as you put it) is a vehicle to get there.

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

#26

Post by axod »

dnene wrote: post #25
paul wrote: post #14

Earlier quoted context omitted.

I think I agree with everything Joel said in that post. These crazy rules people come up with for "proper object oriented" programming remind me of extreme religious rituals. You have to observe all these stupid little rules or else your code will become impure you and will spend an eternity in code maintenance hell. I'll make a somewhat heretical claim even: Unit test are 20% useful engineering, and 80% fad. They ar…

I have the deepest respect for you and your writings, but exactly how much maximum code coverage have you achieved and sustained for at least a month using automated unit tests ? Just wondering how long you've visited the region you're writing a travel review about. Unit tests are about confidence in the software. Automation is the mechanism for sustained confidence. Engineering (and / or fad as you put it) is a vehi…

You can have 100% code coverage, and still not be testing anything. Unless you're testing thoroughly the right parts, they're a false sense of security.

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

#27

Post by dnene »

axod wrote: post #26
dnene wrote: post #25

Earlier quoted context omitted.

I have the deepest respect for you and your writings, but exactly how much maximum code coverage have you achieved and sustained for at least a month using automated unit tests ? Just wondering how long you've visited the region you're writing a travel review about. Unit tests are about confidence in the software. Automation is the mechanism for sustained confidence. Engineering (and / or fad as you put it) is a vehi…

You can have 100% code coverage, and still not be testing anything. Unless you're testing thoroughly the right parts, they're a false sense of security.

I agree with that. Its just an (imperfect) proxy measure of the depth / extent of unit testing. Asking how much code coverage is likely to give a better reflection of the effort behind unit testing rather than just a - "have you done unit testing".

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

#28

Post by axod »

nostrademons wrote: post #11
lacker wrote: post #4

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

In this case, I think Kent's right. Joel's doing it wrong. You should never have 10% of your unit tests depend upon the location of a menu. You should have one unit test that depends upon the location of the menu, and everything else should be isolated by stubs, shunts, mocks, whatever. Otherwise, they aren't really unit tests, because they're testing more than a unit. I didn't realize how wrong I was doing it until…

I agree, in theory. However, when you're quickly iterating, redesigning, changing how things work, having to completely rework the unit tests as well is pretty much wasted effort.

I think it depends on the project - is it a 'design up front, go away code once' project, or an iterative constantly changing thing.

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

#29

Post by swombat »

andreyf wrote: post #16
dasil003 wrote: post #2

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

Never heard of this guy before, but considering that he just wrote 3 paragraphs eloquently saying "Joel is an idiot" without saying anything about how they disagree makes me think quite little of him. Ad hominem attacks are rhetoric - meant to influence, not inform. See How to Disagree, by PG: http://www.paulgraham.com/disagree.html

Kent Beck is the creator of Extreme Programming, one of the fathers of Test-Driven-Design and a bunch of other agile practices. Quite well known amongst most programmer circles.

More info here: http://en.wikipedia.org/wiki/Kent_Beck

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

#30

Post by swombat »

axod wrote: post #28
nostrademons wrote: post #11

Earlier quoted context omitted.

In this case, I think Kent's right. Joel's doing it wrong. You should never have 10% of your unit tests depend upon the location of a menu. You should have one unit test that depends upon the location of the menu, and everything else should be isolated by stubs, shunts, mocks, whatever. Otherwise, they aren't really unit tests, because they're testing more than a unit. I didn't realize how wrong I was doing it until…

I agree, in theory. However, when you're quickly iterating, redesigning, changing how things work, having to completely rework the unit tests as well is pretty much wasted effort. I think it depends on the project - is it a 'design up front, go away code once' project, or an iterative constantly changing thing.

'Fraid not, axod. It's when you're quickly iterating and changing lots of stuff that quality unit testing helps you the most. Let's look at 2 possible scenarios:

1) You don't bother testing much. You make lots of changes, iterate quickly. Before the changes, you have code that, let's say, you know works. After the changes, you know there's probably bugs, but you don't know where.

2) You test fairly thoroughly. You make lots of changes, iterate quickly. Before the changes you have code that you know works. After the changes, you know where most of the bugs are because your tests tell you where they are.

It's the difference between walking with your eyes open or closed... it may be more work to process all that information about obstacles, but it sure is helpful if you want to avoid those obstacles.

Post reply on HN