The Duct Tape Programmer 551
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."
So, does the Duct Tape Programmer... (Score:4, Funny)
Re:So, does the Duct Tape Programmer... (Score:5, Funny)
...also protect you from sellers of snake oil and fake gems?
No but I have a one-line perl script for that.
Re:So, does the Duct Tape Programmer... (Score:4, Interesting)
Are you referring to duck typing?
http://en.wikipedia.org/wiki/Duck_Type [wikipedia.org]
(For the uninitiated, this is one of the reasons Ruby and Python programmers can deliver code in a tiny fraction of the time it takes Java or C# programmers.)
Re:So, does the Duct Tape Programmer... (Score:4, Funny)
No, that is because nothing important is done in Ruby or Python.
Re: (Score:3, Insightful)
And also a big difficulty doing big projects with Python - it becomes too damn unwieldy.
Nevertheless, noodle monster bless Python. Right tool for the right job, etc.
Re:So, does the Duct Tape Programmer... (Score:4, Insightful)
Bad programmers can write "unwieldy" code in any language. High-level, dynamic, duck-typed languages are not unique in this respect.
The difference is, the app is up and running, ready to ship with the duck-typed languages, whereas people using lower level static languages are still writing converters and reconverters which don't add anything to the actual functionality of the app.
Re:So, does the Duct Tape Programmer... (Score:5, Insightful)
Except that it isn't. Sure, it starts, runs for a few seconds, and then exits due to typing error.
All duct typing does is move type errors from compile time to runtime, which also means that you can never be sure if you've actually squashed them all. I truly hate that aspect of Python.
Re:So, does the Duct Tape Programmer... (Score:4, Interesting)
To be fair, you must concede that while the static languages catch some errors at compile time which might not be caught until runtime (or ideally, QA) with a dynamic/duck language, the static languages also "catch" a great deal of non-errors which the programmer is forced to deal with even though they never would have caused problems at run-time, while having the side-effect of reducing code re-use.
Having to fuss with every little inconsequential detail has an advantage as far as testing goes, but it does come with a great cost as well. Some would argue that dynamic/duck + extra testing has the same effect with less cost than static + less testing.
Ruby and Python have only been "mainstream" for a few years, while static languages have been around since the ancient days. We have yet to see how high they can rise, but I'm betting they'll go pretty far--especially considering the fact that QA teams are far less expensive to business than programmers are.
No, we need a more nuanced analysis. (Score:4, Insightful)
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.
Re:So, does the Duct Tape Programmer... (Score:4, Interesting)
To be fair, you must concede that while the static languages catch some errors at compile time which might not be caught until runtime (or ideally, QA) with a dynamic/duck language, the static languages also "catch" a great deal of non-errors which the programmer is forced to deal with even though they never would have caused problems at run-time, while having the side-effect of reducing code re-use.
Um... no. I work with a proprietary duck type language [wikipedia.org] and Java at work. Java does not catch non-errors, IMHO. On the other hand, we have to test the hell out of the duck type language because we can only find the bugs at run-time, and with the complex code we write at work, that takes a LONG time!
Duck typing is nice and has some nice features. I think it makes remoting such a painless thing to implement. But in practice, I do not find it is better or faster than statically typed languages. In fact, if you are working in a large team, static typing is faster because if goober over there on the other side of the floor changes his interface, he is the one who notices it and has to fix it. In the duck-type language mentioned above, I find out about it when the next nightly dev build happens and I spent half the morning fixing problems he caused.
Duck typing is simply different. It has certain strengths in certain situations, just as statically typed languages. I know this in an unpopular view but: the right language for the right task. Seriously, just because Python/Perl/Ruby is your Dremel motor tool doesn't mean you should remodel your kitchen and build your own cabinets from scratch with just a Dremel!
Type Errors Aren't Really My Problem (Score:5, Insightful)
Except that it isn't. Sure, it starts, runs for a few seconds, and then exits due to typing error.
Most of the time when I have an error, it's not a typing one. Sometimes it's something else the compiler would catch -- misspelled identifier, function or method name I misremembered (or forgot to implement), whatever -- but more often than not, I don't spend a lot of time hitting my face with my palm over a typing error.
No, most of the time, I find that it's my logic: I only *think* I've given the computer instructions that will accomplish what I want it to do. But I've overlooked something, left out a step, forgotten a corner case, whatever.
Having a compiler make sure my types are right doesn't generally contribute much to solving this kind of problem, at least for the common meaning of typing we're usually invoking when we're discussing this issue (e.g., typing as it's supported by languages like Java). You could argue that unit testing is kindof like a big type test (do these modules exhibit certain specified behaviors for their "type"?), and maybe there's a language that treats typing like that, which would be intriguing. But having a compiler tell me something like "class x doesn't have method y"? Not generally germane to most of the issues I have while developing, really, and even when it is, I don't really care if I discover this at run time, particularly since feedback is at least as immediate as what you'd get from a compiler if not more.
And meanwhile, as others have pointed out, I'm spending less time writing convertors/adaptors.
There are problem domains where I probably wouldn't use an interpreted/duck-typed language, but I find I'm more productive when I can use them.
Re:So, does the Duct Tape Programmer... (Score:5, Funny)
What!? You can have multiple lines in a perl script?
Re:So, does the Duct Tape Programmer... (Score:5, Funny)
Not really. I've seen way too much duct tape python and ruby code.
Re:So, does the Duct Tape Programmer... (Score:5, Interesting)
Re:So, does the Duct Tape Programmer... (Score:5, Insightful)
forgive them if they never write a unit test, or if they xor the next and prev pointers of their linked list into a single DWORD to save 32 bits, because they are pretty enough, and smart enough, to pull it off.
No, I don't forgive them for writing obfuscated spaghetti code and leaving it for me to maintain. Also FTA:
Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.
I laughed out loud when I read this. I write in C++. It's my favorite language. But I can't stand these Duct Tape Programmers who are the ones casting to void * because they can't be bothered with templates. Now I know nothing of COM or CORBA, but multithreading is generally not something you have a choice about. Avoid it if you can, think very carefully about when you need to use it because of the application requirements.
Re:So, does the Duct Tape Programmer... (Score:4, Interesting)
Mine too, but I identify with Spolsky's duct tape programmers (not the term, but the idea).
We all set the limit somewhere ... Spolsky, JWZ, ESR and a whole lot of slashdotters think C++ is on the wrong
side of that limit. I like to think they're basing that on old information, from the hype days in the 1990s
when everyone had to pretend that they were developing abstract general reusable libraries
rather than Getting Work Done. I think that sick attitude is mostly gone from C++ today
(although some (not all) Boost libraries give me nasty flashbacks ...)
That is something to be grateful for,
Sure you have a choice. You can pick a task which has no need whatsoever for multithreading, and add threads. Lots of people do this, when a sane select() loop would have been enough.
Re:So, does the Duct Tape Programmer... (Score:5, Insightful)
That may be true... although personally, I find that when I'm really cursing some other programmer's name and wishing disease and misfortune upon him and his family, it's the work of a "ten-levels-of-inheritance deep wrappers around wrappers that wrap wrappers that generate code on the fly" overengineerer, rather than a spaghetti coder. At least with spaghetti coding, I can walk through it mentally and figure out what's going on (although it may take a while) - with "clever" code, I can't make heads or tails of it without a debugger.
Re: (Score:3, Insightful)
Extra bonus when they somehow manage to implement an O(n^2) problem in O(n^4).
Re:So, does the Duct Tape Programmer... (Score:5, Insightful)
I bet Joel doesn't drive to work in a duct-taped go-cart .... and I bet he wouldn't drive over bridges or work in a building which wasn't designed by a proper, qualified engineers/architects.
Out in the real world his "duct tape" programmer would be called a "cowboy builder".
As for his ranting on C++: He's demonstrated his C++ ignorance enough times for C++ programmers to just ignore his opinion - he still thinks it's just C with added bloat. I agree that multithreading is harder than it looks but templates and multiple inheritance...? Puh-lease.
The final nail in the coffin of the rant is in the last line where he says it's ok to avoid unit testing but that xoring two pointers together is somehow cool. If you weren't ignoring him before you should be by now.
Summing up: Joel has jumped the shark, every article just confirms it more
Re:So, does the Duct Tape Programmer... (Score:5, Funny)
Build a Man a Fire, and He'll Be Warm for a Day, Teach a mean to build his own fire and ruin a perfectly good business opportunity.
Set a man on fire, and he'll be warm for the rest of his life!
True that (Score:5, Insightful)
Agile, scrum, patterns, unit tests, etc.
.
Interesting ideas, but can anybody show me *any* significant, quantitative, comparative proof of improved ROI?
.
Software is about money guys.
You can't measure Synergy (Score:5, Funny)
You can't measure Synergy man, you just have to feel it!
Re:True that (Score:5, Insightful)
Agile, scrum, patterns, unit tests, etc. . Interesting ideas, but can anybody show me *any* significant, quantitative, comparative proof of improved ROI? . Software is about money guys.
From experience yes to unit tests. The number of times regressions have been picked up by a test bank before deployment to the UAT (user acceptance testing) system it pays for itself many times over. Patterns save time when an experienced group discusses design, but with developer turnover I get the feeling I have spent at least as much time explaining patterns to new developers as I have saved.
Re: (Score:3, Insightful)
According to TFA, there are times when you have to choose between unit tests and staying ahead of the competition. What would you do?
Re: (Score:3, Interesting)
Only unit test what needs to be unit tested. If it needs to be tested the testing will pay for itself. If it's simple enough that it doesn't need testing, then you're wasting your time writing those tests.
Half the benefit of the unit tests/test-first methodology is that they force you to design even your internal interfaces in a reliable way. The other half is knowing you didn't introduce regressions in that oh-so-clever code.
For most projects you don't need a whole lot
Re:True that (Score:5, Informative)
Unit tests are only as good as the programmers who make them. And if the programmer can think of a unit test... chances are that his code has already accounted for it; after all it's the same person, and he will be in the same mindset as he was when writing the code in the first place.
Re:True that (Score:5, Insightful)
Unit tests are only as good as the programmers who make them. And if the programmer can think of a unit test... chances are that his code has already accounted for it; after all it's the same person, and he will be in the same mindset as he was when writing the code in the first place.
Uh-huh, and then a year later, he needs to add some new and complicated functionality, but needs the old functionality to work too. He thinks he's preserving the old logic, but it has been a while and he is not in the same mindset anymore, and prior to committing the change to the repository, he runs the unit tests and -- woops! -- it fails. He goes and fixes it, now both the new and old functionality tests pass, and he checks in working code.
And by "he" I mean "me".
Unit tests do wonders for myself and my group. We develop a large and constantly evolving code base. And we have a saying/rule-of-thumb: There are features that are automatically tested in our check-in procedure, and there are features that are broken. How do you determine what needs testing? Well what do you want to still work a year from now? There's your answer.
It's not appropriate for every situation, but it works for us.
Re:True that (Score:5, Insightful)
Re:True that (Score:5, Insightful)
Um, no, you just disproved your own point.
Netscape did deliver a browser years ahead of the competition... And in all its crash-prone, flawed glory, people loved it. It took the web from a geeky novelty to a mainstream phenomenon. Not until MSIE 5 came out, a full five years after the first version of Netscape Navigator, did Netscape finally fall below 50% usage.
So the moral here? Beating your competition matters more than elegance - But having a viable business plan matters even more.
Re: (Score:3, Insightful)
I have a one-word rebuttal to that: Vista.
Re:True that (Score:5, Insightful)
I'd say at least write tests while you're closing bugs. Having an easily detectable bug pop up again two or three releases after you "fixed" it seems to indicate (even to non-developers) that you don't know what you're doing.
Re: (Score:3, Interesting)
According to TFA your reputation doesn't matter, just your ability to ship now now now.
In other words, how to be Electronic Arts. No thanks.
Re:True that (Score:5, Insightful)
Actually you've touched on the running theme in all of Joel's articles. Good developers are good developers. A good developer can get away with being a duct tape programmer, because they are good. Chances are that good developer could use almost any methodology and/or tool and ship working software. While it's interesting to look at the tools and methodologies good developers use, I would rather see ways to make mediocre developers better.
Re:True that (Score:5, Insightful)
From eperson experience, I ahve seen all you list work extremely well.
the projects took anywhere from 10 - 20% longer to go live, but all of them went out with huge success and barely any bugs. In fact one million line project went out and only had 2 bugs. Not a single one had a complaints about missing features or bloat.
Anecdotal, yes; however I ahve been programming for a long time and I was amazed at how well it worked out. Freaking amazed.
The problem s not that they don't work, the problem is most places don't actually implement them correctly, or have on partial buy in.
If your turd never gets out the door, that's a people problem, not a problem with the method of development.
Yes, software is about money in business; however management needs to begin to understand how to quantify it better. Taking 20% longer but have almost no fixes or down time after release isn't easily quantifiable, as such in is seldom considered.
A good accountant will find away to make it quantifiable, and good management will look at the overall projects vs project done via other development methods.
I just wrote an application, almost all of the function were just reuse of previous projects I ahve done. How does an account quantify the value of reuse?
If you write database classes more then once, you are doing something wrong.
Re: (Score:3, Insightful)
In fact one million line project went out and only had 2 bugs. Not a single one had a complaints about missing features or bloat.
Anecdotal, yes; however I ahve been programming for a long time and I was amazed at how well it worked out. Freaking amazed.
I'm amazed you can ship a million lines with only two bugs (found that is) when you misspell "have" as "ahve" three times in a single post. There are plenty of spelling "bugs" in your post and when I get through them, you have enough grammar "bugs" that it's hard to understand half of what you're trying to say -- that fact that it's logically inconsistent doesn't help as well. Please tell me you are not a native English-speaker and that all this craziness is just "lost in translation".
I just wrote an application, almost all of the function were just reuse of previous projects I ahve done. How does an account quantify the value of reuse?
Reuse of code does n
Re: (Score:3, Funny)
Maybe he's French...
Re:True that - NOT (Score:5, Insightful)
I manage a small team of programmers. When I first started, I 'inherited' a developer, let's call him Crufty Joe, who had worked at the company for 20 years and had developed financial and hr routines on the old mainframe and spiffy new oracle apps system. Joe had developed a lot of code, but he was always having to perform updates and corrections...
Why? Because he was a duct tape programmer! He always got it done by the deadline, but then he spent 75% of his time maintaining the huge pile of cruft that he had left in his wake over the years.
Well, Joe retired and I had to place two developers on his projects for the next year just to clean out all of the old '50% working' routines, in some cases we just tossed the exisiting work and started from scratch. What was really frustrating about this was that the Oracle apps have a huge, nearly incomprehensible, but extremely useful architecture that he did not even bother to leverage, but just wrote around.
This story acts like stopping to think about what you are doing means that you are going to implement huge, stupid architectures, but in reality he is just making excuses for being a sloppy hack. I feel damn sorry for anybody that has to support this crap in the future.
Re: (Score:3, Insightful)
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 pr
Re: (Score:3, Insightful)
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 cl
Re: (Score:3, Insightful)
Re:True that - NOT (Score:5, Interesting)
I guess in my experience, your example doesn't really go anywhere to disprove the article. IE I had a project where we followed all the correct design principles and did 2 years of work * 5 developers for a project that was to be the future of the company. Another division had started before us a similar project with slightly different goals. The sold management on their duct tape software that met some of the spec before ours. So my project got canceled. Their duct tape software had to be completely re-written to add the remaining features (8 years later they still haven't surpassed what we had almost done.) The fact that they were done (with something) first won out. The fact that duct tape allowed them to provide the solution, and buy them the time to re-write it, in my mind showed how it makes them more successful (I did replace a bunch of their code with ours, and the correctly written code spawned other projects to use its base, so not a failure.)
So the fact that your co-worker got the jobs, seamed to show people they needed that solution, and thus seams thats the reason you got the time to re-write them. Shows that duct tape programming "works." Even if it isn't always the most efficient method in the long run. IE this is about how many projects have just been abandoned because they were stuck in doing it the right way, where you slap something together, you got your foot in the door, and may buy the time to do it the right way.
Re: (Score:3, Insightful)
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
Re:True that - NOT - RTFA (Score:4, Insightful)
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.
Re:True that (Score:4, Interesting)
Software is about money guys.
Which is exactly what is wrong with software. Software should be about creating a useful tool. When you have a blacksmith who cares more about money than his craft, you have a poor blacksmith indeed. When you have a musician who cares more about money than music, he produces crap.
No wonder Linux is less insecure than Windows. Linux programmers are about making tools, Windows programmers are about making money.
Re:True that (Score:5, Insightful)
Software is about money guys.
Which is exactly what is wrong with software. Software should be about creating a useful tool.
For some people writing software is also about paying the rent and buying food.
Re: (Score:3, Interesting)
For some people writing software is also about paying the rent and buying food.
Do a job good enough that people want to pay you and you will be payed, but do shitty work and nobody will want to see you again. My dad always told me that about his construction but it applies here too.
Re:True that (Score:5, Interesting)
Indeed. I have a friend [slashdot.org] who works in construction. His boss is a stickler for quality and tries to keep costs down as well. As a result, he has more business than he can handle while his competetitors are cutting corners, charging high prices, and going out of business right and left.
Re:True that (Score:4, Insightful)
Re: (Score:3, Insightful)
Which is exactly what is wrong with software. Software should be about creating a useful tool.
A truly useful tool either makes or saves money. If you build a hammer that has perfect balance and pounds in a nail with one hit every time, someone will pay you money to have one like it.
No wonder Linux is less insecure than Windows. Linux programmers are about making tools, Windows programmers are about making money.
More like: no wonder Windows is more popular than Windows. Linux programmers are about making cool hacks they like, Windows programmers are about making tools people actually use, and thereby make money for their efforts.
Re: (Score:3, Insightful)
Money provides the motivation to do good work. A blacksmith who cares so much about his work he redoes everything 6 or 7 times until it is perfect is a blacksmith who will soon be begging for food.
A programmer who produces shitty code for money was never capable of producing quality code.
Re:True that (Score:5, Insightful)
I'm probably a "duct-tape programmer" in some ways. How did I become one? By learning everything I could about being an "architecture astronaut" first.
You learn how to do things properly and then you know when and when not to step back from that. If anyone RTFS and says to themselves they don't need to have a good solid understanding of the principles of software design or even a grounding in some of the popular modern methodologies. The linked article is full of colourful metaphors about go-karts and WD-40. Making your argument by metaphor is usually a bad sign - you use them for people who would have trouble understanding the subject if you just stated the case plainly. I hope that's none of us. The article writer seems to see some great division between those who "wield their WD-40 and duct tape elegantly even as their go-kart careens down the hill at a mile a minute" and those who "are still at the starting line arguing over whether to use titanium or some kind of space-age composite material". Well the division between those two groups isn't normally one between two sets of people, but between two environments and resource levels. In an ideal situation, I'll create a rigorous specification and use that as the formal basis for my unit tests and do things by the book. Sometimes I find myself "careening down the hill" because I'm suddenly dumped a big, live system and told "make these vaguely described modifications by yesterday". And I'm the same individual. I'll tell you what I want to see if you're in that latter environment - I want to see someone who understands what corners they are cutting and when to do so and when they can't. Same goes for some of the project management methodologies. You don't have to do things by the letter of the law of Agile development or whatever, but if everyone in the group understands the principles, it can streamline things.
Being better than the rest at anything doesn't come easy. This stupid article has some metaphorical "duct-tape programmer" who doesn't need to bother with the "achitecture astronaut" stuff because they're a whiz with their "WD-40". Enough with the metaphor. Show me the real instances of people who are better than others because they don't know about the theory.
Some articles are stupid. This is one. It's a load of overblown metaphor and hypotheticals. Ironically enough, it falls into the trap of dealing only in hypothetical and idealised situations that it lambasts some programmers for. Sure - if you're up against a tight deadline and in the midst of a melee of programmers, don't waste two weeks drawing UML diagrams and Gantt charts. But that sort of judgement has nothing to do with not knowing the principles of software design or project management. Banging out a quick website might be a case of shifting images left and right from day to day based on customer feedback. But real programming is most definitely not a "downhill go-kart race". It's about producing maintainable, reliable code that meets the customers' needs. And if you see someone who looks like they're gluing brilliant code together on the fly with "duct tape", you'll probably find they're someone with a lot of experience and who understands the theory well enough that you don't notice them using it. As Ovid said: "Thus by art, is art concealed." In other words - they make it look easy, because they're good.
Re:True that (Score:4, Interesting)
Exactly. All of Joel's articles about about good to expert developers. More than likely the people he describes could use any tool or methodology and ship correct, working software.
This reminds me of when people try to copy a particular athletes workout or diet. Most professional athletes are genetic wonders and many succeed at their sport not because of their workout and diet, but in spite of it.
Re:True that (Score:5, Insightful)
Nobody cares if it's ugly and stiched together
... except the guy who has to go into it six months down the road because a new requirement came up or a new system must be integrated
Ruel of Thumb (Score:5, Insightful)
Re:Ruel of Thumb (Score:5, Funny)
Well yes, but it's me and it's usually my own code. Perhaps this explains why I keep meeting myself in the halls.
Re: (Score:3, Funny)
Re:True that (Score:5, Insightful)
One of the important things I learned awhile after leaving school, was that no one really cared how elegant or perfect my programming was, they really just wanted the work to get done. Missing the deadline just to make things look better didn't help anyone. Of course it was nice to get code that was easily maintainable later on, but it shouldn't be your primary goal. I've seen some overengineered architectures that looked like someone was trying to make things easy to maintain, but the result was a nightmare to modify because no one understood all the layers and abstraction, and a "simple" porting job where the team took so much time creating the perfect portability layer that the product never finished.
Re:True that (Score:5, Insightful)
You'd be surprised how many money generating services run on top of really sloppy code that you wouldn't want anybody else to see. ... Nobody cares if it's ugly and stiched together.
I think this is true of many things in life outside the realm of software development: most people would be horrified if they knew the real story about how most things are made, and how thin the veneer of "quality" is sometimes. Over the years I've just come to accept that the universe is fairly forgiving of mediocrity.
I don't think this is a valid reason to intentionally do shitty work, but it's probably good to remember that if you make a good faith effort at building something in a non-sloppy manner, it's going to fare pretty well most of the time.
Re:True that (Score:4, Insightful)
my employer's fault (Score:4, Interesting)
my employer knows I can whip out a fast 4,000 line (but ugly, no artistic talent) web portal or e-commerce app in a month when it should be a 20K line project done by a team, so that's what we do. dangerous I think, we handle real money with that shit.
Re: (Score:3, Insightful)
Your employer measures the utility of a program by how many lines are in it. That's all that's needed to know that your management are clueless and are proud of pushing crap out the door.
Re:my employer's fault (Score:4, Informative)
hahaha. you know, I once had a boss that would make stupid statements like that, how he could have done xyz in minutes. one day I threw the keyboard at him and said, "you are full of shit, show me!" that stopped his b.s. bragging to me at least, though he continued to b.s. everyone else.
Re:my employer's fault (Score:4, Funny)
Re: (Score:3, Insightful)
wow, i could write your 4000 lines of code in 3 days.... why does it take you a month?
Because there is a lot more to developing an app than writing code.
Re:my employer's fault (Score:4, Insightful)
I can write 4000 lines of code in 3 days too... Or alternatively, I can write 60 useful lines in the 3 days, and be 60 useful lines of code ahead of you.
Bad Mischaracterization (Score:5, Insightful)
The "duct tape programmer" is just as dangerous as the "astronaut architect".
What distinguishes good architects from these fools is this:
A good architect is someone with the experience to know when to cut corners and when to enforce rigid discipline.
Re: (Score:3, Insightful)
A good architect is someone with the experience to know when to cut corners and when to enforce rigid discipline.
Which is entirely subjective by definition, so we're back to the basics: a good programmer writes working programs.
Re:Bad Mischaracterization (Score:5, Insightful)
After reading the article, there's nothing we didn't know before: release early, release often. But here's the killer quote all of you need to duct tape somewhere in your office right now:
Duct tape programmers dont give a shit what you think about them. They stick to simple basic and easy to use tools and use the extra brainpower that these tools leave them to write more useful features for their customers.
Re: (Score:3, Insightful)
Duct tape programmers dont give a shit what you think about them. They stick to simple basic and easy to use tools and use the extra brainpower that these tools leave them to write more useful features for their customers.
Exactly. Many posts will go on about how having a good architecture will make it easier to maintain in the long run, and other such things, but it all comes down to one thing:
TIME
If your code is useful, it will be used, you will get revenue (hopefully!), and you will have the TIME to improve things, clean up code, write unit tests, and all of the other things that are good and proper in life, but which only indirectly benefit the end used. This is the fundamental opportunity cost for software.
Re: (Score:3, Insightful)
The killer (literally) quote for me was:
When you are done, you might have a messy go-cart, but itâ(TM)ll sure as hell fly. ..ONCE.
I guess the last word got edited out.
I'm all for the least formal processes consistent with the production of reasonable quality software shipping on schedule using the resources you have available. But anyone who has had to maintain the code written by cowboys (which is what DTP's are) knows how much damage their unbridled attitude can do to a company.
The article acknowled
Re:Bad Mischaracterization (Score:5, Interesting)
Several issues cloud this mix:
At the bottom of every successful development are a few people who just get on and write the code, it's where it actually happens. Ever see a hole in the road where one guy is down the hole with a shovel, and 4 others are stood around the top? I'm the guy down the hole, have been down coding holes for 20 years and pretty much every project I have started coding, I have finished and delivered, some where big methodology driven things, some where me against the world with a couple of weeks to deliver. But get keen interested and pragmatic people on the shovel and the job gets done
"Shit and fix" coding (Score:3, Interesting)
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 t
Re: (Score:3, Insightful)
I've been writing code for 30+ years. I've seen all of these disciplines come in and out of favor.
Each started with a simple concept, and was then perverted into something so that people who couldn't code could design and run projects and get paid more than the coders. Agile programming was the closest to anything useful, then it too was perverted with a bunch of useless rules and methodology structures that every
Re: (Score:3, Interesting)
Agreed. I have a guy on my staff who is constitutionally unable to cut corners. The upside is, when he says the feature he's working on is done, by god, it's done. I can't remember the last time we found a bug in his code. The downside is, it takes him a long time, and sometimes we would really like to have the first 80% of the functionality done quickly so that other people could start to bu
Oh no. Now all the numties have an excuse! (Score:5, Insightful)
False dichotomy (Score:5, Interesting)
I'm plagiarizing a point I saw on Reddit and I'm too lazy to find the original article, but I agree with the author of it: there doesn't have to be a choice between "crappy duct tape" programming and "crappy over-architected" programming. A decent programmer can get both: a small program that does its job well, AND can be extended in unplanned-for ways for new functionality.
Industry Software (Score:3, Insightful)
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.
Re:Industry Software (Score:5, Insightful)
Liability doesn't mean power. Liability just means liability. Personal liability and sign-off for developers just means he has to choose between bankruptcy and a life of "Would you like fries with that?" if failure occurs, or losing his income now (and possibly having trouble finding a job because he's got a reputation for being difficult) because he won't sign off.
"Don't forget to ship your software!" (Score:5, Insightful)
Why is it that whenever I read an article by Joel I feel like I'm being talked down to?
Re:"Don't forget to ship your software!" (Score:5, Insightful)
Becasue Joel is an ass.
Seriously, he is an ass, and is often wrong.
Re:"Don't forget to ship your software!" (Score:5, Funny)
Hey, it's a great piece of advice if ex Duke Nukem Forever programmers read the article!
Re:"Don't forget to ship your software!" (Score:5, Insightful)
He starts out with a good premise, that as programmers we tend to want to over-engineer stuff and that is something we should try to avoid because it adds unnecessary cost to a project. Then he apparently has a brain hemorrhage and starts dumping on a whole host of invaluable software tools that actually increase productivity and reduce errors, both of which help you ship your code faster.
And what the hell is he talking about with "those breathtakingly good-looking young men"? Homoeroticism aside, what does this have to do with anything? The only thing I can see is that he's saying these guys can get away with horrific things (e.g. not writing unit tests, pointer voodoo--wait, I thought we weren't using C++-like languages because they're too hard and you can't ship quickly enough), simply because they are pretty and/or smart. I thought this was also how people got away with over-engineered projects too? The smart, charismatic guy proposes a solution that's over-the-top but everyone is too busy being in awe over his intelligence or their desire to fellate him that no one notices.
Am I way off-base here? As I said, I usually like reading Joel's stuff and I feel like I've learned a few things from his articles but after this I'm left wondering where he's getting access to such fine recreational drugs and hot, smart programmer guys.
even better than the duct tape programmer (Score:5, Funny)
is the duct tape manager
trying to hop in his chair to the phone, arms bound to the armrests with duct tape, screaming MMMMPH MMMMPH through the glorious dull shiny grey of...
what were we talking about?
Different approaches for different problems (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
No. In scenario 1, what should be done is trying to get the customer to reduce the problem. It is unlikely that the customer regularly deals with 400 different forms, much more likely is that at most 5 forms stands for 99% of the traffic and the other 395 are one-off's much to rare to spend time on. The correct approach is to identify those 5 forms, implement the processing for those forms as quickly as possible and then evaluate if the client is happy.
Then when the system has been delivered, you may refact
Netscape a victim of too much duct tape? (Score:5, Insightful)
Curious that JWZ and his time at Netscape were particularly lauded here.
It's quite likely I'm being a bit snarky here... but Netscape lost the browser wars just a few years after they hit it big. And the core code of Netscape Navigator was bad enough that they eventually abandoned it around 1999 with the start of the Mozilla project.
Now don't get me wrong, it was only through the herculean efforts of guys like JWZ at Netscape that allowed them to ship a product at all. And certainly it made him and some of the founders a lot of money, which is a valid measure of success in business.
But to point to that particular code base as an example we all should follow? I don't think so. Certainly, choosing C++ then (or now in my opinion) is a mistake. And I've definitely seen people get overly rambunctious with architecture... especially in the Java world. But I think that's mostly the result of programming languages sucking as much as anything else. That and most people just aren't that good at design. Mostly meaning that when they've come up with a bad design themselves, they can't admit that and then really do what it takes to try and fix it. Of course, in the business world there are always severe time / money constraints, so that makes it real hard. And that's when not having unit tests hurts more... because it is harder to make significant changes to the code and have some assurance you didn't make mistakes.
Re:Netscape a victim of too much duct tape? (Score:4, Informative)
Certainly true for Joels world of market economy.. (Score:4, Insightful)
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.
Duct tape is fine, if you throw it away quickly (Score:5, Insightful)
Shipping is easy. Any idiot can whip something together that solves a problem, ships on time etc. That is rarely the issue. The issue is doing it in a fashion that will scale, be extensible, modifiable, understandable, high performing... the list goes on.
Given enogh time, any idiot could also make a system that is polished and architected to the point where it is fast, modifiable and extensible, and long overdue.
Bottom line: the whole skill of this business is delivering something that is architected enough while still meeting the deadline. In my experience, the necessary timeframe to deliver something long lasting and well architected is around five to ten times the time it would take to just solve the problem (tm). Of course many business exist today because they managed to release something to make money. The biggest mistake of many startups is probably polishing too much and not releasing early enough. The biggest mistake of those who DO make it past the first release is to not throw the first solution away and start over if it was something duct taped together.
Re:Duct tape is fine, if you throw it away quickly (Score:5, Insightful)
Everyone seems to be taking this article as "do anything it takes to ship" and saying that's a horrible attitude.
Your comment is the first I've seen that seems to be more along my understanding of the piece. Duct Tape Programming is about getting what is needed done and building from there.
"I need a website that lets people share videos".
So what do you do? Do you make a little site that serves flash videos? That's Duct Tape Programming.
Making a little site that takes videos and catalogs them and tries to analyze them for similarity and has editing tools and needs to be able to scale to 20 computers and... That's the problem.
When you start your site, it's OK to have it not be able to instantly scale out to 10,000. Sometimes it's better to get the basic features there and build them up and fix them as you go. Not everything needs to be there from day one. Not everything needs 3 layers of abstraction because it's "what people do".
As your program goes on, you clean it up, add abstractions where needed. The first version of Word for Windows didn't look ANYTHING like the current version. If you are going to make a new word processor, you go after the old version, not aim at the sky.
Your understanding of his post agrees with mine. This isn't about a system to last 20 years, this is about a system to fix things NOW while you make it better so your users don't have to keep doing things by hand for 6 months while you try to figure out why your framework build on another framework isn't interacting correctly with some other thing.
The problem with Duct Tape Programmers (Score:5, Insightful)
Joel Spolsky, meet TheDailyWTF (Score:5, Insightful)
My respect for him ratcheted down quite a lot. Yes, you must ship (who knew?). That's what milestones and deadlines are for, so keep overarchitecting and feature creep from occurring. However, I would NEVER want to let a "Duct Tap Programmer" near any project that I would ever have to modify, maintain, or extend. You know, something that isn't completely trivial.
Re: (Score:3, Interesting)
Refactoring is an art that all programmers should cultivate. It turns shitty code into nice code, without breaking it or losing all the bug-fixes that have been hacked in over the years. In most cases, ugly code needs refactoring, not rewriting.
Architecture astronauts (Score:5, Interesting)
I don't think this guy ever worked with any software engineer with any significant amount of experience. Or maybe he just works with people that suck as software engineer.
The typical evolution towards wisdom in Software Engineering goes like this (simplified):
At best what the guy in the article is calling "duct-tape programmer" is somebody past the 3rd transition only and what he calls and "astronaut architect" is somebody past the 2nd transition only.
I would hardly call a junior designer type "architect".
As a duct tape programmer, I strongly disagree. (Score:3, Interesting)
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.
There's a place for only Duct Tape Programmers... (Score:3, Interesting)
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).
Since when did quality become optional? (Score:4, Informative)
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.
Re:Since when did quality become optional? (Score:4, Interesting)
Good enough means good enough. It's not 50%. It's not 80%. It's whatever is the powers that be decide is the appropriate trade-off between competing interests (i.e. time to market, cost of deployment, $ paid to developers, estimates of the cost of future bug fixes, ...). If the market doesn't accept the product, it only means that their definition of "good enough" was wrong, not that there isn't a different "good enough" that the market will embrace.
"Good enough" for the software that runs a nuclear reactor or the space shuttle is probably near 100%. Pace-makers, surgeries, and pharmaceuticals failing? It's been known to happen. Sure, maybe only in 1/10000 cases, and only if you don't have a pre-existing condition. So, good enough is maybe five nines there. "Good enough" for that $1 umbrella you bought at Wal-Mart probably means something entirely different.
Joel, the authority on programming? (Score:4, Insightful)
First off, Jamie Zawinski no longer programs much. He runs a nightclub. [dnalounge.com]
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.
Duct tape sucks (Score:4, Insightful)
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...