Live data from Hacker News

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

threeriversinstitute.org

71–80 of 100 posts

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

#71
post #14
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’ve never seen Kent Beck as a crazy rules person. I think his comment from stackoverflow demonstrates this:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

http://stackoverflow.com/questions/153234/how-deep-are-your-...

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

#72
post #14
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 wouldn't write off unit testing and test-driven development so quickly. My personal experience is that sometimes it felt like a waste of time, and when it was, I dropped it. For times when I had a clue of what I wanted to do, but only just a clue, writing the test first was a nice tool for fleshing out behavior.

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

#73
post #14
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…

And of course, if you find that these rituals are not working for you, then you "obviously" are not doing them properly.

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

#74

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.

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

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

#75
post #70

Earlier quoted context omitted.

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.

Don't conflate having a project canceled with having it fail. Successful projects get canceled for a variety of reasons, and some failed projects never get canceled.

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

#76
post #54
post #43

Earlier quoted context omitted.

There are two schools of thought in programming I have seen. 1. Design it right the first time, tests and all. 2. Build a throwaway, no tests, little refactoring as you quickly iterate Programmers who fall into category 1 in my experience mistakenly believe that they understand the requirements of the software they are writing. Category 2 programmers tend to be ones who actually deal with users/real world, and know t…

You're assuming that you'll get something in front of users more quickly without writing tests. I find that's not the case in my experience.

I find there's a balance to be struck. You want to get stuff in front of users quickly, but if that stuff sucks so much that it's unusable, you aren't going to release it (and if you did, nobody would use it). So you want enough tests that you can be reasonably confident of the code and not spend a lot of time debugging, since debugging is the real timesink that'll kill you.

I often find that I unit test all but the latest layer. As soon as I start depending on code from something else, it's time to write some tests. But if I just wrote something, it's probably in flux and tests would just prematurely lock down the interface. Write the code, write the client (which probably requires that you rewrite the code), and then write the tests in lieu of debugging the code.

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

#77
post #69
post #65

Earlier quoted context omitted.

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, i…

I think the best benefit of unit tests is really saving you from the "Will this break anything?" problem. Uncertainty is the real big killer for programming productivity; if you know what to code, you just type it out and you can get like 10 lines/minute. So have some way that you can run things and say "I know this broke something" or "I know this didn't break anything."

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

#78
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. (J…

Most great programmers take very well to unit tests. The way they became great was to assume their code is flawed and take steps to remedy that.

Perhaps I'm being a little harsh, but I don't think Joel or his employees are really all that great. I mean, they're working on bugtracking software. Great programmers tend not to trade interesting problems for private offices and gigantic monitors (plus, they often can get jobs at places that offer them interesting problems, private offices, and gigantic monitors).

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

#79

Earlier quoted context omitted.

Do you know of any good texts or articles that describe the "right" way to test? I put myself in the category of mediocre test writer, because I do bump into the problem fairly regularly of having a lot of tests fail when I do a rewrite. I'd love to learn how to write better tests...and your last paragraph seems to scratch the surface of a superior approach.

The Google Testing Blog can be helpful: http://googletesting.blogspot.com/

Seconding this. I think the internal Google training materials were some of the best I've run across, and the Google Testing Blog is basically the public face of those.

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

#80

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.

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.

Post reply on HN