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 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.
-
Hans Dietrich wrote:
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.
Heck, I had to use "duct type" (I call it a "hack") more than once - we do live in real world, don't we? The difference is - I am not proud of it and don't promote it as a good development practice.
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
-
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.
Well said. That should be drilled into all the newbies heads.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
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."
So pretty much the difference between 'get it done' and 'get it done right'. It's as much of a problem to duct tape everything as it is to sit staring out the ivory tower, as per most everything there's a certain amount of balance required based upon how much time you have now, and how much time you're going to have to spend on it later. Warning: Long Old Annoyed Story ahead. Obviously there's issues with both, and I have a wonderful example of both. In college we were given a horrifically failed programming project from students, a networked checkers game. Our task was to make it work correctly in at least a few areas(which it didn't, never did). Two members of the group I was assigned to work on it with decided it would be brilliant to use a directed graph to define the checkers board and promptly started to work on it, given they ignored my pleas for a simpler data structure I spent the ten minutes to write out exactly what it would take to make the program work using a 2d array(it was 'working' off a 1d array). They complained how it wasn't terribly elegant, without looking at the remarkably simple and clean code I had prepared to replace the existing functions. That was the first half hour, having spent the time to actually write out the code and it's boundary conditions. Now, since they where bound and determined to get their 'nice clean code' together, I focused on the auto-generated code GUI for the board itself. Reconstructing it as a 2d array to layer safely over my code I cut out over 900 lines of auto-gen code, and had a functional model that would let us pass the project safely. This was an additional hour. I spent a half hour linking the two chunks together, taking the model and making it a reality. I haven't said much about the other guys, why? It wasn't till now that they had the Directed graph logic figured out, they showed me their wonderful and graceful and beautiful logic. And I asked them exactly how they expected to handle when someone was kinged with their directed graph causing them to look a tad nauseous. So, I told them if they wanted to work on their directed graph model for a few more hours they could call my dorm room. Or they could implement a few additional features to what I had just emailed them and we could get an A. Was it Ivory tower? Duct Tape? Nope, it was programing. Simple logic proved effective enough, in roughly 2 hours. Does it make me a horrible team mate for not going along with the self-proclaimed leader, possibly, but I will point out who's code go
-
So pretty much the difference between 'get it done' and 'get it done right'. It's as much of a problem to duct tape everything as it is to sit staring out the ivory tower, as per most everything there's a certain amount of balance required based upon how much time you have now, and how much time you're going to have to spend on it later. Warning: Long Old Annoyed Story ahead. Obviously there's issues with both, and I have a wonderful example of both. In college we were given a horrifically failed programming project from students, a networked checkers game. Our task was to make it work correctly in at least a few areas(which it didn't, never did). Two members of the group I was assigned to work on it with decided it would be brilliant to use a directed graph to define the checkers board and promptly started to work on it, given they ignored my pleas for a simpler data structure I spent the ten minutes to write out exactly what it would take to make the program work using a 2d array(it was 'working' off a 1d array). They complained how it wasn't terribly elegant, without looking at the remarkably simple and clean code I had prepared to replace the existing functions. That was the first half hour, having spent the time to actually write out the code and it's boundary conditions. Now, since they where bound and determined to get their 'nice clean code' together, I focused on the auto-generated code GUI for the board itself. Reconstructing it as a 2d array to layer safely over my code I cut out over 900 lines of auto-gen code, and had a functional model that would let us pass the project safely. This was an additional hour. I spent a half hour linking the two chunks together, taking the model and making it a reality. I haven't said much about the other guys, why? It wasn't till now that they had the Directed graph logic figured out, they showed me their wonderful and graceful and beautiful logic. And I asked them exactly how they expected to handle when someone was kinged with their directed graph causing them to look a tad nauseous. So, I told them if they wanted to work on their directed graph model for a few more hours they could call my dorm room. Or they could implement a few additional features to what I had just emailed them and we could get an A. Was it Ivory tower? Duct Tape? Nope, it was programing. Simple logic proved effective enough, in roughly 2 hours. Does it make me a horrible team mate for not going along with the self-proclaimed leader, possibly, but I will point out who's code go
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.
-
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