

Duct Tape Considered Harmful - markdennehy
http://stochasticgeometry.wordpress.com/2009/09/25/duct-tape-considered-harmful/

======
tptacek
I have a bad feeling that this Spolsky post --- which I liked, for what it's
worth --- is going to spark a very long, very boring testing vs. shipping
controversy, in which both sides, by taking sides, are going to come off
grating and sanctimonius.

~~~
wastedbrains
I agree and I find that the people who are architecture astronauts as he
refers to them, are very vocal and active on forums, twitter, and blogging.

I don't want to get into the whole testing debate, but I think you can read
the whole article and remove the one point on testing and it still holds.

------
daleharvey
What I took from Spolsky article wasnt that you shouldn't touch X/Y/Z, but
that you should approach new code in the simplest and quickest way you can.

I have often been guilty over engineering things to do them the "right way",
to either end up throwing the feature out anyway or having to reengineer
because I didnt know enough about the problem to fulfill its design from the
outset anyway.

while prototype fast is a reasonably mundane point, Its still one we get wrong
time and time again, and I think programmers pay lip service to it as an
ideal, but when it comes to actually having to leave that nasty bit of code
alone because it does its job, too often we go down the wrong path of making
it "right"

~~~
steamer25
"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil." \--Knuth

------
aarongough
I have a friend who develops OpenGL drivers in C for various aerospace uses
and his perspective on code quality was very interesting to hear.

As a web-developer I used to think of tests as frivolous wastes of time,
whereas he saw them as an essential and necessary part of the development
process.

Since I started implementing testing on all my projects I have noticed that my
ability to change the code has actually gone _up_ , which in in stark contrast
with my initial expectations. I think that having a sounds testing methodology
definitely has benefits even in cases where financial/life loss due to
software failure is an impossibility...

~~~
ajross
But the point was that the decision interacts with the market, though.
Obviously testing is good and omitting testing completely is bad. But at the
end of the day the someone or something needs to _pay_ for the software.
Software vendors that ship late due to elaborate design and testing regimes
get paid less, in practice, than the "duct tape" folks who beat them to
market.

The video drivers you mention are a good example: an aerospace customer is
almost certainly operating on a slower schedule, and probably has contracted
the revenue already. The value of time to market here is less. And of course
the value of code quality in a vehicle safety application is much higher than
it is in a consumer web app.

So I'm not surprised at all that sane and smart people would make different
testing decisions in the two regimes. They're _both_ right.

~~~
markdennehy
"The market" was the motive behind the Ford Pinto memo as well, wasn't it?

~~~
eugenejen
When I was a child, my father got the Pinto. even though it is a unsafe car as
we knew later. But in a then poor Taiwan, it is like a luxury and it helped
him to do his job.

Here is an argument against Ford Pinto case
[http://www.pointoflaw.com/articles/The_Myth_of_the_Ford_Pint...](http://www.pointoflaw.com/articles/The_Myth_of_the_Ford_Pinto_Case.pdf)

~~~
markdennehy
I wrote "the ford pinto memo", not "the ford pinto".

The point wasn't whether the car was okay, it was about the amoral behaviour
of the company. Ford crossed a line between wanting to produce something to a
given spec; and depraved indifference to the damage the errors in the design
would cause. It only sounds like a subtle difference.

~~~
eugenejen
Please read the article about the myth. The memo is not specially evil. Its
decision is based on NHTSA. The company and the government agency are pretty
rational. But it just tells us even we are rational, the complexity of the
world is much more unpredictable.

Companies and governments should be amoral but rational. otherwise church and
state will not be able to separated from each other. To me, moralistic
companies/governments do more harm than welfare to humanity.

------
raganwald
“Considered Harmful” Essays Considered Harmful:

<http://meyerweb.com/eric/comment/chech.html>

------
wglb
Let's take a step back here. Joel's blog entry was about ONE chapter in Codes
at Work. If the anti-duct bloggers were to read the entire book, they would
see that TDD, C++, templates, pattern fever, OO oration, IDEs--don't get much
credibility with the whole lot of them.

But there are self-interest forces at work in arguing against the duct-tape
arguments--advocates of patterns, tdd and so on.

Two parties in this argument here have shipped real software in crunch mode.
Perhaps others in this argument have not.

~~~
plinkplonk
"Two parties in this argument here have shipped real software in crunch mode.
Perhaps others in this argument have not."

This is a key point. Agile methodology vendors who wax loudest about TDD and
other "core practices" have never shipped any significant software [1]. None
of them ever built a software product or a startup. Neither do they _show_ us
any decent body of code written with their superior approach [2] (vs talk
interminable about how _our_ code will be better if we adopt their advice and
pay them the big consulting $$).

After all the book is about _Coders_ At Work, not "Methodology Vendors at
Work" (which might be an interesting book, in a very horrific fashion).

[1] How many of the creators of the Agile Manifesto have shipped any
significant software or built a software company? Most (All?) of them are
methodology consultants.

[2] Kent beck has JUnit. Robert Martin has Finesse. The rest of the agile
gurus don't have anything. I leave it to the readers to decide if JUnit and
Finesse are significantly superior, designwise, to other Open Source code
bases, written without TDD.

~~~
ZeroGravitas
You don't actually say that no _real developers_ use TDD, but you seem to
imply that by focusing on the fact that the teachers, authors, consultants and
trainers that promote it "loudest" are earning money via the teaching,
authoring, consulting and training in which they loudly promote it. Bit of a
catch-22 there, no? Since if their job involves communication about
programming topics you automatically ignore the message and you'll only listen
to those not trying to communicate.

Luckily, I just finished reading this article by one of the Twisted guys in
relation to the recent release of Tornado which, in passing, sings the praises
of TDD, basically calling it essential for the work they do:
[http://glyph.twistedmatrix.com/2009/09/diesel-case-study-
in-...](http://glyph.twistedmatrix.com/2009/09/diesel-case-study-in-that-
thing-i-just_24.html)

~~~
plinkplonk
"You don't actually say that no real developers use TDD, but you seem to imply
that by focusing on the fact that the teachers, authors, consultants and
trainers that promote it "loudest" are earning money via the teaching,
authoring, consulting and training in which they loudly promote it."

No that isn't what I am saying. I am saying many of these people have _no_
programming experience worth a damn. If someone were to tell me how to
program(which is what all these methodology sellers do), they would be much
more credible if they actually had the programming chops to back it up.

Musashi writing a book on swordsmanship is one thing. If I (who couldn't wield
a samurai sword to save his life) write a book that claims my "style" of
swordsmanship is better than anything all the others existent today, I
shouldn't be surprised if practicing swordsmen don't pay me much heed.

It is the juxtaposition of people with no demonstrated/demonstrable
programming skills being loud and obnoxious about the superiority of their
advice about programming which I pointed to.

I was also careful to distinguish between Beck and Martin (who at least walk
the walk by putting out code developed using the methods they preach) from the
other more "all hat no cattle" folks like Jeffries. so to answer your
question,

"Bit of a catch-22 there, no? "

No, Not at all. :-). I don't have any problems with people telling me how to
program. But I don't trust people who _demonstrate convincingly that they know
nothing about programming_ (like Ron Jeffries does with his Sudoku code) who
also claim to be "masters" of programming.

That would be like trying to learn fighting skills from a martial arts
"master" you saw getting bashed around by a couple of punks at the bar last
night, and ended up being taken to hospital and is still covered with bandages
and walks with a limp! A master who wins fights would be much more convincing
if he claimed he discovered a new martial art which makes existing ones
obsolete.

I explicitly said

"None of them ever built a software product or a startup. Neither do they show
us any decent body of code written with their superior approach (vs talk
interminably about how _our_ code will be better if we adopt their advice and
pay them the big consulting $$)."

I stand by this. These guys write books that are the programming equivalent of
"Who Moved My Cheese"?. "Coders at Work" otoh, focusses on people who actually
_are_ great programmers. Each interview contains more wisdom on programming
than reams of "agile" (and these days "lean") textbooks.

FWIW, I did TDD almost exclusively for three years (when I worked at
ThoughtWorks), but I don't do TDD anymore, though I still have unit tests.

~~~
ZeroGravitas
It still seems excessively _ad hominem_ to me.

I don't know about the specific people named in swordmanship but generally in
sport the best teachers, coaches and managers will not necessarily be the best
at the actual sport. Maybe that doesn't apply in the martial arts though.

And that's at the top level. For ordinary folks I'd suggest that the advice
given by a legend may be inspirational, but that pragmatic advice from a
standard teacher which is aimed at their level (e.g. "walk away from bar
fights if at all possible") may be more appropriate. So I have no problem with
methodology suggestions provided by the less than _leet_.

Also, your reply suggests you unit test, you just don't write the tests first.
Which means, compared with the average programmer, you're like Greenpeace
complaining about PETA and while you see a big difference the 'average' person
just lumps you in together under the general heading of "extremist weirdos".

~~~
plinkplonk
"It still seems excessively ad hominem to me."

Fair Enough. You have a right to form your own opinions. Asking for proof of
competence is not "ad hominem", especially in a context where that competence
is what is under discussion. But yeah,, whatever.

I think most agile guru can't code for nuts. If you have difference of
opinion, _show me_ some great code these agile gurus wrote that in your
opinion gives them the "level" to teach us how to code. Or a wildly successful
project they managed(No the original XP project at Chrysler that failed
doesn't count! ;-)) to the point they can give us the rest of us lessons.

"So I have no problem with methodology suggestions provided by the less than
leet."

I don't either. But I _do_ have problems with people who can't put one foot in
front of the other _masquerading_ as martial arts teachers. A teacher should
know _something_ beyond the students they purport to teach.

Shifting form martial arts to music, If someone doesn't know how to string a
guitar and sets himself up as a "master guitarist" , should we all
automatically respect him as a maestro just because he _calls_ himself one?

Programming like music depends on quality of the _output_ , not what title is
on a visiting card. if someone can't sing "Jingle Bells" in tune, he is hardly
a "musician" no matter what he calls himself or how much he
blogs/tweets/writes self promoting pamphlets. Likewise for the programmatic
equivalent of what (agile "guru" Ron Jeffries's attempts at TDDIng a Sudoku
solver are. Please do a web search for "Ron Jeffries Sudoku Norvig" for the
gory details).

A master musician is someone who can _play_ very well. A music teacher should
play _much_ better than the untrained/untalented, if not at superhuman levels.
There is a minimu,m bar of performance where it is criminal to let such a
person "teach".

" your reply suggests you unit test, you just don't write the tests first."

I use what works.

But your vague Green peace/PETA analogy doesn't hold. You have your history
mixed up.

You imply that anyone who uses unit tests is different from a an Agile Kool
Aid drinking, propaganda spouting full time TDDer only as matter of degree. So
Unit tests = agile to some degree !

Yeah Right :-).

Unit (and other) tests were used _much_ before the agile weirdos came on the
scene and blew it up into some ultimate design method (which I don't believe
in - I've stated what I believe in - I think the Agile movement is _largely_
inhabited and sustained by consultants and "scrum masters" and people who
write books but no/very bad code.).

Using unit tests is not supporting Agile/XP/whatever. Drawing an occasional
UML ish diagram on the whiteboard doesn't mean you support the RUP methodology
salesmen.

FYI. I am done with this thread. I have no intention of going back and forth
with you on a long and tedious thread. The PlinkPonk Thread Depth Alarm just
went off. If you are really interested in discussing this offline, my email is
in my profile. Else, well met and have a great day.

------
gfodor
The amount of false dichotomies and developer stereotypes Spolsky and Atwood
manage to get spewed from ordinarily calm and logical people is astounding.

