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."
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.
Bad Mischaracterization (Score:5, Insightful)
The "duct tape programmer" is just as dangerous as the "astronaut architect".
What distinguishes good architects from these fools is this:
A good architect is someone with the experience to know when to cut corners and when to enforce rigid discipline.
Re:Bad Mischaracterization (Score: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.
Oh no. Now all the numties have an excuse! (Score:5, Insightful)
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.
Well... (Score:2, Insightful)
One month to write and years to debug and get right.
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: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.
"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?
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:True that (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: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: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
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.
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.
Re:True that (Score:5, Insightful)
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:"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:Bad Mischaracterization (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.
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.
The problem with Duct Tape Programmers (Score:5, Insightful)
Re:Bad Mischaracterization (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 everyone had to be sent off to class to learn.
The top percentage of coders are already architects without the label. All they need is a software request and a rough diagram of system components in order to get started. They understand how to write code so it interacts nicely with other code.They know how to write code the traps and handles errors properly. They know how to write code that doesn't blow up because some unknown data crept into the system. They know how to write efficient code and do performance testing. They don't need to sit down and design an entire system down to each module, they can pick a spot to start and just begin coding. Sure, they might have to change a few things as they go, but I've never seen a system designed by architects that didn't need some tweaking along the way either.
What it all comes down to is we still do modular programming and design with flowcharts, there just called different things and have different rules now.
Architects are needed for developers with poor design skills. Developers are needed for architects with poor coding skills. Take the time to find employees with both and just get the work done. Let your competition spend too much money hiring too many people and follow fads.
Gotta go
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:my employer's fault (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:Different approaches for different problems (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 refactor the code to add support for the more common of the 395 remaining formats. Trying to implement parsers for all those 400 formats at once is a recipe for disaster. You will get architecture astronauts discussing "what if"-scenarios endlessly while building X layers of abstractions without getting anywhere.
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: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: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: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.
Ruel of Thumb (Score:5, Insightful)
Re:True that (Score:4, Insightful)
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.
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.
Re:Bad Mischaracterization (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 acknowledges this at the end: DTPs are pretty boys. They make it all look so easy, because they can make excellent and refined judgments on the fly about what corners to cut and what bits are genuinely critical. But the reality is that anyone who thinks they are a DTP isn't one, and they'll cut too many corners, and produce something that is the equivalent of a go-cart that makes it through one race and then falls to bits, because duct tape just isn't that durable, and people who rely on it in production environments are dangerous idiots.
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.
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:True that - NOT (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 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.
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:3, Insightful)
I have a one-word rebuttal to that: Vista.
Re:True that (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:True that (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 not mean it's bug free -- sure you've had some testing on the previous code but using it in new and different ways is bound to expose bugs in any non-trivial piece of code.
Re:my employer's fault (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:True that - NOT (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 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.
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:Isn't this Microsoft? (Score:2, Insightful)
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.
Re:Bad Mischaracterization (Score:2, Insightful)
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:True that - NOT (Score:3, Insightful)
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.
Re:True that - NOT (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 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.
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:True that (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:So, does the Duct Tape Programmer... (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: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.
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.
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: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:True that - NOT (Score:3, Insightful)
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."
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:2, Insightful)
No, I don't forgive them for writing obfuscated spaghetti code and leaving it for me to maintain.
"Spaghetti code" is just a term used by programmers to describe someone else's work.
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:4, Insightful)
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:3, Insightful)
For the uninitiated, this is one of the reasons Ruby and Python programmers can deliver broken code in a tiny fraction of the time it takes Java or C# programmers.
Fixed that for you. Static typing is a safety check. Get rid of it, you also get a higher chance of runtime bugs that slip through undetected, and lie dormant until you trigger the exact condition that leads to the bug.
"But", you hear the adherents of dynamic languages saying, "this is what unit tests are for! Just make sure you have 100% coverage, and you'll be fine!". But that's the point - to truly get to that 100%, especially in a reusable framework, it means you have to test things such as someone passing an object of a wrong type to your method - something that is simply impossible in, say, Java. So Java developers may lose on the amount of code because of all the extra type annotations, but win on not having to test type safety violations that the language checks for them.
Of course, in an article about "duct tape programming", this point is probably moot - "duct tape", as described in TFA, strongly implies "no unit tests".
Re:True that (Score:3, Insightful)
I wasn't picking on him because he was dyslexic, I was noting that given the quality of his post, I found his claim (of 99.9998% bug-free code) to be hard-to-believe.
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...
Re:Joel Spolsky, meet TheDailyWTF (Score:1, Insightful)
Exactly. He seems to think that the alternative to over-architecting is not architecting. Um, what about just properly architecting?
Re:Since when did quality become optional? (Score:2, Insightful)
This is getting late in the posting, so I don't expect many people to read this but ...
20 years of developing software has taught me that good enough is good enough. What is good enough for one project, is overkill for another, and nowhere near good enough for yet another. As a software developer, I see my job as turning code into $$$. Good enough means that you have to perform a mental cost-benefit analysis on what you develop.
But what is good enough? That is the variable. Sure, there are twits out there who try to argue that there is exactly one level of "good enough" for ALL projects. Clearly for the products that you cite, 50% is not good enough. But for some things, if something works only half the time, it could (does not translate to will) still be useful enough to be put to use.
Over time, user demands, and competition will push the "good enough" bar higher.
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:3, Insightful)
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
The solution is templates and type inference, not moving type errors to runtime.
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.