Joel Sposky’s writing is amazing. You should read everything he writes. In particular from: https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/
Jamie Zawinski is what I would call a duct-tape programmer. And I say that with a great deal of respect. 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.
I agree:
duct tape programming good.
Focusing on titanium when you’re at the start line bad.
Of course, mid-wit programmers think duct tape programming is about not following “good design” or “good style.” They mistake it with novice programming. Like this fool:
https://keasigmadelta.com/blog/duct-tape-programming-is-hard/
A "duct tape programmer" is someone who throws code together quickly without burdening themselves with code structure, good design, etc. Ian says that management loves them, because they can write working code and ship it to customers quickly. However, they leave ugly and hard to maintain code in their wake, which their colleagues don't like.
No. No. No. And. No.
Joel’s duct tape programmer is not writing ugly unmaintanable code without a focus on structure and design. It leads to more maintainable code than those architect astronauts who design castles nobody can debug. Joel clearly means this:
And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”
If a duct-tape programmer were just a hack, he’d say “I don’t need multiple inheritance to ship this now so why bother.” But he doesn’t. He pushes back that the whole idea of multiple inheritance as flawed. That’s a deep thinker.
Duct tape programmers know the essence of good engineering isn’t the parts you use. He’s not a parts geek. He’s focused on how to use the parts.
A shiny sparkly overly complicated monstronsity is much harder to maintain than a small, simple well designed low-tech solution.
Duct tape programmers know once you build something working end to end with duct tape, swapping out the duct tape for titanium screws that’ll never come out in 100 years is straightforward and can happen after the product’s been shipped.
So… if it’s not ugly coding for the sake of speed, what is duct tape programming?
Duct Tape Programming
If I had to define it, duct tape programming is programming while focusing on the interfaces without concern for the implementation.
Duct tape programmers know interfaces last forever. QWERTY is still here with us despite innovations like dvorak or colemak. My handle and personal email, was based on a book I read when I was 9. But now that it’s my interface. I’m stuck with it.
The 80 character limit for many languages (like Go) has its origins in the width of the US dollar.
Punch cards, which date back to 1890, were the same size as US currency. This was so standard cash holding technology could be repurposed for punch cards (this choice is great engineering by the way, use an existing standard to use existing technology with your new technology).
Those punch cards had 80 columns.
Early terminals wanted to be compatible with these 80 punch cards, so they enforced 80 columns.
Code had to render cleanly on those 80 column terminals without word wrapping.
Modern terminals descend from them, at 80 columns by default.
Ergo…80 characters.
Everybody hates that makefiles use tabs. And makefiles use tabs because its author couldn’t change the interface for a few dozens in its early days.
But make was easily rewritten by GNU and BSD.
Swapping out duct tape (Proprietary AT&T code) for steel (free software)? No problem.
Changing the interface of tabs to spaces. Impossible.
Duct tape programming is recognizing if you build a type writer out of legos, and the product is a hit, there’s plenty of time and money to replace the legos with steel. But there will NEVER be time to fix the interface.
In high tech you’re usually shipping a new product. Here, speed matters. The customer interface matters. But nothing else does. Not even if its implementation is barely held together by duct tape. Once successful, there’s plenty of time to reimplement an interface. And if it fails, you failed fast.
What people get wrong about duct tape programmers
I tend to disagree on duct tape programming. I think the extremes are bad, duct tape and as well, overengineering.
> In high tech you’re usually shipping a new product. Here, speed matters. The customer interface matters. But nothing else does.
In my experience, most of your work will not be building new features from scratch, but extending the existing ones, fixing issues on existing ones, etc. A software system is group of small peaces that are couple and work together. When taken to the extreme, duct tape programming makes these peaces so tightly coupled that a minimal change in one of them can brings the whole system down.
Doesn't duct tape programming add unnecessary debugging effort before the product is ready to ship, though? Unit testing, which Joel states that duct tape programmers refuse to do, was created for anticipating and speeding up the final stages of the software development process. How do you explain this inconsistency between wanting to deliver fast and refusing to use rapid development methods?