Joel does it again
-
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
-
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
The thing with Joel is that he's in a different position than a lot of the people here which is why he is reviled so much by a lot of people here and a small minority here almost always think "that's exactly right". Many, perhaps the majority, of people here seem to be of the cubicle dweller variety, they are not responsible directly for the bottom line. Their roof over their head won't disappear if they take a less efficient but "cooler" route. On the flip side many of us live and die by things like how fast we can get something out the door in a working state. We empathise greatly with the end user because we are in communication with them all the time etc etc. And we know to our core what end users care about and what they care about rarely makes the top 100 of what most developers here seem to care about. It's only natural that from different perspectives people will not necessarily agree. My contention has always been that every developer should be exposed early and often to things like bottom lines, end users, business considerations big picture stuff basically. For two reasons: one they would be more content realizing that there is a world outside of their monitor that has a direct bearing on why people who don't code for a living are asking them to do things in particular ways and secondly they will become much better developers when they work more closely with a mindset based on the real world and not the ivory tower they were often educated in or mistakenly think is primarily important from hanging around on sites like this too often.
"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.
Hmph. I wasn't interviewed for that book. :(( Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
-
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.
While I don't agree with the terminology, I do agree with some of the sentiment - shipping a product is much more important than polishing code; after all, no matter how much you polish a turd it's still not an acceptable substitute for broccoli. The problem that Joel doesn't cover is that some really bad programmers behave just like these duct tape programmers, and as a company owner, you can't afford to work out which they are. Is somebody slacking off from writing tests because he doesn't need them and his code works straight off the bat, or are they just lazy, incompetent and trying to avoid doing any work.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
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.
What works for building tree-houses doesn't work for building nuclear waste storage facilities - and vice versa.
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
Hmph. I wasn't interviewed for that book. :(( Marc
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
I assume you were just way too awesome for the book.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
While I don't agree with the terminology, I do agree with some of the sentiment - shipping a product is much more important than polishing code; after all, no matter how much you polish a turd it's still not an acceptable substitute for broccoli. The problem that Joel doesn't cover is that some really bad programmers behave just like these duct tape programmers, and as a company owner, you can't afford to work out which they are. Is somebody slacking off from writing tests because he doesn't need them and his code works straight off the bat, or are they just lazy, incompetent and trying to avoid doing any work.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Pete O'Hanlon wrote:
no matter how much you polish a turd it's still not an acceptable substitute for broccoli
Do you like broccoli? I'd take the turd. Even an unpolished turd is an acceptable substitute for broccoli The metaphor is valid though :)
harold aptroot wrote:
Do you like broccoli?
Yes.
harold aptroot wrote:
I'd take the turd.
Whatever spanks your danglers I suppose.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
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 took it to mean, "by the third release".
-
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.
Yes, I'm guilty of over engineering, but that's because I love to code! :-D This line was a good wake up call for me (and not because of the cool curse word): “At the end of the day, ship the fucking thing! It’s great to rewrite your 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.” * SA-LAP! *
- S 50 cups of coffee and you know it's on! Code, follow, or get out of the way.
-
But duct tape is a Design Pattern. :confused:
Clever. :-D
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] -
What works for building tree-houses doesn't work for building nuclear waste storage facilities - and vice versa.
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
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
I agree. "Let's ship the proof of concept and we will go back to refactor it later" is the third biggest lie. Lie #1 - I love you. Lie # 2 - maybe we shouldn't go into it here in the lounge. Lie # 3 - Let's ship the proof of concept and we will go back to refactor it later
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
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.
http://www.joelonsoftware.com/items/2009/09/23.html:
[...] One thing you have to be careful about, though, is that duct tape programmers are the software world equivalent of pretty boys... [...] You, my friend, cannot go out in public without combing your hair. It will frighten the children. Because you’re just not that pretty. Duct tape programmers have to have a lot of talent to pull off this shtick. [...]
Meh. Essay boils down to, "Fly by the seat of your pants: do whatever's necessary to get the product out the door, skip whatever isn't necessary. Oh, and be damn good, 'cause if you aren't you'll go down in flames". (yes, I just summarized a collection of long, rambling metaphors with a much shorter metaphor. Deal with it.) That's a great strategy, if you can pull it off. I've worked with programmers who usually could, programmers who usually couldn't, and programmers who never could... but constantly tried anyway. The last are the worst: instead of shipping without some feature, we shipped with it... broken... and some rather unpleasant collateral damage. I know the bits about C++ and multithreading delighted at least one person here, but frankly they're irrelevant to the discussion (and please... who here is writing Windows desktop apps and still managing to keep their process down to a single thread? Ha! I don't believe you.)
