Joel On Software geek

[jzoller]

I admit it: I like Joel On Software.

Besides, this article describes a goodly number of the best programmers I've met.

Joe Z.

[Daklu]

I usually like him too, but I didn't like that article. The only worthwhile message, "don't forget to ship your product," is buried under an avalanche of contempt for anyone who tries to methodically improve their software. Then he pulls the "mediocre programmer" card out of his back pocket, neatly preventing contrary opinions. Coercive journalism at its finest.

I guess we should all aspire to be duct tape programmers and just wing it a little more... whether we're building a go cart or a Formula 1 racing car.

(I did find it rather funny that he held up a Netscape programmer as an example of programming excellence. Maybe Netscape failed because it was over-engineered. On the other hand, maybe it failed because there were too many duct tape programmers flying by the seat of their pants.)

[Dirk J.]

I guess we should all aspire to be duct tape programmers

Not in LabVIEW.

I think LV's shallow learning curve prevents 'beginners' to think about design patterns.

An extreme LV duct tape programmer is someone using a lot of local and global variables, 10+ frame stacked sequences, discards a main-program-while-loop as too complicated because there is a 'run continuously' button; uses only Express VI's (the baby-blue color spells: beginner ) and thinks the combination of a state machine with an event structure is overdoing it, because why would you respond to a Stop-ValueChange with Stop-case in the next iteration of the allready redundant MainProgramWhileLoop ........?

The result is the code that we all see from time to time, loaded with globals and locals, cases polling a single boolean, etc etc.

It doesn't help that LV still ships with examples that use a polling architecture.

It's sure important that Average Joe can wire something up in 10 minutes, but if he has been wiring for two weeks that way, he starts to complain that LV is much slower and sluggish then say C++ or whatever language he's heard of from his non-duct-tape colleages.

I know it doesn't compare exactly to Joel's COM-multiple-inheritence-multi-threading rant, but still. Duct tape programming in LV is disadvantagous in the long run.

/dirk

Edited September 26, 2009 by Dirk J.

[PaulG.]

I usually like him too, but I didn't like that article ...

I liked it ... I think. But I completely understand your criticism.

I do see his point "you’re not here to write code; you’re here to ship products.”

I think too many developers think it's the company's obligation to pay them to write "elegant" and sophisticated code when the company needs you to write robust and functional code and get it out the door, or in my case, out on the floor to test shipping products. I think his point is that too many developers try to make things complicated (for job security? bragging rights?) that you eventually have something so complicated that unforeseen bugs creep into the code weeks or months down the road. I've inherited such projects, and probably wrote one or two myself.

IMO, if you want to methodically improve your coding skills you need to do that on your own time - not on the company's dime. Don't get me wrong. I learn something new every day on the job, but if I wanted to tackle a project using something totally new like OO or scripting techniques I would do that on my own time. And I would only put it into a work project when I was absolutely sure I knew what I was doing.

My $0.02

[Dan DeFriese]

To be honest, I'm not sure I read the same article...

I don't believe the duct tape metaphor was intended to condone a McGivor menality of thowing whatever you have available as fast as possible to ship the product. I came away with the idea that the praised programmer is generally unimpressed with the faddish super-douper-extra-dynamic techniques he doesn't understand. He sticks with techniques which he considers simple and reliable, like duct tape.

Edit: Hew, looks like PaulG read the same article.

Edited September 26, 2009 by Dan DeFriese

[Michael Aivaliotis]

As far as learning on the job. I disagree with learning on your own time. Your employer should pay for your training time. Even if that means letting you go off for a week to experiment with LVOOP on your own or by chatting on LAVA. Some employers don't allow that, this is why we see many people trying out new techniques on new projects. I've been in that situation. I had an employer you drained the life out of me to the point where my only reward for hard work was the knowledge I gained by experimenting with new LabVIEW features (used on projects of course). Yes, it was risky being on the bleeding edge sometimes, but I took calculated risks and I was the one who had to fix things when it went bad. And I always did.

Side-step rant:

As an old timer, I can tell you that back when I was programming in LabVIEW 3.11, we still got systems out the door and there were many alliance member companies that were building systems exclusively using LabVIEW and making successful businesses out of it. We didn't have event structures, we didn't have DAQmx, we didn't have LVOOP, heck we didn't even have multithreading. We just kept building systems with LabVIEW because no one told us we couldn't. I chuckle to myself when I read posts on the forum about how now LabVIEW is a real language people can finally use because it has by-ref objects or some other feature A or B. Some of the techniques you learn when you have little to work with, you take with you throughout your career.

[ShaunR]

I'm a bit ambivelent about this article. I thought a "duct-tape programmer" was basically an un methodical script kiddy type. But he describes any programmer that applies KISS. After all if you have 2 weeks to write some code that puts a "widget" in a "doodah", why spend 2 weeks writing code to interface to other code (that you have still to write) that puts a "widget" in a "doodah". That seems to be the gist of the article rather than lauding seat-of-yer pants programming.

From experience. there are (simplistcly) 4 phases to software projects. Design, Implemention, Fire-fighting and Delivery. KISS programmers do a lot less of the fire-fighting because they have less to go wrong.

[jzoller]

I think his point is that too many developers try to make things complicated (for job security? bragging rights?) that you eventually have something so complicated that unforeseen bugs creep into the code weeks or months down the road.

It's worse than that: they do it to "make it better", or "more generic", or "more elegant". The best of reasons, but soon you end up with an overdue Observer-Decorator-Factory-Factory architecture and 6 levels of abstraction, when a polling loop would have worked just fine.

LV developers tend to be somewhat more prone to duct tape than, say, Java developers. I suspect it's because so many LV users are engineers and scientists of other disciplines, where code is not the goal.

Joe Z.

(I did find it rather funny that he held up a Netscape programmer as an example of programming excellence. Maybe Netscape failed because it was over-engineered. On the other hand, maybe it failed because there were too many duct tape programmers flying by the seat of their pants.)

Netscape's failure is fascinating, and pretty well documented.

Among other things, they decided to re-write their browser from scratch, "the right way". It ended up more than a year late, during which time Microsoft took the entire market.

Maybe they needed more duct tape

Joe Z.

[Daklu]

It's worse than that: they do it to "make it better", or "more generic", or "more elegant". The best of reasons, but soon you end up with an overdue Observer-Decorator-Factory-Factory architecture and 6 levels of abstraction, when a polling loop would have worked just fine.

I agree with you on this point. Adding unnecessary complexity is bad, and there certainly are software theorists in every company who tend to do this. (I suspect it's an unconcious attempt to keep their work interesting rather than intentional obfuscation for job security.) But there are times when complexity is both necessary and helpful and I felt like Joel completely dismissed those cases. Duct tape on a go cart is fine. Duct tape on the wing of a 747 isn't. Ultimately the software should be as complex as it needs to be, no more and no less.

Two examples in particular really kind of bothered me:

"They were being extremely academic about their project. They were trying to approach it from the DOM/DTD side of things. ‘Oh, well, what we need to do is add another abstraction layer here, and have a delegate for this delegate for this delegate. And eventually a character will show up on the screen.’"

The article presents this as an example of the kind of overengineering duct tape programmers despise. What the article doesn't mention is that in the overall architecture of the application that may have been the best way to do it. The duct tape programmer, working in his little section of code, wants to make a call directly to Widget D and sees calling Widget A, which delegates to Widget B, which delegates to Widget C, which in turn calls Widget D, as a complete waste of time. He's probably right if the software is going to be released and never touched again. For software such as Netscape that is going to be maintained and built upon for quite some time, you're generally better off (IMO) taking the extra time up front to do it right. Every shortcut or hack you implement couples your code modules together that much more. After a while you end up with a big ball of mud that is impossible to understand or modify and you're left with needing to do a rewrite.

"...and you’re going to get paged at night to come in and try to figure it out because he’ll be at some goddamn “Design Patterns” meetup."

Yeah, this bothered me because it hit too close to home. I've been studying design patterns lately and I've found them extremely helpful. With this one sentence Joel dismisses design patterns and, by extension, the whole concept of architectural reuse. Maybe he likes reinventing the wheel all the time... I'd rather learn from what others have done.

LV developers tend to be somewhat more prone to duct tape than, say, Java developers. I suspect it's because so many LV users are engineers and scientists of other disciplines, where code is not the goal.

I agree with the conclusion, but not the reason. I believe it is because a) LV users typically do not have any software engineering experience and thus don't know of any other way to program, and b) most users aren't asked to build complex systems where design patterns and architectural considerations come into play.

Among other things, they decided to re-write their browser from scratch, "the right way". It ended up more than a year late, during which time Microsoft took the entire market.

I've only read a bit on the demise of Netscape. Why did they make that decision?

I disagree with learning on your own time. Your employer should pay for your training time.

I think it depends entirely on the specific situation. At one end of the spectrum, full-time employees definitely should be given training at company expense if the company is asking them to take on challenges they have not encountered. At the other end, I don't want to pay a consultant to spend two weeks learning LOOP. I expect him to already be an expert on the subject. Contract positions can fall anywhere between the two extremes, with short term contracts leaning towards the consultant side and long term or open ended contracts leaning towards the full time employee side.

[Dan DeFriese]

Duct tape on the wing of a 747 isn't.

Unfortunately, not everyone feels this way.

[crelf]

Unfortunately, not everyone feels this way.

Ha! Hopefully that's not duct tape - it's speed tape (sometimes known as 600mph tape).

[Cat]

Netscape's failure is fascinating, and pretty well documented.

Among other things, they decided to re-write their browser from scratch, "the right way". It ended up more than a year late, during which time Microsoft took the entire market.

I was a devoted Netscape user until they did their browser "the right way". Then I gritted my teeth and switched to IE. And it had nothing to do with waiting for the new version. It was soley because to Netscape, "right way" = "bloat ware". They tried to become every thing to everybody and along the way lost their most important product -- a really decent web browser. So they lost me as a customer.

There's a lesson in there somewhere for software designers...

[John Lokanis]

I used to respect Joel, but if there was a way to comment on that article, I would simply tell him:

'you are an idiot'.

The line that really got me was: "If there’s no unit test the customer isn’t going to complain about that.”".

Sure, that is what Microsoft has been thinking and doing all along. The world is their beta (and often alpha) tester! Who cares if it is good, as long as it ships.

Well, I have spend MANY hours of mine and my employer's time dealing with the bugs that these 'duct tape' programmers leave in the code because they are too lazy or stupid to come up with a decent set of requirements, design and test plan and then take the time to actually implement it!

Wiz-bang features for the sake of elegance may be a waste of time, but careful planning, execution and testing of ANY code is CRITICAL. I don't care if it is going in a 747, a desktop OS or an mp3 player. Just because it ships doesn't mean it is good.

/rant

-John

[John Lokanis]

Here is another good discussion of that article:

http://blog.objectmentor.com/articles/2009/09/24/the-duct-tape-programmer

My favorite comment about Joel was: "never take software advice from a bug tracking system salesman".

[Michael Aivaliotis]

The line that really got me was: "If there’s no unit test the customer isn’t going to complain about that.”".

Ya, I don't like that. Even if you duct tape, you should still test.

[jzoller]

Sure, that is what Microsoft has been thinking and doing all along. The world is their beta (and often alpha) tester! Who cares if it is good, as long as it ships.

Not sure how Microsoft got into this... they probably employ more testers than any other company on earth. For a high level description of their process, check out this pdf from MS research. It has some nice numbers on the impact of TDD, as well.

Joe Z.

[Black Pearl]

My favorite comment about Joel was: "never take software advice from a bug tracking system salesman".

BDD - Bug Driven Developement

Felix

[Daklu]

These are the comments that summarize my thoughts:

“duct tape programmers – sacrificing tomorrow’s productivity, today!”

"Duct tape is a patch, not structure. You can’t build a house out of duct tape, but you can patch a hole until you have time to do the right thing."

[Daklu]

The author of Coders at Work commented on Joel's blog here.