Debunking the duct tape programmer(jeffreypalermo.com)
jeffreypalermo.com
Debunking the duct tape programmer
http://jeffreypalermo.com/blog/debunking-the-duct-tape-programmer/
3 comments
"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.
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.
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.
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.
never take software advice from a bug tracking system salesman
Beautiful.
Beautiful.
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.
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.
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.
1
I have used and paid to use Fogbugz. I've used JIRA as well, and I would choose Fogbugz over JIRA any day, despite the silly name. Since I've gone independent, I use the free version of hosted Fogbugz (Fog Creek is kind enough to offer it for free for independents and startups).
--edit it's free for students too
2 I'm of the opinion that truly top talent doesn't care about the language. It's the programming problems they care about. Fogbugz does some non trivial stuff like evidence based scheduling. I'm sure some top programmers would find that interesting, regardless of whether it's programmed in a vb-like syntax or not.
Having said that, Joel says a lot of things, some of it makes sense and some of it doesn't. It's the Internet. Opinions are plentiful, and we're all free to agree or disagree.
--edit it's free for students too
2 I'm of the opinion that truly top talent doesn't care about the language. It's the programming problems they care about. Fogbugz does some non trivial stuff like evidence based scheduling. I'm sure some top programmers would find that interesting, regardless of whether it's programmed in a vb-like syntax or not.
Having said that, Joel says a lot of things, some of it makes sense and some of it doesn't. It's the Internet. Opinions are plentiful, and we're all free to agree or disagree.
It's written in ASP.NET, not VB.
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"
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"
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/
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/
I love that first article; after many paragraphs extolling the "safe" choices, at the end he casually slips in that he's actually using a language that no-one else in the world is.
Nevertheless, Wasabi is to VB as Arc is to Lisp.
Nevertheless, Wasabi is to VB as Arc is to Lisp.
Why is this a valid rebuttal?
I don't agree with everything Joel says, and I definitely find the StackExchange marketing approach flawed at best, but I've been using Fogbugz for quite some time, and it is far from being horrible software. I would take it over JIRA any day.
Yes, Joel is an Internet brand. His blog entries are designed to get eyeballs by being opinionated. But he does have a legitimate development background. You can't dismiss his opinion outright because he sells bug tracking software.
I don't agree with everything Joel says, and I definitely find the StackExchange marketing approach flawed at best, but I've been using Fogbugz for quite some time, and it is far from being horrible software. I would take it over JIRA any day.
Yes, Joel is an Internet brand. His blog entries are designed to get eyeballs by being opinionated. But he does have a legitimate development background. You can't dismiss his opinion outright because he sells bug tracking software.
I immediately found the quote "never take software advice from a bug tracking system salesman" an ad-hominem attack. It doesn't address at all why the advice would be bad.
I imagine he's trying to suggest it is in Joel's best interest for people to have buggy code so he can sell more bug tracking software. It doesn't sound like a very good argument, but I think it's supposed to be a joke.
yes, it is a joke. and a teeny-tiny bite of prophecy.
and, by the way, the tweet is correct, i had said it before. http://twitter.com/mhinze/status/2485789965 - months before this brouhaha.
and, by the way, the tweet is correct, i had said it before. http://twitter.com/mhinze/status/2485789965 - months before this brouhaha.
It is not an attack towards person. It simply points that a guy selling bug tracking system makes his living from people having bugs in their software.
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.