
The Duct Tape Programmer (Response from Uncle Bob Martin) - johns
http://blog.objectmentor.com/articles/2009/09/24/the-duct-tape-programmer
======
gfodor
All of these types of arguments are at the wrong level of abstraction.

I've found that what makes the best programmer is not if they are a "duct
tape" programmer or a "architecture astronaut" or whatever, but _self
awareness_. They can call a hack a hack, and understand it's impact. They know
when and _how_ architecture can be improved, and when it _should_ be improved.
They can take criticism of their work because odds are, the criticism is
something they already had an understanding of and can justify, or if not,
they are willing to see where there was a gap in their thinking. They have a
plan, and can forge a system ahead in a general direction of progress without
getting bogged down in the details or taking one step forward and two steps
back. You get the idea.

Nobody is talking about this, arguments generally deteriorate where someone
sets up a false dichotomy and then the internet collectively rips them apart.
But they get ripped apart because of the falseness of the dichotomy, not
because of the fact that they are looking at the wrong things altogether.

~~~
j_baker
I think this is just an example of Parkinson's Law of Triviality:
<http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality>

------
tristan_juricek
The same feeling hit me when reading this: the spirit of the oringal "Duct
Tape" blog was right, but the specifics kind of overgeneralized. What I took
away: most programmers don't have a sense of perspective on the products
they're building - to most of us, it's more software then product.

My nutshell analogy in Joel-speak: "software perspective is to architecture
astronaut as product perspective is to duct tape programmer".

The dangerous path you get on is "always shipping" without paying attention to
what maintenance means. Of course, this only matters to a Real Business - you
know, places that make money instead of burning it. But I find that there is a
breaking point where all that code rushed out of the door starts to cost ya.
And yeah, you might have to consider a revision, perhaps even adding fancy
things like unit tests to figure out what the hell is breaking, or a template
to reduce the code base size, whatever.

But even in maintenance mode, the perspective still doesn't change. It should
be about making a good product (lowering maintenance costs to speed up new
development) instead of "the right way to build software".

~~~
dasil003
Yeah, Joel is definitely, definitely wrong about unit tests. Not in the
TDD/BDD/Agile koolaid kind of way, but in terms of ancillary tools, automated
testing in general could only be second to version control for what it does to
long term productivity.

 _the dangerous path you get on is "always shipping" without paying attention
to what maintenance means_

The Joel article glosses over this too much. Why? Because this is what the
unwashed masses of programmer wannabes attempt to do all day every day. You
know these people, the ones that just have no business being programmers. In
other industries there are standards, credentials and transparent performance
evaluations that prevent people like this from even getting hired. Yet in the
programming industry they make up a disturbing percentage of the work force.
That's one extreme--the most common one.

Joel is more focused on the architecture astronauts who need code to be a
little too elegant. I know first hand that these kinds of people can really
damage your ability to ship a product if given too much control, but I think
it's wrong to draw a distinction and favor a "duct-tape programmer". First,
because most of these people probably have the capacity to ship amazing stuff
with a little guidance and the occasional reality check from more "duct-tapey"
colleagues. Second, because these guys push forward the state of the art. They
often see the big architecture picture in a way that others don't. They may
waste a lot of time by short-term metrics, but their work is the only kind
that eventually leads to long-term dividends. Occasionally some of them may be
so obsessive compulsive that they just can't be forced to ship. Fine, they
should go get Ph.Ds and do great things in academia, but they're still
infinitely more valuable than the people who don't even really grok
programming.

~~~
holygoat
"in terms of ancillary tools, automated testing in general could only be
second to version control for what it does to long term productivity."

His whole point is that _short-term_ productivity is sometimes more important.
No point building a product that'll be easy for you to extend in the future if
you don't build it quick enough to _have_ a future.

~~~
dasil003
_My_ whole point is that short-term productivity doesn't need an advocate. If
you're literally going to die then sure, go ahead and throw the hail mary.
However in the vast majority of cases the future becomes the present quicker
than anyone foresaw and then you find out that 20% time savings has now put
you in a position where _all_ future development is 50% more expensive, at
which point you either (possibly) scored an amazing victory or you (more
likely) handed yourself a crippling setback. You know, sort of like the
situation that presumably led to the rewrite of Mozilla.

------
mikedouglas
Uncle Bob seems to be confusing spirit with conclusion. JWZ and Joel are
arguing against "[using complex technologies] for their benefits", where
simpler tech would suffice. When you're designing a browser, C++ and
multithreading do have benefits, but "Duct Tape Programmers" would argue that
they aren't worth the design overhead when you're facing a tight deadline.

Same with COM, unit tests, design patterns, etc. Obviously, Joel doesn't
believe these have no benefits and that they're only used because they're
cool. He doesn't endorse them because he doesn't believe they are worth it.

It's fine if you disagree with the duct tape mindset, but don't construct
strawmen to show "we all really agree".

~~~
branden
I think the problem with Joel's post is that you have to read between the
lines to understand what he's advocating. He knows that a strong voice makes
for a more compelling blog, but that caused his message of balance and
tradeoffs to get muddled. As a programmer who can engineer to a fault, I found
Uncle Bob's post much more useful.

~~~
mikedouglas
I'm not sure. Uncle Bob's post came off as so reasonable and moderate that I
have trouble applying it to any practical situation. Joel's post drew
conclusions I don't agree with (redesigning to add multithreading after the
first release seems like classic 'second system syndrome'), but at least I had
a fairly good idea of the personality he was describing.

------
trunnell
I hate the epithet "architecture astronauts." It smacks of anti-
intellectualism. We wouldn't say the same thing about actual architects: we
would never deride Frank Gehry for building the
<http://www.guggenheim.org/bilbao> saying, "wow what a waste of time, why
didn't he just duct tape it... he would have finished sooner!" Physical
architecture is about function as well as form; the Bilbao Guggenheim is not
just a work of art, it's a highly functional building. Software architecture
is similar in that better designs are more functional, more easily understood,
and more easily maintained.

Not everyone is Frank Gehry, but working architects can learn from him just as
we working programmers can learn from Bob Martin.

~~~
bkovitz
I would deride Frank Gehry. I've only been to one of his buildings, but it
struck me as gratuitously zany: a very expensive and confusing way to do what
could have been done better with a good ol' roughly rectangular box.

Many of those classic rectangularish buildings are beautiful. Their beauty is
not the kind that stuns you for a week and then becomes annoying. It's the
kind that is comfortable to be around, and you appreciate more and more as you
spend years living with it.

~~~
abalashov
A particular _instance_ of Frank Gehry's work may not meet your approval, but
would you go so far as to condemn the _methodology_ of the sort of thing that
is Frank Gehry's craft? The motives? The pursuit?

~~~
bkovitz
With considerable uncertainty because I haven't spent much time with his
buildings (maybe there is an "aha!" moment waiting for me), yes. The motive
appears to be, "How pointlessly weird can I get?" Part of the method seems to
be, "Let's make this EXPENSIVE."

~~~
trunnell
_I would deride Frank Gehry... The motive appears to be, "How pointlessly
weird can I get?"_

I'm sorry you don't like Frank Gehry. But surely you're not saying,
categorically, that software architecture is pointless?

I'm making that point that there may be good design or bad design, but we
should not characterize _design itself_ as harmful-- which is what is implied
by pitting "duct tapers" against "architecture astronauts."

~~~
bkovitz
_But surely you're not saying, categorically, that software architecture is
pointless?_

Not at all, only that Frank Gehry might be a poor analogy to enlighten people
about the value of software architecture and design. "Duct tapers good" vs.
"architecture astronauts bad" is surely a false dichotomy and a horrible
analysis of the situation. Here's an example that might shed better light on
the real situation: Microsoft is crawling with duct tapers, and Apple takes
design seriously. Microsoft is much wealthier, but I prefer to use Apple
products, and I wouldn't want to work at Microsoft.

------
andreyf
_As for Joel’s consistent dismissal of unit testing, he’s just wrong about
that. Unit testing (done TDD style) does not slow you down, it speeds you up._

This seems logically impossible. Maybe I'm misunderstanding TDD, but at the
heart of it, TDD seems to suggest you:

1) Give instructions that describe how to check the instructions you're about
to give are correct

2) Give instructions

This is _not_ the right solution to the problem "I'm unable to give the
computer the instructions I intend". At the very fundamental level, it clashes
with DRY, and is only effective if you're very uncertain in your ability to do
(2). The right solution is improving your ability to do (2) - by creating
better abstractions and metaphors, not by repeating yourself.

~~~
kscaldef
Ah, yes, the "I don't have to write tests because I'm perfect" school of
programming.

1) You aren't perfect.

2) Your coworkers aren't perfect.

3) Your "abstractions" are still code that can have errors in it

Also, you are misunderstanding the argument that TDD speeds you up. Yes, at
the micro level it may take a bit more time. But, as the system grows, your
ability to add or change functionality without breaking things increases when
you have tests to verify that it is still correct. (Also, automated testing is
much, much faster than manual testing.)

~~~
wvenable
_But, as the system grows, your ability to add or change functionality without
breaking things_

I disagree unless all your changes are really shallow. You change the
structure of your application in significant ways and you'll break the tests
too. So now you have two problems.

~~~
Periodic
The code and the tests go together. You don't just make a pile of code, and a
pile of tests, and hope they all go together right.

You have some big tests that are general and test that all the components work
together, but for each component you have lots of little tests, and if you are
going to change the component you change the tests FIRST. That's TDD.

You deliberately break the tests before you change one line of the actual
code.

~~~
wvenable
See, I think the value in tests would be that they are reusable. If you're
smart enough to write a test for a situation, then you're smart enough to code
for that situation in the first place (and conversely if you miss an edge case
in code, you're just as likely to miss an edge case in testing). If you're
constantly rewriting your tests -- what's the gain?

Now certainly writing everything twice is actually a great way to catch
errors. NASA does that with the shuttle. But I wouldn't argue that its faster.

I prefer to just liberally sprinkle my code with run-time assertions. We have
a small defect rate even after pushing out massive structural changes to the
application. The bugs that we do have tend to involve an unpredictable set of
conditions that no automated test would ever be written to find.

------
wglb
Well, perhaps uncle Bob should read not only Joel's column but also Peter's
book. JWZ is not alone in that book (Coders at Work) about not using fancy
stuff. C++ gets a pretty universal smackdown from all there. In fact, one of
the hackers there preferentially codes in assembly, because C is not close
enough to the machine.

There are many nuggets there about IDE, unit testing, proof of program
correctness, literate programming, design patterns. My reading of the book is
that if your gig is agile or TDD or templates, you will have a cold audience
in those coders. Even if you bring it on with attitude.

~~~
coliveira
JWZ says that one of his methods to smell bad developers is finding if they
are too excited about C++ and templates.

------
lacker
_Unit testing (done TDD style) does not slow you down, it speeds you up._

I do a lot of unit testing myself, but I know many programmers for whom unit
testing does slow them down. Some people get so caught up in unit testing and
refactoring for better testability that they either get nothing done. And some
people do it wrong, test for extremely specific behavior, and their code
becomes impossible to change. I have also known people that try TDD but end up
failing to write code that they know how to write but they don't know how to
test. It is not a panacea. You have to "do it right".

Contrast that with something like source control. It is hard to waste tons of
time on source control that you could have saved if you just didn't use source
control. It is fairly easy for even the most incompetent programmers to use
source control.

------
astine
It's better to ship shit than not at all, but it's better to ship late than to
ship shit. The problem is that if you ship too late, you don't ship at all.

~~~
rm-rf
I've been on the 'shipped shit' side of applications a couple times. Ten's of
thousands of customers and a shiny new app that could only be described as
shit.

I'd have rather had the product late.

~~~
holygoat
But would the customer?

------
sutro
Look at the surrounding website. What is being sold by Object Mentor?
Training, consulting, books, advice. Not software.

~~~
bkovitz
How could anyone upmod that? It's pure _ad hominem._

~~~
holygoat
No it's not. It's an instance of "cui bono", and skepticism about credentials.

~~~
thrdOriginal
The comment can be read as "you're just saying that because you sell training,
consulting, books, and advice, not software." Which absolutely has nothing
constructive or destructive to say about the merits of Uncle Bob's argument.
Looks like an ad hominem to me.

------
ardit33
"As for Joel’s consistent dismissal of unit testing, he’s just wrong about
that. Unit testing (done TDD style) does not slow you down, it speeds you up.
One day I hope Joel eventually realizes this. "

Bullshit. I call TDD more like "insecurity driven development". Perfect fit
for big corps, where mistakes are punished, and being fast is not really
rewarded. *hence the myriad of processes to do even simple check-ins.

There is much better ways to deal with it: 1\. Design interfaces, that
implement the features you think you need. That's like the outline of your
essay.

2\. Have classes that implement them (put all messy code there). Write your
essay.

3\. Do some functionality testing on the features that are important, and can
reasonable be measured (.ie. no functionality testing/unit testing in UI
stuff). And make sure you use it. Unit test may catch only some stuff. Proof
read it.

From my experience in my previous startups, If you have to ship in three
weeks, unit testing is the very first thing that gets tossed out of the
window.

At the end of the day, who cares if your product has few bugs. You got to ship
something. And I am saying this from experience, where a product I worked is
being used by over 2million of people. Buggy? Oh yes. Did the bugs kill the
overrall experience, i don't think so. If we had missed that deadline, there
was huge financial ramification for the company (apart 10s millions of
dollars, it was a relationship breaker with the main client). We took our time
to fix some of those bugs on subsequent releases.

If we had to do TDD, we probably would have never get done in time. Sure we
might have found and fixed some of the bug earlier, but none of those bugs
were detriment to the whole experience anyways.

The only time you really should care to test about even the most minuscule
feature, is if you are doing some highly financial/sensitive stuff. Most
starts are not in that field anyways.

~~~
johnb
"insecurity driven development" is probably a good alternate title for TDD,
but instead of taking it at it's trollish face value it can generate a good
analogy.

If you start walking down a dark alley - you start feeling insecure. You've
got a few options from that point.

You can back out of the alley and hey, no more insecurity. A little
embarrassing but you're feeling OK, you just have to go the long way round the
block.

You can push on through the alley in the dark - something bad could happen or
you could get through fine. You don't really know until you've popped out the
other side.

Or you could carry a god-damned torch. Obviously when carrying a torch, you
don't have it turned on all the time, just when you wander into darker areas
where you're less sure of the environment. It lets you walk at full pace
without stubbing your toe or getting mugged or whatever.

In more concrete terms: I'm a bit of a poor-weather TDDer (same with pair
programming) If i start working on something that could be algorithmically
challenging, cuts across multiple layers of our app, touches something scary
(like our accounting code, because i don't want to lose any of our $$$), or am
just plain stumped - I write a test. It fails. I make it pass. I write the
next. I make it pass. I realise my code looks like ass, I refactor. The tests
still pass.

I can give an actual example from this week. Our app is a large RoR app that
serves multiple sites from the one codebase based on an internal DSL we have.
We're in the final week of a must launch redesign (date was set because of a
bunch of marketing, etc) and I get an urgent and large last minute change
dropped on my desk (i'm sure you all know that feeling). I'll admit my first
move wasn't to go TDD, I just went for the quick and hopeful move of quickly
adding some code that looks like it should work to our DSL.

It didn't. So my very next move, knowing that I have a deadline I must hit
with a risky technical change, was to start writing tests. If i hadn't, I'd
have to be verifying my code works by checking around 3 different pages after
a server restart which is both slow and 4 layers away from the changes. So it
was faster in real time.

I'm not a big fan of TDD zealots, TDD is just another tool in the box. But TDD
haters really get my goat. You're willfully shutting yourself out of a tool
that can make your life easier, and help deliver code faster.

~~~
gnaritas
You're right, it's weird how people don't understand, don't write the kind of
tests that slow you down; write the kind that help you work faster by
automating the manual testing you'd be doing otherwise. Test things that you
think might break, or you want to make sure won't break and skip testing the
dead simple stuff where you feel it'd be a waste of time. You don't have to
test everything. Seriously, if some strategically written automated tests
don't speed you up, you're doing something wrong.

------
simplegeek
I don't use Visual Studio for work but I've used it for some side projects.
What's wrong with that? Not sure why author doesn't like it. Agree with rest
of the article though, to extent.

~~~
middus
He seems to be more of a UNIX kind of guy.

------
marcofloriano
I disagree with his post. Maybe this kind of approach works for employees ...
but when you are an entrepreneur and need to get the think done real fast not
because your boss is asking but because if dont do that you are dead ... the
Joel approach is much more realistic.

At this scenario, the idea "Be smart. Be clean. Be simple. Ship! And keep a
small roll of duct tape at the ready, and don’t be afraid to use it." is just
impossible. You have to choose and you have to choose really fast.

------
tptacek
Can I ask, not to make a point but because I genuinely don't know, what
software Uncle Bob Martin has shipped? What products has he worked on?

~~~
plinkplonk
"Can I ask, not to make a point but because I genuinely don't know, what
software Uncle Bob Martin has shipped? What products has he worked on?"

AFAIK, he is the chief maintainer of Fitnesse. It is not particularly ground
breaking code, and is by no means an epitome of design brilliance. That said,
at least he walks the walk and puts some code out there (like Kent Beck
[junit] and unlike the rest of the agile "gurus". )

Most of the agile "gurus" can't code for nuts(e.g: Ron Jeffries's "Sudoku
Solver" attempt is a public example of how _not_ to use TDD, as is his book on
TDD ing which is full of pious agile homilies and terrible code).

It is instructive to make a list of the initiators of the Agile Manifesto and
try to find some code written by them so we can judge their skills. Mostly
crickets chirping.

~~~
tptacek
I had no idea that there were famous "TDD-ers" or "Agile-ers" that were
infamous for not being able to code at all. I just don't keep track of this
stuff that closely. Thanks!

------
trunnell
Simplicity often follows good design.

Duct taping seems to be at odds with simplicity. Joel's advice to just duct
tape it would lead to crappy, unmaintainable code just as often as over-design
would.

------
itistoday
If you're wondering whether either party in this discussion has any new
insights or ideas to share that you haven't heard of before, do yourself a
favor and completely ignore all of this masturbation.

Here, I'll summarize the conversation:

"Quit dicking around and ship!" "Sure, but you don't want me to ship shit!"
"C++ sucks!" "C++ sucks, but sometimes it's a necessary evil!"

There, saved you an hour.

------
ilyak
Joel's point wasn't that some programmers aren't smart enough to use C++ plus
COM plus multithreading.

He just said that humans aren't smart enough. They, however, might think that
they are. Which is sad.

------
davidmabe
_In Joel Spolsky’s recent blog he talks about "Duct Tape Programmers"._

I'm not sure I trust anyone that doesn't know the difference between a "blog"
and a "post".

