Joel does it again
-
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
-
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
-
I am staunchly against the premise that simplicity is better. I am also staunchly against the premise that complexity is better. If you don't take the problem at hand into account, choosing either simplicity or complexity is an uninformed decision.
If this is a problem of communication or perspective forgive my rant that's about to come, but it sounds to me like you are saying there are often legitimate reasons to choose a complex solution *over* a simple solution to the same problem. I've been developing for over 30 years and professionally with my own company not in a cubicle somewhere for over 15 and there has *never* in all that time been any real world situation where simplicity was not better. All the best solutions are both simple and elegant. Any developer who doesn't get that in their bones is not ready to take a lead on anything. Simplicity is the tao of programming, always has been, always will. Sure some solutions are required to be more complex than others due to the nature of the problem being addressed, that's just reality. But when given multiple ways to solve a problem the simplest choice is hands down always the best choice. Sometimes, rarely, there is only one solution and it is a complex solution. Rarely as in 1% of the time there are no other options. A complex solution to a problem is more often though a sign of lack of planning, thinking or just plain talent to see outside the box. I understand that many developers are cogs in a big machine, they sit in a cubicle somewhere and have the luxury of being self indulgent and playing with their employers time and money and the good will of the end users, I get that and the posts here in this thread pretty much reveal who is who in that department. In my line of work there is only one test that any technology or solution needs to pass: Is it better for the end user. And high on the list of "better" is getting it into their hands in a timely fashion so they can actually get their job done with it. It has to be good enough, not perfect, not cool, not flashy necessarily, just good enough for the end user to accomplish their tasks with it. If I worked for a big corporation and was making some kind of in-house app and given free reign and few constraints I'm sure I'd be dabbling with all the latest buzzword technology as well, it's human nature and I don't blame people for it, but in these tough economic times I think it's encumbent on all of us to focus more on the end result.
"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.
Um...sounds to me like you're describing a simpler solution in the end there right? :) Simpler as in you said it made it MUCH easier to deal with serial ports.
"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
-
Um...sounds to me like you're describing a simpler solution in the end there right? :) Simpler as in you said it made it MUCH easier to deal with serial ports.
"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
No, the algorithm was more complicated. It required advanced coding techniques that Joel and the "Duct-Tape" model sneered at. The upfront cost was quite high, a model which Joel and buddy blatantly eschewed--they sneered at the notion of writing complicated, unit tested, well designed core library code. Don't say that's not what they meant, since I can only interpret what Joel actual wrote and what the fellow he referred to said: they were contemptuous of complex solutions, even at the unit level.
-
No, the algorithm was more complicated. It required advanced coding techniques that Joel and the "Duct-Tape" model sneered at. The upfront cost was quite high, a model which Joel and buddy blatantly eschewed--they sneered at the notion of writing complicated, unit tested, well designed core library code. Don't say that's not what they meant, since I can only interpret what Joel actual wrote and what the fellow he referred to said: they were contemptuous of complex solutions, even at the unit level.
I took his article as a cautionary tale against unnecessary complexity, gratuitous complexity. What you described sounds like entirely necessary complexity and in the long run is the simplest solution for all future serial port development needs.
"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 took his article as a cautionary tale against unnecessary complexity, gratuitous complexity. What you described sounds like entirely necessary complexity and in the long run is the simplest solution for all future serial port development needs.
"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
Must be fun to read articles and just make up what they are about. :)
-
Must be fun to read articles and just make up what they are about. :)
-
If this is a problem of communication or perspective forgive my rant that's about to come, but it sounds to me like you are saying there are often legitimate reasons to choose a complex solution *over* a simple solution to the same problem. I've been developing for over 30 years and professionally with my own company not in a cubicle somewhere for over 15 and there has *never* in all that time been any real world situation where simplicity was not better. All the best solutions are both simple and elegant. Any developer who doesn't get that in their bones is not ready to take a lead on anything. Simplicity is the tao of programming, always has been, always will. Sure some solutions are required to be more complex than others due to the nature of the problem being addressed, that's just reality. But when given multiple ways to solve a problem the simplest choice is hands down always the best choice. Sometimes, rarely, there is only one solution and it is a complex solution. Rarely as in 1% of the time there are no other options. A complex solution to a problem is more often though a sign of lack of planning, thinking or just plain talent to see outside the box. I understand that many developers are cogs in a big machine, they sit in a cubicle somewhere and have the luxury of being self indulgent and playing with their employers time and money and the good will of the end users, I get that and the posts here in this thread pretty much reveal who is who in that department. In my line of work there is only one test that any technology or solution needs to pass: Is it better for the end user. And high on the list of "better" is getting it into their hands in a timely fashion so they can actually get their job done with it. It has to be good enough, not perfect, not cool, not flashy necessarily, just good enough for the end user to accomplish their tasks with it. If I worked for a big corporation and was making some kind of in-house app and given free reign and few constraints I'm sure I'd be dabbling with all the latest buzzword technology as well, it's human nature and I don't blame people for it, but in these tough economic times I think it's encumbent on all of us to focus more on the end result.
"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
Let me attempt to rephrase. I am not saying that choosing a complex solution over a simple solution to the same problem is legitimate. What I am trying (perhaps failing) to state is that choosing either a complex or a simple solution to ANY problem without first truly understanding the problem at hand is uninformed. For example, the quicksort or mergesort algorithm is very complicated when compared to the bubblesort algorithm. You can elegantly express a bubblesort in most programming languages in three or four lines of code. However, for the vast majority of sorting problems, it is better to go with the more complex quicksort or mergesort versus the simpler bubblesort.
-
Let me attempt to rephrase. I am not saying that choosing a complex solution over a simple solution to the same problem is legitimate. What I am trying (perhaps failing) to state is that choosing either a complex or a simple solution to ANY problem without first truly understanding the problem at hand is uninformed. For example, the quicksort or mergesort algorithm is very complicated when compared to the bubblesort algorithm. You can elegantly express a bubblesort in most programming languages in three or four lines of code. However, for the vast majority of sorting problems, it is better to go with the more complex quicksort or mergesort versus the simpler bubblesort.
Far better to use the LINQ OrderBy method. :laugh:
-
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. JimmyRopesNever deliver a p.o.c. Just demo it.
-
Far better to use the LINQ OrderBy method. :laugh: