Last week Joel Spolsky wrote a blog post entitled The Duct Tape Programmer where he praises developers who favor simple programming practices to complex ones. This blog post strongly resonated with me and made me recall some related thoughts on complexity and solving problems in software projects. Some key excerpts from his which I'll use as a jumping off point are below

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.
Duct tape programmers are pragmatic. Zawinski popularized Richard Gabriel’s precept of
Worse is Better. A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.

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.

The urge the reduce the complexity of the tools used to solve software problems is one that every software developer should share. However even more important is reducing the complexity of the actual solutions that are delivered to your customers at the end of the day. End users can't tell if you used complicated C++ techniques like template metaprogramming and mixins to build the application. They can tell when your application fails to solve their actual problems in a straightforward way or is so late to ship due to project delays that they lose interest in waiting for you to solve their problems.

There are many famous and everyday examples of this culture of complexity in software projects which are eventually trumped by solutions that solve 80% of the problem in a simple way. My favorite example is contrasting the World Wide Web invented by Tim Berners-Lee with Project Xanadu as envisioned by Ted Nelson.  Today the WWW is used by over a billion people to enrich their lives in myriad ways on a daily basis and has created hundreds of billions dollars in value by minting an entire new industry. Project Xanadu is a sad footnote spoken about in hushed tones by fans of hypertext who bewail the success of the Web and how it has forced us to settle for less (i.e. Worse Is Better).

If you aren't familiar with Project Xanadu you can think of it as a networked system of hyperlinked documents and media just like the WWW which had to satisfy the following seventeen rules

    1. Every Xanadu server is uniquely and securely identified.
    2. Every Xanadu server can be operated independently or in a network.
    3. Every user is uniquely and securely identified.
    4. Every user can search, retrieve, create and store documents.
    5. Every document can consist of any number of parts each of which may be of any data type.
    6. Every document can contain links of any type including virtual copies ("transclusions") to any other document in the system accessible to its owner.
    7. Links are visible and can be followed from all endpoints.
    8. Permission to link to a document is explicitly granted by the act of publication.
    9. Every document can contain a royalty mechanism at any desired degree of granularity to ensure payment on any portion accessed, including virtual copies ("transclusions") of all or part of the document.
    10. Every document is uniquely and securely identified.
    11. Every document can have secure access controls.
    12. Every document can be rapidly searched, stored and retrieved without user knowledge of where it is physically stored.
    13. Every document is automatically moved to physical storage appropriate to its frequency of access from any given location.
    14. Every document is automatically stored redundantly to maintain availability even in case of a disaster.
    15. Every Xanadu service provider can charge their users at any rate they choose for the storage, retrieval and publishing of documents.
    16. Every transaction is secure and auditable only by the parties to that transaction.
    17. The Xanadu client-server communication protocol is an openly published standard. Third-party software development and integration is encouraged.

Reading this list is like going through a list of places where World Wide Web fails. Rule #14 which implies every document on the network is redundantly backed up in disparate locations so they can always be is something the WWW doesn't do today which is why we have broken links and 404s all the time. Rule #9 implies that not only is copyright respected and tracked throughout the system but there is even a micropayment platform built in. All the discussions on micropayments saving newspapers would be moot if Project Xanadu ruled the world since it would have existed from day one. Rule #16 on transactions being secure and auditable sounds like Nirvana in today's world of botnets, malware and phishing scams which plague the Web.

Yet despite the fact that the forty year old Project Xanadu is a more compelling vision than were we are today it failed and Tim Berners-Lee's World Wide Web succeeded. In practical terms, Project Xanadu was trying to solve too many complex problems in a v1 product. In contrast, Tim Berners-Lee focused on the most valuable problems to solve for end users which was sharing documents and media with anyone on the Internet and punted on a bunch of the hard problems that would require a more controlled and tightly coupled network as well as a ton of more code. Tim Berners-Lee solved less than half the problems Project Xanadu set out to solve but has changed the world immeasurably for billions of people by providing simple solutions to complex problems and running away from trying to create complex solutions to complex problems.

The bottom line is that a lot of the time it's OK to create a solution that solves 80% of the problem. Always remember that shipping is a feature.

Note Now Playing: Drake, Kanye West, Lil Wayne & Eminem - Forever Note


Sunday, 27 September 2009 23:50:09 (GMT Daylight Time, UTC+01:00)
It's a shame that Joel soiled an otherwise good book report with his own unreasonable biases against developer testing.
Monday, 28 September 2009 12:16:49 (GMT Daylight Time, UTC+01:00)
I don't entirely agree.

I've written a response on my blog:

Here's an extract:

Occam’s razor. Now all new and improved in the digital age.
By dmg46664

Dare Osbanio’s blogged about the danger of complex solutions and the benefits of duck-tape programming.

Indeed, this philosophy can be applied outside the programming world, but since I’m responding to this specifically I’ll continue to use the software context.

I don’t agree. Of course I acknowledge that in order to get software out the door, sometimes you have to scale back on feature creep and can’t always satisfy all concerns on version one. Very often by seeing your software being used you find that all the concerns you had thought to satisfy originally aren’t real concerns. What I disagree with is the mantra that ‘Simpler is always better’. I prefer the Occam’s razor version : ‘Keep things as simple as possible, but no simpler’. It’s ironic that this is easier to understand than the literal translation “Don’t multiply entities unnecessarily”. :)

It’s easy to find examples to counter the WWW/Xanadu example that Dare points out. In fact a surprising number of them come from Google. A notable one is Gmail. I was a hotmail user and liked the benefits of a web client. Gmail was late to the game, but they brought with their client significantly more complexity. Namely, threaded conversation view, tagging of emails instead of folders (and the inbox tag, for archiving), and a thick javascript client that would take longer to load initially, but user experience once logged in would be super quick. Coupled with the incentive of significantly more space which was actually eventually matched by hotmail at the time I switched, the added complexity/functionality was a boon for the user. Even as I show off the features of my gmail client to users of MSNLive and Yahoo, they grimace to think that all their organizing of their mail would be lost if they were to switch, the plight that can come from early adoption, coupled with a fear of the unknown.

More examples from Google: GWT, a more complex and yet surprisingly powerful way to write javascript, without... (more on the blog).
Monday, 28 September 2009 19:32:21 (GMT Daylight Time, UTC+01:00)
Besuchen Sie meine Homepage um mehr zu erfahren.
Tuesday, 29 September 2009 04:09:20 (GMT Daylight Time, UTC+01:00)
I agree that simple is better and that shipping is definitely one of those "gotta have" features.

However there is one problem with the going-for-duct-taped-code-look approach; that is that a simple system becomes inherently complex (if there is any growth in the system.) When the growth happens a duct-taped solution can become unwieldy after a few iterations. Look at the current state of XHTML/HTML 4/XHTML 2/HTML 5 situation we have (A Comic Strip Explication) ... While shipping should be a priority; over-engineering avoided; one should take as much "thought/design" time as possible to make something that's far from duct-tape as one can get.

Wednesday, 30 September 2009 08:48:40 (GMT Daylight Time, UTC+01:00)
Nobody argues that simple isn't better than complex. However, few agrees on the definition of simplicity. Particularly in the Java space I find this to be an issue, with frameworks that promises to simplify while in reality it does the opposite.
Casper Bang
Monday, 05 October 2009 11:54:14 (GMT Daylight Time, UTC+01:00)
Boy does this resonate with me! It's been a lifelong passion of mine, literally. I've been at this programming game for over 40 years without interruption or stagnation. "Good enough" is my thang.
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. -- Antoine de Saint-Exupéry

I heard this as a teenager, literally, from Bernie Kreitzer, an aeronautical engineer I worked for as a human spreadsheet calculator for a summer job. He gave me the gift of engineering insight. His partner gave me the gift of a visit to Control Data to see the 6600 in LA. That was it, I was hooked!
When the growth happens a duct-taped solution can become unwieldy after a few iterations. at the current state of XHTML/HTML 4/XHTML 2/HTML 5...

The other half is the art of laying a foundation for growth. Standards like those aren't software, and they are usually the product of academics, not engineers.
However, few agrees on the definition of simplicity. Particularly in the Java space I find this to be an issue, with frameworks that promises to simplify while in reality it does the opposite.

Ha ha, Java, yeah. Don't get me wrong, Java is one of those languages I loved when I was working with it. But it seems to attract adders, not subtractors.
Comments are closed.