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."
...also protect you from sellers of snake oil and fake gems?
Ezekiel 23:20
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.
Please do not read this sig. Thank you.
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.
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.
You can't measure Synergy man, you just have to feel it!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
I agree with most of Joel's post. What bothers me with this kind of thing is that there are a lot of idiots out there just waiting for an excuse for their poor standards. For every real Duct Tape Programmer there are ten buffoons who will now take that label for themselves. But hell they shoudln't be hard to spot.
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.
One month to write and years to debug and get right.
Wow....praises for everything that is wrong with programming.
I believe in a 100% good project, and somewhere around 97%+ good project. If it can't be delivered, then you're not smart enough, or it's not possible.
Of course, I think he means something along the lines of industry software.
I work in the auto repair industry as a system administrator. We have 20 industry specific programs. They fall into two categories:
1. Programs developed by companies within the industry with no real programming experience. IE. Auto Shop gets smartest guy to learn how to program - builts program...these are the programs that are 50% good. Poor programming practice, unstable, but overall, on a good day, works well enough to increase efficiency beyond that of a pen/paper.
2. Programs developed by professional programmers with no industry experience. These programs are polished, stable, run fast. The problem is, since the programmers have little or no industry experience, there is an obvious disconnect in the work process within the program. This results in features we don't need, or things we need that are absent.
Overall, as a system administrator, #2 are better for me, because they work. #1 are better for the workers themselves.
We have one program that "tracks changes" by polling every file on the hard drive constantly. Starts at the top and works through every file and starts again. We have a server dedicated to this, chews up a 4-core processor. When asked about it, they said there was no other way to do it...uh huh...this is the #1 approach.
WD-40 is never the right lubricant, and it probably isn't the penetrating oil you are looking for.
Nerd rage is the funniest rage.
Your Honor, the Vehicle Control System works over half the time. We are not responsible for this tragedy.
Writing programs is easier than debugging them. So if you write a program in a way that takes all your intelligence, you won't be smart enough to debug it.
They don't even hold a candle to gaffer tape programmers.
Why is it that whenever I read an article by Joel I feel like I'm being talked down to?
This concept, like so many others, is a double-edged sword. I personally have seen some brilliant programmers show me some amazing stuff but refused to release it or sell it for nebulous reasons. That having been said, releasing a product that is poorly designed under the hood makes it a nightmare to maintain and can quite easily paint you into a corner. For example, IMHO, nobody should build their own application framework nor should anyone use only what Microsoft or Apple creates. Qt is the right solution because you can concentrate on developing the application and not have to worry about the plumbing. IMHO, this is one major reason why Quickbooks sucks. Intuit should have switched to Qt long ago. The product would have been much better and they'd have the added benefit of true feature parity between the Windows and Mac versions.
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?
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
I have to admit, I looked at this headline "the duct tape programmer," and thought, how do you program duct tape?
Scenario 1: Your client needs an application that will accept data input for approximately 400 different forms, allow those forms to be validated using some rules that are simple and others that are very complex, and put those forms through a fairly standard work flow.
Scenario 2: Your client needs an application that has 5 different forms used for very different purposes whose data will be processed in very different ways.
In Scenario 1, you had better do some engineering up front to save you from custom coding the parts of those 400 forms that could have been "over-engineered" into templates, base classes, and interfaces.
In Scenario 2, it makes sense to duct-tape.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
'Ship early and ship often.'
But it's definitely no silver bullet; it's not for every project, nor every developer, I've been disappointed to see how integration of Agile via scrum derail projects and upended a department where inexperienced / low skilled developers got overwhelmed by the shift in focus from doing it 'perfectly' to shipping. There's a subtle but significant shift in responsibility from the project manager to the developer. Lots of guys don't like it and really can't handle having things so visible; they're used to being able to hide behind the complexity of their work for days or even weeks without really having any accountability. Agile gives them nothing to hide behind.
Notes From Under *nix: blas.phemo.us
Shipping is a feature. A really important feature. Your product must have it.
Can't really argue with that at all.
More engineering would be nice if re-use were allowed.
From what I understand, many government contracts forbid the contractor from taking code written for one contract and applying it to the development of another contract. This apparently can happen even if the customer is the same for both contracts!
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
Spolski is smart and I usually like what he writes, but it's important to remember that he spent his formative years at Microsoft.
Cruel joke, but...
A Duct Tape Programmer needs a Duct Tape Kitteh: Yahoo News, Sept. 22.
Adidas To Bring Back Sneakernet
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 programmers may be invaluable tools in Joels world of overpervasive market economy and the corporate, but in some areas of application duct tape just does not cut it. Mission critical applications, like those used in health "industry", expensive satellites and other kind of space vessels, tunnel digging machines and what not - everything that just cannot fail - will not really benefit from Joels so cleverly coined "duct tape programmer" character. Not sure if Joel included these areas as applicable for the "duct tape programmer" attitude, but I just wanted to say I don't think they are. Let duct tape programmers develop Photoshop, and all those benemoths of software that runs slower the faster machines we throw at them, occupy more space for the same set of features and so on and so on - probably nobody notices that anymore, as we all are sworn to content. But the few areas where software quality makes it or breaks it, Joel is off the mark, IMO.
In a way, I think Joel might just be restating what I have always found to be a core axiom of software design/development:
"Use the right tool for the job".
I would add the corollary, if one is a master of a tool, the tool has reasonable support, and one can get a job done with that tool, then there is no need for anything else other than that tool for that specific job.
It's when you don't have the right tool in your toolkit that things get more difficult. Knowing when you have the right tool/approach, and when you don't and you need another person, approach, or tool makes all the difference.
I think the idea of saying 50% is good enough is about the fact that you can do a whole lot with just one tool, like using a screwdriver to hammer a nail. It's not the exact right tool for a job, but actually can also get it done too.
IMHO, anyway,
SixD
P.S. Just don't get caught being a tool!
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
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.
Wherever You Go, There You Are
This issued has been explored before as Technical Debt but most managers and a large number of programmers like to think they are the experts of technical wizardry.
I agree. The best is a balance. It's okay to explore new techniques for making cleaner or more re-usable code, but there are those who become purists and fad zealots and get carried away. The best systems in terms of delivery and maintainability are controlled by a middle ground.
Table-ized A.I.
A poor plan vigorously executed is better than a perfect one never executed.
To me, the real value is to know what you can cutout with negatively impacting the customer experiences. far too often people build cost and delays into projects by building in cool when cool is of no value to the customer.
Not a new idea, and valid today academic exercises are best left to academics where they can't hurt anyone.
I'm a consultant - I convert gibberish into cash-flow.
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.
is Release 2.
I have been making this point for years only to be told I was an idiot. Look. Just because you can cram data into XML files, doesn't mean you should! Why use a database when a flat file makes more sense? I don't believe his promoting bad programming habits, I think he is trying to say, don't over complicate the simple things in life. I don't need a freaking API written when I can just query the damn database myself! KISS = Keep It Simple Stupid!!
Surely they aren't release-early-release-often, but they release their products with massive numbers of features which "just work" enough that people can get some productivity out of them and keep using them until something else comes along.
"Real artists ship" ... Yeah, and so do mega-corporations with crappy uber-apps. Can we please not follow the YC path and please stop posting blog entries that are 3 paragraphs long, expelling the virtues and personal opinions of an egomaniac?
"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"
1) Solves more problems, but creates as many as it solves
2) Survives longer because you're too busy putting out the fires caused by #1 to re-architect (and busy holding awards ceremonies for the idiots who "fixed" the avoidable problems they caused in the first place)
This is what a lot of people fail to understand about Lotus Notes. It's not supposed to be beautiful and elegant and petite; it's a humongous roll of duct tape. It's ugly, but it gets the job done, and can often get you from nothing to "50%-good solution" in an afternoon.
[Opinions mine, not IBM's.]
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
interesting comment.
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.
I don't know what kind of crack I was on, but I suspect it was decaf.
The comparison to Steve Jobs is... weird.
Steve Jobs is *famous* for holding products back because they're not polished enough. He's famous for wanting products that do not very much, but what they do, they do right. He's famous for not shipping half assed solutions.
Rather the opposite of what the summary suggests.
An /. article just disappeared into oblivion. Was it a hash collision?
Just image the probability of that occurrence!
Oh noes, the world is going to explode!
WE ARE ALL GOING TO DIE!!
Seriously, look at http://tech.slashdot.org/story/09/09/24/238251/Microsoft-Releases-Prototype-of-Research-OS-Barrelfish
The article content doesn't match article link name. User's comments also refer to old article.
I hate to say but slashdot is b0rken.
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".
Duct Tape Programmers produce Fog Bugz?
would you drive on a bridge that only went 99% of the way across?
Always write code as if the guy who has to maintain it is a sociopath who knows where you live.
People who know better don't listen to Joel Spolsky. He's the John Dvorak of programming.
My idea is that a good duct tape coder does mostly procedural code that is well named, strongly typed and designed by contract. I don't think that is what you are describing here.
love is just extroverted narcissism
Delivers fast, gets paid, walks away, starts running to avoid being hit by the shrapnel.
Not so good for those who are left to pick up the pieces.
Where are we going and why are we in a handbasket?
Sooo, if DucTape Programmers work at Apple, do Masking Tape Programmers work at Microsoft?
Excuse me, but please get off my Pennisetum Clandestinum, eh!
I've always viewed multiple inheritance as the hallmark of duct-tape programming. Being (correctly) forced to do single inheritance forces you to do proper architecture (but not architecture for architecture's sake), abstraction (within reason), and seriously think about the structure of your program.
There's nothing more duct tape then slamming a bunch of random classes together into one class.
It's almost like he is in full support of spaghetti code. This guy probably would've had Duke Nukem Forever out already, but only the first level would've actually worked the way it was supposed to...until patches 1.01 through 6.8 came out. But hey, it mostly kinda works...on Sundays...during full moons...
I don't like Linux. This doesn't make me a troll.
The duct tape programmer represents those developers that "just want to do it".
Their comfort zone is coding so they really what to start coding and "see things moving" asap. They'll work really hard, go down coding/design dead-ends and back, re-write whole sections of the code, work long hours and eventually deliver something .... that doesn't do what's actually needed (say, because a requirement wasn't double checked with the users, or the format of the data being exchanged with some other system wasn't properly hammered-down with the guys developing the other system or the chosen technology can't deliver the needed performance or any other of a million reasons). Crazy last minute adjustments and re-writtings follow and what comes out is a "not exactly what we needed app", from start held together with spit and chewing-gum.
Compare this with somebody that works smart and takes some time to prepare up front before starting coding (things like checking requirements, hammering down message formats, making sure the chosen technology can deliver) and at the end delivers something that not only works but also does what is needed and, just as important, keeps on working without requiring constant baby-sitting.
FTA:
"Zawinski didn't do many unit tests. They "sound great in principle. Given a leisurely development pace, that's certainly the way to go. But when you're looking at, 'We've got to go from zero to done in six weeks,' "
Oh yeah, abandoning unit testing to get code out the door!
Maybe you got confused by his depiction of the architecture idiot at the beginning, but the core idea of this article is to abandon anything that slows delivery...
Seriously, no Unit Testing???
Wherever You Go, There You Are
From 20+ years experience I can confirm that my personal productivity is greater when developing in "Anarchy" mode. When I work on a team that employs rigid methodologies I find that development output slows down significantly and that the resulting software is of no greater quality for the extra time spent building it. I also find that creativity is greatly reduced, and in many cases, devalued completely when using cookie-cutter techniques. This observation doesn't mean I don't see the value of discipline or patterns, but do I think programmers need to balance creativity and organization. It is the balance between power and control that allows something to navigate at high velocities. I suppose the same could be said for programming.
A problem with duct tape programming can be that after each delivery you spend a little more time each week doing maintenance on the code that you "delivered". Not that this doesn't also happen with over-engineered apps but more so with under engineered apps. Eventually you have delivered so much that you are spending 100% of your time doing maint and it is time to get a new job.
on time, on budget, all functional ---- choose two.
What we are all here to solve, at the end of the day, is a Business Need.
And your design document can never be more accurate than the definition of the business need.
If your solution is well written and matches the design document, yet is unable to solve the business need, you've missed the mark.
If your solution has some flex in it, and maybe ever some performance issues, but solves the business need, it's a win.
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
I'm working on slop-bucket code like that now that I inherited. It's frustrating, but having seen this odd phenomenon before, I realized something: Reactionary programmers develop better reactionary skills to compensate. Sure, they are fixing things often, but they are also fairly proficient at digging around in spaghetti and fixing it. Cleaner approaches atrophy one's skills at ad-hoc repair such that you *have* to rely on cleaner approaches. You become a less-skilled trouble-shooter.
I'll still take the cleaner approach over the ad-hoc approach (barring over-engineered red-tape code), but for some reason the ad-hoc approach is "good enough" in the hands of a good ad-hoc-er. It's an odd thing to witness.
I've also seen another guy type (keyboard) at 100-miles-an-hour as he kept reinventing the wheel. He expressed no interest in further automation and abstraction to simplify the process. I think he had a kind of A.D.D. that made him want to be moving all the time. It's almost as if the guy with tweezers can mow the lawn almost as fast as a guy with a lawn-mower because he tweezed so damned fast. It may work as long as he doesn't get repetitive motion injuries.
I'm not endorsing ad-hoc-ism and mass repetition, but only saying that the down-sides may not be as big as one would think. Those who engage in the practice are often determined and resourceful survivors who find a way to work with what they know and are good at.
Table-ized A.I.
I love the duct tape analogy here. I can't help but recall that duct tape itself has a history loaded with irony. Duct tape is one of the most successful products in history, with thousands of uses and strong sales, decade over decade. However, duct tape is particularly bad at one thing - as tape for duct work. Yes, duct tape doesn't tolerate the temperature changes common to duct systems, and therefore is particularly bad at the one purpose it was designed for in the first place. Hopefully, duct tape programmers are good at writing portable code.
Duct tape programming has it's place and it's called the prototype. A really good programmer builds the elegant solution faster than the hack anyway, because hack never really work. Making smart design decisions corrects most of the author's complaints about "shiny" new features that are too complicated. I dispute that C++ is difficult to code, if you don't like templates then don't use them. As far as multi-threading is concerned, get a real degree, take an operating systems or programming languages course and get over it.
IMHO if you can't build good threaded code in C++ or Java you need to stop calling yourself a Programmer and leave the software development to those of us who do it the right way.
-- Adam McCormick
I'd point to the Non-Zero Return part of ROI when it ships. Someone can spend a month doing a .01 release to clean up the ugliness after it sells as a free update.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
is the enemy of quite a lot. Got us all of these wonderful new craptastic "killer apps" companies push these days. Have fun with your Execu-speak.
I think it all kinda depends on where you are. sometimes you have no choice but to be a duck tape programmer. if they want it done next week or your job is on the line then you do what you have to to make it work. the problem comes when someone doesn't realize that there is another way. I'm sure your "Crufty Joe" was at his position long enough and had enough expertise to be able to convince the bosses "hey we need to spend some time and clean up this code" but instead he just kept going on his way.
I've had this same problem in the graphic design business. i spent a good portion of the last few years cleaning up designs made by my predecessor (and even ones made by me before i knew how to do it correctly) so i get it. but now that i'm trying to break into the programming world i find myself having to resort to duct-tape style coding just to get stuff done, what looks better on your resume? a website that you hacked together that looks like crap in the back end that someone else had to spend a year cleaning up, or no website at all?
Okay I will give you that- not unit testing is pretty stupid. I guess there is a happy medium between the astronaut and the duct tape guy.
love is just extroverted narcissism
Why was Joe a Duct Tape Programmer? Because he learned long ago that being an archetecture astronaught means most programmers won't really understand what you are doing, and will contribute retarded changes that will end up making the system more complicated than it would have been without the abstraction intended to simplify things. Better not give the fucktards you work with and who will have their fingers in your project more power to fuck it up than absolutely necessary. In Joe's spare time ( some of that 75% ) he develops the high quality code which cleverly uses the latest software engineering principles to be able to ship a product all by himself that ALLOWED him to retire.
whey hey!!!!
I recently had to deal with the worst of both worlds- a guy who coded like sht yet wanted to use EVERY new gewgaw released by MS for .NET.
The code was only followable by using the debugger- and he was a debugger pro (I hardly ever use it)
love is just extroverted narcissism
Modded troll? Parent is on topic and pretty insightful IMHO...
that isn't what I would call "duct-tape programming," it's what i would call "terrible, reckless, silly programming"
captcha: moisten
Duct tape programmers may be invaluable tools in Joels world of overpervasive market economy and the corporate, but in some areas of application duct tape just does not cut it.
I agree but would add one thing. In mission critical apps, simplicity is extremely important. These guys don't go for the "classes constructed entirely from multiple inheritance from templates" approach either.
it is not 1989. we are not academia. oh and get off my lawn!
Seriously how is this post new, or anything about it new?
IranAir Flight 655 never forget!
How many shops do you know of that measure number of post-release, customer-reported bugs before and after the latest switch to [insert wonder software development method of choice here]?
.
There's lots of talk, but not much objective research. Scrum, Agile, Patterns, Unit Tests, et al. All can be gamed (particularly unit tests) to please management. The improvement seems to be a matter of faith more than anything.
.
Has anyone done meaningful measurements? If so, what did you find?
Please do not read this sig. Thank you.
"But now I've taken my leave of that whole sick, navel-gazing mess we called the software industry. Now I'm in a more honest line of work: now I sell beer." (Source)
Be who you are...and be it in style!
...duct tape code is like the bad version of glue code. Instead of adapting two things that are modular and should work together, you have two completely different things that are just duct taped together with a ton of tape, and with lots of sharp edges tearing at it. Duct tape code can take you from a complete and utter failure to a mediocre result that's shippable, but it's never a very good solution. But if you know IT, you know most of it is built on workarounds of workarounds and pretty much the one rule of software is that if you knew what you know now, you'd never build it that way.
Live today, because you never know what tomorrow brings
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).
Anybody that does it shouldn't consider themselves a professional.
Its simply an excuse for doing a sloppy job and leaving your shit for other people to sort out.
I hope I never have to be the one to support this guys hacky code.
Duct tape programing seems apt for the silicon valley set that has to ship something before someone else eats your lunch. I accept that they do what they have to do. But the rest of us that practice our craft in banking, insurance, medical devices, etc? No way. You can't afford duct tape mistakes.
Yeah, I know duct tape programmers, I've worked with too many of them. They are the guys who jump from company to company starting projects and never having to maintain the hacked up poorly thought out pieces of shit they leave behind. Fuck those idiots, I've seen two companies get crushed under the weight of maintaining applications written by guys who don't even consider maintenance when writing their code, only completing the project so they have something nice to put on their resume in order to dupe another hapless company into letting them lead another new project that will fail because it wasn't built with long term maintenance in mind.
Well said. I agree that "architecture astronauts" are around phase 2 only, but that doesn't mean they don't get a job where they can force their ideas onto others. It's not too hard to impress whoever is interviewing your by knowing too many buzzwords and ideas of grand designs.
However, I agree with Joel that overengineering is evil and is probably a more serious issue than underengineering. And by "Duct tape programmers" he doesn't mean programmers that wrote CRAP code. He means programmers that add code that works and doesn't introduce more complexity than is absolutely necessary. And I agree that this is a good thing. With current development tools if you have relatively clean code (preferably unit tested), you can refactor it and add abstraction layers, interfaces, flexibility etc. at a later date when that is needed.
"Duct tape development" is actually promoted by Agile development model. You are supposed to write only the code that is needed NOW to solve THIS problem and refactor later. Unit tests are supposed to make refactoring safe.
I guess as with all things in life there must be a balance. But I believe everyone who has ever done design can say that they have at some point designed their systems for future requirements. And then these requirements never arrived, system evolved in a different direction, and all the complexity and flexibility introduced was bloat and a waste of time and effort. OTOH developing systems without and design is also stupid.
--Coder
I'm the sole programmer on an internal app spanning about 150 web forms. My policy is to try to get each form done as quickly as possible. I have a few helper classes that I add to as needed, but generally I feel like there's something wrong if it takes me more than 2 hours to write a simple report form. So my code looks like crap, and the DBA bitches because i don't handle errors caused by him randomly deleting shit out of the database that should never be deleted. Why do I write such bad code? because I know I'll have to do it over 3 times anyway, because the users get it and then decide the specs they told me aren't what they *really* wanted. Also, in an event-driven programming model, your code is going to end up looking like shit no matter what you do.
Yeah, I knew someone else like this at an old job. He banged out one particular project and it was fine for all of a week - they they started asking for more things to be added. Then more things, and again more things. It would always work . . . until something new popped up. He eventually took to complaining about the group that made these requests, even for things he screwed up like lack of input validation, rather than taking any time to stop what he was doing and clean up what he had already done.
Eventually he left and I was stuck with the project, and the thing that struck me is that if he had designed the entire thing better up front none of the additions would have been very difficult to implement.
in the last eight years the duct tape programmers that have worked here have cost us more money and embarrassment then we care to think about. we have had meetings where we cant help ourselves but get very angry and loud about the mess they have created. we have slowly identified and rooted them out. in one instance, the programmer gave notice that he was resigning and making a career change due to the amount of problems he caused.
In their place are well thought out solutions that scale upward with minimal ease. where we actually map out what the solution should look like first, identify which tools should be used at each step of the solution, identify and make allowance for the potential changes that will come over the next year, and then begin building from the foundation up. after a year of investment we end up with solutions that are easily repurposed because their components are finished and clean. the ability to duplicate that again and again is where we make the money. we dont have to rebuild anymore, but we charge like we do.
the problem with 'duct tape' programmers is the big umbrella it puts up for the young, inexperienced, fresh out of school kids to hide under and screw up your company. They want to throw in some hours and some code and hurry back outside for recess again. I bet for every 10,000 of those is a single duct tape programmer who is worth having around for the occasional emergency.
Which is entirely subjective by definition, so we're back to the basics: a good programmer writes working programs.
A good programmer writes working programs, that have an underlying simplicity to their architecture.
Like all pain, suffering is a signal that something isn't right
Joe?
voicemode="arnie"-this is a baaad ideeuh
Why? See this http://it.slashdot.org/article.pl?sid=09/09/25/1239236
That's what happens when you ship a 50% polished/completed piece of software, then the "new and improved" one is again, 50% completed. this goes on for decades
What is needed is an end to software snakeoil and insist on a warranty, suitable for purpose, and free from glaring defects, just like any other "product". When your product fails to work, even with oodles of third party expensive help, it's just time to admit reality that it is designed from the ground up "wrong" and should be removed from the market by law, and all the folks who got took get their cash back.
It is only going to get better once they take some billion dollar hits with recalls and cash back to their victims, across the spectrum of software. All other industries have to provide a minimum quality and a warranty to ship products.
Time to take the training wheels off this alleged industry and force them to put on big boy's pants..
Wah, wah, wah, cry, whine, bitch, moan, complain, "we'll show you, it will cost so much you won't buy it and stuff! And my dad can beat up your dad, too! and..and..it can't be done, so there" (software "industry" sticks it's tongue out and walks off in a petulant huff)
Uh huh Same exact BS thing all the other corporations whined about way back when they got told they were going to be having warranties applied to their products whether they liked it or not and the time for snakeoil and caveat emptor was over, and you know what? Sure, a few manufacturers went under, and it's no great loss, as demand for products was still there, so REAL, as in not just self described "professionals" took the market, responsible ADULTS. "Business" still kept making things and selling them, just the quality got better. They still have screwups, but they manage to struggle on now, don't they?
We bought a duct tape software to run our internet business. The sellers said (and I quote) "We don't use industry best practices." Not proudly but matter-of-factly.
The up side is that the thing is the right price. $1.5k vs $50k.
The down side is that it is spaghetti code, uses global data to pass information around, is not object oriented, doesn't use unit-of-work database transactions and gives error messages all day long. We manage to survive because we have somebody who is tech savy, me, but it is the source for plenty of aggravation but probably less than $48.5K worth of aggravation.
Amazingly we have not lost any significant amount of data.
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.
That's what I thought too, though I myself am probably a duct tape programmer by the sounds of it. Doesn't help that I keep getting asked to add in new features to my current main project (just a web based database app written with perl/sqlite) every couple of weeks of course, but I have spent this week going back over everything and tidying a lot of stuff up, making it much more modular and coherent. It feels good :)
which is totally what she said
I keep seeing this "good enough" meme going around. At a company meeting, recently, management was espousing the same crap.
I can only hope that these people are plagued with "50%-good" products. 50%-good tires, that blow out ocassionally, causing an accident. Maybe Joel would like some 50%-good surgery, or a 50%-good pacemaker. How about getting to fly in 50% good airplanes for the rest of his life?
I'm not surprised that most of this bullshit is coming out a culture in which Walmart was able to become the success it has. We needed something for a weekend project recently and bought the materials from Walmart, because it was closest. What poor quality crap. It'll all need to be replaced in a year, contributing to landfill and wasted resources. I'm not going purchase from Walmart any more, and I'm not going to spend money on half-baked, crap-quality software, either.
Word gets around about quality. It's the American auto-maker's nightmare right now. Ford, Chrystler, Chevrolet... they're all struggling to reverse decades of built-up public perception about poor quality, even when some of them are actually making fairly decent cars right now. It isn't quite the same with software; Microsoft has been making crap software for, well, ever, and they're still dominant. But I think that if you take the monopoly factor out of it, software companies *do* suffer from delivering half-assed product to their customers.
Can you emulate what JWZ did? Sure. Does that mean you'll be successful? I doubt it. THis discussion isn't about unit tests or dev methodologies in the traditional sense. It's about guys that threw that stuff out and achieved success in spite of it. It's much more subtle than being a hack that get's stuff "done." It's about being a hacker that get's stuff Done (with a big D) One you want on your team, they are rare individuals that can guide you towards riches, the other? Well you've probably got them around and they're probably paid too much and they actually cost the organization over the long term rather than help it.
My idea is that a good duct tape coder does mostly procedural code
So suddenly people who favour an OO or functional approach can't be "duct tape" coders? Interesting, particularly since a good procedural coder does the exact same thing as a good functional or OO programmer: the break the code down into small, testable, reuseable modules that are highly cohesive and weakly coupled. Whether you do that with procedural modules, objects, or functions is entirely irrelevant (though some paradigms make certain types of design simpler, eg high-order functional reuse, etc).
that is well named
WTF does that have to do with "duct tape" coding? That's just good coding practice in general, whether or not you're over- or under-designing.
strongly typed
So now we can't even use Perl or Python? The duct tape of the programming world? Jebus...
designed by contract
Once again, that's just a good idea in general.
Frankly, looking at your list, they're either just good ideas, or baseless prejudices, nothing more.
...he was a duct tape programmer! He always got it done by the deadline, but then he spent 75% of his time maintaining... in some cases we just tossed the exisiting work and started from scratch
Maintainability costs money. The article would have been much better if it just linked to the KISS principle as a reminder that needless complexity is bad. Instead there's this apparent (unintended?) emphasis on lower quality with the use of the "duct tape" metaphor as well as an out of context reference to Gabriel's "Worse is Better" essay*. The hard problem in software is maintainability, which is usually the result of hack-n-slash code that appears "done" because it "works" (just don't ever change it).
* There is a big difference between not developing the "perfect product" (i.e. every ideal feature) vs. code quality. The latter has a direct correlation to maintainability costs and future development velocity.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
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.
I have learned to write code in an open, easy to understand style so that future support persons will be able to hack it without too much trouble. That usually means avoiding some of the more subtle and elegant techniques that a particular language uses.
Code can be hacked without destroying its future usability, and that is my pet peeve; it's ok to hack, it's not ok to turn code that was maintainable into a bloody unusable mess. I hate compiler directives. Are you too stupid to put platform dependent code in a separate file?
Regardless, I do understand that shipping code is crucial. I don't hate hackers, but they get the job done. I just hate cleaning up after them.
Best regards.
So what do "smart" programmers do when the customer changes the requirements at the eleventh hour, or you discover that some of the information provided by a third party was incorrect? Do you say "Ohh, sorry, it'll take us six months to re-engineer. The class hierarchy is all wrong now, you see..." or do you just, you know, Get It Done?
And the duct-tape programmer is not afraid to say, "multiple inheritance sucks. Stop it. Just stop."
Thank-you Joel, for saying that. Some features just need to be ripped out, and MI is one. I'm not a huge fan of Java; but this is one thing they got right. When so many successful apps are written in something that doesn't have that feature, you need to ask yourself why it exists. That alone is not reason enough to eliminate it; but it's a start. When I learned about MI and tried it, I could tell it was a train wreck and I never used it. That was 10 years ago when I was obviously less experienced; but it's cool to see that validated by someone like Spolsky.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I think I've seen this before.
Perfect is the enemy of good... 'nuff said.
I was thrilled with unit tests until the Puppy happened. I was lucky enough to get an early start on a project. Early on, I wrote a suite of tests that I'd run to make sure nothing broke, and that edge cases were working. Then I continued to develop and write code, making the odd entry to the unit tests, but only in cases where I thought it was needed.
Then the Puppy came to my team. As the lead, I encouraged him to write unit tests. Those soon grew to epic proportions. I was buried in a sea of special one off requests from upper management for a period of two-three weeks and kept my eye off of him. When I finally could take a breather and get back into the swing of thing, I discovered mountains of tests - it was all he had written. No implementations!
Then requirements change as they often do. About a third of the tests were rendered useless do to the changes. Now, I still run my unit tests from time to time, but I am a little leery of putting that much time in to testing when the situation can be so volatile. And I have to keep a closer eye on the Puppy.
I just want to say <AOL>Me Too</AOL>.
First off, Jamie Zawinski no longer programs much. He runs a nightclub.
Second, Joel Spolsky isn't exactly a big name on programming. He's better known as a blogger than a developer. He runs a little company that makes a desktop project tracking tool. That's not rocket science. We're not hearing this "duct tape" stuff from people like Dave Cutler, who designed VMS and Windows NT. Or lead developers on MySQL. Or big names in game development.
Spolsky is taking potshots at the template framework crowd. He has a point there. I've been very critical in that area myself; I think the C++ standards committee is lost in template la-la land. The real problem with C++ is that the underlying language has a few painful flaws for historical reasons, and attempts to paper those flaws over with templates never quite work. (Read up on the history of auto_ptr to understand the pain.) But that's almost a historical issue now. Newer languages such as Java and Python aren't as dependent on templates as is C++. If you get the basic language design right, you don't need templates as much.
If it ain't broke, you're not trying!
(from The Red Green Show)
... 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 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...
Before throwing "Crufty Joe" under the bus, you should realize that his "cruft" came from an infinite stream of seemingly-minor change requests that were not part of the original design and had to be "duct-taped" on to the original application.
And I'd be willing to bet that if you stay there for 20 years that your code will look just like his.
"We want to handle this type of customer just like these guys, except when this happens do that." "Except if they're part of this group. Or their name is 'xxxx', in which case do this other thing."
Nice post. It's great to classify people, and if you can get lots of attention by doing it it is even better.
Smart programmers having taken the time upfront to design the system in a modular and flexible manner are already aware that requirements ALWAYS change down the road. So when the eleventh hour rolls around and the requirements have shifted the code requires only minimal adjustments to meet them. Agile is more than a buzzword, it already had a meaning in the dictionary before the PHBs got hold of it.
If you don't risk failure you don't risk success.
When did he become a programmer?
Bob Martin has posted a response to Joel's article at http://blog.objectmentor.com/articles/2009/09/24/the-duct-tape-programmer
My god, where do they live? In the land before time? What is described, is the age-old pseudo-dichotomy of the programmer who first plans everything, and then codes it, and the amateur, who throws together some spaghetti code that barely works, but gets the pat on the back from management, for being faster. While the planning programmer then gets negative comments, when taking so long to add functions to the 1.1 version.
The point is, that for big projects both strategies don't work well. The first one, because management or clients are a bunch of children, who don't know what they want, until the project is done, and let you completely change directions more often then there are minor version numbers available. (A result of reactive planning, which is reversing the steps of natural planning, on management's side.) And the second one, results, as I said, in a hard to maintain mess.
But we are long out of this dark times. I think it's pretty much standard nowadays, to work in the spiral model. A method which now is more than two decades old!
You define the biggest risks/problems/questions, you plan and develop a prototype, using test-driven development and as little work as possible, you answer your questions, and then repeat the whole process. Until you reach the "good enough" state.
So proper planning and "good enough" are no opposites, as made-up in the "article", but indeed an old hat, know to work best when correctly combined.
But what did I expect from a site, where a third of the articles are advertisements in disguise, a third are made-up false dichotomies, and the other third are badly written and misinterpreted actual news.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
it looks like joel spolsky has finally completed the metamorphosis from developer to point haired boss.
for "duct tape programmer" read "programmer who will agree to do any old shit without complaint".
if he wants to rationalise his crap management style let him.
when the software finally implodes as a result of this nonsense, the manager can order a re-write and call it "agile re-factoring" or some such opaque bullshit.
here's a new trendy software methodology for you:
"if you don't actually write code - shut the f**k up"
You want an example of duct tape programming? Somebody who hard-codes values that can be gotten from a database. I don't want no more of them duct tape programmers.
Where does this term "Duct Tape Programmer" come from at all?
Can we say "extreme programming" and leave the original term in place?!
His company originally coded their software in VBScript. Ok, fine, it was "back then." But over time, rather than refactor on a modern platform (and despite praising .Net to high heaven), they instead extended VBScript to create their own proprietary programming language. All this to run some bug tracking software BTW.
He scores high on the geek cred and he's a good writer, but I don't understand how he is taken seriously as a major authority on software development. There must hundreds of companies out there producing products on the level of things like Fog Bugz or Copilot. They just don't have a founder who obsessively blogs about everything.
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
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.
I suspect there are few MBTI type INTJ/INTP who code with duct tape, aside from prototyping.
If somebody shipped a browser as crash-prone as Netscape was today, it wouldn't matter if it was three years ahead of the competition. People would play with it for a bit, and then use something stable.
Um, no, you just disproved your own point. Netscape did deliver a browser years ahead of the competition...
Here you go: http://www.thefreedictionary.com/today
Mission critical applications, like those used in health "industry"
I worked on medical software with duct tape programmers. They key was that we knew when to use duct tape and when to make something bulletproof. Our database was bulletproof; but we didn't care if the UI had a glitch.
No, I will not work for your startup
So let's say I am writing software for a factory that assembles machines.
It has to represent various component parts:
Some of the parts the program needs to organize and assemble are
wheels (which have diameters), bodies (chassis or frames), and seats.
The factory makes sit-down lawn mowers, push mowers, and bicycles.
The parts have all been painted in different colors (a Painted thing has a color, of course).
My program needs to tell all the red bicycle parts to go to assembly area B.
Then it needs to attach the wheels to the bodies, and add a seat to each.
We would like it to avoid making multi-colored lawnmowers with bicycle seats
and bicycle wheels. Each model of lawnmower needs a different diameter
of wheel. Each model of bicycle also needs a different diameter of wheel.
Lawnmowers each need 4 wheels. Bicycles and push-mowers each need 2.
Please write me an elegant single inheritance data model to represent the entities
that the factory program needs to work with. Please avoid making any representation
choices that my buddy the other programmer would have a 50/50 chance of choosing
the opposite representation convention for the same thing. Because you are writing half
of the system, and he's writing the other half, then you have to integrate them.
Hint, he hates colored things that happen to be lawn mowers, but loves lawnmowers
that happen to have a color.
Where are we going and why are we in a handbasket?
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.
Duck typing is not a dynamic vs. static thing. Ocaml has statically checked duck typing for objects.
Why don't you people fucking educate yourselves before spouting off?
Everytime I've been in or led a project that attempted the noble spiral model
(which I do believe in),
management and/or customer always said (ordered) two self-fulfilling and fatal things:
1. We need more features in iteration 1 (subtext: we don't believe you will ever get to iteration 2)
2. This iteration 1 thing is good enough. You are finished. We cannot pay for more dev.
Note how elegantly symbiotic the two positions are.
Where are we going and why are we in a handbasket?
Templates are important and can impact the amount of code that needs to be maintained. Of course, C++ templates were a non-starter. I like Eiffel's approach to templates and OCaml's module approach. Neither of these languages are mainstream, though, I am not entirely sure of the reasons for that.
The article also talks about unit tests, rather not doing unit tests: I tend to agree with the approach when I am developing in say Eiffel or OCaml: in C/C++ or Java, though, unit tests are a useful safety net. There is a library called Weasel (based on Eiffel) that uses design-by-contract statements within the program to generate automated test cases, to reduce the total number of hand-written test cases. Having coverage through unit test cases certainly is a norm and I would believe that it might be a management risk to do otherwise.
Makes sense in the sense that duct tape programmers may certainly be people to hire for developing GUIs. Ironically though, nothing gives software such a bad reputation as because of its GUI, and we have had bad GUIs for years. But I guess people working in health sector had years to complain and by now are used to it.
I have on several occasions peeked over the shoulder of various doctors and nurses as they used their software, and have on all occasions noticed how ugly the GUI looked and behaved.
I would have to also argue that sometimes a GUI glitch can be fatal to a patient. A button performing a different function that it is expected to perform. After all, a GUI is just an interface, what if somebody swapped the labels for the buttons on a life support machine? ;-) You cannot rush out medical software, IMO. It should be done when it is done. Before it's done, its predecessor should be used.
Makes sense in the sense that duct tape programmers may certainly be people to hire for developing GUIs. Ironically though, nothing gives software such a bad reputation as because of its GUI, and we have had bad GUIs for years. But I guess people working in health sector had years to complain and by now are used to it.
Not in this case. We had significant UI testing. The fact of the matter was that, to our customer, the data was the most important thing. Therefore, we had to prioritize a bullet-proof database for demos and milestones. QA helped us fine-tune the UI, but at that point the database was pretty solid.
No, I will not work for your startup
We have a whole department full of duct tape developers, writing Business Objects reports and other BI-type code. They can't write efficient database queries to save their asses. As one of the production support DBA's, I get the pleasure of debugging/tuning their crap after it hits production and won't run. Just yesterday, after one of the production Oracle machines fell over, we discovered a query that was piping a whopping 2.4 PETABYTES of data through a SELECT DISTINCT clause. Considering the database itself is less than 300GB, we found this rather interesting. When challenged, the developer responsible for the query says "It should only return about 10 rows". True, if it ever finishes applying the DISTINCT.
Ship first, tune later, I love that philosophy...
Wants to keep his name in the limelight.
Inexplicably comes close to success because of Slashdotters theodp and kdawson, neither of whom apparently knows anything about real coding.
Film at 11.
You just described how DTP survives where there is poorly qualified and short-sighted management. In that sense, nearly every kind of corruption is good. Its not the whole story if you're looking for long term success.
But you make a valid point also, particularly when paying customers are in the role of your management.
Good ol' alberts words saying that everything should be as simple as
possible but not one bit simpler is violated by both
the duct tape coder and the postal architect....
Spaghetti is spaghetti no matter if it is made up of
recursive class template wrappers or nested if statements. It's
the battle of the crappy coders.
"Multiple inheritance is bad" - now that's just the mentality
of a crappy coder, a good coder knows when Multiple inheritance
is bad, and when multiple inheritance is good - it's *not always* bad...
you understand? kind of "it's not that simple"
You know, I happen to think that the net is the biggest duct tape of all. Hundred of billions of dollars have been spent building apps on something that wasn't designed for that, and almost each time a new solution came, it was based on a hack that somebody did, that was glorified into some great technology (say ajax, for instance).
That is the old Worse Is Better theory. LISP machines were fantastic, but were replaced by badly designed kludges. Smalltalk environments were amazing, but everybody used less elegantly designed languages/environment instead. The thing that get the job done NOW, with the smallest curve of learning gets the momentum and WINS.
When you see the kind of kludge and complexity that is CSS (for instance) to get a somewhat controllable UI on the web, it is hard not to feel sorry. Now, people are developing apps in javascript, with very poor development environments, getting extremely fragile systems, that run hundred of times slower than a normal desktop application would. And buggy as hell (for instance, getting proper drag and drop behavior in web apps is currently impossible).
I can't avoid thinking that a properly designed web technology would make all those issues moot, but of course, that "perfect" system would never have been able to get momentum. Maybe the great designer is the one that knows how to design a system just badly enough to be successful....
Whoa, there buddy, I don't throw any of my people under the bus. But if you think that I am going to sit idly by and watch a team member dig himself a hole just because it is the quickest way to deliver a product... well I wouldn't be doing my job and, imho, would deserve to be tossed under the bus myself.
Maybe you are familiar with Oracle 11i apps, maybe not. I have seen (and been) the bright guy that just 'picks it up', but I can also tell you that most of the code I wrote early on was utter crap and may have even broken certain arcane licensing and support rules...
The database schema is _sick_ and works into it a security model based on synonyms of views of tables that spans dozens of schemas and is necessary for sound information control. A lot of the time you can create your own tables and use them to handle changing business rules or even *shudder* hard code values and rev up the code when the values change (Joe's favorite approach). However, by merely reading the RTM's (there are many of them), learning the funtional setups and spending a few years dicking around with the system, you discover that some bright programmer within the halls of oracle already considered it and provided a really effective method to deal with it.
I challenge anybody to convince any (in this case really nice and competent) fellow to change their ways with just a few years remaining until retirement. Joe accepted a lot of it, but that does not automagically change all the legacy code hanging out just waiting for our business people to make some changes to the setups and start screaming when stuff stops working.
So, I take your '20 year challenge' to heart and I work daily to keep that from happening with my own code or my co-workers. IMHO, there are way too many programmers out there that will read this 'duct tape' piece and use it to justify their own shoddy methods for me to read it without my head spinning around and taking the time to spout off about taking the time to do it right.
Wherever You Go, There You Are
[sarcasm on] 0th Never document anything and never comment anything. (Hey, when the next guy comes through and has to reverse engineer your code he'll thank you for the fun.) 1st Don't write function. Just dump the code right in place. Hell, a function isn't really useful unless it's at least a couple thousand lines long. 2nd Don't give things good names. I is fine and what the hell, name your stack 'q'. The computer can figure it out no problem. 3rd Use GOTO's whenever possible. 4th White spaces is for chumps so don't have things line up and for god sakes skip the formatting. [sarcasm off]
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
No, this is simply not like this. If a static type system compiler fails to compile the file because of a type error, then there is truly a type error in the program. The idea that some such programs would not have caused problems at runtime is dubious, because what programs can actually run cannot be divorced from which programs compile.
The arguments in "favor" of dynamic typing are simply misaimed. More and better static analysis of code before allowing it to execute is a virtue; the lack of static analysis and rejection of code is not an argument for dynamic type systems, it's an argument against it.
The sort of argument that can be made fairly against static type systems is the following:
So basically, static type analysis is (a) desirable, (b) hard to get right, (c) easy to misuse.
Are you adequate?
Let's try this again
[sarcasm on]
0th Never document anything and never comment anything. (Hey, when the next guy comes through and has to reverse engineer your code he'll thank you for the fun.)
1st Don't write function. Just dump the code right in place. Hell, a function isn't really useful unless it's at least a couple thousand lines long.
2nd Don't give things good names. I is fine and what the hell, name your stack 'q'. The computer can figure it out no problem.
3rd Use GOTO's whenever possible.
4th White spaces is for chumps so don't have things line up and for god sakes skip the formatting.
[sarcasm off]
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
...what Joel "straw man fallacies for fun and profit" Spolowsky says about it? Seriously, all this dude does is amplify his self-importance with grandiose soft(war)e stories while giving mediocre programmers pseudo-intellectual cover to do whatever the hell they want when they're not micro-managed. Ooh, yeah, that's making us all so much more practical and productive. Blog to the hand, JS.
The original article is written from an extremely narrow point of view. I don't want anyone wielding duct tape and WD-40 to create software that is used in a life/death situation (e.g., Care delivery in the Healthcare field). That stuff better be provably rock-solid (as much as one can verify). Joel is on a rant with blinders on and making a case that ignorance is bliss. He's being foolish. Appropriate use of appropriate technology is key. And having a diverse toolbox (and knowing how/when to use the tools) is equally important. You know...when all you have is a hammer, every problem looks like a nail.
Correction: What I meant to say was: "What you just described can be done with RAII".
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.
Tweet, tweet.
Our database was bulletproof; but we didn't care if the UI had a glitch.
Strange, I coded also medical software. I my company it was vice versa. Database had a bug? Who cares. Was invisible. But the UI had to be perfect. Pixel precision. This was what the customer could see. I quit.
We had hours of conversation whether a red was red enough. Colours and perfect layout of the printed reports were most important. Whether the actually results were correct....since our product manager did not understand the medical relevancy no resources were available to do even a rudimentary quality control there. Oh yeah, the user manual were perfect, too. It was his highest priority to find even the last typo in it.
Many years ago I inherited a project that had obviously been used to learn C++.
Every feature of the language was basically used once. Except the comment delimiter.
I believe stepping through a routine is the best way to learn it, even if it's readable.
This is especially true of crappy object onion code.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
I can't speak for everybody, but I tend to do this by asking questions like the following:
If it's a function that either a lot of stuff depends on (or not a lot, but really important stuff), and we are likely to go back and change it in the future, then yeah, both of those are cases for writing unit tests for it. But if it's not a relatively "core" piece of code (that other things depend on), or if I can't imagine that it's going to get modified in the future, then no unit test. (If the "no revisions" assumption is proven wrong later, then yeah, you can write unit tests then.)
The top targets for unit tests in my book tend to be highly reusable, complex pieces of code that simplify a non-trivial problem that gets encountered in many forms, and where it is likely that you will either (a) get some functional detail wrong that is only discovered in the future, (b) discover a faster way of doing the same thing. For example, code that generically implements a search algorithm deserves to be unit-tested extensively.
Are you adequate?
As 'nice' as a clean architecture, specification, unit tests, etc sound, in practice I have observed problems:
-Companies *still* think good software is done by larger development teams, and that a consensus is critical to acheive quality product. Everyone sits around, gives feedback, and lets other people provide their feedback out of being civil. This takes an eternity, and without some person stepping up to be the asshole who gets his way, a lack of consistent vision leads toward everyone marching toward mediocrity. As a result, I've found that a project with fewer developers who maybe touch base briefly once a week better than teams that have 2 hour meetings to ensure they are in 'lock-step' every other day. Good developers know when to touch base and sync up, and they also know when to just shut up even when they think their idea is better (if everyone insisted on getting the 'best' idea in instead of just getting the good idea in, projects just stall).
-People invest so much time writing specs to code for that might be as well suited just to code up a prototype and describe it as a 'reference' implementation rather than trying to plan everything without touching code at all. For me, my mind just logically realizes fault with a design when coding that I wouldn't think of when writing it up in specs.
-Unit tests are a mixed bag. They can catch carelessness, but exacerbate the problem of developer misunderstanding/miscommunication as they gain a false sense of security seeing unit tests pass (and they take a long time to develop, and if a modules interactions are sufficiently complex, impossible to get decent coverage).
-What I describe was hinted at (though no one dared question unit tests) when I was taking software engineering. Unfortunately, the class was wrapped in buzzwords like 'extreme programming', 'agile processes', and functional requirements were supposed to be thought of in terms of 'user stories'. Hidden behind those buzzwords were grains of truth, however, as I saw the concepts 'adopted' by some software development shops, I really saw use of buzzwords with no meaning. 'User stories' even when called that ended up being the same thing that functional requirements have always been. Words like agile are attached to processes that will expend months of planning without a single line of code, then lock into the design and say nothing can change without a miracle even if the coding demonstrates something was really wrong with the design.
In summary, I think a *lot* of the process-heavy shops/projects have the heavy process in place to compensate for mediocre programmers. The thought is that a team of a dozen programmers is important, and impossible to afford with good talent. The reality is a typical dozen-man team can be replaced by 3 or 4 really good developers with strong vision and produce a much better product in much shorter time. Don't try to get more developers, just get fewer, better programmers and don't saddle them with trying to pull the dead weight of an unskilled team.
XML is like violence. If it doesn't solve the problem, use more.
I think I trend more toward a duct tape programmer but will adjust my styles to suite the rest of the project I happen to be working on at the time. As a frequent duct tape programmer, that doesn't mean I have a free pass to write piss-poor, unmaintainable code. It means I should be disciplined in my coding without others constantly having to double-check that I'm being disciplined. Bad coders are bad coders, no matter what framework you put them in. Overly architected scenarios aim to keep a developer's ability to screw up code to a small area, but they can always make a mess of the code they write.
My strategy is to not try to use an architecture discussion ahead of time to predict if a peer's code is going to be bad, I wait for him/her to start checking in, and scan his/her's commits. If it looks fantastic, I am pleased and move on. If it looks like absolute garbage and is going to cause major problems, I will take measures to correct. If it isn't exactly what I want to see, and I believe I have a better way, but their approach seems workable as well, I keep my mouth shut because I know the debate will not be worth it. I fully expect my code to be read by others and critiqued as well without excessive discussion ahead of time.
XML is like violence. If it doesn't solve the problem, use more.
noticing an unusually large amount of type-o's in this discussion? apparently TFA motivated some of you.
a) the one who does duct type because he did not understand what all "these new" programming techniques *can* do for him *iff* handled correctly. (i.e. he tried it, he failded and decided it is not his incompetence but something different)
b) the one who does duct type because he decides that this is the best route at some point (no i dont need a design pattern to filter a text file line by line - usually).
c) the one who uses duct type because the people around him dont have certain experiences
That much said, let me tell you a little story. I am an experimental physicist and a -taken that into account- a quite proficient programmer. I love programming in all flavors. And while i don't ship programs -i have to ship results acquired with the programs- i and some colleagues usually use the measurement software i write. The fist approach i had was quick to write and extremely ducted. It was a C program with a graphical display in java, which could be scripted by perl. Needless to say nobody used it or wanted it (because it contained 2 language bindings to be maintained - even when done with SWIG this goes beyond the limits).
I dropped it directly after my masters thesis. I then wrote just a quite clean c to java binding, and scripted the software in jython. In my oipinion nowadays this was the *best* (best like the guy standing besides you table and telling you how greatly jython enables solid scripting of java ignoring some *minor* problems) solution.. This way found some acceptance (i.e. i was not the only one to use it), however other social problem in the chair prevented it from being used. Moreover there are not many physicist who can write these three languages.
Then i did a decision which saved my phd thesis. I switched to matlab (the program would run under octave, but it used the instrument control toolbox). Yes. Matlab can be a pain in the ass. Yes i curse regularly at the data structures. I curse at the non-existence of multi threading, on the strange way of programming the ui and on many things more. However these restrictions make it - after some time - really easy to write extremely predictable and easy to debug code. Yes, i am feeling like being in the 80s again when i call the drawnow function to force an update of the ui. On the other hand, no thread replotting over and over is eating the processor resources. After the thing was settled, essentially the whole group started to use it (respectively a derived version of a co-worker who stayed there longer and was more keen on GUIs).
After that (in 2006) i joined another group as a post-doc. The guys used either labview (the duct tape language #1 - in the bad sense) or tcl. After having looked at it (i avoided tcl for a long time) i decides to jump on tcl. I looked at the old software and decided it needs a complete rewrite. I looked at the oo extensions of tcl. I asked my colleagues - none of them knew anything about oop. So i skipped oo, but kept some parts of the program like i would do in oop. Writing the program was actually wasier than i though. tcl also is a very predictable language unless you are doing nasty things. The program is accepted well - because it works - and new features are easy to add - because the interactions with the old are easy to understand.
So, yes, i am happy that i resisted the urge to over-engineer the solution and just implemented good ideas - and i am observing that i am better the more i duct-tape (with a vast amount of thinking before where NOT to duct-tape). However i am also happy that i did not start to use or extend the spaghetti code from my colleague - whose program is covered in several layers duct tape.
So true. I know so many people who I'm tempted to call them "good coders", except for the fact that they freakin never ship anything. They'll polish, and goof off, and talk about how their implementation covers all aspects of things that don't matter in the slightest to just delivering the app to the users.
So, I take your '20 year challenge' to heart and I work daily to keep that from happening with my own code or my co-workers. IMHO, there are way too many programmers out there that will read this 'duct tape' piece and use it to justify their own shoddy methods for me to read it without my head spinning around and taking the time to spout off about taking the time to do it right.
I really hate to sound like I'm justifying crap, however with the current economy, businesses want something that works now, not in a year or two (or even six months). Something that does pretty much what they want and takes a month is worth much more than something that does 100% of what they want and takes a year.
For a lot of businesses, if they can't get what they need right away, next year might not come.
In fact, lately I've been seeing a lot of businesses going for Open Source solutions that don't quite do exactly what they want, but are close enough that the cost and time difference makes it a bargain.
Just for an example, one client was considering Exchange/Outlook/Barracuda with some custom Outlook add-ons to connect to some internal systems, however after seeing the difference in software, hardware and development costs and time, decided that Postfix, Squirrelmail, Spamassassin, WebCalendar, Apache & PHP would be just fine.
I hope all your projects work out for you, but I really don't think you'll have all the time available that you need to do a nice, neat, documented, provably-correct job on any non-trivial projects.
In any case, have fun and if it starts eating your brain, just leave. There's plenty of work available if you can delver a reasonable solution in a reasonable time.
Cobol. Yes, all you fanatics who really reeeeaaaaallly like it. Face it! It was created in less than 6 weeks by a small group (including Grace Hopper), and collectively did not expect their little project to last any more than about 6 months. They even said so, and also included that if they though anyone would be using their stuff more than 6 months, they would have bothered to do a better job of it. They tried to cure some of the warts about 10 years after they did the awful deed. They got some of them, but not all of them. They pushed it out quick with the full expectation that the stop gap would be used for a short time till something better came along. Thats the heart of the problem. Half working, warts and all gets adopted. Unless it gets fixed quickly, use swells, and it gets harder to make changes as people develop more and more around it. This is the other side of quick-n-dirty. Pushing it out quick *MUST* be followed by fix it up quick, at least try to get 80% of the warts out quick, and let people know that its a work in progress, and give guidelines where things are likely to change.
This demonstrates the need to built a prototype/model (using duct-tape method) before investing large amounts of resources developing the final product for large software projects.
Once upon a time, there was a project that had been underway for 19 months, but had not yet delivered anything to the users. Management was concerned, and was considering drastic measures such as pulling the plug and starting over with a new project team. At this point, management brought in a trusted developer I'll call DT to help analyze the project's status.
After a series of meetings with different project team members, DT gained an understanding that some software components had already been developed and tested, and it should be possible for the team to deliver a workable system within a few months. Seeing this, management relented and decided to give the project team a bit more time to deliver something.
A few weeks later, at a weekly meeting, one of the team members mentioned they were considering using message queues, but he was leaning against using them. In agreement, DT said that using message queues to handle communications between components of the app looked like overengineering. At this point, a developer sitting across the table went ballistic and started spouting semi-comprehensible technobabble about why message queues were needed and how, at a previous workplace, nobody ever would have said this was overengineering.
To be continued?
Perhaps DT's criticism of the message queue approach makes him a duct tape developer in this case.
It was three or four years late.
That is not an example of duct tape programming.
A true example would be a programmer who, when told that hard-coded values are going to be replaced with database values, decides to implement something quickly with MySQL or another database he already knows how to work with, rather than go through endless rounds of debating design requirements and customized DB interfaces.
Step 1. Get it working
Step 2. Get it working right
Step 3. Get it working fast
The world is a big place, if your part of it fits on a small list, then you ain't all that big. Logic, it sucks doesn't it?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
What you're saying is the Duct-Tape project give the appearance of success but was in reality a failure.
The reality is that Duct-Tape projects allways need to be re-engineered from scratch using a proper engineering approach.
In the old days we used to call them prototypes or proofs of concept.
And so they write FORTRAN with curly braces, and waste enormous amounts of time pushing out bloated spaghetti code (6-10 times as many lines of code, full of bugs that could have been avoided) because... they're stupid. Because they can't or won't learn to use the technology effectively.
And here Joel's the guy who wrote Smart and Gets Things Done. Where (he argues) you're supposed to hire the best brains money can buy (I agree, but I am one ;-). Maybe the PHBs finally got to him...
Duct tape programmers may be invaluable tools in Joels world of overpervasive market economy and the corporate, but in some areas of application duct tape just does not cut it. Mission critical applications, like those used in health "industry", expensive satellites and other kind of space vessels, tunnel digging machines and what not - everything that just cannot fail - will not really benefit from Joels so cleverly coined "duct tape programmer" character.
Actually, that's an ideal type of programmer for mission-critical stuff. If it really really has to work, then everything in Joel's essay about using the simplest programming style is good advice. The last thing you want is some meta-meta-programming that's impossible to debug, or too-clever-by-half multithreaded code.
Joel also mentioned duct tape programmers XOR'ing DWORD fields to fit in "next" and "prev" pointers of a linked list element. That kind of stuff really should not go into mission critical software, because it becomes just another component viable for debugging when things do not work as they are supposed to. Add to that the general attitude of duct tape programmers - "it has to appear to work" - mission critical stuff is REALLY not their field of expertise. The concepts of OOP and meta programming were INVENTED for the sake of proving theories before applying them in mission critical software. Duct tape programmers deal on a whole another level of reality - the "software has to ship" reality. Which is what Joel always stresses, being he is an IT boss himself. Simplicity is also orthogonal to complexity - NASA uses C indeed, because it is very easy to understand, but they are known to jump ship occasionally into C++ and other langugages, because they too get tired of constantly having to think like computers, which is what lower level languages like C force you to do, more so than C++ abstractions. A C++ program can be simple too, while it has more complex overall structure because of layers of abstractions it has. "Meta meta programming" is just wrong application of a perfectly valid and good concept. Just because most programmers struggle with it, does not make it less good. We need to learn more, that is all. Joel however does not have time for that. However, Joel does not (and perhaps should not?) design orbital guidance software.
Yes, but he mentioned that example in the context of the "pretty boy" nature of duct-tape programmers. We let them get away with it "because they're pretty enough, and smart enough, to pull it off" - in other words, it DOES work as it's supposed to. That's the only reason we forgive them!
Fair enough. I don't actually have much against the pretty duct tape programmer boys, I just through my years of development experience have come to appreciate the theories of computer science, and how they MAY help us. Meta programming is a wonderful thing when it works, and so are threads and what not. I just resent the stubborness of many developers who for some higher reason refuse to f.e. switch to C++, even disregarding the fact that C++ is actually a subset of C, and since gcc can compile both, why not use it where it is due? Same goes for many theories many simply close their senses on and mumble their "lalalalala". I think we owe more to these theories - often their purpose is to liberate us from the dirty work. We just have to learn how to properly use them. I find nothing amazing in a guy who can write Netscape in C. Joel does, because Joel likes his company make money using cheapest possible labour, which excuses his motivation entirely and is understandable. We will not get very far though with the kind of attitude. Remember that while Joel and many corporate duct tapers type away their simplified code, this code they write is in turn supported by tools that had come by after years of extensive and refined research into things much deeper than "real artists ship" mantra suggests :-) We owe those researchers a lot. Of course there is space for both disciplines, but they complement each other, while Joel seems to be entirely focused on his Holy Grail of Commercial Software Development. I have been following his blog for a while now, and I have come to know his ways - he is a very practical man with a team to manage. I respect his ways, but am of a different camp myself.
Seriouosly. Joel had a single claim to fame (fogbugz) that most people didn't even like. Why do some people consider him an authority on anything?
Stop posting this clown on the front page.
BeauHD. Worst editor since kdawson.
Joel, I always respected your writing, but take this article and jam it. All I can say after seeing the pretty boy duct tape-er specials - Good luck with your business from the crap you generate - I hope it works for you.
I was an applications programmer from the late 60's to the middle 70's when I moved on to a life of Systems Programming.
I have been there trying to debug mish mosh programs like the ones talked about in the article. They are NOT fun to debug in fact they were my worst nightmare. I was a typical programmer and I was called in in the middle of the night to try and fix these "bastards". Even with decent comments trying to figure out how you got there is often not easy. The dump you have is a point in time failure and just trying to figure out where in the program it failed is at times iffy. After complaining for years about "sphegetti" code management decided that structured programming was the way to go. Nice but it took too much time and deadlines went out the window. Then they came up with another name (long time forgotten) and it was semi workable and reasonably easy to code. We started to implement it and I will admit it was reasonably easy to debug and much more it was easy to figure out how you got there with a minimum of fuss. About that time I left programming for the wonderful world of systems and never looked back.
When I coded I used the philosophy of minimum branching and lots of comments. When somebody had to debug my code it was easily done and I got a few thanks along the way.
One time I coded up a fix for an IBM part of the OS and it took 1/50th the amount of time to run as the IBM version. I sent in the source for my fix and it was completely ignored and as of today 40 years later the program (or variation of it) is still running on the latest Z/os systems IBM is offering.
I can see why Joel would advocate Duct Tape Programming. Systems shipped by Duct Tape Programmers tend to "work" for some subset of what the users actually need or want. This results in a lot of bugs being filed, so there's a need to track, assign, fix, and verify bugs. As it happens, the main product that Joel's company makes is bug-tracking software. On the flip side, Joel, do you REALLY want your company associated with the attitude that throwing something out there that sorta works is better than shipping a quality product?
Strange, I coded also medical software. I my company it was vice versa. Database had a bug? Who cares. Was invisible. But the UI had to be perfect. Pixel precision. This was what the customer could see. I quit.
Our customer knew what they were doing; and due to the nature of the project clearly prioritized the data.
No, I will not work for your startup
I wrote a response in my blog:
http://info.rmatics.org/2009/10/06/duct-tape-programming-macho-yes-practical-rarely/