Debunking the duct tape programmer
-
I think the pragmatic programmer uses a little of both as circumstances dictate. To extoll the virtues of one over the other is to miss the point of real-world programming: all coding is a compromise between the shiny promise of perfectly architected code and something simple and robust that works well but might well be sneered at by design pattern afficionados and the like. There are too many pointless pissing contests in the software world: ignore them and just try to be the most professional and pragmatic programmer you can be in whatever language/technology you choose to make a living from.
digital man wrote:
There are too many pointless pissing contests in the software world: ignore them and just try to be the most professional and pragmatic programmer you can be in whatever language/technology you choose to make a living from.
AMEN! I usually don't participate on programming forums because of the nonsense that goes on. Every time somebody says something, some pedantic fool takes him to task! You've said a mouthful. Thanks! --Geoff
-
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."
The problem with the "Duct Tape Programmer" essay is that it's an example of either/or thinking. There are MANY levels of software development techniques between duct-tape and astronaut-engineer that are effective depending on the task at hand. Personally, I shy away from both of the extremes and try to find some happy medium where we actually ship products on time that are well designed (and not OVER designed) and easy to maintain.
-
Oh, and the other thing that is worrisome is people saying, "We're on a tight deadline, so I get to write crappy code."
Best wishes, Hans
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'
-
Russ-T wrote:
Yes, granted, you're here to ship products. However, if your code isn't clear and maintainable then you really are just making a rod for your own back and not helping anyone at all!
You are exactly right. Consider though if the choices available are A) make a rod for your own back or b) not ship a product, have no customers and consequently run out of money and have no food. I'd choose option A every time. That to me is what it comes down to. There is no answer that is always right, it always comes down to the circumstances of the business at the time.
exactly. which is why almost all contract gigs involve duct tape. start-ups involve duct tape too because you don't know if anyone's actually going to buy it. The only time you don't have loads of duct tape is an existing business with an established product, and you're writing something new, or getting to re-write something. Then MAYBE you can take the time to do it right because you know you have to support it. Or, if you're lucky enough to get a boatload of VC money right off. Still waiting for a gig like that :laugh:
-
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.