6073341
story
Comments: 551 +- Developers: The Duct Tape Programmer on Friday September 25, @09:40AM
Posted
by
kdawson
on Friday September 25, @09:40AM
from the coders-at-work dept.
from the coders-at-work dept.
background: url(//a.fsdn.com/sd/topics/topicprogramming.gif); width:80px; height:48px;
programming
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."
Related Stories
: by
A great many people think they are thinking when they are merely
rearranging their prejudices.
-- William James
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.
So, does the Duct Tape Programmer... (Score:4, Funny)
Re:So, does the Duct Tape Programmer... (Score:5, Funny)
...also protect you from sellers of snake oil and fake gems?
No but I have a one-line perl script for that.
Parent
Re:So, does the Duct Tape Programmer... (Score:5, Funny)
What!? You can have multiple lines in a perl script?
Parent
Re:So, does the Duct Tape Programmer... (Score:5, Insightful)
Except that it isn't. Sure, it starts, runs for a few seconds, and then exits due to typing error.
All duct typing does is move type errors from compile time to runtime, which also means that you can never be sure if you've actually squashed them all. I truly hate that aspect of Python.
Parent
Type Errors Aren't Really My Problem (Score:5, Insightful)
Except that it isn't. Sure, it starts, runs for a few seconds, and then exits due to typing error.
Most of the time when I have an error, it's not a typing one. Sometimes it's something else the compiler would catch -- misspelled identifier, function or method name I misremembered (or forgot to implement), whatever -- but more often than not, I don't spend a lot of time hitting my face with my palm over a typing error.
No, most of the time, I find that it's my logic: I only *think* I've given the computer instructions that will accomplish what I want it to do. But I've overlooked something, left out a step, forgotten a corner case, whatever.
Having a compiler make sure my types are right doesn't generally contribute much to solving this kind of problem, at least for the common meaning of typing we're usually invoking when we're discussing this issue (e.g., typing as it's supported by languages like Java). You could argue that unit testing is kindof like a big type test (do these modules exhibit certain specified behaviors for their "type"?), and maybe there's a language that treats typing like that, which would be intriguing. But having a compiler tell me something like "class x doesn't have method y"? Not generally germane to most of the issues I have while developing, really, and even when it is, I don't really care if I discover this at run time, particularly since feedback is at least as immediate as what you'd get from a compiler if not more.
And meanwhile, as others have pointed out, I'm spending less time writing convertors/adaptors.
There are problem domains where I probably wouldn't use an interpreted/duck-typed language, but I find I'm more productive when I can use them.
Parent
Re:So, does the Duct Tape Programmer... (Score:5, Funny)
Not really. I've seen way too much duct tape python and ruby code.
Parent
Re:So, does the Duct Tape Programmer... (Score:5, Interesting)
Parent
Re:So, does the Duct Tape Programmer... (Score:5, Insightful)
forgive them if they never write a unit test, or if they xor the next and prev pointers of their linked list into a single DWORD to save 32 bits, because they are pretty enough, and smart enough, to pull it off.
No, I don't forgive them for writing obfuscated spaghetti code and leaving it for me to maintain. Also FTA:
Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.
I laughed out loud when I read this. I write in C++. It's my favorite language. But I can't stand these Duct Tape Programmers who are the ones casting to void * because they can't be bothered with templates. Now I know nothing of COM or CORBA, but multithreading is generally not something you have a choice about. Avoid it if you can, think very carefully about when you need to use it because of the application requirements.
Parent
Re:So, does the Duct Tape Programmer... (Score:5, Insightful)
That may be true... although personally, I find that when I'm really cursing some other programmer's name and wishing disease and misfortune upon him and his family, it's the work of a "ten-levels-of-inheritance deep wrappers around wrappers that wrap wrappers that generate code on the fly" overengineerer, rather than a spaghetti coder. At least with spaghetti coding, I can walk through it mentally and figure out what's going on (although it may take a while) - with "clever" code, I can't make heads or tails of it without a debugger.
Parent
Re:So, does the Duct Tape Programmer... (Score:5, Insightful)
I bet Joel doesn't drive to work in a duct-taped go-cart .... and I bet he wouldn't drive over bridges or work in a building which wasn't designed by a proper, qualified engineers/architects.
Out in the real world his "duct tape" programmer would be called a "cowboy builder".
As for his ranting on C++: He's demonstrated his C++ ignorance enough times for C++ programmers to just ignore his opinion - he still thinks it's just C with added bloat. I agree that multithreading is harder than it looks but templates and multiple inheritance...? Puh-lease.
The final nail in the coffin of the rant is in the last line where he says it's ok to avoid unit testing but that xoring two pointers together is somehow cool. If you weren't ignoring him before you should be by now.
Summing up: Joel has jumped the shark, every article just confirms it more
Parent
Re:So, does the Duct Tape Programmer... (Score:5, Funny)
Build a Man a Fire, and He'll Be Warm for a Day, Teach a mean to build his own fire and ruin a perfectly good business opportunity.
Set a man on fire, and he'll be warm for the rest of his life!
Parent
True that (Score:5, Insightful)
Agile, scrum, patterns, unit tests, etc.
.
Interesting ideas, but can anybody show me *any* significant, quantitative, comparative proof of improved ROI?
.
Software is about money guys.
You can't measure Synergy (Score:5, Funny)
You can't measure Synergy man, you just have to feel it!
Parent
Re:True that (Score:5, Insightful)
Agile, scrum, patterns, unit tests, etc. . Interesting ideas, but can anybody show me *any* significant, quantitative, comparative proof of improved ROI? . Software is about money guys.
From experience yes to unit tests. The number of times regressions have been picked up by a test bank before deployment to the UAT (user acceptance testing) system it pays for itself many times over. Patterns save time when an experienced group discusses design, but with developer turnover I get the feeling I have spent at least as much time explaining patterns to new developers as I have saved.
Parent
Re:True that (Score:5, Insightful)
Parent
Re:True that (Score:5, Insightful)
Um, no, you just disproved your own point.
Netscape did deliver a browser years ahead of the competition... And in all its crash-prone, flawed glory, people loved it. It took the web from a geeky novelty to a mainstream phenomenon. Not until MSIE 5 came out, a full five years after the first version of Netscape Navigator, did Netscape finally fall below 50% usage.
So the moral here? Beating your competition matters more than elegance - But having a viable business plan matters even more.
Parent
Re:True that (Score:5, Insightful)
I'd say at least write tests while you're closing bugs. Having an easily detectable bug pop up again two or three releases after you "fixed" it seems to indicate (even to non-developers) that you don't know what you're doing.
Parent
Re:True that (Score:5, Informative)
Unit tests are only as good as the programmers who make them. And if the programmer can think of a unit test... chances are that his code has already accounted for it; after all it's the same person, and he will be in the same mindset as he was when writing the code in the first place.
Parent
Re:True that (Score:5, Insightful)
Unit tests are only as good as the programmers who make them. And if the programmer can think of a unit test... chances are that his code has already accounted for it; after all it's the same person, and he will be in the same mindset as he was when writing the code in the first place.
Uh-huh, and then a year later, he needs to add some new and complicated functionality, but needs the old functionality to work too. He thinks he's preserving the old logic, but it has been a while and he is not in the same mindset anymore, and prior to committing the change to the repository, he runs the unit tests and -- woops! -- it fails. He goes and fixes it, now both the new and old functionality tests pass, and he checks in working code.
And by "he" I mean "me".
Unit tests do wonders for myself and my group. We develop a large and constantly evolving code base. And we have a saying/rule-of-thumb: There are features that are automatically tested in our check-in procedure, and there are features that are broken. How do you determine what needs testing? Well what do you want to still work a year from now? There's your answer.
It's not appropriate for every situation, but it works for us.
Parent
Re:True that (Score:5, Insightful)
Actually you've touched on the running theme in all of Joel's articles. Good developers are good developers. A good developer can get away with being a duct tape programmer, because they are good. Chances are that good developer could use almost any methodology and/or tool and ship working software. While it's interesting to look at the tools and methodologies good developers use, I would rather see ways to make mediocre developers better.
Parent
Re:True that (Score:5, Insightful)
From eperson experience, I ahve seen all you list work extremely well.
the projects took anywhere from 10 - 20% longer to go live, but all of them went out with huge success and barely any bugs. In fact one million line project went out and only had 2 bugs. Not a single one had a complaints about missing features or bloat.
Anecdotal, yes; however I ahve been programming for a long time and I was amazed at how well it worked out. Freaking amazed.
The problem s not that they don't work, the problem is most places don't actually implement them correctly, or have on partial buy in.
If your turd never gets out the door, that's a people problem, not a problem with the method of development.
Yes, software is about money in business; however management needs to begin to understand how to quantify it better. Taking 20% longer but have almost no fixes or down time after release isn't easily quantifiable, as such in is seldom considered.
A good accountant will find away to make it quantifiable, and good management will look at the overall projects vs project done via other development methods.
I just wrote an application, almost all of the function were just reuse of previous projects I ahve done. How does an account quantify the value of reuse?
If you write database classes more then once, you are doing something wrong.
Parent
Re:True that - NOT (Score:5, Insightful)
I manage a small team of programmers. When I first started, I 'inherited' a developer, let's call him Crufty Joe, who had worked at the company for 20 years and had developed financial and hr routines on the old mainframe and spiffy new oracle apps system. Joe had developed a lot of code, but he was always having to perform updates and corrections...
Why? Because he was a duct tape programmer! He always got it done by the deadline, but then he spent 75% of his time maintaining the huge pile of cruft that he had left in his wake over the years.
Well, Joe retired and I had to place two developers on his projects for the next year just to clean out all of the old '50% working' routines, in some cases we just tossed the exisiting work and started from scratch. What was really frustrating about this was that the Oracle apps have a huge, nearly incomprehensible, but extremely useful architecture that he did not even bother to leverage, but just wrote around.
This story acts like stopping to think about what you are doing means that you are going to implement huge, stupid architectures, but in reality he is just making excuses for being a sloppy hack. I feel damn sorry for anybody that has to support this crap in the future.
Parent
Re:True that - NOT (Score:5, Interesting)
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.
Parent
Re:True that (Score:5, Insightful)
I'm probably a "duct-tape programmer" in some ways. How did I become one? By learning everything I could about being an "architecture astronaut" first.
You learn how to do things properly and then you know when and when not to step back from that. If anyone RTFS and says to themselves they don't need to have a good solid understanding of the principles of software design or even a grounding in some of the popular modern methodologies. The linked article is full of colourful metaphors about go-karts and WD-40. Making your argument by metaphor is usually a bad sign - you use them for people who would have trouble understanding the subject if you just stated the case plainly. I hope that's none of us. The article writer seems to see some great division between those who "wield their WD-40 and duct tape elegantly even as their go-kart careens down the hill at a mile a minute" and those who "are still at the starting line arguing over whether to use titanium or some kind of space-age composite material". Well the division between those two groups isn't normally one between two sets of people, but between two environments and resource levels. In an ideal situation, I'll create a rigorous specification and use that as the formal basis for my unit tests and do things by the book. Sometimes I find myself "careening down the hill" because I'm suddenly dumped a big, live system and told "make these vaguely described modifications by yesterday". And I'm the same individual. I'll tell you what I want to see if you're in that latter environment - I want to see someone who understands what corners they are cutting and when to do so and when they can't. Same goes for some of the project management methodologies. You don't have to do things by the letter of the law of Agile development or whatever, but if everyone in the group understands the principles, it can streamline things.
Being better than the rest at anything doesn't come easy. This stupid article has some metaphorical "duct-tape programmer" who doesn't need to bother with the "achitecture astronaut" stuff because they're a whiz with their "WD-40". Enough with the metaphor. Show me the real instances of people who are better than others because they don't know about the theory.
Some articles are stupid. This is one. It's a load of overblown metaphor and hypotheticals. Ironically enough, it falls into the trap of dealing only in hypothetical and idealised situations that it lambasts some programmers for. Sure - if you're up against a tight deadline and in the midst of a melee of programmers, don't waste two weeks drawing UML diagrams and Gantt charts. But that sort of judgement has nothing to do with not knowing the principles of software design or project management. Banging out a quick website might be a case of shifting images left and right from day to day based on customer feedback. But real programming is most definitely not a "downhill go-kart race". It's about producing maintainable, reliable code that meets the customers' needs. And if you see someone who looks like they're gluing brilliant code together on the fly with "duct tape", you'll probably find they're someone with a lot of experience and who understands the theory well enough that you don't notice them using it. As Ovid said: "Thus by art, is art concealed." In other words - they make it look easy, because they're good.
Parent
Re:True that (Score:5, Insightful)
Nobody cares if it's ugly and stiched together
... except the guy who has to go into it six months down the road because a new requirement came up or a new system must be integrated
Parent
Ruel of Thumb (Score:5, Insightful)
Parent
Re:Ruel of Thumb (Score:5, Funny)
Well yes, but it's me and it's usually my own code. Perhaps this explains why I keep meeting myself in the halls.
Parent
Re:True that (Score:5, Insightful)
One of the important things I learned awhile after leaving school, was that no one really cared how elegant or perfect my programming was, they really just wanted the work to get done. Missing the deadline just to make things look better didn't help anyone. Of course it was nice to get code that was easily maintainable later on, but it shouldn't be your primary goal. I've seen some overengineered architectures that looked like someone was trying to make things easy to maintain, but the result was a nightmare to modify because no one understood all the layers and abstraction, and a "simple" porting job where the team took so much time creating the perfect portability layer that the product never finished.
Parent
Re:True that (Score:5, Insightful)
You'd be surprised how many money generating services run on top of really sloppy code that you wouldn't want anybody else to see. ... Nobody cares if it's ugly and stiched together.
I think this is true of many things in life outside the realm of software development: most people would be horrified if they knew the real story about how most things are made, and how thin the veneer of "quality" is sometimes. Over the years I've just come to accept that the universe is fairly forgiving of mediocrity.
I don't think this is a valid reason to intentionally do shitty work, but it's probably good to remember that if you make a good faith effort at building something in a non-sloppy manner, it's going to fare pretty well most of the time.
Parent
Re:True that (Score:5, Insightful)
Software is about money guys.
Which is exactly what is wrong with software. Software should be about creating a useful tool.
For some people writing software is also about paying the rent and buying food.
Parent
Re:True that (Score:5, Interesting)
Indeed. I have a friend [slashdot.org] 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.
Parent
my employer's fault (Score:4, Interesting)
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.
Re:my employer's fault (Score:4, Informative)
hahaha. you know, I once had a boss that would make stupid statements like that, how he could have done xyz in minutes. one day I threw the keyboard at him and said, "you are full of shit, show me!" that stopped his b.s. bragging to me at least, though he continued to b.s. everyone else.
Parent
Bad Mischaracterization (Score:5, Insightful)
The "duct tape programmer" is just as dangerous as the "astronaut architect".
What distinguishes good architects from these fools is this:
A good architect is someone with the experience to know when to cut corners and when to enforce rigid discipline.
Re:Bad Mischaracterization (Score:5, Interesting)
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
Parent
Re:Bad Mischaracterization (Score:5, Insightful)
After reading the article, there's nothing we didn't know before: release early, release often. But here's the killer quote all of you need to duct tape somewhere in your office right now:
Duct tape programmers dont give a shit what you think about them. They stick to simple basic and easy to use tools and use the extra brainpower that these tools leave them to write more useful features for their customers.
Parent
Oh no. Now all the numties have an excuse! (Score:5, Insightful)
False dichotomy (Score:5, Interesting)
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.
"Don't forget to ship your software!" (Score:5, Insightful)
Why is it that whenever I read an article by Joel I feel like I'm being talked down to?
Re:"Don't forget to ship your software!" (Score:5, Insightful)
Becasue Joel is an ass.
Seriously, he is an ass, and is often wrong.
Parent
Re:"Don't forget to ship your software!" (Score:5, Funny)
Hey, it's a great piece of advice if ex Duke Nukem Forever programmers read the article!
Parent
Re:"Don't forget to ship your software!" (Score:5, Insightful)
He starts out with a good premise, that as programmers we tend to want to over-engineer stuff and that is something we should try to avoid because it adds unnecessary cost to a project. Then he apparently has a brain hemorrhage and starts dumping on a whole host of invaluable software tools that actually increase productivity and reduce errors, both of which help you ship your code faster.
And what the hell is he talking about with "those breathtakingly good-looking young men"? Homoeroticism aside, what does this have to do with anything? The only thing I can see is that he's saying these guys can get away with horrific things (e.g. not writing unit tests, pointer voodoo--wait, I thought we weren't using C++-like languages because they're too hard and you can't ship quickly enough), simply because they are pretty and/or smart. I thought this was also how people got away with over-engineered projects too? The smart, charismatic guy proposes a solution that's over-the-top but everyone is too busy being in awe over his intelligence or their desire to fellate him that no one notices.
Am I way off-base here? As I said, I usually like reading Joel's stuff and I feel like I've learned a few things from his articles but after this I'm left wondering where he's getting access to such fine recreational drugs and hot, smart programmer guys.
Parent
even better than the duct tape programmer (Score:5, Funny)
is the duct tape manager
trying to hop in his chair to the phone, arms bound to the armrests with duct tape, screaming MMMMPH MMMMPH through the glorious dull shiny grey of...
what were we talking about?
Netscape a victim of too much duct tape? (Score:5, Insightful)
Curious that JWZ and his time at Netscape were particularly lauded here.
It's quite likely I'm being a bit snarky here... but Netscape lost the browser wars just a few years after they hit it big. And the core code of Netscape Navigator was bad enough that they eventually abandoned it around 1999 with the start of the Mozilla project.
Now don't get me wrong, it was only through the herculean efforts of guys like JWZ at Netscape that allowed them to ship a product at all. And certainly it made him and some of the founders a lot of money, which is a valid measure of success in business.
But to point to that particular code base as an example we all should follow? I don't think so. Certainly, choosing C++ then (or now in my opinion) is a mistake. And I've definitely seen people get overly rambunctious with architecture... especially in the Java world. But I think that's mostly the result of programming languages sucking as much as anything else. That and most people just aren't that good at design. Mostly meaning that when they've come up with a bad design themselves, they can't admit that and then really do what it takes to try and fix it. Of course, in the business world there are always severe time / money constraints, so that makes it real hard. And that's when not having unit tests hurts more... because it is harder to make significant changes to the code and have some assurance you didn't make mistakes.
Duct tape is fine, if you throw it away quickly (Score:5, Insightful)
Shipping is easy. Any idiot can whip something together that solves a problem, ships on time etc. That is rarely the issue. The issue is doing it in a fashion that will scale, be extensible, modifiable, understandable, high performing... the list goes on.
Given enogh time, any idiot could also make a system that is polished and architected to the point where it is fast, modifiable and extensible, and long overdue.
Bottom line: the whole skill of this business is delivering something that is architected enough while still meeting the deadline. In my experience, the necessary timeframe to deliver something long lasting and well architected is around five to ten times the time it would take to just solve the problem (tm). Of course many business exist today because they managed to release something to make money. The biggest mistake of many startups is probably polishing too much and not releasing early enough. The biggest mistake of those who DO make it past the first release is to not throw the first solution away and start over if it was something duct taped together.
Re:Duct tape is fine, if you throw it away quickly (Score:5, Insightful)
Everyone seems to be taking this article as "do anything it takes to ship" and saying that's a horrible attitude.
Your comment is the first I've seen that seems to be more along my understanding of the piece. Duct Tape Programming is about getting what is needed done and building from there.
"I need a website that lets people share videos".
So what do you do? Do you make a little site that serves flash videos? That's Duct Tape Programming.
Making a little site that takes videos and catalogs them and tries to analyze them for similarity and has editing tools and needs to be able to scale to 20 computers and... That's the problem.
When you start your site, it's OK to have it not be able to instantly scale out to 10,000. Sometimes it's better to get the basic features there and build them up and fix them as you go. Not everything needs to be there from day one. Not everything needs 3 layers of abstraction because it's "what people do".
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.
Your understanding of his post agrees with mine. This isn't about a system to last 20 years, this is about a system to fix things NOW while you make it better so your users don't have to keep doing things by hand for 6 months while you try to figure out why your framework build on another framework isn't interacting correctly with some other thing.
Parent
The problem with Duct Tape Programmers (Score:5, Insightful)
Joel Spolsky, meet TheDailyWTF (Score:5, Insightful)
My respect for him ratcheted down quite a lot. Yes, you must ship (who knew?). That's what milestones and deadlines are for, so keep overarchitecting and feature creep from occurring. However, I would NEVER want to let a "Duct Tap Programmer" near any project that I would ever have to modify, maintain, or extend. You know, something that isn't completely trivial.
Architecture astronauts (Score:5, Interesting)
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".
Re:Industry Software (Score:5, Insightful)
Liability doesn't mean power. Liability just means liability. Personal liability and sign-off for developers just means he has to choose between bankruptcy and a life of "Would you like fries with that?" if failure occurs, or losing his income now (and possibly having trouble finding a job because he's got a reputation for being difficult) because he won't sign off.
Parent