Duct Tape Programmer

It's a fun and feel-good article. The problem is that 90% of the people who read that article, sit back and grin, and say "yup, that's me", also need to read this article. That 90% includes everyone who reads that second article, sits back and grins, and says "yup, that's everyone else".

Quote:

Original post by Kingerthethird Found this article while reading Job Listings. Felt like Sharing. http://www.joelonsoftware.com/items/2009/09/23.html

I don't know. There's also the opposite of over-engineering, and that's being totally oblivious to newer technologies, to the point of becoming obsolete and detached from reality. Both extremes are bad.

Over engineering certainly is a big problem. Then again, are people who claim that all OOP is the spawn of Satan and everything should be done in pure C any better ?

Quote:

Original post by Yann L Quote: Original post by Kingerthethird Found this article while reading Job Listings. Felt like Sharing. http://www.joelonsoftware.com/items/2009/09/23.html I don't know. There's also the opposite of over-engineering, and that's being totally oblivious to newer technologies, to the point of becoming obsolete and detached from reality. Both extremes are bad. Over engineering certainly is a big problem. Then again, are people who claim that all OOP is the spawn of Satan and everything should be done in pure C any better ?

I agree, it's a fine balance probably. During my job I learned to make more modest code so developers (including me) can read it and it just ships even if it's not brilliant and has some bugs. On the other hand, I also have experienced just pounding on rotten code to get something done will haunt you after a release with costly bugfixing and maintenance. Not writing a single unittest does result in meeting that first deadline, but what happens after that is also important...

Yeah, I could see this being both a good thing and a bad thing. As the saying goes 'busy people get stuff done because they are busy'. I've seen thing from both sides in the same project - ancient, crusty, hacked together VB code that had been ported to .Net, and overly-complex, uber-designed server side code. Both aren't fun to work with. Rather than doing a hackjob or an uber-engineered job, I'd rather just make it work and make it nice.

Do it. Do it right. Do it right now.

Get those three down, and you won't have any problems.

Duct tape programmers are the reason why some software ends up on The Daily WTF. Sure your go-cart can fly, but...oops...the breaks don't work for people between 178 and 201 pounds.

Quote:

Original post by Sneftel also need to read this article.

"You might be wrong about everything" is generally a good rule to live by.

Joel is beating up strawmen and arguing for nothing in particular. The only intelligible point of the article was made long ago as You Aren't Gonna Need It and Do The Simplest Thing That Could Possibly Work. They're not unqualified rules to be used in ignorance and isolation of everything else, though.

I was reading the thing, nodding in agreement, until I hit this gem:

Quote:

You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work.

Templates? Seriously? Templates are too hard to understand? They make things over-complicated? If anything, they make things much simpler, saving a lot of copypasta that's only a hassle to work with as project size grows...

Quote:

Original post by Koobazaur Templates? Seriously? Templates are too hard to understand? They make things over-complicated? If anything, they make things much simpler, saving a lot of copypasta that's only a hassle to work with as project size grows...

A template is a tool, like any other language feature or construct. They can indeed be very useful, but they can also be horribly abused. I've seen monstrosities of recursive template magic in production code, that even the creator himself could not decipher anymore after two weeks.

The same goes for multithreading. It's an incredibly useful feature. But nothing is worse than people using MT in production code without actually understanding it, while introducing bugs that are almost impossible to trace (especially if you have a shipping deadline).

I disagree with Joel over that one should entirely avoid these things. They are a vital part of modern software engineering. However, abuse of such features, especially by individuals that aren't competent in using them effectively, is just as bad.

Quote:

Original post by Koobazaur Templates? Seriously? Templates are too hard to understand?

This comment is a sure way to tell that you don't have a lot of experience with what can be done by using templates. Go and look at the source of Boost Spirit. You will not be the same person anymore...

(Not that I don't like Boost Spirit [grin])

[Edited by - Yann L on October 2, 2009 9:48:49 PM]

Quote:

The problem is that 90% of the people who read that article, sit back and grin, and say "yup, that's me", also need to read this article. That 90% includes everyone who reads that second article, sits back and grins, and says "yup, that's everyone else".

After reading both of these articles, I'm not sure I identify with either. I mean, the idea of a duct-tape programmer kinda scares me. I don't want to work with hacked C code or an engineer who habitually does it, that can be harder to read (and make work) than any templated nightmare. As Programmer One puts it:

Quote:

Duct tape programmers are the reason why some software ends up on The Daily WTF. Sure your go-cart can fly, but...oops...the breaks don't work for people between 178 and 201 pounds.

Not that I don't like or use templates, quite the contrary. But yea, you'll see some wild things with templates. I'm getting increasingly familiar with the boost libraries. It is a powerful library, but sometimes a given aspect of the library (many in fact) can be quite a bit to chew on.

Quote:

Go and look at the source of Boost Spirit. You will not be the same person anymore...

I think spirit is a parser of some kind, right? I haven't used it yet, but if its anything like complex lambda expressions I totally believe you.

As far as overconfidence is concerned, I'm probably quite the opposite. Uncertainty is a persistent foe of mine. I know I've over analysed in the past (did it alot in college) and I'm sure I'm not alone here, but I do like to get my line of thinking straight. I would argue that a big part of the engineers job is R & D. Is it a pain in the ass, absolutely. I can't speak for everybody, but I'd rather hit a wall on paper than in code. That's why I got into the habit of re-factoring. I give myself x amount of time to generate a solution before I make myself just go through it. At least there is some fore-thought, and I at least have some background to go off of as a plug along. And if I don't like how it turned out, I chew on it some more and spit out part 2.

At work I'm more of a duct tape programmer in the sense that the most important thing is to progress towards completion, and not overcomplicate things, especially if there are several people on the same project.

At home, when working solo on a hobby game, I tend to use the more advanced elements of the programming language, and design patterns and all that fancy stuff just for fun.

@AndreTheGiant:
And in the end it makes you a better programmer, I'd say... just because at work you can then tell what nifty design trick is worth pursuing and what just got you four additional files to compile and one another layer of indirection to the same code.

Personally I'm a huge fan of refactoring. Honestly... when I'm approaching a new problem, I mostly have the feeling that I *don't* know enough to actually write code. But at the same point I'm aware that I will loose myself in endless meandering paths of consideration if I try to think through everything. I simply don't have a gut feeling about the topic, and writing code is about the only way for me to get this. Call it intuition or condensed experience or whatever - it's the thing that guides me through miles of code to fix that certain bug or implement that certain feature. And it's a rough time when I know I'm coding without it.

Refactoring comes to the rescue for that otherwise blocking problem: I simply start coding, and I usually get something working out of it. And after that I have an feel of how the problem actually works. In an ideal world that's the point where refactoring starts and leads to better code.

On a slight tangent, I have to second Joel Spolsky's recommendation of Coders at Work. I'm reading it right now, and while it probably won't change my world, it is a very pleasant and interesting read. It's quite interesting to see where most of the interviewed coders tend to agree and where they sometimes disagree.

The way I look at it, at work I'm paid to get the job done to the best of my abilities.

If thats via working on a large design, or throwing code together quickly depends on the situation at hand, perceived problems and allowed time.

Granted, its easy to get it wrong; we had a milesone at work where we had a delivery and an 'over delivery' plan. I focused too much on the over delivery (which, it became apprently half way into week 2, was impossible within the given time frame something I feel I should have spotted earlier) so there was a slight scramble while I rearranged my thoughts to refocus (and get the deliverable done).

End of the day, I feel to be the 'complete programmer package' you need to be able to take both paths as required, if you always pick one over the other then you probably want to consider looking at a change of process.

I am calling bullshit on this article.

"Just ship it" is an admirable goal and Joel has taken a potentially valid point and an interesting story (Jamie Zawinski's) and basically butchered it.

What especially makes me call "bullshit" is that mid way through he harps on about how "C++, templates, multiple inheritance, multithreading, COM, CORBA" are "hard" and that these so called "Duct Tape" programmers are so laudable for choosing not to use them.

AND THEN he goes on to say that a "Duct Tape" programmer should be forgiven for shit like "xoring the "next" and "prev" pointers of their linked list into a single DWORD to save 32 bits". Huh? That is suddenly easier than using C++ and templates??

Now I haven't read the interview with Zawinski - but I'd like to see what he has to say, uncoloured by Joel's over-inflated ego.

Joel on Software hasn't been good since Fog Creek started becoming successful.

The post does not to me strike a chord with the following quote by einstein:

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

i agree with parts of that article, and other parts I vehemently disagree with.

I think a "just ship it" attitude is acceptable, even preferred, but only as long as one has an architecture in place to handle the blow-back from that kind of development. You need to have a strong test-driven development cycle, actually take the time to refactor unmaintainable code, and actually collect meaningful profiling/performance data from the application in live production environment. Then, and only then, is "Duct-tape" programming a good idea for any project that is meaningful in size. Given that kind of environment, the team can effectively decide which parts to engineer or optimize, while making sure that functionality remains in-tact.

If you've got a little utility that you are only going to use in-house and only use once or twice, then yeah, you don't need to spend a month engineering it. Just make it work, I don't care how you do it.

But if everyone on the team is always running in "just ship it" mode, then it'll be a blast for the first fraction of the development cycle, and then once the code-base achieves any degree of complexity, you are going to hate your life and heinous unmaintainable spaghetti code that you have managed to produce.

Oh, and the most amusing part:

Quote:

Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.” Remember, before you freak out, that Zawinski was at Netscape when they were changing the world.

Uh huh. Who here remembers those halcyon days of Netscape Navigator? I do. And it was a crashy, buggy mess. It was tolerable because it was still better than anything else, but if subjected to modern security analysis, it would probably be riddled with exploits.

Quote:

They thought that they only had a few months before someone else came along and ate their lunch. A lot of important code is like that.

Really? Really? It seems to me that truly critical code (ie, security patches) should absolutely never break anything. So a "Just Ship It", no unit tests attitude is a recipe for disaster. Unit tests are there for (among other purposes) saving you from testing every little regression manually.

I can think of very few circumstances where shipping a buggy product on time beats shipping a good product somewhat later. It certainly isn't true for games. And the far superior model in those circumstances is (to borrow from XP yet again) frequent small releases. To release quickly, you sacrifice features (which are continually added in small increments), not code quality.

I generally like Joel's technical articles (when he bothers to do them anymore), but this one misses the mark by quite a bit. He's basically argueing for cowbody coding. In particular I have a problem with this:

Quote:

Zawinski didn't do many unit tests. They "sound great in principle. Given a leisurely development pace, that's certainly the way to go. But when you're looking at, 'We've got to go from zero to done in six weeks,' well, I can't do that unless I cut something out. And what I'm going to cut out is the stuff that's not absolutely critical. And unit tests are not critical. If there's no unit test the customer isn't going to complain about that."

The problem is that all this is this is just true enough, as far as it goes, to sucker the inexperienced and/or pointy-haired-boss types trying to cut corners. If all you want to do is to get from nothing to v1 and pull a fade then by all means go ahead.

Where you will get kicked in the ass is when the bugs start pouring in for v1. Or when you try to get from v1 to v2. Or when you're most of the way done with v1 and then the customer comes along and says that no, you need to do things this way instead of that way.

Quote:

Original post by Andrew Russell Joel on Software hasn't been good since Fog Creek started becoming successful.

You don't suppose he's out trying to deliberately sabotage the competition? This suddenly makes things make a lot more sense.