The duct tape programmer
It began when Joel Spolsky wrote an article on his blog entitled The Duct Tape Programmer. And then it began to spread, some liked it, others not so much. But the curious thing was to see the amount of blogs that immediately raised the finger to say how Joel was wrong, how the comparison was exaggerated, how the concept was flawed.
Heaven's sake! Let's stop this thing of always wanting to label everything as right or wrong, few things in life are right or wrong, black or white, light or dark, or whatever you prefer to compare. The secret is to seek balance. And when we talk about software development, programming, this becomes even more true. Very few things are on the ground of right and wrong, in most cases, you need to use common sense (rare thing nowadays) to choose the most appropriate form of work, the most appropriate technology or most appropriate working tool.
Therefore, instead of wasting energy criticizing the article, we get the main idea and see how it can improve our lives, the way we work, to see if we can do our best in developing software.
Analysing the article
In the article mentioned at the beginning of this post, Joel talks about the term "duct tape programmer" in reference to the book Coders at Work, which is a collection of interviews with experienced programmers and their jobs.
In this book Joel found the interviewee Jamie Zawinsky, one of the developers of the Netscape browser, and described Jamie as a "duct tape programmer". Look at the definition: > 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.
Yes, the main point here is simple: the duct tape programmer is more interested in solving problems and deliver the product, rather than bothering to add complexity on top of complexity on top of complexity (Hey Java, I'm looking at you!). > And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”
In order to gain agility we have to say "No" sometimes. "No" to unnecessary complexity, "no" to features that do not add value, "no" for tools that have a huge learning curve and that ultimately add little or no value to our work. We have to focus on what will solve my problem or the problem of my customer. This paragraph of the article says it all: > Peter asked Zawinski, “Overengineering seems to be a pet peeve of yours.” “Yeah,” he says, “At the end of the day, > ship the fu**ing 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.”
I need to emphasize this: you’re not here to write code; you’re here to ship products. Yes, that's why we get paid and this should be our main issue, deliver great products to our customers.
Of course we shouldn't take this concept and treat it as absolute truth, it is far from it. I repeat once again, like everything in life, we need to analyze it with balance. There is no acceptable reasoning in deliver the product on time but full of errors and compromised structure.
So, a duct tape does not solve all our problems, sometimes you may need to use something more complicated, but more durable. In software development, we need to evaluate when our problem will be solved with the simplest solution possible or if we have to use something more complex to gain in the future.