Debunking the duct tape programmer
-
I think the pragmatic programmer uses a little of both as circumstances dictate. To extoll the virtues of one over the other is to miss the point of real-world programming: all coding is a compromise between the shiny promise of perfectly architected code and something simple and robust that works well but might well be sneered at by design pattern afficionados and the like. There are too many pointless pissing contests in the software world: ignore them and just try to be the most professional and pragmatic programmer you can be in whatever language/technology you choose to make a living from.
digital man wrote:
all coding is a compromise between the shiny promise of perfectly architected code and something simple and robust that works well but might well be sneered at by design pattern afficionados and the like.
In fact, my ideal is much closer to "something simple and robust that works" than "the shiny promise of perfectly architected code" (whatever that means). But duct-tape programming is exactly the opposite of "robust" and that's my main issue with it.
-
The problem I have with both the pro- and con- factions is that there is a dearth of real-world examples. For example, I have no idea what a "sound organizational method" is. What is the antithesis of "sound organizational method"? Is it spaghetti code? As a contractor I've had to use a fair amount of duct tape, because by the time I'm hired the project is already in trouble. Why would the client hire me if everything was peachy? Is there "good" duct tape programming and "bad" duct tape programming, like cholesterol?
Best wishes, Hans
Hans Dietrich wrote:
sound organizational method
Silent Organizational Methods. Like, Perl Ninjas.
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist -
Among the numerous responses to the Joel's controversial text[^], I like this one[^] the best. Some quotes: "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" And a more serious one that IMHO sums it up: "The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms. This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method."
IMO the main problem with duct tape programmers is that we have to many bad ones of them, and they'll use Joel as an excuse. Maybe Joels hiring policies work as advertised indeed, and he never worked with people bad at programming.
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist -
stephen.hazel wrote:
He's just sayin' to not go overboard with complexity
"Duct tape" is not about avoiding complexity, it is about cutting corners. If you copy and paste a chunk of code rather than refactoring it into a separate function, you are applying a "duct tape" solution and it is not simpler than doing the right thing, just messier.
If I wanted to argue, I'd say that duct tape is not a well defined term. But, I've been of your opinion on about 97% of your posts. Threads and c++ are DEFINITELY worthwhile sometimes. Eh, I've got code to write (and, fortunately for me, no shipping dates I'm missin at the moment)
-
Among the numerous responses to the Joel's controversial text[^], I like this one[^] the best. Some quotes: "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" And a more serious one that IMHO sums it up: "The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms. This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method."
Tempted as I am to pay attention to someone who uses the phrase "analysis paralysis" four times in the course of a brief article, I think he's missing the point. Tack on all the caveats you want, but there exist situations in which a quick and dirty solution is not a bad idea. That was the point of the original article; if someone's overengineering something, it's time to restore the balance.
-
Nemanja Trifunovic wrote:
"Duct tape" is not about avoiding complexity, it is about cutting corners.
No, it's not. You and many others seem to have based an entire rebuttal on the term "duct tape" without actually reading the article.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
John C wrote:
You and many others seem to have based an entire rebuttal on the term "duct tape" without actually reading the article.
Doesn't say much for the metaphor then... ;-)
-
Among the numerous responses to the Joel's controversial text[^], I like this one[^] the best. Some quotes: "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" And a more serious one that IMHO sums it up: "The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms. This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method."
Gaaaaah! :omg: Are we still paying attention to this stuff? :doh: The guy who wrote the article is a manager, not a programmer. And he used as an example code written in 1994 for Netscape; when C++ was a new language, Java didn't exist and refactoring and unit tests where mostly unknown! Can we move to the 21st century, please?
Of all forms of sexual aberration, the most unnatural is abstinence.
-
Russ-T wrote:
I seem to recall that Netscape, for as long as I was using it, was a big steaming pile of crap. Coincidence?
Worse than that - the code base became so messy they had to rewrite it from scratch - that's how Firefox was born.
Nemanja Trifunovic wrote:
they had to rewrite it from scratch
They were lucky: "Some of the best computer programs ever written owe much of their success to the fact that all the work was unintentionally lost, at about this stage [Reexamination, after first working program], and the authors were forced to begin again". -- Donald E. Knuth, The Art of Computer Programming :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
True. However no one craps on McGuyver for doing the same thing. :)
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
No one blows up more stuff that programmers...it's just not as exciting. We need a visual studio plugin to "zazz" up exceptions. :)
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
No one blows up more stuff that programmers...it's just not as exciting. We need a visual studio plugin to "zazz" up exceptions. :)
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
-
I think the Duct Tape essay raises a few good points, but I do have some problems with it. The two that leap out are: It’s great to rewrite you code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products. Yes, granted, you're here to ship products. However, if your code isn't clear and maintainable then you really are just making a rod for your own back and not helping anyone at all! Zawinski didn’t do many unit tests. ... "If there’s no unit test the customer isn’t going to complain about that." Remember, before you freak out, that Zawinski was at Netscape when they were changing the world. I seem to recall that Netscape, for as long as I was using it, was a big steaming pile of crap. Coincidence? ;P PS I love the photo[^] in the Debunking essay :laugh:
Russ-T wrote:
Yes, granted, you're here to ship products. However, if your code isn't clear and maintainable then you really are just making a rod for your own back and not helping anyone at all!
You are exactly right. Consider though if the choices available are A) make a rod for your own back or b) not ship a product, have no customers and consequently run out of money and have no food. I'd choose option A every time. That to me is what it comes down to. There is no answer that is always right, it always comes down to the circumstances of the business at the time.
-
Among the numerous responses to the Joel's controversial text[^], I like this one[^] the best. Some quotes: "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" And a more serious one that IMHO sums it up: "The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms. This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method."
Hi Nemanja, It seems like "poetic justice" : as I was about respond to your post the "Vista Ultimate machine from hell that will not upgrade to SP2" once again decided, without warning, to log me off and try to install the same 56 "upgrades and patches" that it does every time I turn the machine on and off. This was in spite of the fact I had already tried to "head the installer off at the pass" by activating it and telling it to give me four hours more of time before it intervened again :) As usual our dance with the future stumbles around on the crutches of the past tripped up by the cracks in history. Thanks for the links to Spolsky's article, and to Palermo's rebuttal. I view Spolsky's writing in terms of his general public role as "agent provacateur" : i.e., to me, the article is a polemic, but a tasty one. Every company I've been with, including Adobe, for all practical purposes was up to their eyeballs in what I was calling, in the 1980's, "dinosaur dentistry," which I think is very much parallel to what Spolsky's talking about. But, by "dinosaur dentistry" I refer to the fact that a lot of programmer's time is spent doing work-arounds between complex entities, each one of which, like the Oludvai Gorge in Kenya, has multiple layers of accretion going all the way back to the origins of software. And, I think context makes a lot of difference here : a start-up that faces a do-or-die ship date for its first product cannot afford the luxury of R&D or seminars in Agile; a behemoth, a Google, an MS, an Apple, cannot afford not to be doing future prototyping that takes for granted freedom from current hardware, os, and memory usage patterns. I think it would be interesting to consider the obvious outstanding technical success of jQuery in the light of Spolsky's article, and the article (by Zawinski) Spolsky based his essay on in Siebel's book, "Coders at Work." Is the success of jQuery (who hasn't adopted it ?) an example of a "better mousetrap," or "duct tape," or "a root canal for javascript" : or is it an algorithmic enchantment descended from "on high" to light the world of "mere mortals" ? For sheer brilliance : I think Linq qualifies. Is Linq "duct-tape," or is it an example of the type of solution that once you see it, and see its "generic" power across the domain boundaries of SQL, XML, and Collections, you wonder how you ever lived without it ? I certainly see "algorithmic beauty" in the design, and implementation, of Linq. best, Bill
"Many : not conversan
-
Hi Nemanja, It seems like "poetic justice" : as I was about respond to your post the "Vista Ultimate machine from hell that will not upgrade to SP2" once again decided, without warning, to log me off and try to install the same 56 "upgrades and patches" that it does every time I turn the machine on and off. This was in spite of the fact I had already tried to "head the installer off at the pass" by activating it and telling it to give me four hours more of time before it intervened again :) As usual our dance with the future stumbles around on the crutches of the past tripped up by the cracks in history. Thanks for the links to Spolsky's article, and to Palermo's rebuttal. I view Spolsky's writing in terms of his general public role as "agent provacateur" : i.e., to me, the article is a polemic, but a tasty one. Every company I've been with, including Adobe, for all practical purposes was up to their eyeballs in what I was calling, in the 1980's, "dinosaur dentistry," which I think is very much parallel to what Spolsky's talking about. But, by "dinosaur dentistry" I refer to the fact that a lot of programmer's time is spent doing work-arounds between complex entities, each one of which, like the Oludvai Gorge in Kenya, has multiple layers of accretion going all the way back to the origins of software. And, I think context makes a lot of difference here : a start-up that faces a do-or-die ship date for its first product cannot afford the luxury of R&D or seminars in Agile; a behemoth, a Google, an MS, an Apple, cannot afford not to be doing future prototyping that takes for granted freedom from current hardware, os, and memory usage patterns. I think it would be interesting to consider the obvious outstanding technical success of jQuery in the light of Spolsky's article, and the article (by Zawinski) Spolsky based his essay on in Siebel's book, "Coders at Work." Is the success of jQuery (who hasn't adopted it ?) an example of a "better mousetrap," or "duct tape," or "a root canal for javascript" : or is it an algorithmic enchantment descended from "on high" to light the world of "mere mortals" ? For sheer brilliance : I think Linq qualifies. Is Linq "duct-tape," or is it an example of the type of solution that once you see it, and see its "generic" power across the domain boundaries of SQL, XML, and Collections, you wonder how you ever lived without it ? I certainly see "algorithmic beauty" in the design, and implementation, of Linq. best, Bill
"Many : not conversan
I loved that article... thanks Bill. I think Joel pushes the case a little past its logical limit - always a great way of generating sharp contrasts. It doesn't endorse *bad* design or ignoring what can be (productively) gleaned from best-practices. I'm a platform agnostic, but my company does Rails and .NET. I think these are the duct tape trends Joel is talking about, as another forum poster noted. When I was consulting on Java projects, we'd invariably have a conversation with "the guy." "The guy" was the one who *wrote* the application server or knew (and only he knew) precisely how the reflection-based, auto-generated, JVM optimized, semi-stateless EJB's were callable - or whatever. I liked that guy. I admired that guy. But, we have clients now, and I'm glad we don't have that guy. We've served about 40 clients in 8 years. One manufacturing client gave us a material-usage optimization problem once. That was cool. The rest are moving data around, multiplying, dividing, adding, subtracting, and then moving the data around again. So, I think the duct-tape programmers have simple factored out "the guy" and his arcane understanding. But, in all fairness, different applications require different degrees of design-analysis and fault-tolerance. If the .NET runtime or a JVM were stove-piped, the down-stream pain would be significant. If my ducttape programmer opts for a long switch case over an interface for a social networking website.... well... thanks for getting it done on time.
-
I think the pragmatic programmer uses a little of both as circumstances dictate. To extoll the virtues of one over the other is to miss the point of real-world programming: all coding is a compromise between the shiny promise of perfectly architected code and something simple and robust that works well but might well be sneered at by design pattern afficionados and the like. There are too many pointless pissing contests in the software world: ignore them and just try to be the most professional and pragmatic programmer you can be in whatever language/technology you choose to make a living from.
digital man wrote:
There are too many pointless pissing contests in the software world: ignore them and just try to be the most professional and pragmatic programmer you can be in whatever language/technology you choose to make a living from.
AMEN! I usually don't participate on programming forums because of the nonsense that goes on. Every time somebody says something, some pedantic fool takes him to task! You've said a mouthful. Thanks! --Geoff
-
Among the numerous responses to the Joel's controversial text[^], I like this one[^] the best. Some quotes: "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" And a more serious one that IMHO sums it up: "The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms. This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method."
The problem with the "Duct Tape Programmer" essay is that it's an example of either/or thinking. There are MANY levels of software development techniques between duct-tape and astronaut-engineer that are effective depending on the task at hand. Personally, I shy away from both of the extremes and try to find some happy medium where we actually ship products on time that are well designed (and not OVER designed) and easy to maintain.
-
Oh, and the other thing that is worrisome is people saying, "We're on a tight deadline, so I get to write crappy code."
Best wishes, Hans
Having worked in both housing construction and now software construction, I can say that this applies to both fields. The mentality of 'just get it done' seems to happen everywhere. I've even worked on houses where things were crooked so we just shimmed it and moved on. Software for some reason seemed to get blamed for this behavior more than is fair. The only time I've been able to sit down and do things right without duct tape has been on projects where we knew A)we'd be maintaining the code and B)we'd be adding new features in the near future. Otherwise its hard to sell anyone on 'doing it right'
-
Russ-T wrote:
Yes, granted, you're here to ship products. However, if your code isn't clear and maintainable then you really are just making a rod for your own back and not helping anyone at all!
You are exactly right. Consider though if the choices available are A) make a rod for your own back or b) not ship a product, have no customers and consequently run out of money and have no food. I'd choose option A every time. That to me is what it comes down to. There is no answer that is always right, it always comes down to the circumstances of the business at the time.
exactly. which is why almost all contract gigs involve duct tape. start-ups involve duct tape too because you don't know if anyone's actually going to buy it. The only time you don't have loads of duct tape is an existing business with an established product, and you're writing something new, or getting to re-write something. Then MAYBE you can take the time to do it right because you know you have to support it. Or, if you're lucky enough to get a boatload of VC money right off. Still waiting for a gig like that :laugh:
-
Among the numerous responses to the Joel's controversial text[^], I like this one[^] the best. Some quotes: "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" And a more serious one that IMHO sums it up: "The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms. This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method."
I've said it before and I'll say it again:
aspdotnetdev wrote:
Seems a bit absolutist to me. I say go with what works well. If you are a new programmer without much experience, then you should probably spend some of your time trying to understand the more complex ideas. If you start working for a corporation right away in which the quickest solution is the right one, you'll never learn and you will be forever mediocre. However, if you are spending all of your time in theory land without actually finding good uses for those theories, that is probably a waste of your time and the company's time (theories are hard to learn without practical application and your lack of learning and over-engineering is wasting the company's time). I prefer a middle ground. I try to code so that I don't prevent changes in the future, but I'm not typically going to code for those changes before they are required. After all, if you've done that, then you're not dealing with change so much as trying to prevent it. With something that evolves as much as software, that is a losing battle. As far as programming to cater to the lowest common denominator, I don't like that idea. Perhaps the example you present will help more junior developers later on when they encounter your design. There is nothing better for learning than to see the theory applied to a practical example in the context that the "student" is working in anyway. In fact, I was just talking with my coworkers and manager about WPF. I was worried about the learning curve, as any new developers we hire may not be up to learning WPF. However, given a multitude of examples, I can see even a very junior developer not having a huge problem with WPF. That being said, WPF does have room for improvement to make it more intuitive, but that's off topic. Point is, learning is not bad, in moderation. And designing intelligently is not bad, when done appropriately. Coding to ship a product as fast as possible is just short-sighted, albiet necessary with new products. To see such "duct tape" coding applied to a mature product is less than ideal (I know because I have to deal with a million line beast that is made of 2 inches of code and 5,000 yards of duct tape).
Visual Studio is an excellent GUIIDE.
