The Duct Tape Programmer

True that by gestalt_n_pepper · 2009-09-25 02:44 · 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.

--
Please do not read this sig. Thank you.

Re:True that by Chrisq · 2009-09-25 02:50 · Score: 5, Insightful

Agile, scrum, patterns, unit tests, etc. . Interesting ideas, but can anybody show me *any* significant, quantitative, comparative proof of improved ROI? . Software is about money guys.
From experience yes to unit tests. The number of times regressions have been picked up by a test bank before deployment to the UAT (user acceptance testing) system it pays for itself many times over. Patterns save time when an experienced group discusses design, but with developer turnover I get the feeling I have spent at least as much time explaining patterns to new developers as I have saved.
Re:True that by geekoid · 2009-09-25 03:07 · 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.

--
The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Re:True that by oldspewey · 2009-09-25 03:10 · 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

--
If libertarians are so opposed to effective government, why don't they all move to Somalia?
Re:True that by bcmm · 2009-09-25 03:13 · Score: 5, Insightful

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.

--
# cat /dev/mem | strings | grep -i llama
Damn, my RAM is full of llamas.
Re:True that by h4rm0ny · 2009-09-25 03:21 · 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.

--

Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
Re:True that by ChienAndalu · 2009-09-25 03:26 · 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 by NewbieProgrammerMan · 2009-09-25 03:31 · 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.

--
[b.belong('us') for b in bases if b.owner() == 'you']
Re:True that by EastCoastSurfer · 2009-09-25 03:48 · 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 by Chris+Burke · 2009-09-25 06:14 · 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.

--

The enemies of Democracy are

Bad Mischaracterization by smack.addict · 2009-09-25 02:45 · 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.

Oh no. Now all the numties have an excuse! by freddled · 2009-09-25 02:48 · Score: 5, Insightful

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 by ciggieposeur · 2009-09-25 02:50 · Score: 5, Interesting

I'm plagiarizing a point I saw on Reddit and I'm too lazy to find the original article, but I agree with the author of it: there doesn't have to be a choice between "crappy duct tape" programming and "crappy over-architected" programming. A decent programmer can get both: a small program that does its job well, AND can be extended in unplanned-for ways for new functionality.

even better than the duct tape programmer by circletimessquare · 2009-09-25 02:58 · Score: 5, Funny

is the duct tape manager

trying to hop in his chair to the phone, arms bound to the armrests with duct tape, screaming MMMMPH MMMMPH through the glorious dull shiny grey of...

what were we talking about?

--
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it

Re:True that - NOT by garyisabusyguy · 2009-09-25 03:14 · 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.

--
Wherever You Go, There You Are

Duct tape is fine, if you throw it away quickly by Alkonaut · 2009-09-25 03:18 · 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 by JohnWiney · 2009-09-25 03:19 · Score: 5, Insightful

is Release 2.

Joel Spolsky, meet TheDailyWTF by diamondsw · 2009-09-25 03:24 · 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.

--
I don't know what kind of crack I was on, but I suspect it was decaf.

Architecture astronauts by Aceticon · 2009-09-25 03:32 · Score: 5, Interesting

I don't think this guy ever worked with any software engineer with any significant amount of experience. Or maybe he just works with people that suck as software engineer.

The typical evolution towards wisdom in Software Engineering goes like this (simplified):

Starting by making small programs or programs supposed to be used only once (i.e. school assignments)
Transition 1: Discovery of code reusability, the problems with copy & paste coding and how using methods lets you partition your code into more easy to understand blocks - this is when one transitions beyond junior developer
Transition 2: Discovery of the concept of software design and how it makes for more adaptable code which is easier to understand and how it helps main complexity small as the size of the program increases - this is when one transitions into junior designer
Transition 3: Discover that there is such thing as too much design. That over-designing decreases maintenability, makes the code harder to understand by others and by oneself in the future. That the flexibility that the real world will require from the code will rarely match one's initial idea of what should be made flexible during design and that trying to create a top-to-bottom design that covers all eventualities actually results in an inflexible system. Above all, discovery of the value of the KISS approach: don't design/implement a specific something now because you think you will need it later, it is often easier to do it then if you do actually need it and you probably won't need it and are just making for big code instead of useful code. At the same time discover that newer isn't always better when it comes to software tools, languages and frameworks and that coolness and hype are really bad things to focus in when choosing something to use in an professional IT project - this is how you get medior designers and senior developers
Transition 4: Discover that creating software is actually a process not an act. That a lot of things serve as feed-ins to the actual design and development of software and a lot of things feed out from it. That software isn't just made, it lives, evolves and gets changed. That making an application is easy (no mater how big and complex) and making the right application which does what's need in the right way for the users of the application is what's hard. That the quality of your feed-ins (requirements, analysis, time, people and all manner of preparations) is much more relevant to the success of a project than the code or the design. That over the long run, the true quality of the code and design is measured by how easy it is to regression test, maintain, support, extend and by how fast new designers/developers can pick up the code (which are some of the feed outs) - this is how you get senior designers and technical analysts.
Transition 5: Discover that the applications your develop are part of an ecosystem. That software talks to software that talks to software. That many applications need to do many of the same things, only in slightly different ways. That standardizing (up to a level) things like certain kinds of exchange of information between applications or the kind of libraries used for certain common functional areas (such as multi-system logging, single-sign-on, messaging) will make for increased overall productivity and maintenability (develop and maintain a single implementation for each and distribute it as a library). Discover that standardizing on a reduced number of mature programming languages makes it easier to find people to work with them and move people around to different projects and systems - this is how you get technical architects

At best what the guy in the article is calling "duct-tape programmer" is somebody past the 3rd transition only and what he calls and "astronaut architect" is somebody past the 2nd transition only.

I would hardly call a junior designer type "architect".

Ruel of Thumb by cmiller173 · 2009-09-25 03:34 · Score: 5, Insightful

Always write code as if the guy who has to maintain it is a sociopath who knows where you live.

Re:Ruel of Thumb by gestalt_n_pepper · 2009-09-25 04:19 · Score: 5, Funny

Well yes, but it's me and it's usually my own code. Perhaps this explains why I keep meeting myself in the halls.

--
Please do not read this sig. Thank you.

Re:"Don't forget to ship your software!" by Taevin · 2009-09-25 03:42 · Score: 5, Insightful

In this case, I'm left wondering what the fuck just happened? like when someone from marketing comes by my desk with a slurry of buzzwords and technical jargon they don't understand, but it's sure to make my code rock solid. Seriously, I usually like his articles, but what the fuck is he on about?

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.

C++ is too hard? I admit it's no longer my first choice of language, but seriously? How much software (enterprise-class, even) is written and continues to be written in C++? I'd wager quite a bit.
Templates are too hard? I sincerely hope he's referring to jackasses that try to write an entire program solely out of templates and not the code reuse and simplification they offer. If he's actually supporting the kind of jackass that copy-pastes everything so there are a dozen different copies of a file with 1 change each (previously, I've referred to this kind of programmer as a Duct Tape Programmer in my head)... then fuck you, Joel, that guy is in the cubicle next to mine and I'm the one that has to fix his shit!
Multithreading is too hard? When you first heard about it, maybe. Yes it requires a bit of a mental shift from blowing through your whole process in one god-awful, huge, slow loop but asynchronous processes are not rocket science.

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:So, does the Duct Tape Programmer... by VisceralLogic · 2009-09-25 04:59 · Score: 5, Funny

Build a Man a Fire, and He'll Be Warm for a Day, Teach a mean to build his own fire and ruin a perfectly good business opportunity.

Set a man on fire, and he'll be warm for the rest of his life!

--
Stop! Dremel time!

Re:So, does the Duct Tape Programmer... by urbanRealist · 2009-09-25 05:03 · Score: 5, Insightful

FTA:

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.

--
I've seen a lot of things, but I've never been a witness.

Re:So, does the Duct Tape Programmer... by computational+super · 2009-09-25 05:14 · Score: 5, Insightful

the Duct Tape Programmer writes the worst kind of spaghetti code in the world.

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.

--
Proud neuron in the Slashdot hivemind since 2002.

Re:So, does the Duct Tape Programmer... by ultranova · 2009-09-25 07:24 · Score: 5, Insightful

The difference is, the app is up and running, ready to ship with the duck-typed languages,

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.

--

Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

26 of 551 comments (clear)