Joel does it again
-
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.)
-
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
Oh, I agreed with 'get it shipped'. Every position i've had has been with a consulting firm or free-lance. Every hour is accountable and you do what's needed to get it done under time and under budget. That said, I think there is a middle ground that his article doesn't adress. Like I said, to me it read like a trip down memory lane about the 'good old days'. Had he used more balanced, and current, examples i'd likely agree with the bulk of it.
...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 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.
akidan wrote:
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.
I encountered just such a thing today. I believe in doing it right the first time. I work with a duct tape programmer type who likes to knock things out in record time. Today there was a production problem and he tried to blame my process that supplies his process with an xml document. His process didn't work so the first thing he said (with the manager standing over him) was that my xml was broken because he just received an updated copy of the file from a process I run weekly. My response was there is nothing wrong with the xml file. It is xml so read it and show me where the format is different from previous files I have supplied. Of course he couldn't find any change in structure because I haven't touched my process since I released it months ago. I took the time to code it right and it works according to the design. Luckily I was there to defend myself or the manager would have gone away with the mistaken impression that I was the cause of the problem. When I left this evening he was still trying to figure out why his process was not working. After at least 4 hours of looking he still didn't have a clue what was not functioning. At least the manager knows who wrote the flawed process. I, on the other hand, solved a different production problem (the customer not supplying a required field) in one hour in code I hadn't looked at in over a year. Do it right the first time and sleep at night.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
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
Same thing here. So many times I've seen people (and myself of course) fall in to the trap of using technology for technologies sake. This part really resonated with me: "you’re not here to write code; you’re here to ship products" That sums up things so well. When the Architect Astronauts get involved, it all goes awry so very quickly. I used to be an AA, now I'm in AAA. Hi, my name is Phil, It's been 137 days since my last Design Pattern... - Phil
-
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 really dislike design patterns and often engineer by the seat of my pants, however the accusation that programmers use technologies as a crutch cuts both ways. Using COM for no reason but to use it is as dumb as not using C++ because... I have no clue what the reasoning there was. Templates can and very often are overused--they cause major code bloat if you aren't careful--but they can also be very useful and a good programmer will understand all the ramifications and make a decision. (Though they better be prepared to defend those decisions; I'm sick and tired of programmers who whine and complain when asked to defend their coding decisions.) Thing is that I've spent a good portion of my career cleaning up after, and cursing, the "duct tape" programmers that Joel describes. I happen to be very good at it too, at least in the C/C++ realm. My biggest complaint is that these programmers tend to think they are far more clever than they really are and code that way. By all means, before you write a class ask yourself if a simple set of procedural functions would work just as well. But, I'd better not see you passing a fucking structure into every function unless you have a really, really, really damn good reason (say you have to interop to the DLL from .NET.) Oh, and by the way, Netscape was memory leaking, BSOD causing shit. Anyone who holds that code and the way it was coded as a model is a fool and a jackass rolled into one. * * * I get really irritated with the attitude that "you’re not here to write code; you’re here to ship products." Actually, you're "here" to solve customer's problems and hopefully make a profit while doing so. It may sound like the same thing, but it isn't. I've found that if you concentrate on solving the actual problem the customer is facing, you quite often reduce the requirement set and amount of work you have to do. Moreover, I just find it far more satisfying that being a code monkey in a crap product factory.
modified on Thursday, September 24, 2009 7:40 PM
