Debunking the duct tape programmer
-
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 dunno. Personally, I don't see any polemics in the post... He's just sayin' to not go overboard with complexity. I think we can all agree with that. He's not sayin skip the complexity when it's time to ship. He's just sayin' it's important to ship. duh. He may be a salesman, but I'll still listen to his advice. Most of it's pretty dang good. I appreciate hearin' bout the stuff my boss should know.
-
I dunno. Personally, I don't see any polemics in the post... He's just sayin' to not go overboard with complexity. I think we can all agree with that. He's not sayin skip the complexity when it's time to ship. He's just sayin' it's important to ship. duh. He may be a salesman, but I'll still listen to his advice. Most of it's pretty dang good. I appreciate hearin' bout the stuff my boss should know.
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.
-
Hence KISS: kepp it simple, stupid. Has always worked for me (I'm stupid) and I cringe when I see over-engineered code that may work but is a nightmare to maintain or fix.
-
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.
You've hit the nail right on the head. Five, because there is no ten link. :-D
BDF People don't mind being mean; but they never want to be ridiculous. -- Moliere
-
I dunno. Personally, I don't see any polemics in the post... He's just sayin' to not go overboard with complexity. I think we can all agree with that. He's not sayin skip the complexity when it's time to ship. He's just sayin' it's important to ship. duh. He may be a salesman, but I'll still listen to his advice. Most of it's pretty dang good. I appreciate hearin' bout the stuff my boss should know.
stephen.hazel wrote:
He's just sayin' to not go overboard with complexity.
Except he wasn't since he never actually said that. He was having a love fest with a guy he admires and got carried away with that guy's polemics. The article actually asserted that ANY technology more complex that C wasn't worthwhile (Joel tried to moderate that a little, but he didn't try very hard.) Among other claims was that multi threading was worthless, in part because nobody understands it. Unit testing is worthless since there isn't enough time (given the propensity of Netscape of the early 90s to leak memory and crash, it was pretty obvious to me at the time that they did very little testing. This is now confirmed.)
-
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.
-
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 equally hate the both extreme types of programmers: 1. “Home grows developers”: Ill or self educated individuals, duct type dedicated, full of “innovation” ideas, using OOP only in conversation with other “home grown” developers, but not in their code. For them 900 rows function and SQL script injected in the application source code is something perfectly normal and 10K rows is a HUGE project! 2. “Genii”: A good programmers with obsession of perfection. They will spend five days designing the perfect singleton class instead of just getting job done for one day. They are capable of moving the OOP concept one step further, from useful technique to over complicated, unreadable pile of crap where one simple function is separated between twenty different classes. Using the templates is obligatory, only languages: C++ or Java. Oh, I forgot – Oracle is not RDBS, Oracle is religion!
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
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.
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
-
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."
There is good and bad in everything. I feel like .net is the perfect tool for duct tape programming. As long as use the framework to complete most of your tasks and follow simple best practices like using the app and web config files, coding with using statements in C# whenever possible, creating strong typed properties for accessing things like Session, ViewState and App.Config variables, it really does help you from creating too much of mess. ***Edit (forgot SQL Parameters)
I didn't get any requirements for the signature
-
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