Joel does it again
-
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: