
Debunking the duct tape programmer - 8ren
http://jeffreypalermo.com/blog/debunking-the-duct-tape-programmer/
======
sqrt17
The article misses the point that Spolsky makes: some people are smart enough
that they can foresee _where_ the duct tape can be applied (and, by extension,
where it would be catastrophic to do so).

This is, of course, a far cry from the person who does everything with duct
tape, because it's simpler to do so. And it's also a far cry from the person
who always follows his/her standard approach, because nobody ever got fired
for [using the safe-but-costly approach].

In essence, the duct tape programmer has a safety margin between the smartest
he could do, and what he actually does, and uses this safety margin (1) to
make the software actually work, because he can avoid stupid errors, and debug
the subtle issues that come up, and (2) to make the software ship on time. Not
using your most-advanced-yet-poorly-understood techniques does not mean you'd
stick to the stone age approach, but that you're perfectly fine with using
stone age tools in addition to the fancy-schmancy newfangled stuff where it
makes sense.

I, for one, won't Party with Palermo on this. I'm more cautious of people
making their money with agile training than with people selling bug tracking
systems.

~~~
talvisota
I agree with you, but the point is damn well hidden behind one of the
crappiest analogies of all time: using duct tape is an indication that you're
great engineer - but _only_ if you are one of the naturally talented "pretty
boys" who know what they're doing.

------
terra_t
"Analysis Paralysis" often has a root cause: incompetence.

A pal of mine was a consultant for a logistics company serving a large country
that's north of the U.S. This company was developing a package tracking system
in Java, back around 2000 or so, when "Java" was often a synonym for "Project
Failure."

Now, when the whole thing started, I told him that I could knock off a
prototype in a week in PHP. Nope, these guys decided to spend five months
developing a framework for their application, and then they were going to
spend the next month developing the actual app.

Well, six months later, I hear that the predictable outcome had happened:
management was shocked to discover that the application took 30 seconds to
serve up a page view.

My pal sent me a copy of the app and it was an absolute rat's nest: the kind
of project where you use 1500 lines of code to say what you could say in 15.
The sheer bulk of the code made it difficult to maintain: and it had poor
performance written into it's DNA. The real problem was that this wan an IBM
shop that was developing its first webapp, developing its first Java app
and... nobody knew what they were doing.

\-----

Don't get me wrong. There's nothing wrong with front-loading your design and
analysis work... IF YOU KNOW WHAT YOU ARE DOING! In the hands of people who
have a holistic view of the application and toolset it's based on, front-
loading is a beautiful tool that can make implementation and testing a breeze.

However, because it delays feedback, prolonged analysis doesn't (necessarily)
test the ideas behind a design. Bad ideas can get in, and stay in -- nothing
challenges the arrogance of the uninformed.

If, on the other hand, you are humble, and "know what you don't know", a rapid
prototype can be a powerful way to get some experience, test your ideas, and,
who knows, maybe even ship something.

~~~
slantyyz
I would argue a different root cause for "Analysis Paralysis": fear.

Most people who analyze things to death fear making decisions that result in a
mistake (subsequently resulting in job loss). The costlier a decision, the
more likely the paralysis will occur.

And quite often, these people are technically competent.

------
gaius
_never take software advice from a bug tracking system salesman_

Beautiful.

~~~
dirtyaura
Spolsky seems to be a less fashionable idol than he was when I started to
become interested in startups. In the context of programming AND startups, his
opinions have much more weight to me than XP proponents'.

Joel has created a successful company that is apparently fun to work in, have
shipped several working and commercially successful products and made a
service for human-kind by designing and successfully launching programming Q&A
site that doesn't suck. Plus his writings inspired a generation of programmers
to start companies, just like PG's writings did later.

Contrast this with Extreme Programming that OP embraces as a third option
compared to duct tape programming vs analysis-paralysis. I was very excited
about XP when I was young and inexperienced programmer, but nowadays XP sounds
much more snake-oil salesmanship to me than Joel's opinions. Did original XP
gang work in startup like environments, or were they actually solving problems
(payroll systems) that they and many others had already solved? And Kent Beck
seems to be still working on jUnit (and trying to find a way to monetize it),
not shipping new products.

My kudos goes to Joel and duct tape programmers around the world.

~~~
gaius
Joel seems to talk a lot of sense but this is tempered for me by two things.
1) no-one I know uses any of his products and 2) I have a hard time believing
he really is able to attract the top talent to work on a project management
tool written in VB.

~~~
mhp
It's written in ASP.NET, not VB.

~~~
martin
Really? Since when?

<http://www.joelonsoftware.com/items/2006/09/01.html>: "FogBugz is written in
Wasabi, a very advanced, functional-programming dialect of Basic"

<http://www.joelonsoftware.com/items/2006/09/01b.html>: "And since FogBugz
goes back many years and was originally written in VBScript, Wasabi is 100%
backwards-compatible with VBScript." (granted, VB != VBScript)

<http://fogcreek.com/Jobs/Dev.html>: "Today we happen to use Wasabi,
JavaScript, xhtml and CSS, and C++ to build FogBugz"

~~~
mhp
I'm totally wrong. I meant to write .NET (not ASP.NET) and .NET isn't even a
language, so I'm doubly wrong. It's probably been four years since I've
touched the code :\

It isn't written in VB and never was. In 2000 it was written in classic ASP
(vbscript) and c++. Probably a few years after that it was converted to
Wasabi, which at the time was very close to VBScript, but is now equivalent to
C#. For the last few years it is shipped as a .NET product on both windows and
unix, and the /Dev.html page you cited is accurate. (The articles you cited
from four years ago aren't accurate anymore).

<http://xkcd.com/386/>

