If you’re a developer, you probably have already read it, or read about it: The Duct Tape Programmer. There are some really good points about this article–but it’s clear that the article itself is written by someone who is not a duct tape programmer.
The differentiation between an Architecture Astronaut and a duct tape programmer is pragmatism and simplicity:
You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the Architecture Astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.
Architecture Astronauts proclaim with absolute certainty whatever it is they are promoting. Duct tape programmers say “shut the hell up and get this out the door.” Your toolkit is just that: a toolkit, and there is no point in tossing that toolkit out the door for new tools simply because it is the new hotness.
So how does Joel Spolsky characterizes Duct Tape Programmer thinking? By being an Architecture Astronaut:
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.
“Stop it, just stop.”
Each of these have their place, if your first desire is to ship. Me, if you treat C++ as C with classes, avoiding templates (unless it’s a STL object, ’cause using std::vector is easier than rolling your own), and for the most part avoiding exceptions (because the rules for exceptions can get really convoluted), then you should be fine. C++ is a tool, like Java, like C, like Objective-C: C++ has more potential pitfalls, but just ignore them. Multiple inheritance also has it’s place: it’s what you do when you accidentally code your class tree into a circle and don’t have time to renormalize things into a well-defined class hierarchy. Multi-threading only is useful when dealing with networking or when you put the thread handling into a thread queue and can just create a well-defined process and toss it in–and if you want to ship on Windows, you have to deal with COM.
And if we’re going to complain about CORBA, can we also complain about SOAP–which is not simple, despite the name? And can we complain about all the additional crap (like introspection) being tossed into the base XML-RPC specification?
The two overriding rules are “just ship the damned thing” and “sometimes life is messy.” Towards the first “just ship the damned thing”, it means don’t be afraid to use yesterday’s well-defined tools rather than today’s cutting edge experimental crap. It means avoiding the well-known pitfalls in the tools: if you treat C++ as C with objects, it will be far better than using C and trying to build your own class hierarchy processing. It means not rebuilding what someone else has done for you for free: why use C with objects when you have C++? Why build your own Complex number type or dynamic array processing or hash map, when there is std::complex and std::vector and java.lang.HashMap? And it means sometimes you’ll code something because it’s what will ship, rather than architecting something that is beautiful–which means sometimes you’ll find yourself creating a class which multiply-inherits or a Java class with half the methods written as one-line delegates. Because it’s ugly–but it will ship. And do you have time to figure out how to reorganize your class hierarchy into a strict tree representation?
Sometimes it also means knowing where to draw the line when using a toolset. Me, I like C++ but hate templates with a passion and think exceptions are good if used in a limited way. I like Java because it allows you to write a lot of code quickly, but hate Java because it has allowed lots of people to write lots of code quickly–and in the hands of an Architecture Astronaut it’s allowed them to create all sorts of abominations that showcase their theoretical bullshit. (cf: Spring or Hibernate, which has struggled to make a simple problem impossible to solve. Cross cutting? Puhleeeease…) The last time I wrote a Java server, I wrote code directly to the Servlet layer, with a simple bit of parser code to parse XMLRPC. Took me an afternoon to get up and running against an iPhone client.
It certainly also means waiting to jump on the next tool bandwagon once it stops being a theoretical playground for bored Architecture Astronaut wannabe weenies. Which is why I’m not on the Ruby on Rails bandwagon or the Code in the Cloud concept. I like tools that are well-defined which have well-defined and mature development tools: one reason why it’s easy to write code in Java is because there are many solid IDEs which help you write code. (Eclipse, Netbeans, IntelliJ).
Just ship the damned thing already, okay? Remember: shipping is a feature far more important than any other feature in your product.