Duct Tape and Programming
“Duct tape programming” is not something I would ever want to be accused of, though recently Joel Spolsky wrote a feature suggesting it was a virtue. There are several implications made by the slapstick name. I hear the phrase and envision an individual frantically patching leaks in a card-board boat. For that same reason I wouldn’t trust someone who embraced the title “duct tape engineer” or “duct tape doctor”. I don’t really believe the term should engender professional respect.
Code made to be thrown away may be written in almost any manner successfully (prototypes and import scripts for unique systems come to mind.) I am speaking of long-lasting or large systems as I describe my views below.
There are no appropriate times for quick patches at the expense of system integrity. Sometimes hard-coding a value is a legitimate solution to an immediate concern. When you find yourself hard-coding several values maybe it’s time to refactor. The worst thing you can do when traveling the wrong direction is to keep going. You’ve got to turn around. Quick and dirty fixes accumulate and build off of each other if they are not properly dealt with they usually cost more time to maintain than they ever saved.
“[A duct-tape programmer] is the kind of programmer who is hard at work building the future, and making useful things so that people can do stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute. This will happen while other programmers are still at the starting line arguing over whether to use titanium or some kind of space-age composite material that Boeing is using in the 787 Dreamliner.” -Joel Spolsky
The duct-tape programmer may have a fine strategy for go-karts, but I would really prefer the second group build my formula 1 race car. If I’m in the middle of a race, sometimes duct tape is a good temporary solution for minor emergencies, but it is not what I want the entire chassis made out of. It should not be what holds the wheels on.
“When you are done, you might have a messy go-cart, but it’ll sure as hell fly.” -Joel Spolsky
I don’t believe expert developers make messy go-carts. I do believe there will always be some rough edges. There will always be something that could be a bit more flexible. Some things may not make it, and other things may not be polished. That said, the result of an expert’s work shouldn’t be messy. Elegance is what we strive for, acceptable is what we usually achieve. A mess is the mark of an amateur.
In the development process you may make a hundred little messes as you go, but I have found it faster to clean as I go than to simply let them build up. A writer will go over the last sentence and attempt to clean it up, then the last paragraph and so on. Gradually they increase the scope of consideration until it seems to fit well and they continue writing from that point. The process is iterative, but also incremental.
I believe good programmers must also do this incremental iterative editing. To fall back on the writing analogy, it would be a daunting task (possibly requiring a re-write) if you never re-worked the sub-sections and left all editing to be done upon completion of the work. In this way, even if you do not have time to complete a module to perfection (as is often the case), it should at least be beyond the state of a “mess”.
One of the primary theories of why the “un-sinkable” Titanic sank involved weak rivets and unskilled riveters. The combination of bad materials and poorly skilled rivet workers was certainly a concern, but at the end of the day they got it done. They made a marvelous looking ship that would appear to function in day to day use. This “get it done even if it is messy” attitude is the “virtue” being touted by Joel Spolsky.
“Many of the rivets studied by the scientists — recovered from the Titanic’s resting place two miles down in the North Atlantic by divers over two decades — were found to be riddled with high concentrations of slag. A glassy residue of smelting, slag can make rivets brittle and prone to fracture…
In their research, the scientists, who are metallurgists, found that good riveting took great skill. The iron had to be heated to a precise cherry red color and beaten by the right combination of hammer blows. Mediocre work could hide problems.” -New York Times
Other factors were at play with the Titanic. An out-dated rudder design would have made it more difficult to steer out of the way of dangerous obstacles. Clinging to simpler, older methods may not always be a good idea. A simple rudder design may have worked fine on a smaller ship, but as scale increases you cannot always simply take what you were doing and make it bigger. For this same reason C is not always the appropriate solution, object oriented languages such as C++ shouldn’t be ruled out simply because they can be misused to increase complexity.
It may be that 1,517 people died because of poor materials, inappropriate design considerations, and inexpert craftsmanship being used in the face of a deadline. Note the use of the word inexpert. The riveters were capable of working and getting the project done. The ship held together. Unfortunately this isn’t good enough when stressing a system over time.
With software development stresses are typically thought of as performance and user/data scaling related. I also consider the stresses applied to expanding existing systems and fitting in new ones during the development and maintenance process. Over time the ability to intelligently re-factor and avoid ending up with a mess becomes more important.
Can you afford to hire inexpert programmers to build the foundations of your business? Will your marketing guys call your product un-sinkable?
Let me be clear in explaining that I understand there is a bottom line. But even if it does not cause human casualties, the collapse of a large software project does have real repercussions. Careers are ended when software developers do not take their responsibilities seriously (or when they are told to ignore them by the people who pay them). Management is left to wonder why something which appeared to work fell apart at the seams.
The facade the user interface presents can be very convincing. A solid user interface usually means the users believe the entire system is solid. People attach their expectations to what they can observe readily, but as experts we need to see more and be proactive in maintaining quality throughout the project right to its core.
“Ceci n’est pas une pipe.”
The argument I often hear in defense of the “bottom line” is that “customers don’t care how it is made as long as it works.” This is true, but there are hidden dangers to poor construction which may result from the single-minded desire to deliver. If good development practices are not observed on important systems the technical issues will overcome any possible short-term time savings. Good software development should not involve sacrificing features for architecture, or sacrificing architecture for features. A balance can exist without resorting to wild extremes in either direction.
The fact that customers don’t care how a product is built is not a valid excuse for poor craftsmanship. A chair which appears to work properly, but falls apart after a year of use reflects poorly on the craftsman.
It is not enough to deliver a product that works well. People who argue that it is good enough are short-sighted. We must deliver products that can grow well to match future requirements. We must ensure we are careful in building solutions which do not contain rotten cores lest they collapse in on themselves. Getting performance anxiety and over-thinking problems may be a problem for people more interested in architecture than solutions, but you can be a thoughtful and productive developer, the two are not mutually exclusive!
Solid development goes hand in hand with a reliable product. You want your business to rely on reliable products. If it does not, you may find yourself wondering why you’re clutching at wreckage.
Duct-tape may be excellent, but I just don’t trust it well enough to hold all my rivets in place.
October 16th, 2009 at 2:39 am
After reading Joel’s post I was hit by a sort of light that let me do work without worrying whether it was the best. I agree - this type of work shouldn’t _always_ be undertaken in this way, but - at times - it gives you the edge - and as long as you remember where the holes are and fix them later then surely everyone’s a winner.
I usually take Joel with a pinch of salt and read out the good bits of what he says and ignore or re-think some of the crazy bits; If you’re a developer that sits home all day writing apps but doesn’t think they’re good enough because they’re not “perfect” then Joel is giving you the power to realise that “shipping is a feature” and whether your app is perfect or not the fact that you got there first or you have at least somthing is better than nothing. You can always re-write the thing later but to get you on the lader duct tape is a great way to go.
I also think Joel sometimes makes analogies out of things but at the end of the day he’s really talking about code - comparing the go cart to the titanic is a far reach, as would be comparing bug tracking software to real time medical equipment.
October 18th, 2009 at 4:47 am
First, thanks for your response on my lonely little blog! I respect what you’re saying here. Taking anything with a pinch of salt is pretty much a given, lately I’ve been needing half the salt shaker on some of Joel’s posts though. I think you’re getting the right message from his post, but look at all the things you’ve had to ignore to get to that.
Sure, at times it is a fine thing to do. Throw away code and small projects for specific tasks are two places it could work fine. Any situation where re-writing the system is realistic and won’t take more than a week or two you’re probably steering fine too (just watch for those projects growing beyond that and being terrible as a result. This happens sometimes when prototypes are used to start production by accident which is one of the most dangerous things about prototypes and applies here as well.)
I did my best to mention that you can get away with a patchwork approach in some cases, but it was just a quick mention. Mostly I’m worried about Joel preaching poor practices increasingly more often. Things like not understanding what unit tests are useful for exactly, and suggesting that code quality doesn’t really matter are two examples. I don’t care if he means something other than what he says, I live in a world where you can’t just say “quality doesn’t really matter” and have me believe you mean the opposite of that.
Jeff Atwood may have been having a bad influence on him, I’m not sure.
I am one of the guys “getting things done” I am not afraid of getting my hands dirty and actually solving real world problems. Check out my “Pandora’s Jar” hack a few blog posts ago for an example. I work as a full-time developer to pay the bills and program in my spare time for fun. I know you haven’t suggested otherwise, but I thought it might put some perspective on my “do it right” suggestions.
I think it’s great to let people know that you should not get too hung up with trying to be perfect. Perfection is impossible to achieve. It is probably one of the biggest causes of procrastination (other than sheer laziness.) That paralyzing fear that you’ll fail is something that should be dispelled (the fear, not the part about failing*) and is a real problem. But I don’t feel Joel was tackling that really, he may have touched on it, but really I think he was looking for an excuse to jab at TDD and people like Robert Martin who actually work on big systems and care about code quality. That’s what bugs me about the recent posts.
*We all fail, almost every decision you make will be sub-optimal and as a result you would probably be able to re-write any project and make it better. The difference between good and bad developers is probably largely in how they handle failure.
October 20th, 2009 at 12:43 am
Lol, I have a bunch of Google-Alerts set up on various keywords; It proves much more fruitful than following links and shakes up my usual rss feeds a little with some fresh content :-p
I have to admit; As I’ve gotten to “know” Joel I’m not sure if his articles have changed or if it’s me that’s changed - a lot of what he used to write gave me a good push in lots of the right directions and I even used some of his ideas (especially for the office) at my old place. I had lots of friction with the managers but thankfully came out on top and being happy developer.
Lately he seems to be drifting and his articles are much shorter, but I don’t care if others follow his advice to the letter; A good programmer/person takes inputs from lots of angles and works out the best ones to use; I’m quite pleased with how stack overflow turned out so whatever Jeff is doing - whether it’s following practices or not - its working and working quite well. I’m not much of one to “tamper” with the world so if I see somebody listening to Joel and I think he’s wrong I’ll just let them carry on - at least they can explore their choice and return with an answer - who knows, they might invent a new process along the way.
I think Joel secretly likes TDD but is just tryting to stirr up the community to get a straight answer or to make his own decision; He’s said a bunch of times in his podcasts he often has a strong opinion that can sway between yes and no - and as we all do - this often shifts quite sharply as new information is learned - so maybe one day when he “gets” TDD he might tout its benefits.
October 20th, 2009 at 12:50 am
Oh I forgot to mention; I too am a full time developer - have been for over 4 years now (ended up skipping University and starting at the bottom of the ladder as mere Junior Developer :-p); It pays the bills and I enjoy most of what I do - however, the programming I do for “work” or rather, sombody elses is dare I say - of less quality - or of less value to me anyway.
The code I wrote personally - as a craft, rather than a job - is much more refined and better optimised; The value code has when it’s for your own benefit or soon to be making YOU the money - seems much more, than when sombody is paying you to do it; especially when sombody is paying you one amount and they’re recieving another (which is often the case in larger companies).
I try to bring a lot of what I do at home into the work place; especially regarding testing and a “better” working and testing environment but some things are just too hard to justify; If the client can’t see it and the code is just a one off; who cares what it looks like or if it was test drvien or copied from somewhere else - if it _works_ and the client is happy; Job done; if they want it to change and we wrote it wrong; change em for it - they’ll pay. This is where I think the “get things done” comes in to play, I don’t always agree but again, I get paid, my employer gets paid and the client is happy - why strive for more :-p.
October 20th, 2009 at 11:17 am
I’m not quite sure I agree with your dichotomy between the workplace and home, but I do understand your point. Call me an idealist, but I really believe you should take pride in your work regardless of the situation. If you don’t, maybe you need a change? I’ll admit that I can’t always make the project clean and good, it’s hard when you’re working with other people who make their own decisions on how some things should be. Those decisions may compromise your own ability to work well, and I understand that can make it tough to do well. Management, deadlines, and fellow programmers who don’t care as much as you are all potential hurdles, and sometimes it’s a bit too hard to clear, but that doesn’t mean you should give up!
You do say you “try to bring a lot of what you do at home to the work place”, you’re reading tech blogs, so obviously you care about doing a good job. Please don’t take the above to indicate I think you’re doing any less than your best.
__
TDD is a lot more controversial than just plain unit tests. I won’t fault Joel for not being convinced of TDD, but I don’t think he even understands the benefits of unit testing really. I think most people can agree that unit tests have value, not all people, but many. Test driven development, on the other hand, seems like it’s a bit tougher to totally get behind because it drastically changes work flow instead of simply adding a new tool to your toolbox.
I’m not really sure if it is a beneficial thing or not, personally. I think it may be in certain applications, but I can see it getting in the way if you know what you’re getting after in the first place. I’m not really sold on the 90%+ unit test coverage, I seem to do pretty well at around 50-70% which is enough to pick out most of the problems I may end up introducing in a system and takes very little time to do. Maybe it isn’t ideal, but it seems like the best return on investment.
I’d have to try TDD to really say if it’s great or not, I’ve kind of dabbled a bit with it, but haven’t seriously applied it, so this is all just my best guess based on my experience with unit testing. As I said in an earlier post, I typically design top-down and program bottom-up. This means that sometimes I’ll draw out the end result much as a TDD practitioner would, but it also means sometimes I’m working above the code level and don’t do that. So I already kind of do this, I just haven’t really formalized it and I don’t know if formalizing it in test cases would be beneficial.
__
There are a few very good reasons to always strive for more, I will write a new post about this sometime this week! Thanks for the inspiration for a topic.