Debunking the duct tape programmer
-
Among the numerous responses to the Joel's controversial text[^], I like this one[^] the best. Some quotes: "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" And a more serious one that IMHO sums it up: "The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms. This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method."
I've said it before and I'll say it again:
aspdotnetdev wrote:
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.
-
Having worked in both housing construction and now software construction, I can say that this applies to both fields. The mentality of 'just get it done' seems to happen everywhere. I've even worked on houses where things were crooked so we just shimmed it and moved on. Software for some reason seemed to get blamed for this behavior more than is fair. The only time I've been able to sit down and do things right without duct tape has been on projects where we knew A)we'd be maintaining the code and B)we'd be adding new features in the near future. Otherwise its hard to sell anyone on 'doing it right'
Totally agree. The only time I've seen this path not taken is where a first-line manager knew what would happen in the future. Unfortunately, at most companies the management bonuses are pegged to meeting delivery dates, not delivering quality code.
Best wishes, Hans
-
Among the numerous responses to the Joel's controversial text[^], I like this one[^] the best. Some quotes: "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" And a more serious one that IMHO sums it up: "The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms. This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method."
I think the point of duct tape coding has been missed - just because you're on a tight deadine doesn't mean you should write dodgey code. I don't see it as being an acceptable excuse. I've recently been involved on a project with an insane deadline where the developers did some of the worst coding I've ever seen. Their excuse - the deadline was too tight & they needed to get it done. The end result of all their duct tape coding, was that after "completing" the code, they then had a ton of bug fixes to do. Of the total number of hours they spent on the ENTIRE project, over 40% of that was bug fixes. My take on duct tape code is just to do your best to do it properly the first time (I do concede there are times when duct tape coding is a necessity. I am guilty of doing it too, but only in dire circumstances after the customer has explicity been made to understand that it's a short term solution and they are willing to take the risk). What's the point of being able to meet a deadline when your customer thinks your software sucks when they use it? You're killing your own business.
-
Having worked in both housing construction and now software construction, I can say that this applies to both fields. The mentality of 'just get it done' seems to happen everywhere. I've even worked on houses where things were crooked so we just shimmed it and moved on. Software for some reason seemed to get blamed for this behavior more than is fair. The only time I've been able to sit down and do things right without duct tape has been on projects where we knew A)we'd be maintaining the code and B)we'd be adding new features in the near future. Otherwise its hard to sell anyone on 'doing it right'
DiscoJimmy wrote:
The only time I've been able to sit down and do things right without duct tape has been on projects where we knew A)we'd be maintaining the code and B)we'd be adding new features in the near future. Otherwise its hard to sell anyone on 'doing it right'
There’s an epiphany here. If we are to maintain a product with a given code base, all hacks must be resolved to an acceptable engineering standard as soon as possible. Even if the hack makes it into the current product, the next revision must have the hack fixed, even if it involves refactoring and redesign. For too long, the organization where I work has maintained a product that was first introduced in 1995 under MFC/C++. Features were hastily added to it and the mantra was “just get it out”. Then as more feature requests were fielded, it became more of a battle to not break something or cause a side effect. (I see it as a skeleton that you keep throwing stuff on to. Eventually, that body gets too obese and cannot stand up. Then figuring where to make fixes, you have to open the folds to find where to do your surgery.) It must be written into the iterations (since we use agile) that hacks must be identified and corrected. Tasks must be added to correctly engineer the hack, even if it means redesign. (Figure that the hack is just a quick way to see how the code/feature works. A better (more thought out) solution will be needed.) Think of it as the builder of a log cabin who had to use 2 x 4s to create the walls of his cabin because the time and price of cutting the logs was to costly in terms of money and schedule. He has a useable cabin, but not what he wanted, and maybe not as sturdy as a real log cabin. Later, the builder can either add log siding to the cabin to give the impression of a log cabin or remove the 2 x 4s and replace with real logs. Also, if the builder decides to add to the cabin, the 2 x 4 structure may not hold up if he adds a 2nd level. He may have to remove some 2 x 4s and place in sturdier cuts of wood. Unfortunately, this is what we are faced with in software. But, it doesn’t matter so much if the software collapses, unlike the cabin. We can just find the problem and fix it. But, if the structure is so badly hacked together (also a bad design or no design), then it will take longer to fix the problem(s). And, as software products get larger and larger, the more chance of hacks and problems. Yes, marketing wants to get the product
-
Among the numerous responses to the Joel's controversial text[^], I like this one[^] the best. Some quotes: "i've said it before, @jbogard : never take software advice from a bug tracking system salesman" And a more serious one that IMHO sums it up: "The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms. This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method."
I read sarcasm into Joel Spolsky's article: ...you’re not here to write code; you’re here to ship products. However, here are two related compilations: - Dirty Coding Tricks By Brandon Sheffield [^] When the schedule is shot and a game needs to ship, programmers may employ some dirty coding tricks to get the game out the door. - Cowboy Coding [^] [^] Cowboy coding is a software development methodology without an actual defined method – team members do whatever they feel is right. Typical cowboy coding will involve no initial definition of the purpose or scope of the project, no formal description of the project, and will often involve one programmer. :cool:
I would imagine if you could understand Morse Code, a tap dancer would drive you crazy. -- Mitch Hedberg (American Comedian, 1968-2005)
-
DiscoJimmy wrote:
The only time I've been able to sit down and do things right without duct tape has been on projects where we knew A)we'd be maintaining the code and B)we'd be adding new features in the near future. Otherwise its hard to sell anyone on 'doing it right'
There’s an epiphany here. If we are to maintain a product with a given code base, all hacks must be resolved to an acceptable engineering standard as soon as possible. Even if the hack makes it into the current product, the next revision must have the hack fixed, even if it involves refactoring and redesign. For too long, the organization where I work has maintained a product that was first introduced in 1995 under MFC/C++. Features were hastily added to it and the mantra was “just get it out”. Then as more feature requests were fielded, it became more of a battle to not break something or cause a side effect. (I see it as a skeleton that you keep throwing stuff on to. Eventually, that body gets too obese and cannot stand up. Then figuring where to make fixes, you have to open the folds to find where to do your surgery.) It must be written into the iterations (since we use agile) that hacks must be identified and corrected. Tasks must be added to correctly engineer the hack, even if it means redesign. (Figure that the hack is just a quick way to see how the code/feature works. A better (more thought out) solution will be needed.) Think of it as the builder of a log cabin who had to use 2 x 4s to create the walls of his cabin because the time and price of cutting the logs was to costly in terms of money and schedule. He has a useable cabin, but not what he wanted, and maybe not as sturdy as a real log cabin. Later, the builder can either add log siding to the cabin to give the impression of a log cabin or remove the 2 x 4s and replace with real logs. Also, if the builder decides to add to the cabin, the 2 x 4 structure may not hold up if he adds a 2nd level. He may have to remove some 2 x 4s and place in sturdier cuts of wood. Unfortunately, this is what we are faced with in software. But, it doesn’t matter so much if the software collapses, unlike the cabin. We can just find the problem and fix it. But, if the structure is so badly hacked together (also a bad design or no design), then it will take longer to fix the problem(s). And, as software products get larger and larger, the more chance of hacks and problems. Yes, marketing wants to get the product
Yeah, that's a good analogy about the house. I used to work with a guy who had a saying 'Should we bother to put a sweet attic on our shithole of a house?' And he was right; sometimes, especially in contracting, you come across a project that was so badly designed in the first place that there isn't much point in overthinking the design of your add-on module. If they didn't bother to lay it out right in the beginning, they can't expect anything but duct tape solutions when it comes to patches. I look it as it as essentially 'selling tomorrow for today'. Marketing wants it out now sure, because they're concerned about today, but in the long run, if you hack stuff together and don't budget time to go back and fix it, you are ALWAYS working around yesterdays hack, and eventually the time to product is much higher than it should be (and maybe higher than your competitor) and you're in deep trouble. So while marketing THINKS they're saving time by taking short cuts, they're actually costing the company time in the long run. That's why my approach is, if it's a contract patch job, or if its a quick version 1.0, then duct tape is cool. Otherwise it's just too important to keep the product lean and agile. There's way too many tomorrows you'll have to deal with to screw it up today.