×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Duct Tape Programmer

kdawson posted more than 4 years ago | from the coders-at-work dept.

Programming 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

551 comments

So, does the Duct Tape Programmer... (3, Funny)

K. S. Kyosuke (729550) | more than 4 years ago | (#29539505)

...also protect you from sellers of snake oil and fake gems?

Re:So, does the Duct Tape Programmer... (4, Funny)

goombah99 (560566) | more than 4 years ago | (#29539885)

...also protect you from sellers of snake oil and fake gems?

No but I have a one-line perl script for that.

True that (5, Insightful)

gestalt_n_pepper (991155) | more than 4 years ago | (#29539523)

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.

Re:True that (1)

Anonymous Coward | more than 4 years ago | (#29539565)

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.

Nice, structured and clean code is appreciated, but this is the real world we're talking about where deadlines are everything. Getting it up and running is the goal. Nobody cares if it's ugly and stiched together.

Re:True that (5, Insightful)

oldspewey (1303305) | more than 4 years ago | (#29539843)

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

Re:True that (4, Insightful)

NewbieProgrammerMan (558327) | more than 4 years ago | (#29540069)

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 (5, Insightful)

Chrisq (894406) | more than 4 years ago | (#29539595)

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:True that (2, Insightful)

Jurily (900488) | more than 4 years ago | (#29539735)

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 (3, Interesting)

plalonde2 (527372) | more than 4 years ago | (#29539825)

I'd avoid the false dichotomy.

Only unit test what needs to be unit tested. If it needs to be tested the testing will pay for itself. If it's simple enough that it doesn't need testing, then you're wasting your time writing those tests.

Half the benefit of the unit tests/test-first methodology is that they force you to design even your internal interfaces in a reliable way. The other half is knowing you didn't introduce regressions in that oh-so-clever code.

For most projects you don't need a whole lot of tests but there will be a couple of subsystems that you almost can't manage without them.

Re:True that (5, Insightful)

bcmm (768152) | more than 4 years ago | (#29539879)

If somebody shipped a browser as crash-prone as Netscape was today, it wouldn't matter if it was three years ahead of the competition. People would play with it for a bit, and then use something stable. It's possible that the type of programming he's talking about works only in the specific situation that there isn't reasonable competition, yet.

Re:True that (1)

Jurily (900488) | more than 4 years ago | (#29540015)

People would play with it for a bit, and then use something stable.

Exactly. Then you come out with the stable version, and win. Early releases aren't products, they're marketing.

Re:True that (1)

moranar (632206) | more than 4 years ago | (#29539911)

You could also hire better new developers. Or at least, ones that have design patterns experience.

Re:True that (1)

tepples (727027) | more than 4 years ago | (#29540031)

You could also hire better new developers. Or at least, ones that have design patterns experience.

If none of the local schools do a good job of teaching patterns, that could get very expensive very fast.

Re:True that (1)

moranar (632206) | more than 4 years ago | (#29540071)

You could also incorporate 'experience working with design patterns' into the interview process. Just a thought.

Re:True that (5, Insightful)

geekoid (135745) | more than 4 years ago | (#29539811)

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 - NOT (5, Insightful)

garyisabusyguy (732330) | more than 4 years ago | (#29539889)

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:True that (3, Interesting)

mcgrew (92797) | more than 4 years ago | (#29539947)

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 (5, Insightful)

ChienAndalu (1293930) | more than 4 years ago | (#29540051)

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 (5, Insightful)

h4rm0ny (722443) | more than 4 years ago | (#29539983)


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.

my employer's fault (3, Interesting)

rubycodez (864176) | more than 4 years ago | (#29539525)

my employer knows I can whip out a fast 4,000 line (but ugly, no artistic talent) web portal or e-commerce app in a month when it should be a 20K line project done by a team, so that's what we do. dangerous I think, we handle real money with that shit.

Re:my employer's fault (0)

Anonymous Coward | more than 4 years ago | (#29539633)

wow, i could write your 4000 lines of code in 3 days.... why does it take you a month?

Re:my employer's fault (0)

Anonymous Coward | more than 4 years ago | (#29539695)

Somehow I doubt 4000 lines of "hello world" is what his employer is looking for.

Re:my employer's fault (3, Informative)

rubycodez (864176) | more than 4 years ago | (#29539717)

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 (0)

Anonymous Coward | more than 4 years ago | (#29539795)

yeah, but i am not full of shit and would take your challenge any day, just to crush you and make you look stupid.

Re:my employer's fault (1)

K. S. Kyosuke (729550) | more than 4 years ago | (#29539739)

Comments don't count! (And neither does autogenerated code. And I will only accept "MyInsanelyLongClassName i = MyInsanelyLongClassNameFactory.getInstance()" as, say, twenty chars. Don't try to look *that* important.)

Re:my employer's fault (3, Insightful)

mksql (452282) | more than 4 years ago | (#29540013)

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 (1)

geekoid (135745) | more than 4 years ago | (#29539847)

Software isn't art, it's engineering.

It's YOUR fault, you are the engineer. Learn how to do engineering.
When was the last time you wrote a risk analysis of releasing a quick and dirty app to management? when was the last time you got an actual design sign off?

Youa re nothing more then the type of hack that holds this industry back.

Real artists ship... (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29539545)

...exploding phones and MP3 players and cracking computer cases.

Bad Mischaracterization (5, Insightful)

smack.addict (116174) | more than 4 years ago | (#29539549)

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 (2, Insightful)

Jurily (900488) | more than 4 years ago | (#29539577)

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 (4, Insightful)

Jurily (900488) | more than 4 years ago | (#29539677)

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:Bad Mischaracterization (3, Insightful)

xleeko (551231) | more than 4 years ago | (#29539937)

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:Bad Mischaracterization (0)

Anonymous Coward | more than 4 years ago | (#29539797)

True, but not all authors of working programs are good programmers. For evidnce, see any pile of unmaintainable, but working shell scripts. Programming is an engineering discipline, and as such it has practical concerns like maintainability, suitability to the task, scalability and adaptability. Balancing those factors and still shipping a working result on time is really quite hard, and requires a skilled individual.

Re:Bad Mischaracterization (1)

Jurily (900488) | more than 4 years ago | (#29539917)

Balancing those factors and still shipping a working result on time is really quite hard, and requires a skilled individual.

Yes. However, merely blurting out truisms will not help anyone. It's not what they achieve that's important, but how. More precisely, what can I do to achieve the same level of success.

GP: "Write good programs fast, and ship on time."
TFA: "If someone proposes an architecture that's way more complicated than it is necessary for the task, just say no and stop caring what they'll think."

See the difference?

Re:Bad Mischaracterization (1)

camperdave (969942) | more than 4 years ago | (#29539923)

Except when a program falls over it rarely kills people or costs tens or hundreds of thousands of dollars, you either end task it or reboot the computer. There's practically never an investigation done as to why it crashed. Code is never inspected by government regulators. A programmer will not lose his or her job if their program crashes.

Architects are engineers. They are held to quality and safety standards, and face severe penalties for non-compliance. These standards have been developed over time by investigating failure modes of materials and structures. These standards are neither subjective nor arbitrary.

Re:Bad Mischaracterization (1)

rcuhljr (1132713) | more than 4 years ago | (#29540075)

That's not at all universally true. Writes software for defense and medical purposes some time.

Re:Bad Mischaracterization (0)

Anonymous Coward | more than 4 years ago | (#29539959)

There's a lot more to it then that. I spent a summer working for a lumber company that had all of their programs written by an electrical engineer who taught himself C. There was no formatting, an obscene usage of goto's, global variables labeled x and y, and 90% of the program was around 15,000 lines of code in one file.

The program worked, but nobody except the guy who wrote could make any sense of the code, and if something broke it would take weeks to fix instead of hours.

A program needs to work, but it also needs to be serviceable, and that is where the rigid discipline comes into play.

Re:Bad Mischaracterization (1)

Xest (935314) | more than 4 years ago | (#29539605)

Spot on.

I can't think of anything more disasterous than having either an architect astronaut OR a duct tape programmer, well, except perhaps having both.

The problem is that architecture in itself helps speed up application development. An application that is just an unorganised mish-mash of code is going to cause massive delays when something needs to be changed and that's a key point - over-architecting means something will be extremely slow to produce, but likely be extremely easy to maintain, under-architecting means it'll be extremely quick to produce, but an absolute nightmare to maintain. A good developer can get the middle ground and enjoy the best of both worlds, ultimately ending up with a much better program, in a reasonable timeframe and that remains maintainable, saving massive amounts of time over the duct tape programmer's monstrosity in the long run.

Re:Bad Mischaracterization (1)

WinterSolstice (223271) | more than 4 years ago | (#29539699)

I happen to have firsthand experience in a shop where the astronautical architecture teams (yes, several dozen of them, with 10-15 people each) come up with rigid and overengineered concepts that they then throw over the wall onto piles of outsourced contractors who are sub-duct tape level.

This results is crazy weird decisions with awful execution.

Yes, you are right. Having both is a freaking nightmare. I had to sit in the middle, attempting to preserve database and system uptime while developers wrote code to store massive PDFs of every single EDI transaction inside a database, then killed appservers writing code to parse the PDFs and turn them in XML on the fly at the other end.

Worthless. Just utter crap.

Re:Bad Mischaracterization (1)

Oriental_Hero (72624) | more than 4 years ago | (#29539649)

Heh, Joel in the article says a similar line for "Duct Tape Programmers"
"Duct tape programmers have to have a lot of talent to pull off this shtick"

Anyone got a more succinct way of putting this like the above for architects?

Re:Bad Mischaracterization (4, Interesting)

khakipuce (625944) | more than 4 years ago | (#29539713)

It's all about the people, a good developer (and a good architect) can use anything from a duct tape approach to a full-on methodology based life-cycle depending on the scale, complexity and critcality of the job in hand. You cannot use the same approach for building a sky scraper that you might use for building a garden shed.

Several issues cloud this mix:

  • Non technical management really struggle to tell genuinely good developers from braggards and people who must be good because they are weird
  • Architects and analysts want fashionable things on their CVs as much as developers do, so they push towards the newest buzz because their next job may depend on it

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

Re:Bad Mischaracterization (1)

Trails (629752) | more than 4 years ago | (#29539813)

Additionally, a good architect will discuss and collaborate with the Duct Tape Programmer.

Re:Bad Mischaracterization (1)

geekoid (135745) | more than 4 years ago | (#29539869)

A good architect is someone who knows how to lay out the archetecture reasonable WITHOUT cutting corners.

The can write up a doc t present to management in a day outline the plan.
The know how to deal with management push back by delivering risk analyst.

Christ people, it's time to come out of the basement and be professionals.

"Shit and fix" coding (2, Interesting)

RingDev (879105) | more than 4 years ago | (#29539875)

I'm completely with you on that one. What Joel is effectively lobbying for is what I've long termed "Shit and fix" coding. You write something dirty but quick to meet the minimal needs of the project. You have non-existent testing, inconsistent modularization, and a maintenance nightmare that crops up every 6 weeks as the application breaks or users request a functional change.

After a few years the application is such a mess and original knowledge sources are so far gone (documentation? what's that?) that the only option for the company is to recreate the application from scratch. Blowing tens if not hundreds of thousands of dollars on fixing the pile of crap that has been building up.

There is definitely a balance between over engineering and minimal effort. I've seen efforts to go in both directions. If I had a dollar for every time I saw someone put IO operations on the GUI thread in Windows, I'd be a rich man. But at the same time, I've seen people design data abstraction layers that turn a 3-tier application into a 7-tier "solution".

-Rick

Re:"Shit and fix" coding (1)

PinkyDead (862370) | more than 4 years ago | (#29540001)

And from a management level the "Shit and Fix" programmer is great because they got the product out the door.

The "useless one" is the one who comes in to implement the simple feature that the customer wants, but can't. Not because it's beyond him, but because the original thing fails to provide the most important features for any product that is going to grow - maintainability and adaptability.

However, if I may adapt your motto - the "Quick shit, learn and dump" model actually works quite well.

Balance (Re:Bad Mischaracterization) (1)

Tablizer (95088) | more than 4 years ago | (#29539909)

I agree. The best is a balance. It's okay to explore new techniques for making cleaner or more re-usable code, but there are those who become purists and fad zealots and get carried away. The best systems in terms of delivery and maintainability are controlled by a middle ground.

Re:Bad Mischaracterization (2, Insightful)

johnlcallaway (165670) | more than 4 years ago | (#29539979)

What a bunch of bs...putting labels on things and trying to force people into tiny boxes.

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 .. I got shit to do.

Oh no. Now all the numties have an excuse! (5, Insightful)

freddled (544384) | more than 4 years ago | (#29539579)

I agree with most of Joel's post. What bothers me with this kind of thing is that there are a lot of idiots out there just waiting for an excuse for their poor standards. For every real Duct Tape Programmer there are ten buffoons who will now take that label for themselves. But hell they shoudln't be hard to spot.

False dichotomy (5, Interesting)

ciggieposeur (715798) | more than 4 years ago | (#29539599)

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.

Re:False dichotomy (1, Funny)

Anonymous Coward | more than 4 years ago | (#29539753)

there doesn't have to be a choice between "crappy duct tape" programming and "crappy over-architected" programming.

Indeed. I do crappy over-architected duct-taped bodgecode every day.

Well... (2, Insightful)

Anonymous Coward | more than 4 years ago | (#29539603)

One month to write and years to debug and get right.

Industry Software (2, Insightful)

Jazz-Masta (240659) | more than 4 years ago | (#29539611)

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 (0)

Anonymous Coward | more than 4 years ago | (#29539897)

Please show them

http://msdn.microsoft.com/en-us/library/aa365261%28VS.85%29.aspx

And/or

http://msdn.microsoft.com/en-us/library/aa365721%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/aa364583%28VS.85%29.aspx

Each of these should let you 'watch' for file changes in a system. Mostly the second one is what you really want. It 'marks' when something in some file changed and what file changed (not the change itself). Its pretty cool.

Re:Industry Software (1)

geekoid (135745) | more than 4 years ago | (#29539925)

#2 is better for both, becasue if they are they are good developers the engineer there software, adding new features should be a lot easier.

"We have one program that "tracks changes" by polling every file on the hard drive constantly."

hahaha, excellent. Those developers should be removed from the industry.

There is only one problem with the industry:
You are not required to be a certified engineer to write apps. If that was the case a lot of problems in the industry would go away becasue the developer would be liable, and it would give them power over management when management tries to force q dead line down their throat.

WD-40 (1)

maxume (22995) | more than 4 years ago | (#29539617)

WD-40 is never the right lubricant, and it probably isn't the penetrating oil you are looking for.

Re:WD-40 (1)

ceoyoyo (59147) | more than 4 years ago | (#29539655)

But there is a can of it over there and I need to get this bolt out in the next five minutes.

Re:WD-40 (1)

PvtVoid (1252388) | more than 4 years ago | (#29539683)

WD-40 is never the right lubricant, and it probably isn't the penetrating oil you are looking for.

Word. WD-40 is a water displacer, and a pretty good solvent. You use it for removing lubricant.

Tri-Flow is godlike.

Re:WD-40 (0)

Anonymous Coward | more than 4 years ago | (#29539977)

WD-40 is never the right lubricant, and it probably isn't the penetrating oil you are looking for.

That's true-- in fact, WD-40 isn't really a lubricant; it's a "water displacement" ("WD") agent to free up stuff that's stuck. If you actually want to lubricate, you need an actual lubricant.

(old quote: the only two tools you really need are duct tape and WD-40. If it moves, and it shouldn't, use the duct tape. If it doesn't move, and it should, use the WD-40).

Pay me now or pay me later ... (1)

chazman00 (321337) | more than 4 years ago | (#29539631)

... which is what "Duct-tape programming" amounts to. Sure some solutions can be over engineered. But as you have a number of projects under your belt and see a number of pitfalls, it pays in the long run to avoid some problems upfront. That said, I understand and have worked with programmers who have wanted to add clustering to an application with 15 users. The key is knowing your requirements and your goals.

Re:Pay me now or pay me later ... (1)

Tablizer (95088) | more than 4 years ago | (#29539989)

That said, I understand and have worked with programmers who have wanted to add clustering to an application with 15 users.

I call these "resume programmers". They want to use your shop as their training ground in order to fill up their experience quiver and resume with buzzwords.
     

Litigation (0)

Anonymous Coward | more than 4 years ago | (#29539643)

Your Honor, the Vehicle Control System works over half the time. We are not responsible for this tragedy.

Donald Knuth? Writing programs is easier than ... (0)

Anonymous Coward | more than 4 years ago | (#29539645)

Writing programs is easier than debugging them. So if you write a program in a way that takes all your intelligence, you won't be smart enough to debug it.

"Don't forget to ship your software!" (4, Insightful)

afree87 (102803) | more than 4 years ago | (#29539679)

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!" (1)

D Ninja (825055) | more than 4 years ago | (#29539877)

Interesting observation. I will admit that I like Joel's articles. But, as to your comment, it really has to do with your own perceptions for the most part. I can't find the study, but I did some research on people's perceptions of e-mails that they receive, and one corresponding study showed that people misinterpret the voice of textual information (e-mails, blogs, texting) about 90% of the time. How they perceived the messages appeared to come from things such as their own mood, past experiences with the author of the message, and their own personal view on the world. (I apologize for not being able to find the study.)

So, while Joel may be talking down (he has to consider a relatively wide audience, too), your perceptions might be a reflection more of yourself.

Re:"Don't forget to ship your software!" (4, Insightful)

geekoid (135745) | more than 4 years ago | (#29539929)

Becasue Joel is an ass.

Seriously, he is an ass, and is often wrong.

Balance needed (1)

RogueWarrior65 (678876) | more than 4 years ago | (#29539687)

This concept, like so many others, is a double-edged sword. I personally have seen some brilliant programmers show me some amazing stuff but refused to release it or sell it for nebulous reasons. That having been said, releasing a product that is poorly designed under the hood makes it a nightmare to maintain and can quite easily paint you into a corner. For example, IMHO, nobody should build their own application framework nor should anyone use only what Microsoft or Apple creates. Qt is the right solution because you can concentrate on developing the application and not have to worry about the plumbing. IMHO, this is one major reason why Quickbooks sucks. Intuit should have switched to Qt long ago. The product would have been much better and they'd have the added benefit of true feature parity between the Windows and Mac versions.

even better than the duct tape programmer (5, Funny)

circletimessquare (444983) | more than 4 years ago | (#29539689)

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?

Your post was not a very (0)

Anonymous Coward | more than 4 years ago | (#29540029)

interesting comment.

How do you program duct tape? (1)

Anonymous Coward | more than 4 years ago | (#29539711)

I have to admit, I looked at this headline "the duct tape programmer," and thought, how do you program duct tape?

Different approaches for different problems (2, Insightful)

readin (838620) | more than 4 years ago | (#29539733)

Scenario 1: Your client needs an application that will accept data input for approximately 400 different forms, allow those forms to be validated using some rules that are simple and others that are very complex, and put those forms through a fairly standard work flow.

Scenario 2: Your client needs an application that has 5 different forms used for very different purposes whose data will be processed in very different ways.

In Scenario 1, you had better do some engineering up front to save you from custom coding the parts of those 400 forms that could have been "over-engineered" into templates, base classes, and interfaces.

In Scenario 2, it makes sense to duct-tape.

Re:Different approaches for different problems (2, Insightful)

bjourne (1034822) | more than 4 years ago | (#29540017)

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.

Re:Different approaches for different problems (1)

Ramley (1168049) | more than 4 years ago | (#29540047)

Scenario 1: Your client needs an application that will accept data input for approximately 400 different forms, allow those forms to be validated using some rules that are simple and others that are very complex, and put those forms through a fairly standard work flow. Scenario 2: Your client needs an application that has 5 different forms used for very different purposes whose data will be processed in very different ways. In Scenario 1, you had better do some engineering up front to save you from custom coding the parts of those 400 forms that could have been "over-engineered" into templates, base classes, and interfaces. In Scenario 2, it makes sense to duct-tape.

For me, It makes sense to duct-tape if Scenario 2 is a one-time, non-scaling set of forms. Depending on some circumstances/requirements: if I know that additional forms are going to be required in the future, it makes sense to me to spend a little more time up-front creating a solid framework for easy addition(s)/modifications, thus saving much time in the end.

In Other Words, Agile (1)

tres (151637) | more than 4 years ago | (#29539765)

'Ship early and ship often.'

But it's definitely no silver bullet; it's not for every project, nor every developer, I've been disappointed to see how integration of Agile via scrum derail projects and upended a department where inexperienced / low skilled developers got overwhelmed by the shift in focus from doing it 'perfectly' to shipping. There's a subtle but significant shift in responsibility from the project manager to the developer. Lots of guys don't like it and really can't handle having things so visible; they're used to being able to hide behind the complexity of their work for days or even weeks without really having any accountability. Agile gives them nothing to hide behind.

Shipping is a feature... (1)

Globally Mobile (1635415) | more than 4 years ago | (#29539771)

Shipping is a feature. A really important feature. Your product must have it.

Can't really argue with that at all.

Allow more re-use (1)

readin (838620) | more than 4 years ago | (#29539783)

More engineering would be nice if re-use were allowed.

From what I understand, many government contracts forbid the contractor from taking code written for one contract and applying it to the development of another contract. This apparently can happen even if the customer is the same for both contracts!

Re:Allow more re-use (1)

zippthorne (748122) | more than 4 years ago | (#29540081)

Well, who snuck that into the contract, and which rep allowed it to be added in? If you're working on a project like that, and the reps negotiating the contract don't know that they ought to ditch that clause, you ought to educate them.

And, if you can, spell it out for them in terms of the time savings that could be used to lower the bid and/or increase profits.

Hope he's not working on a pacemaker (1)

bzzfzz (1542813) | more than 4 years ago | (#29539831)

... or aircraft control and navigation, or banking, or encryption, or much of anything besides consumer products where it's OK to fail once in a while. Different situations require different approaches.

Spolski is smart and I usually like what he writes, but it's important to remember that he spent his formative years at Microsoft.

Re:Hope he's not working on a pacemaker (1)

Registered Coward v2 (447531) | more than 4 years ago | (#29539961)

... or aircraft control and navigation, or banking, or encryption, or much of anything besides consumer products where it's OK to fail once in a while. Different situations require different approaches.

I agree, but even in those cases complexity doesn't mean better or more reliable performance. Reliability and predictability is often easier to ensure in a simple solution where there are fewer potential failure modes. Better is truly the enemy of good enough in many cases.

Re:Hope he's not working on a pacemaker (1)

russotto (537200) | more than 4 years ago | (#29540085)

There's only one thing you want LESS than "duct tape" code in a pacemaker. And that's the kind of fancy nonsense Joel's "duct tape programmer" abhors.

Netscape a victim of too much duct tape? (4, Insightful)

ansible (9585) | more than 4 years ago | (#29539857)

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.. (3, Insightful)

amn108 (1231606) | more than 4 years ago | (#29539861)

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.

Not that far off from the old axiom... (1)

SixDimensionalArray (604334) | more than 4 years ago | (#29539865)

In a way, I think Joel might just be restating what I have always found to be a core axiom of software design/development:

"Use the right tool for the job".

I would add the corollary, if one is a master of a tool, the tool has reasonable support, and one can get a job done with that tool, then there is no need for anything else other than that tool for that specific job.

It's when you don't have the right tool in your toolkit that things get more difficult. Knowing when you have the right tool/approach, and when you don't and you need another person, approach, or tool makes all the difference.

I think the idea of saying 50% is good enough is about the fact that you can do a whole lot with just one tool, like using a screwdriver to hammer a nail. It's not the exact right tool for a job, but actually can also get it done too.

IMHO, anyway,

SixD

P.S. Just don't get caught being a tool!

Technical Debt (1)

Herkum01 (592704) | more than 4 years ago | (#29539907)

This issued has been explored before as Technical Debt [c2.com] but most managers and a large number of programmers like to think they are the experts of technical wizardry.

George Patton, IIRC, said something like: (1)

Registered Coward v2 (447531) | more than 4 years ago | (#29539913)

A poor plan vigorously executed is better than a perfect one never executed.

To me, the real value is to know what you can cutout with negatively impacting the customer experiences. far too often people build cost and delays into projects by building in cool when cool is of no value to the customer.

Not a new idea, and valid today academic exercises are best left to academics where they can't hurt anyone.

Duct tape is fine, if you throw it away quickly (5, Insightful)

Alkonaut (604183) | more than 4 years ago | (#29539941)

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.

FINALLY! ENLIGHTENMENT! (1)

oo_HAWK_oo (1619801) | more than 4 years ago | (#29539955)

I have been making this point for years only to be told I was an idiot. Look. Just because you can cram data into XML files, doesn't mean you should! Why use a database when a flat file makes more sense? I don't believe his promoting bad programming habits, I think he is trying to say, don't over complicate the simple things in life. I don't need a freaking API written when I can just query the damn database myself! KISS = Keep It Simple Stupid!!

Isn't this Microsoft? (0)

Anonymous Coward | more than 4 years ago | (#29539981)

Surely they aren't release-early-release-often, but they release their products with massive numbers of features which "just work" enough that people can get some productivity out of them and keep using them until something else comes along.

"Real artists ship" ... Yeah, and so do mega-corporations with crappy uber-apps. Can we please not follow the YC path and please stop posting blog entries that are 3 paragraphs long, expelling the virtues and personal opinions of an egomaniac?

Except.... (0)

Anonymous Coward | more than 4 years ago | (#29539993)

"a 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it's in your lab"

1) Solves more problems, but creates as many as it solves

2) Survives longer because you're too busy putting out the fires caused by #1 to re-architect (and busy holding awards ceremonies for the idiots who "fixed" the avoidable problems they caused in the first place)

Lotus Notes (1)

metamatic (202216) | more than 4 years ago | (#29540003)

This is what a lot of people fail to understand about Lotus Notes. It's not supposed to be beautiful and elegant and petite; it's a humongous roll of duct tape. It's ugly, but it gets the job done, and can often get you from nothing to "50%-good solution" in an afternoon.

[Opinions mine, not IBM's.]

Joel Spolsky, meet TheDailyWTF (5, Insightful)

diamondsw (685967) | more than 4 years ago | (#29540033)

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.

Steve Jobs???????? (1)

beelsebob (529313) | more than 4 years ago | (#29540049)

The comparison to Steve Jobs is... weird.

Steve Jobs is *famous* for holding products back because they're not polished enough. He's famous for wanting products that do not very much, but what they do, they do right. He's famous for not shipping half assed solutions.

Rather the opposite of what the summary suggests.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...