Live data from Hacker News

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

threeriversinstitute.org

61–70 of 100 posts

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

#61
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.

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

#62

Earlier quoted context omitted.

Joel dragged him into this by name. Clearly he thinks Joel is attributing ideas to him that he doesn't hold. Therefore it's not a matter of disagreement--he may well fully agree with Joel's thesis--it's the demonization of his work by misrepresentation. In that light his response seems measured and appropriate.

It may be measured, but it's not helpful. Let's assume that Joel is neither stupid nor malicious. Therefore he is having problems that presumably others are having. In this case it is useful to actually set out the nature of Joel's error, rather than simply saying "Joel is a dolt". Non-malicious criticism can often be helpful in letting you explore why people misunderstand you. Of course my assumptions could be wrong…

2. "Joel is a dolt" - Neither on the lines nor between them have I seen this in Kent's post.

1. "Joel is neither stupid nor malicious" - Stupid + Malicious != AllThereCouldEverBe... Pompous and AttentionCraving are missing for example. Others are too...

0. I _partly_ dislike both stands on software dev. methodology (Kent's and Joel's) so don't take this a fanboysm. I respect Kent's life work more though.

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

#63
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…

Good point, but it's not just fanboys, I've seen Uncle Bob speak and he's a lot less reasonable then he was in his response to Joel.

The thing is, it's appropriate for his audience, large cubicle farms with a completely broken system.

So oversimplifying and extreme work for Uncle Bob when he's consulting.

Joel was obviously talking about the kind of super star programmers he hires in his magical fairy land office. (Just kidding Joel, I wish I worked in an office like that.)

The problem as I see it, is the difference between what's good for good programmers, and what's good for most people who happen to diddle with visual basic. (No offense to VB rock stars, keep on rockin'!)

Kent Beck and Bob Martin are very good programmers, but they get paid from consulting large organizations with not so great programmers.

Joel gets paid by hiring and working with great programmers, in his magical high rise office, with free gourmet food and rainbows.

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

#64
post #37
post #30

Earlier quoted context omitted.

'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 ma…

I disagree. If I'm constantly changing my mind about how best to do something, I don't want the massive overhead of having to change unit tests all the time as well. I'll test as I go, in the code.

"If I'm constantly changing my mind about how best to do something" then you're finding /more/ not /best/ ways.

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

#65
post #55
post #49

Earlier quoted context omitted.

>> "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." No. More often than not, if you change was a large architectural one, which is often the case in young software, your tests are now irrelevant, or broken. >> "It's the difference between walking with your eyes open or closed... it may be more work to process all…

* testThingsYouMightHaveChanged();* If you change that into writeAnAutomatedTestForItAndRunYourTestSuite() you get the following benefits: 1) Every test you write accrues value onto your test suite and helps you avoid problems later; 2) You don't need to spend time to figure out what you might have broken with your change - your test suite tells you in seconds; 3) You can say with some measure of certainty that it's…

BUT you then have to modify:

  while (!compile()) {
    fixCompilationErrors();
    fixUnitTests();
    rewriteUnitTestsThatNoLongerMakeSense();
    WriteNewUnitTests();
  }
Your iterate loop just became maybe twice or 3 times as long. Less iterations = worse code.

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

#66
To quote from 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.

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

#67
post #37
post #30

Earlier quoted context omitted.

'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 ma…

I disagree. If I'm constantly changing my mind about how best to do something, I don't want the massive overhead of having to change unit tests all the time as well. I'll test as I go, in the code.

If your testing in the code then your doing unit tests. But probably in a poor fashion.

Unit tests should hook into the application in such a way that you can reorder the GUI and change nothing.

If you are using Unit tests correctly then any change to the code base at worst requires 10% of that effort to change the test cases. If you can think of any meaningful change that is worse then that your something is wrong with how you're testing.

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

#68
post #36
post #29

Earlier quoted context omitted.

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

He also co-wrote JUnit and wrote SUnit which spawned the many other counterparts in other languages and wrote one of the better Smalltalk books.

And that book is Smalltalk Best Practice Patterns (http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/...). Not anything like the design patterns book in case anyone wonders, and it's a good read even if you don't do Smalltalk.

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

#69
post #65
post #55

Earlier quoted context omitted.

* testThingsYouMightHaveChanged();* If you change that into writeAnAutomatedTestForItAndRunYourTestSuite() you get the following benefits: 1) Every test you write accrues value onto your test suite and helps you avoid problems later; 2) You don't need to spend time to figure out what you might have broken with your change - your test suite tells you in seconds; 3) You can say with some measure of certainty that it's…

BUT you then have to modify: while (!compile()) { fixCompilationErrors(); fixUnitTests(); rewriteUnitTestsThatNoLongerMakeSense(); WriteNewUnitTests(); } Your iterate loop just became maybe twice or 3 times as long. Less iterations = worse code.

rewriteUnitTestsThatNoLongerMakeSense

Delete em. You should be iterating your unit tests.

Over time you will find some really useful unit tests for common mistakes, and others that are basically useless. Try and approach things from the perspective of what you would like to know works and not just tossing everything and the kitchen sink at the problem. When you find a bug add a unit test just in case it comes back, if you change major parts of the system, port the most useful unit tests and delete the rest.

I think of unit tests as saving you from the (I thought I just fixed this) problem.

PS: The major advantage of this approach is you keep adding more tests to the older parts of the system, which are also the most costly to change because other parts of the system assume it works. And assumptions you and your code is making can be really hard bugs to find and fix.

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

#70
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…

originally informed by first-hand experience You can read about that experience here: http://c2.com/cgi/wiki?CthreeProjectTerminated

It's interesting how this "little" detail always seems to get overlooked by the XP zealots. A great book which I think everyone should read before jumping onto the XP/TDD/Scrum/Agile/etc bandwagon is called "Extreme Programming Refactored: The Case Against XP". It highlights the failed C3 project and offers some compelling arguments.
Post reply on HN