The Duct Tape Programmer • Hacker News Board

Re: The Duct Tape Programmer

#121

Post by Quarrelsome » Mon, Sep 28, 2009, 7:08 PM UTC

akeefer wrote: post #109

Tichy wrote: post #108

Earlier quoted context omitted.

I am not actually against unit tests, but I have seen it being taken to unhealthy extremes. For example at some companies there are automated tools that check that every method has a unit test. In the end people write unit tests for Java getter and setters and so on. Mind numbing as that task is, people also end up writing bad unit tests just to silence the tool. A lot of unit tests make sense, but I suspect they als…

No question, it's a fine line . . . you need to be pragmatic and ask "is writing and maintaining this test going to save me more time than it costs?" Over several years, the maintenance of the tests themselves becomes a huge cost, which is something the TDD guys don't seem to talk about much. (My turn for an overly-cynical guess: since many of them are consultants as you've pointed out, they don't hang around with th…

This is why it might be an idea to have unit tests AND QA. Be pragmatic with the unit tests and center them around core functionality and things that are hard to test (think very hard about race conditions for example). QA if they're any good should catch the boneheaded exceptions (such as a mis-behaving getter that calls itself).

Re: The Duct Tape Programmer

#122

Post by Quarrelsome » Mon, Sep 28, 2009, 7:16 PM UTC

DanielStraight wrote: post #15

jerf wrote: post #10

Earlier quoted context omitted.

The Kolmogorov complexity of COM is, at the very least, hundreds of kilobytes of itchy, fidgety, sensitive, and complicated code. The Kolmogorov complexity of xor'ing two pointers to save 32 bits is on the order of tens or hundreds of bytes. (I'm using the term a bit loosely, obviously, but I think it gets the point across.) I suppose it depends on the limit of "slightly", but in context I think it's clear we're talk…

I see what you're saying, and I agree. It's not comparable to COM. I think the thing is, articles like this tend to create some idealized programmer that is just a conglomeration of attributes the author likes even if they are mutually exclusive . To me, avoiding complexity and doing bit manipulation are mutually exclusive. It's like saying you should use left shift (or is it right...?) instead of diving by 2. Ok, it…

You're quite right with unit tests, I often wonder why people only seem to state their about regression. Two and a half years into my project I think our tests have only caught one or two relatively tame regressions. I mostly use them to test new components (that would be hellish to QA manually as the system is so big it takes a while to build->deploy->run), large refactoring of components and integration tests (like spamming our transaction service randomly and ensuring it always outputs valid files)

Re: The Duct Tape Programmer

#123

Post by Quarrelsome » Mon, Sep 28, 2009, 7:27 PM UTC

mkramlich wrote: post #110

tezza wrote: post #71

Earlier quoted context omitted.

Amen, It's nice to hear someone with experience from before the "Unit Test is compulsory" explosion. Programmers should always test their work, but testing comes in much more of a diverse range than mere Unit Tests. There are plenty of cases where Unit Testing is 'embarrasingly'[1] appropriate. These pin-up applications blinds Testing advocates to the fact that Unit Tests are often inferior to other methods or simply…

thanks for backing me up. yeah i often feel un-PC when I say anything bad about unit tests. (Like saying, gee, maybe there are differences between races, or between cultures, or between genders -- Cats, what you say?!?!) and agreed, there are situations where like you said it's embarrassingly appropriate to have tests. To me the classic case is where you are publishing a code library with thousands of real users acro…

Might just be a matter of context and without the context we get the zealotry. Biggest mistake everyone makes when saying "XYZ is teh lames" or "teh wins" is not describing their context.

Our OS team works differently from our apps team for example, because if something in their stuff breaks it's a big deal, they also really worry about backwards compatability and whenever I touch their code I have to create an IPrinter34 to not break things for old clients (who still want their IPrinter12).

In our apps team though we keep things cleaner and kick out the IPrinter23 and keep things as IPrinter so people can read the code more clearly. Backwards compatability isn't so much an issue for us (apart from obviously considering updates) as we release 1 single unit that replaces all our files. If somebody has an old OS then its not supposed to work anyway so the app going titsup is the correct outcome.

Therefore I don't have an opinion on this subject either way, in some scenarios you do IPrinter34 and in others IPrinter.

When people talk with strong opinions on code they should probably start by announcing their own applications of it.