Joel does it again
-
Causes a controversy, that is...[^]. Can't say I agree with him and I really dislike overengineering, frameworks, "architecture", design patterns... But "duct tape" programming? No, thanks.
I'm entirely capable of being a duct tape programmer, but having had to support a system made exclusively with twist tie programming, I've learned a few lessons in Maintainability. I won't say design patterns are a holy writ to take literally and apply in all aspects of coding, but it you take the time to actually understand their uses and purposes you can use the concepts effectively without the bloat of blind implementation of them. Code out the door is all well and good, but if it comes back, make sure you can even decipher what it's doing. A duct tape prototype delivered to the customer as a prototype is fine, if they like it, bring it back, finish it, and give them the actual product. Passing it off as a complete finished product all in the name of 'get it out the door', well, I hope you have to maintain the thing and get the suffering you deserve rather than having your client hire someone like me to figure out what in the blazes you did.
-
I was going to post a link to that here because I so vehemently agree with him it's not even funny. I'm a classic duct tape programmer. The only reason I didn't is that I knew it would be a waste of time because a great majority of the people here I would put firmly in the "Ivory tower" type who would not even consider the merit of what he's saying and the other 10% already live and breathe it every day because they work in small shops where you need to GET THINGS DONE and out the door.
"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
-
Causes a controversy, that is...[^]. Can't say I agree with him and I really dislike overengineering, frameworks, "architecture", design patterns... But "duct tape" programming? No, thanks.
Go, Joel! :thumbsup::thumbsup:
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
-
I'm entirely capable of being a duct tape programmer, but having had to support a system made exclusively with twist tie programming, I've learned a few lessons in Maintainability. I won't say design patterns are a holy writ to take literally and apply in all aspects of coding, but it you take the time to actually understand their uses and purposes you can use the concepts effectively without the bloat of blind implementation of them. Code out the door is all well and good, but if it comes back, make sure you can even decipher what it's doing. A duct tape prototype delivered to the customer as a prototype is fine, if they like it, bring it back, finish it, and give them the actual product. Passing it off as a complete finished product all in the name of 'get it out the door', well, I hope you have to maintain the thing and get the suffering you deserve rather than having your client hire someone like me to figure out what in the blazes you did.
You're assuming there is a contradiction between maintainable code and "duct tape" programming. I don't see one at all given what he's describing in the article. His basic argument is simplicity versus unnecessary complexity and I know many will warp it into something else to suit their hobby horse but they would be wrong.
"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 was going to say "Rarely have I read such a complete load of b******s". Unfortunately I read it every day ...
-
Causes a controversy, that is...[^]. Can't say I agree with him and I really dislike overengineering, frameworks, "architecture", design patterns... But "duct tape" programming? No, thanks.
But duct tape is a Design Pattern. :confused:
-
You're assuming there is a contradiction between maintainable code and "duct tape" programming. I don't see one at all given what he's describing in the article. His basic argument is simplicity versus unnecessary complexity and I know many will warp it into something else to suit their hobby horse but they would be wrong.
"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 don't have a distinct problem with duct tape programing, I have a problem with duct tape coding over duct tape coding. One layer works, one layer can be fine. But I've seen what some people do, I've seen what I've done to get things out on time. At a certain point you have to go back through the mess you've made, straighten things out, link associated concepts, and replace the duct tape with something a bit more solid and coherent. I'm a fan of refactoring the duct tape off, before adding another layer of it, because eventually it will become unmaintainable if all you're doing is patching it together.
-
Causes a controversy, that is...[^]. Can't say I agree with him and I really dislike overengineering, frameworks, "architecture", design patterns... But "duct tape" programming? No, thanks.
I read that this morning and found myself agreeing with much of it. The duct tape thang isn't the greatest analogy in the world but I have worked with people who can just code and others who spend ages fannying around with all manner of clever stuff. I found the systems from the first group to be far more maintainable and much easier to interface with. There is a half way house though, design patterns have their place but too often they used where they shouldn't be and blind devotion to a pattern can lead to some awful code.
-
I don't have a distinct problem with duct tape programing, I have a problem with duct tape coding over duct tape coding. One layer works, one layer can be fine. But I've seen what some people do, I've seen what I've done to get things out on time. At a certain point you have to go back through the mess you've made, straighten things out, link associated concepts, and replace the duct tape with something a bit more solid and coherent. I'm a fan of refactoring the duct tape off, before adding another layer of it, because eventually it will become unmaintainable if all you're doing is patching it together.
Hmmm...perhaps the term duct tape was unfortunate because what you are describing and what he wrote in the article bear no resemblance to each other.
"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 was going to post a link to that here because I so vehemently agree with him it's not even funny. I'm a classic duct tape programmer. The only reason I didn't is that I knew it would be a waste of time because a great majority of the people here I would put firmly in the "Ivory tower" type who would not even consider the merit of what he's saying and the other 10% already live and breathe it every day because they work in small shops where you need to GET THINGS DONE and out the door.
"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
ditto. i hate hate hate it when i see a simple idea turned it into a nest of templated classes just because the programmer thought it would prove that he read a book on design patterns.
-
Hmmm...perhaps the term duct tape was unfortunate because what you are describing and what he wrote in the article bear no resemblance to each other.
"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
At first they don't, I know what he's talking about, and I know what some people are going to run with it with(it's like real agile, and agile as an excuse not to document things). But if it keeps happening, and you're doing things just to get them out the door, it'll turn into what I'm talking about. It's a matter of how long you keep repeating the process without taking the time to ivory tower it into something a bit more graceful.
-
Causes a controversy, that is...[^]. Can't say I agree with him and I really dislike overengineering, frameworks, "architecture", design patterns... But "duct tape" programming? No, thanks.
I mostly agree with him, except for the parts about C++. Although, I must say multiple inheritance is rarely needed and template programming is rarely need (especially the ATL-style of multiple template inheritance -- ugh [don't get me wrong, I love it, it's cool, but it can be daunting to understand]) Sometimes though, slightly complex is better than brain-dead simple. Further, often in order to solve complex problems, you need complex solutions.
-
Causes a controversy, that is...[^]. Can't say I agree with him and I really dislike overengineering, frameworks, "architecture", design patterns... But "duct tape" programming? No, thanks.
It sounded like nostalgia for the old wild west programming days ... that is until I read: Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain. then I realized he must be talking about script kiddies.
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack
-
I read that this morning and found myself agreeing with much of it. The duct tape thang isn't the greatest analogy in the world but I have worked with people who can just code and others who spend ages fannying around with all manner of clever stuff. I found the systems from the first group to be far more maintainable and much easier to interface with. There is a half way house though, design patterns have their place but too often they used where they shouldn't be and blind devotion to a pattern can lead to some awful code.
spot on
-
It sounded like nostalgia for the old wild west programming days ... that is until I read: Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain. then I realized he must be talking about script kiddies.
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack
cmk wrote:
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
And plainly stoooopiiiid!
-
I don't have a distinct problem with duct tape programing, I have a problem with duct tape coding over duct tape coding. One layer works, one layer can be fine. But I've seen what some people do, I've seen what I've done to get things out on time. At a certain point you have to go back through the mess you've made, straighten things out, link associated concepts, and replace the duct tape with something a bit more solid and coherent. I'm a fan of refactoring the duct tape off, before adding another layer of it, because eventually it will become unmaintainable if all you're doing is patching it together.
Distind wrote:
duct tape coding over duct tape coding.
"It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. "
-
I'm entirely capable of being a duct tape programmer, but having had to support a system made exclusively with twist tie programming, I've learned a few lessons in Maintainability. I won't say design patterns are a holy writ to take literally and apply in all aspects of coding, but it you take the time to actually understand their uses and purposes you can use the concepts effectively without the bloat of blind implementation of them. Code out the door is all well and good, but if it comes back, make sure you can even decipher what it's doing. A duct tape prototype delivered to the customer as a prototype is fine, if they like it, bring it back, finish it, and give them the actual product. Passing it off as a complete finished product all in the name of 'get it out the door', well, I hope you have to maintain the thing and get the suffering you deserve rather than having your client hire someone like me to figure out what in the blazes you did.
I currently work at a job where, by nature of the very tight deadlines, I am REQUIRED to be a duct-tape programmer. We pull crazy miracles out of our duct-taped code to get stuff shipped and out the door. Yes, I get the job done, but for the scope of many projects I work on, I pay a huge cost later in trying to maintain the damn thing. The part of his article that scares me is that he does not take the scope of project into consideration at all. Duct-tape coding is not a good or bad trait in and of itself, but there is a time and place for it. As you mention, the same goes for design patterns. You don't (or shouldn't) use them just to say you did or to appear smart, but when applied appropriately, they can cleanly solve real problems that you'd be otherwise scratching your head about. On larger projects, when requirements change (and they WILL change), you're left trying to cut through all the wadded up duct tape you left behind, wishing you'd spent a little less time with duct tape and a little more time actually thinking things through.
-
At first they don't, I know what he's talking about, and I know what some people are going to run with it with(it's like real agile, and agile as an excuse not to document things). But if it keeps happening, and you're doing things just to get them out the door, it'll turn into what I'm talking about. It's a matter of how long you keep repeating the process without taking the time to ivory tower it into something a bit more graceful.
I think there comes a point in a good programmers career where they can crank out "duct tape" style while naturally, almost unconsciously staying within the bounds of proper design and methodology. It's really a matter I think of making the right choices to get code out the door. Unfortunately as in most things in life we all are under the yoke of the lowest common denominator. I think one truly good, talented coder can easily be many orders of magnitude better, cheaper and faster than a whole shop full of muppets.
"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 mostly agree with him, except for the parts about C++. Although, I must say multiple inheritance is rarely needed and template programming is rarely need (especially the ATL-style of multiple template inheritance -- ugh [don't get me wrong, I love it, it's cool, but it can be daunting to understand]) Sometimes though, slightly complex is better than brain-dead simple. Further, often in order to solve complex problems, you need complex solutions.
ahmed zahmed wrote:
Further, often in order to solve complex problems, you need complex solutions.
The best solutions *inevitably* turn out to be the simplest. That's always been the case in software development and what separates a talented developer from a mediocre one.
"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
-
You're assuming there is a contradiction between maintainable code and "duct tape" programming. I don't see one at all given what he's describing in the article. His basic argument is simplicity versus unnecessary complexity and I know many will warp it into something else to suit their hobby horse but they would be wrong.
"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're assuming there is a contradiction between maintainable code and "duct tape" programming. I don't see one at all given what he's describing in the article. His basic argument is simplicity versus unnecessary complexity and I know many will warp it into something else to suit their hobby horse but they would be wrong.
The thing is, it's easy to write code that just works and I agree with Joel on that point. However, it doesn't take that much extra effort to add features (for want of a better word) to your program to enable it to be easily modified 6 months down the line. I think we *all* know that features get added or specifications change at the last minute. The more flexibility you can add up front the better off you are in the long run. And I'm not just talking about templates and multiple inheritance nightmares, but all the way down to the simple stuff like declaring named constants instead of sprinkling your code with seemingly random numbers. In my mind, there's a very fine balancing act between simple and changeable. If it's too simple, it generally doesn't take well to changes later on - things tend to get bolted on as hacks and then left there for years. Yet if it's too complex, you still can't change it, because no-one can remember how it works!
The StartPage Randomizer - The Windows Cheerleader - Twitter