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

41–50 of 100 posts

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

#41

Post by shiro »

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.

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

I think your line is too coarse. I do heavily rely on unit tests even in "iterative constant changing projects". But in the very early "sketching" stage of development I don't bother to write tests. I just play with code on REPL (I work with Common Lisp or Scheme most of the time), in a flat namespace. Then, once I start putting code snippets together into packages (CL) or modules (Scheme), that's about the time I start writing tests as well. After that, even I constantly change stuff, sometimes drastically, unit tests do help me a lot.

It is true that you need effort on reworking on the tests. Actually I think writing tests needs more work than writing actual code. And I think that's the right thing. Writing something that works is an easy part. Making sure it doesn't break in every possible situation is much harder. In language like CL, you can fairly quickly write something that takes typical input and reasonable output without serious thinking. To make sure it works in every corner case you have to think much harder and precisely, and test code reflects that thinking.

(NB: I know some programmers who seem to think out those corner cases in their brain and just spit out a beautiful code at the first attempt. They may not need support from test code, I guess.)

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

#42

Post by davidw »

swombat wrote: post #30
axod wrote: post #28

Earlier quoted context omitted.

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

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

The tests tell you where the tests fail. Some of those failures may be due to bugs, and others may simply due to the way your code now works.

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

#43

Post by trapper »

swombat wrote: post #30
axod wrote: post #28

Earlier quoted context omitted.

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

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 that they don't understand the requirements.

My position is that if you are building something for the first time, you are going to get it wrong, so get it wrong as quickly and cheaply as possible. This means getting it in front of users as quickly as possible, bugs and all.

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

#44

Post by silentbicycle »

jacobscott wrote: post #23
joe_the_user wrote: post #8

Earlier quoted context omitted.

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?

I don't think anybody is arguing that shipping completely untested code is a good idea.

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

#45

Post by jsdalton »

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…

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.

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

#46

Post by DougBTX »

Angostura wrote: post #32
dasil003 wrote: post #19

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…

He could also believe exactly what he says, that Spolsky has a "lack of knowledge of what I do and what I say".

FWIW, I think this is the post being responded to: http://www.joelonsoftware.com/items/2009/01/31.html

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

#47

Post by DougBTX »

swombat wrote: post #30
axod wrote: post #28

Earlier quoted context omitted.

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

> After the changes, you know there's probably bugs, but you don't know where.

Which highlights one of the "problems" with unit tests: if something fails, you have to take time to go and fix it. If you have no tests, you can assume there are no bugs because you are such a great programmer, then go home after a job well done.

That there actually are bugs there doesn't bother you, because you don't know about them. It takes less time to write buggy code.

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

#48

Post by axod »

DougBTX wrote: post #47
swombat wrote: 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…

> After the changes, you know there's probably bugs, but you don't know where. Which highlights one of the "problems" with unit tests: if something fails, you have to take time to go and fix it. If you have no tests, you can assume there are no bugs because you are such a great programmer, then go home after a job well done. That there actually are bugs there doesn't bother you, because you don't know about them. It…

The alternative, is to build you code in a way which tells you quickly about bugs... decent logging, etc

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

#49

Post by axod »

swombat wrote: post #30
axod wrote: post #28

Earlier quoted context omitted.

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

>> "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 that information about obstacles, but it sure is helpful if you want to avoid those obstacles."

Do you seriously think people are just blindly coding and never testing anything here?

  while(true) {
    writeABitOfCode();
    while (!compile()) fixCompilationErrors();
    testThingsYouMightHaveChanged();
    checkLogsForIssues();
  }

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

#50

Post by Hast »

jwr wrote: post #40

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.

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.

Post reply on HN