What can we learn from duct-tape programmers?

What is this about

This is a companion post for Zsepi-s legacy code post. He explains what he has learned while working with legacy code. But, that’s only part of the story.

The other part is that somehow we ended up with some legacy code. How did we get there? Sometimes the original developers wrote the code under heavy time pressure. Sometimes they were juniors and they didn’t know any better. Sometimes they were deliberately acting like duct-tape programmers.

This post is about understanding the duct-tape way of thinking.


I used to think that I was a duct-tape programmer. I was even proud of it. I thought that it was OK to add a little hack here and there just to make it work now. I  don’t know how my coworkers handled this. They might complain here in comments.

Later I changed my attitude towards programming. I read the Clean Code book and applied it eagerly zealously. Again, this might have been difficult for my colleagues. Maybe they wrote their posts about how difficult it is to work with software craftsmen.

What makes them successful

Duct-tape programmers shine most when they need to ship features quickly and it’s OK to have a few bugs. Let’s see two examples:

The story of Goliath

Couple of years ago, when we were working for a company in the travel industry, there was a duct tape programmer on the client side. Let’s call him Goliath.

Goliath wrote really ugly code. Signs of copy-paste on his code was obvious. He even wrote the fabulous catch-all test case:

public void test() {
    try {
        // some calls to have high coverage
        // no assert() -s
    } catch (Exception ex) {
        // ignore

He deleted complete test files when a single test case failed. Still, business loved his work. I was wondering, why?

Well, this company used screen-scraping to find the cheapest flight from one place to another. The low-cost airlines don’t really like when their sites are being screen-scraped so they change them frequently. So, Goliat wrote unmaintainable code, but it was OK. Most of his code was thrown away in a couple of months anyway. All he needed to do is to make the scraping work – but he had to do that quickly.

The story of Al

Couple of years later I was working in the financial industry. There I met Al. Just like Goliath, Al didn’t think twice either when time came to deleting tests. He didn’t hesitate to write a method that takes 16 arguments (8 Strings and 8 Booleans). Still, he was successful.

As I understood, Als component was full of bugs. However, the competitors products were full of bugs too. Moreover, users in finance sector don’t move their assets around too frequently. As long the users can access the basic functions, they’ll stay. Also, Al was a genius assigning the blame on others, so his bugs didn’t affect his career

Lessons learned

The most common tool of a duct-tape programmer is something like the Add parameter refactoring. Their variant is pretty much the same as the original recipe. Except, that instead of tests they are leaning on the compiler. This looks ugly at first, e.g. when you’re adding the third parameter to a method. Sure, Uncle Bob wouldn’t approve it. Still, a few more parameters add only a little more noise to the code. Still, it might prevent you from creating two 5-lines long command classes. And that’s a good for readability.

Duct-tape programmers might be obsessed with optimization. Although most of us know that premature optimization is the root of all evil, some of us needs a regular reminder. Here is my rant in this.  Still, there are some optimizations that you can safely apply as you go. E.g. use StringBuilder instead of StringBuffer or String concatenation. You can also cache the compiled xsl transformations. As long as these changes are easy to follow, they can spare you some effort when speed really starts to matter.

There is an issue with the Boy Scout Rule: if you make a little change on a consistent but smelly code, then it’ll only make it worse: the code will be smelly and inconsistent. This is where duct-tape programmers really shine: they deal with the complexity to some point. When it’s really unbearable, then they redesign or even rewrite the problematic component. As long as there are enough tests for that part, this approach can do wonders for you.

When there’s no lesson to learn

Sometimes it’s really hard to work with duct-tape programmers: They might insist that their 500-lines long method is superior to your neatly factored code. They might claim credit for your ideas. They might blame you for their mistakes. This behavior has nothing to do with being a craftsman or a duct-tape programmer. This would be another topic: working with jerks.

Wrapping up

Working with duct-tape programmers makes you question everything  you learned about programming. Irritating as is, it makes you more conscious about the trade-offs that you’re making anyway.


About tamasrev

A software developer, specialized in Java, addressing himself as generalist. A proud daddy.
This entry was posted in programming and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s