Skip to content

Rough Book

random musings

Menu
  • About Me
  • Contact
  • Projects
    • bAdkOde
    • CherryBlossom
    • FXCalendar
    • Sulekha
Menu

Duct-tape programmers are not heroes

Posted on September 25, 2009September 26, 2009 by vivin

Today, I ran into this article from Joel on Software. Usually, I listen to what software professionals have to say regarding software development and software-development processes in general, and I mostly agree with them. However, I found myself vehemently disagreeing with this article.

In this article, Joel talks about the "Duct-tape programmer". His definition of such a programmer is as follows:

He is the kind of programmer who is hard at work building the future, and making useful things so that people can do stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute. This will happen while other programmers are still at the starting line arguing over whether to use titanium or some kind of space-age composite material that Boeing is using in the 787 Dreamliner.

In other words, he's the kind of guy who's able to get software to ship in time by just making sure that everything works. The end result may not be pretty, but it will work. Joel argues that these kinds of programmers are not only necessary, but that they are heroes. I have to disagree. I think duct-tape programmers are a symptom of a larger problem. In some environments we're forced to become duct-tape programmers to get the product to ship. But I can tell you that it's not something that I'm happy about. I have definitely cut corners a few times in order to meet a deadline, and I have almost always come to regret it. I don't disagree with Joel when he says that duct-tape programmers are necessary in an environment of "overarchitecting". In that environment, they can cut through all the fluff and deliver an product that works, and that can be shipped. But the emergence of the duct-tape programmer because of something else, namely, overarchitecting. Another environment where you can see duct-tape programmers is a software-shop that prioritizes features and deadlines over everything else (which is not a good approach in of itself). Here a duct-tape programmer can be relied on to complete all features and ensure that the product can be shipped. So, yes, this seems like a great thing. But I don't think Joel looks past this. The problem with duct-tape and WD-40 is that it is a temporary solution at best; inelegant and non-scalable. Code written by a duct-tape programmer might as well have "HACK" and "TODO" comments everywhere, because that's what it takes to get the job done!

I also found some of the points he made (to justify the need for duct-tape programmers) in his article to be quite perplexing. First he says:

Here is why I like duct tape programmers. Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use multi-threaded COM apartments, your app will be 34% sparklier, and it’s not even that hard, because he’s written a bunch of templates, and all you have to do is multiply-inherit from 17 of his templates, each taking an average of 4 arguments, and you barely even have to write the body of the function. It’s just a gigantic list of multiple-inheritance from different classes and hey, presto, multi-apartment threaded COM. And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever classes constructed entirely from multiple inheritance from templates, without a single implementation body at all, and it’s going to crash like crazy 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.

Then later on, he says:

One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. 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 agree with him on the first point (but for different reasons). It's stupid to focus on an unwieldy, overly-abstract, and overly-generalized design when there can be a quicker solution to a problem. But that doesn't mean we need to turn into duct-tape programmers and turn out quick n' dirty code. What we need to do is come up with a better design! The fact that we need need to turn into a duct-tape programmer is because of a larger problem: bad design. Too much architecture is just as bad as no architecture. His second point is something I cannot agree with or understand. Yes, these technologies are a little difficult and yes, they do have a learning curve. No one is denying that. By the same token, calculus is difficult as well. But that's no reason to stop using it. If a programmer in general avoids using templates, inheritance, or multithreading then I'd say that they're a terrible programmer. Honestly, any kind of technology is slightly complicated. If you remove all the technology, what is there to use? Your code is probably going to redundant, duplicated, and would generally reek of bad (or no) design. Part of being a good developer is knowing when to use the right technology or approach. If the solution demands multithreading, then use it. If it demands interfaces or some other technology, then use it. As with anything, technology can be abused and it's definitely possible to use un-necessary or completely wrong technologies for a solution. Once again that's a symptom of a larger problem. In this case, it's lack of experience or education (as far as the programmer in question is concerned).

What's even more confusing is that Joel seems to paint the duct-tape programmer to be some sort of hero. I simply cannot understand how he ends up at that conclusion. For example:

Peter asked Zawinski, “Overengineering seems to be a pet peeve of yours.”

“Yeah,” he says, “At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

My hero.

Really? Zawinski was involved with Netscape and to put the above quote in context, he's talking about the development of Netscape. Well, a point to consider is that the communicator code was scrapped when development for Netscape 6 began. Sure it shipped on time, but was the code actually maintainable? Was it scalable? Was it easy to add features and refactor without perpetuating existing technical debt, or adding in new ones?

Another issue I have is the idolizing of duct-tape programmers. A good programmer knows when to cut corners and more importantly, cut corners in such a way that it's easy fix the problem properly later on. A developer should "duct-tape" only as a last resort. Any developer that starts working on a project with the intention of duct-taping should never be allowed to code ever. Earlier on I gave an example of a situation where a duct-tape programmer is seen to be useful: a software shop that focuses on features and deadlines over everything else. A problem in this scenario is that your typical good programmer who writes well-designed is forced to become a duct-tape programmer at the risk of seeming to be too "slow" or worse, "unproductive". The final problem is that for every good programmer that can become a duct-tape programmer when the need arises, there are others who are just terrible programmers in general, and will hide behind the label.

So in conclusion, I just want to say that duct-tape programming in general is bad. If you want to become a good developer then you have to know when to duct-tape your code and only do it as a last resort. The "knowing when to duct-tape" is the hardest part, and that will come with experience, knowledge, and education.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Meta

  • Log in
  • Entries feed
  • Comments feed
  • WordPress.org

Archives

  • February 2023
  • April 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • June 2017
  • March 2017
  • November 2016
  • August 2016
  • July 2016
  • June 2016
  • February 2016
  • August 2015
  • July 2014
  • June 2014
  • March 2014
  • December 2013
  • November 2013
  • September 2013
  • July 2013
  • June 2013
  • March 2013
  • February 2013
  • January 2013
  • October 2012
  • July 2012
  • June 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • July 2011
  • June 2011
  • May 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • August 2008
  • March 2008
  • February 2008
  • November 2007
  • July 2007
  • June 2007
  • May 2007
  • March 2007
  • December 2006
  • October 2006
  • September 2006
  • August 2006
  • June 2006
  • April 2006
  • March 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • February 2005
  • October 2004
  • September 2004
  • August 2004
  • July 2004
  • June 2004
  • May 2004
  • April 2004
  • March 2004
  • February 2004
  • January 2004
  • December 2003
  • November 2003
  • October 2003
  • September 2003
  • July 2003
  • June 2003
  • May 2003
  • March 2003
  • February 2003
  • January 2003
  • December 2002
  • November 2002
  • October 2002
  • September 2002
  • August 2002
  • July 2002
  • June 2002
  • May 2002
  • April 2002
  • February 2002
  • September 2001
  • August 2001
  • April 2001
  • March 2001
  • February 2001
  • January 2001
  • December 2000
  • November 2000
  • October 2000
  • August 2000
  • July 2000
  • June 2000
  • May 2000
  • March 2000
  • January 2000
  • December 1999
  • November 1999
  • October 1999
  • September 1999
©2023 Rough Book | Built using WordPress and Responsive Blogily theme by Superb
All original content on these pages is fingerprinted and certified by Digiprove