Joel does it again
-
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
-
So you're against the premise that simplicity is better or you just don't like his writing style?
"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 changing Joel's argument. Simplicity is very laudable and, frankly, a whole lot of code is way too complicated. But I found what Joel was praising went a little too far. Sometimes using a "complicated" technology not only gives you a better solution, but IS easier once you understand it. Some years ago, I rewrote a serial class to use IO completion ports. It took a little bit to wrap my brain around it, but the resulting class made it MUCH easier to deal with serial ports than the old method. It also greatly increased performance and scalability, so even if it hadn't made life easier, it still would have still been justified.
-
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
Actually, I am [a programmer] to write code. My boss might have hired me to ship products, but it just so happens the two tend to coincide pretty well.
Visual Studio is an excellent GUIIDE.
-
But duct tape is a Design Pattern. :confused:
Not until it has a catchier name.
cheers, Chris Maunder The Code Project Co-founder Microsoft C++ MVP
-
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.)
Exactly.
cheers, Chris Maunder The Code Project Co-founder Microsoft C++ MVP
-
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.)
Shog9 wrote:
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.)
Well said. My current 'application' consists of three computers, one user process, 4-6 services, two device drivers, and literally hundreds of threads.
Software Zen:
delete this;
Fold With Us![^] -
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.
Seems a bit absolutist to me. I say go with what works well. If you are a new programmer without much experience, then you should probably spend some of your time trying to understand the more complex ideas. If you start working for a corporation right away in which the quickest solution is the right one, you'll never learn and you will be forever mediocre. However, if you are spending all of your time in theory land without actually finding good uses for those theories, that is probably a waste of your time and the company's time (theories are hard to learn without practical application and your lack of learning and over-engineering is wasting the company's time). I prefer a middle ground. I try to code so that I don't prevent changes in the future, but I'm not typically going to code for those changes before they are required. After all, if you've done that, then you're not dealing with change so much as trying to prevent it. With something that evolves as much as software, that is a losing battle. As far as programming to cater to the lowest common denominator, I don't like that idea. Perhaps the example you present will help more junior developers later on when they encounter your design. There is nothing better for learning than to see the theory applied to a practical example in the context that the "student" is working in anyway. In fact, I was just talking with my coworkers and manager about WPF. I was worried about the learning curve, as any new developers we hire may not be up to learning WPF. However, given a multitude of examples, I can see even a very junior developer not having a huge problem with WPF. That being said, WPF does have room for improvement to make it more intuitive, but that's off topic. Point is, learning is not bad, in moderation. And designing intelligently is not bad, when done appropriately. Coding to ship a product as fast as possible is just short-sighted, albiet necessary with new products. To see such "duct tape" coding applied to a mature product is less than ideal (I know because I have to deal with a million line beast that is made of 2 inches of code and 5,000 yards of duct tape).
Visual Studio is an excellent GUIIDE.
-
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 -
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. JimmyRopesFunny I work in an environment where every developer works on his/her own projects but we do share concepts. We had a security front end that handles roles and permissions. To be honest I am not sure what it does. It uses Bit/or/and junk. It just works. My counterpart wrote it. Our development environment (ColdFusion) limits the binary operations on string to 32bits or something like that so our tool broke when we needed more than 32 roles/permission. So I took the permbits string and wrote it as an array instead. Problem sorted :) in 15 minutes. My app was up and working in less than an hour. The design pattern guy that wrote the permission thingy in the first place chose to create a "custom" binary-math-class or something - took him two weeks to develop it. It worked the charm. Now he has a binary-math-class thingy that he can use anywhere he wants. :omg: He builds tools!! Now granted I studied art in college and just figured this programming crap out to pay the bills and my counterpart has a degree in math and computer science. So I am guessing I am crap and he does everything the correct way. But my houses get built before his hammer is done being fabricated. :-D
