Slashdot Mirror
The Duct Tape Programmer
theodp writes "Joel Spolsky sings the praises of The Duct Tape Programmer, who delivers programming teams from the evil of 'architecture astronauts' who might otherwise derail a project with their faddish programming craziness. The say-no-to-over-engineering attitude of the Duct Tape Programmer stems not from orneriness, but from the realization that even a 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it's in your lab where you're endlessly polishing the damn thing. Like Steve Jobs, Duct Tape Programmers firmly believe that Real Artists Ship."
my employer knows I can whip out a fast 4,000 line (but ugly, no artistic talent) web portal or e-commerce app in a month when it should be a 20K line project done by a team, so that's what we do. dangerous I think, we handle real money with that shit.
I'm plagiarizing a point I saw on Reddit and I'm too lazy to find the original article, but I agree with the author of it: there doesn't have to be a choice between "crappy duct tape" programming and "crappy over-architected" programming. A decent programmer can get both: a small program that does its job well, AND can be extended in unplanned-for ways for new functionality.
Several issues cloud this mix:
At the bottom of every successful development are a few people who just get on and write the code, it's where it actually happens. Ever see a hole in the road where one guy is down the hole with a shovel, and 4 others are stood around the top? I'm the guy down the hole, have been down coding holes for 20 years and pretty much every project I have started coding, I have finished and delivered, some where big methodology driven things, some where me against the world with a couple of weeks to deliver. But get keen interested and pragmatic people on the shovel and the job gets done
Art is the mathematics of emotion
Only unit test what needs to be unit tested. If it needs to be tested the testing will pay for itself. If it's simple enough that it doesn't need testing, then you're wasting your time writing those tests.
Half the benefit of the unit tests/test-first methodology is that they force you to design even your internal interfaces in a reliable way. The other half is knowing you didn't introduce regressions in that oh-so-clever code.
For most projects you don't need a whole lot of tests but there will be a couple of subsystems that you almost can't manage without them.
I'm completely with you on that one. What Joel is effectively lobbying for is what I've long termed "Shit and fix" coding. You write something dirty but quick to meet the minimal needs of the project. You have non-existent testing, inconsistent modularization, and a maintenance nightmare that crops up every 6 weeks as the application breaks or users request a functional change.
After a few years the application is such a mess and original knowledge sources are so far gone (documentation? what's that?) that the only option for the company is to recreate the application from scratch. Blowing tens if not hundreds of thousands of dollars on fixing the pile of crap that has been building up.
There is definitely a balance between over engineering and minimal effort. I've seen efforts to go in both directions. If I had a dollar for every time I saw someone put IO operations on the GUI thread in Windows, I'd be a rich man. But at the same time, I've seen people design data abstraction layers that turn a 3-tier application into a 7-tier "solution".
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Software is about money guys.
Which is exactly what is wrong with software. Software should be about creating a useful tool. When you have a blacksmith who cares more about money than his craft, you have a poor blacksmith indeed. When you have a musician who cares more about money than music, he produces crap.
No wonder Linux is less insecure than Windows. Linux programmers are about making tools, Windows programmers are about making money.
Free Martian Whores!
I don't think this guy ever worked with any software engineer with any significant amount of experience. Or maybe he just works with people that suck as software engineer.
The typical evolution towards wisdom in Software Engineering goes like this (simplified):
At best what the guy in the article is calling "duct-tape programmer" is somebody past the 3rd transition only and what he calls and "astronaut architect" is somebody past the 2nd transition only.
I would hardly call a junior designer type "architect".
According to TFA your reputation doesn't matter, just your ability to ship now now now.
In other words, how to be Electronic Arts. No thanks.
- Michael T. Babcock (Yes, I blog)
My experience is the Duct Tape Programmer writes the worst kind of spaghetti code in the world. The best way to deal with someone who is over engineering the system is for his project manager & team leaders to do their job and shoot him down to size!
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Agreed. I have a guy on my staff who is constitutionally unable to cut corners. The upside is, when he says the feature he's working on is done, by god, it's done. I can't remember the last time we found a bug in his code. The downside is, it takes him a long time, and sometimes we would really like to have the first 80% of the functionality done quickly so that other people could start to build on it. Don't get me wrong, this guy is really good and I'm very glad to have him, but he would be even better if he cultivated a sense of what corners to cut when.
Your god may be dead, but mine aren't!
Exactly. All of Joel's articles about about good to expert developers. More than likely the people he describes could use any tool or methodology and ship correct, working software.
This reminds me of when people try to copy a particular athletes workout or diet. Most professional athletes are genetic wonders and many succeed at their sport not because of their workout and diet, but in spite of it.
Well, I am - more or less - a duct tape programmer, coming from the embedded field of work.
Two months ago I took a Java training course, never bothered to learn the language right before. One of the students at the training was a woman in her mid-forties, former quality assurance, with a wish to develop software. Last time she has written real code by her self was at the university 20 years ago. After that she only has read other people's code, tested it, found bugs there.
After a couple of days of introducing Java and the whole OOP concept, the teacher gave us some exercise. I don't remember what it was exactly now. What I do remember is that I hacked some code together, not bad at all, with lots of features, much more than it was needed, but since I was so fast, I was very smug about it.
Then the teacher showed my code to all students first, said it was a pretty nice solution with some tricks he never had thought of. Then he showed us her code. That woman had neatly written the task down first, planned everything carefully on paper and then implemented it, with lots of comments and an extremely clean and well-engineered code. Her solution wasn't quite as sophisticated as mine, but the code was so much more readable...
The teacher said that such code was the way to go, and as smug as I was over my solution, I had to admit that her job was much better done. Sure, features are great but clean, maintainable and well-planned code trumps in long term.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
Are you referring to duck typing?
http://en.wikipedia.org/wiki/Duck_Type
(For the uninitiated, this is one of the reasons Ruby and Python programmers can deliver code in a tiny fraction of the time it takes Java or C# programmers.)
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
It's called the video game industry. That kind of methodology works there because you're generally not going to be maintaining the code base once it ships. There are three types of people you need to have a viable and successful team:
1. People who can do abstractions, design, and estimation.
2. People who can implement those designs (Duct Tape programmers are perfect for this).
3. People who can do a little of both.
I call bullshit on any one of these groups pointing the finger to the other and saying, "My way is best". If you had an office of nothing but designers you'd have a different but similar set of problems.
I've seen projects run only by duct tape programmers fail miserably in the field when extensibility and maintenance are required, but when we added a designer to that same team and rewrote the same project we delivered a bug free implementation with a 10 fold performance increase, and no significant bugs. That wasn't magic, it was just taking the time to do the damn thing right (and no more time than that).
A good architect is someone with the experience to know when to cut corners and when to enforce rigid discipline.
Couldn't agree more. A good architect making informed decisions (including when to break out the duct tape) is what separates the cowboy shops from the successful companies.
It amazes me that there are a ton of experienced people that are applying for architecture positions that think that coding is somehow beneath them. When I am applying for a job as an architect, I always tell the employer that I will need at least 6 months of "real programming" on the product before I will be able to do any significant architectural changes. You need concrete knowledge of where the bodies are buried to know how to proceed.
Without the trust of the developers (which is only gained by demonstration of competence) or knowledge of the underlying idiosyncrasies of the system, any change an architect makes is destined to fail.
I guess in my experience, your example doesn't really go anywhere to disprove the article. IE I had a project where we followed all the correct design principles and did 2 years of work * 5 developers for a project that was to be the future of the company. Another division had started before us a similar project with slightly different goals. The sold management on their duct tape software that met some of the spec before ours. So my project got canceled. Their duct tape software had to be completely re-written to add the remaining features (8 years later they still haven't surpassed what we had almost done.) The fact that they were done (with something) first won out. The fact that duct tape allowed them to provide the solution, and buy them the time to re-write it, in my mind showed how it makes them more successful (I did replace a bunch of their code with ours, and the correctly written code spawned other projects to use its base, so not a failure.)
So the fact that your co-worker got the jobs, seamed to show people they needed that solution, and thus seams thats the reason you got the time to re-write them. Shows that duct tape programming "works." Even if it isn't always the most efficient method in the long run. IE this is about how many projects have just been abandoned because they were stuck in doing it the right way, where you slap something together, you got your foot in the door, and may buy the time to do it the right way.
For some people writing software is also about paying the rent and buying food.
Do a job good enough that people want to pay you and you will be payed, but do shitty work and nobody will want to see you again. My dad always told me that about his construction but it applies here too.
Anything can be found funny, from a certain point of view.
Refactoring is an art that all programmers should cultivate. It turns shitty code into nice code, without breaking it or losing all the bug-fixes that have been hacked in over the years. In most cases, ugly code needs refactoring, not rewriting.
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
Does that mean if I like kids I shouldn't watch pron?
... than a half assed product full of bugs in your enterprise: One nobody uses that's been sitting on someone's test server for 2 years.
It's been my experience that if your project takes more than 3 months, someone else's project to do the same job, half assed or not, is the one that will be used. There's always some busybody doing a secret project, which they will show to a VP, usually on their smart phone, while they are buying them drinks at happy hour.
Then when it doesn't scale, they'll find a way to blame their co-workers, who will need to work overtime to make the steaming pile of dung work, while the guy that built it is gathering requirements for his next shitty project. He's a mover and shaker after all!
Git'er done or get plutoed. People don't care if there are bugs, as long as you fix them. They get really pissed when they have to wait ; )
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
This is why there is, in agile methodologies (or at least the descriptions I've seen of them, there's a whole lot that passes under that name) the usual recommendation is write a unit test, write the code to make it pass, rinse, repeat. /b
I agree with you. I've seen it work beautifully.
It just works less good in chaotic situations. It may not be feasible in a time frame to write unit tests for legacy code as things get tangled (think entanglement with production database entanglements and tight schedules)
My compromise methodology now is to add a unit test whenever a bug is found, for detecting that bug. That way, I don't wast time with testing things almost as trivial as x = 1; x++;..check if x is now 2. That way, I'm confident that the bugs unearthed by usage will not remain. Evidence that this works? Our team's bug count was 2 minor last I checked. The average for other teams (with admittedly larger code bases) is in the dozens.
Indeed. I have a friend who works in construction. His boss is a stickler for quality and tries to keep costs down as well. As a result, he has more business than he can handle while his competetitors are cutting corners, charging high prices, and going out of business right and left.
Free Martian Whores!
I brought this question up informally to my coworkers. Punishment or shaming, which I'd read about, doesn't seem to have the desired effect. More of them were of the opinion and experience that code reviews went a long ways towards improving programming skills, including one recent Google hire who had good things to say about Mondrian.
No, duct tape usually starts in Release 2. Release 1 usually has an architecture that does just what Release 1 needed, and is flexible enough to handle certain modifications that thought might be necessary in the future. But Release 2 adds a new feature that just can't fit into the architecture, and is something no one anticipated. Sometimes the original architecture turns out to be too rigid, or sometimes it's incredibly flexible but no one can figure it out (release 1 programmers are often not around anymore). Sometimes it's Release 3 or 4 where the duct tape first has to come out.
To be fair, you must concede that while the static languages catch some errors at compile time which might not be caught until runtime (or ideally, QA) with a dynamic/duck language, the static languages also "catch" a great deal of non-errors which the programmer is forced to deal with even though they never would have caused problems at run-time, while having the side-effect of reducing code re-use.
Having to fuss with every little inconsequential detail has an advantage as far as testing goes, but it does come with a great cost as well. Some would argue that dynamic/duck + extra testing has the same effect with less cost than static + less testing.
Ruby and Python have only been "mainstream" for a few years, while static languages have been around since the ancient days. We have yet to see how high they can rise, but I'm betting they'll go pretty far--especially considering the fact that QA teams are far less expensive to business than programmers are.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Such as ...?
Yeah, that's probably going to take up a few kilobytes of your gigabyte of RAM. Seriously, I believe this is very, very rarely a problem. I'm more concerned about the bloat effect of inlining (which has little to do with templates).
You mean the < and > are clutter, or what other information in e.g. map<string, int> do you feel is clutter and not vital parts of the type name? Or are you talking about the definition of the template? I'm not sure I understand.
*Boggle* Do people still *do* things like that?
I somehow get the feeling that you see templates as just a way to define the C++ standard containers: list, map, vector and so on, and that you dislike them so you define your own lists, maps and vectors using void pointers and casts. That is not at all how I use templates (someone has already written, tested and documented those containers for me). Mine tend to be tiny utilities, like accumulator (some integer type which starts out at 0 and can only be incremented) or small function templates which do stuff to similar but unrelated types. I use them mostly to make my code simpler and easier to use, by removing tedious duplication.
And yet again, the argument for multithreading boils down to "I must max out my CPU resources using no more than a single process"! The situation you describe is bad only if (a) more performance from the program would be nice, (b) a multiple-process design isn't easier and safer, (c) you can handle the extra development cost for a multithreaded design (as you said, it's hard), and (d) you have no other use for the other seven CPUs. That situation can happen, but it's rare. Most threading is due to stupidity, not a real need.
Mine too, but I identify with Spolsky's duct tape programmers (not the term, but the idea).
We all set the limit somewhere ... Spolsky, JWZ, ESR and a whole lot of slashdotters think C++ is on the wrong
side of that limit. I like to think they're basing that on old information, from the hype days in the 1990s
when everyone had to pretend that they were developing abstract general reusable libraries
rather than Getting Work Done. I think that sick attitude is mostly gone from C++ today
(although some (not all) Boost libraries give me nasty flashbacks ...)
That is something to be grateful for,
Sure you have a choice. You can pick a task which has no need whatsoever for multithreading, and add threads. Lots of people do this, when a sane select() loop would have been enough.
Years ago I was an editor of a magazine about Eiffel programming language I wrote this editorial on differences between low-level and high-level of coding.
...richie - It is a good day to code.
Thank you for pointing this out. I love reading Spolsky and I think he has a lot of good ideas but he doesn't always express them very well. This second half of his closing paragraph is extremely important to put the article in context and I think should have been stressed at the very beginning in my opinion:
Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and weâ(TM)ll forgive them if they never write a unit test, or if they xor the âoenextâ and âoeprevâ pointers of their linked list into a single DWORD to save 32 bits, because theyâ(TM)re pretty enough, and smart enough, to pull it off.
Specifically at the beginning of this article he names Jamie Zawinski as the programmer he is talking about. JWZ is a darn good programmer. There is a reason he has an entry for his name in wikipedia. Most of the people developers work with who exhibit these tendencies that Spolsky is describing in JWZ are not good developers and can't get away with it. It should be pointed out that exhibiting these traits will not necessarily make you a good developer. IMO The point Spolsky is trying to get across is that blindly adhering to a development strategy, tool, or architecture methodology will not make a person a good developer either. I too would rather see more articles about how to make the mediocre developers better.
Good enough means good enough. It's not 50%. It's not 80%. It's whatever is the powers that be decide is the appropriate trade-off between competing interests (i.e. time to market, cost of deployment, $ paid to developers, estimates of the cost of future bug fixes, ...). If the market doesn't accept the product, it only means that their definition of "good enough" was wrong, not that there isn't a different "good enough" that the market will embrace.
"Good enough" for the software that runs a nuclear reactor or the space shuttle is probably near 100%. Pace-makers, surgeries, and pharmaceuticals failing? It's been known to happen. Sure, maybe only in 1/10000 cases, and only if you don't have a pre-existing condition. So, good enough is maybe five nines there. "Good enough" for that $1 umbrella you bought at Wal-Mart probably means something entirely different.
I really like when people make insightful comments, while shooting themselves in the foot -- hard.
>As your program goes on, you clean it up, add abstractions where needed. The first version of Word for Windows didn't look ANYTHING like the current version. If you are going to make a new word processor, you go after the old version, not aim at the sky.
Let me copy page 207 of Taming Wild Software Schedule, because this is just too good to be ignored (you can find the text in amazon by doing a "search in content for WinWord"):
The development of Microsoft Word for Windows 1.0 provides an object lesson in the effects of optimistic scheduling practices. Word for Windows, aka "WinWord," spent 5 years in development, consumed 660 man-months of developer effort, and produced a system of 249.000 lines of code (lansiti 1994). The final 5-year schedule was approximately five times as long as originally planned. Table 9-1 on the next page summarizes WinWord's scheduling history.
WinWord had an extremely aggressive schedule. The shortest possible schedule for a project of its size is about 460 days. The longest estimate for WinWord 1.0's schedule was 395 days, which is 65 days shorter than the shortest possible schedule.
Development of WinWord 1.0 contained classic examples of the things that go wrong when a software project is scheduled too aggressively:
â WinWord was beset by unachievable goals. Bill Gates's directive to the team was to "develop the best word processor ever" and to do it as fast as possible, preferably within 12 months. Either of those goals individually would have been challenging. The combination was impossible.
No hard feeling, but that was too good to miss. Anyway, it can actually be used to prove your point: they aimed too high. But, being Microsoft, they succeeded anyway. Overall, I am almost ok with your argument. The only dark side, is that sooo many companies now deliver crappy duct tape one-shot software that hardly work, and never update it, because they go under due to pissed customers...
Here's a great rule of thumb I use. Let's say you're writing a function to do some bit of functionality. Typically you're going to write that code, and then put together some code to check it out real quick before you proceed with the rest of your application. Usually, the cheesy little try-it-out code gets thrown away. Whenever you catch yourself starting to write a little piece of outside code to just check sanity check your method, instead write a unit test for it, and stick that unit test into the comments. I love to use doctest for this in Python, and I imagine there is some analog to it in Ruby.
A lot of people go through the trouble of writing simple little testy code to make sure stuff works, without going through the trouble of saving that code. It takes a little effort to set yourself up so that code can be saved for posterity. But if you do it early, it really doesn't add much to the effort at all. And it makes it much easier to make changes later to the code and to do so with confidence.
You need a boatload of automated tests so that it's actually relatively safe to go back and refactor things without breaking everything.
I know it's a fad for you guys to go on about refactoring things, but it's hard for me to believe that there are very many of you that aren't already breaking task interfaces down enough in initial coding, so I don't believe in reality refactoring even makes sense despite the constant talk about it, and two it's hard to believe the ones of you that mention this refactoring business as some sort of given work for a business unit of any appreciable size that uses the software.
Making a change to any software in production is a disruption to business, essentially a forbidden disruption for anything that isn't broke. And as I read the /. posts through the years referring to this refactoring state of mind, the theme is that of improving maintainability, which as I've posted through the years is complete hogwash. By changing the code and requiring complete retesting and signoff by the business, the time, effort, and disruption to the business that is alleged to be prevented has alrteady taken place, much more than any actual required business logic changes that eventually will be made.
Although I'm sure most of you must work for businesses of appreciable size, it's a very strange scenario indeed being touted that most certainly is unacceptable to any business.
I am sorry that I unload this on one random post mentioning refactoring as some given, it's just one of many in any /. programming thread.
rd
To be fair, you must concede that while the static languages catch some errors at compile time which might not be caught until runtime (or ideally, QA) with a dynamic/duck language, the static languages also "catch" a great deal of non-errors which the programmer is forced to deal with even though they never would have caused problems at run-time, while having the side-effect of reducing code re-use.
Um... no. I work with a proprietary duck type language and Java at work. Java does not catch non-errors, IMHO. On the other hand, we have to test the hell out of the duck type language because we can only find the bugs at run-time, and with the complex code we write at work, that takes a LONG time!
Duck typing is nice and has some nice features. I think it makes remoting such a painless thing to implement. But in practice, I do not find it is better or faster than statically typed languages. In fact, if you are working in a large team, static typing is faster because if goober over there on the other side of the floor changes his interface, he is the one who notices it and has to fix it. In the duck-type language mentioned above, I find out about it when the next nightly dev build happens and I spent half the morning fixing problems he caused.
Duck typing is simply different. It has certain strengths in certain situations, just as statically typed languages. I know this in an unpopular view but: the right language for the right task. Seriously, just because Python/Perl/Ruby is your Dremel motor tool doesn't mean you should remodel your kitchen and build your own cabinets from scratch with just a Dremel!
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com