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."
-
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 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
-
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 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:
-
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:
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.
-
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:
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.
-
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.
Exactly! I think the problem comes when top-level management doesn't realize that the first-line manager is saying, "Just duct-tape it", and so doesn't realize that the duct tape code might have to be replaced in the future. I guess all this stuff would be more credible if there was a line-item on project schedules: "Review/Replace all duct tape code".
Best wishes, Hans
-
Exactly! I think the problem comes when top-level management doesn't realize that the first-line manager is saying, "Just duct-tape it", and so doesn't realize that the duct tape code might have to be replaced in the future. I guess all this stuff would be more credible if there was a line-item on project schedules: "Review/Replace all duct tape code".
Best wishes, Hans
Hans Dietrich wrote:
I guess all this stuff would be more credible if there was a line-item on project schedules: "Review/Replace all duct tape code".
Amen! In most cases they are just not able to see the business value of doing that, at least not until it is too late.
-
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
