Debunking the duct tape programmer

(subscribe to my feed here:

On 23 September, 2009, Joel Spolsky wrote a piece extolling the virtues of the duct tape programmer.  He contrasted the duct tape worldview to the astronaut architect.  While the astronaut architect would sit in analysis paralysis, the duct tape programmer would have some working product already out the door.

“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.” – from

While indulging in analysis paralysis is certainly the downfall of some, there are more alternatives than merely pulling out duct tape and throwing something together.  We also have to keep in mind how to apply advice and from where the advice is coming.  Matt Hinze put it nicely on twitter:

“i’ve said it before, @jbogard : never take software advice from a bug tracking system salesman” – from

If you have small tasks, using the duct tape solution will probably serve you well.  Physical analogies are powerful, so I will stay with the duct tape metaphor.  Duct tape is strong.  It is sticky.  It is easy to apply.  On the other hand, it is not durable (it deteriorates in water and direct sunlight).  It is not removed or reapplied easily, and God help you if you get it stuck to itself.  There are good uses for the duct tape approach, and there are times when it is professional negligence.  If I’m developing an application or website for a political candidate, I’m probably fine using duct tape, but I have two constraints:

  1. I throw the whole thing away when my candidate loses.
  2. My candidate succeeds, gets more funding, and I redo the whole thing.

The argument for quick and dirty solutions is always geared toward getting the first version out quickly.  Time to market!  Time to market!  For small products, it works fine, but for larger systems, the code base can collapse on itself after a life of taking shortcuts.  This effect is well documented in the book, Clean Code

The third option, which Mr. Spolsky neglects to address, is the approach put forth by Kent Beck, in his book, Extreme Programming Explained.  I highly recommend the book, but I will quote since it is freely accessible.  While getting stuck in analysis paralysis or complex solutions is certainly not a good way to go, XP stresses Simplicity as a key principle:

“A simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work next. If you find something that is complex replace it with something simple. It’s always faster and cheaper to replace complex code now, before you waste a lot more time on it.” – from (emphasis mine)

One part of Mr. Spolsky’s premise is supported by this XP principle.  That is, if you are creating a system where a throwaway solution is appropriate (you throw away duct tape – you don’t refactor it), then that is the simplest thing that will work as you need it to.  On the other hand, if you are creating critical business applications like my company does, you want to ensure you are:

  1. Using durable materials
  2. Using malleable techniques so the 2nd, 3rd versions go well
  3. The entire system is clean (no broken windows)

The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms.  This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method.  All of us have used quick and dirty fixes, but the craftsmanship quotient applies if we quickly replace the naive fix with a more organized one.  The patch panel on the left has an organization method.  The patch panel on the right has responded over time to “just one more cable” without much effort to proper organization.


The choices presented between duct tape programming and analysis paralysis are not valid.  There are many choices, and quick and dirty fixes should not be standard operating procedure (SOP).  Organized software engineering should prevail.  Approaches that apply rigorous discipline will always yield better product.  Both discipline about keeping scope under control so that you can ship quickly, and solid engineering techniques to ensure that what is shipped is maintainable for the next version.

ASP.NET MVC in Action screencast

On Monday, 21 September, 2009, I visited the Shreveport .Net user group on an INETA speaking trip.  Brian Sullivan is the user group’s leader, and he was a great host.  The following is a recording of the talk.  I used Camtasia for the recording.  It is best viewed full screen.  For more in depth information, get the ASP.NET MVC book.

Download the slide here.

Competing on the unpopular

As an executive of a company on the Inc 500 list, I’m getting lots of sales calls from people wanting to supply me with programmers.  Most often, they want to supply me with programmers who are not in Austin, TX.  Some are in other countries and some are just is different places.  This got us thinking a bit about why people in Austin use Headspring.  We have one location, and we serve clients in one region.  People in Austin choose Headspring because we are real people working out of their offices.  Real faces.  Real relationships.  Never mind the rigorous extreme programming practices that yield insane levels of quality.

Going forward, we are taking a stand.  We are proclaiming from our home page: “No Offshoring”.  That’s what we are about.  If you call Headspring, you know what you are getting.  Here is a clip from the home page.


ASP.NET MVC in Action spotted at Barnes and Noble

I couldn’t resist being a little excited when I saw our book, ASP.NET MVC in Action, at the Barnes and Noble bookstore at the Arboretum in Austin, TX.  Here is a picture of it.


On a more interesting note, googling for “ mvc in action” brings of some good results but also a site where a pirated copy of the ebook can be had.  I’m not too upset about this.  It’s the same issue with movies and music.  I realize that the people who pirate the book likely are not the same people who would pay for the book. 

On another interesting note, I just discovered that the computer science department at Texas A&M University will be using ASP.NET MVC in Action as one of their textbooks.

Agile Dinner, Sept 17, Austin, TX

I hereby declare a agile/geek/programmer/software dinner/supper on Thursday, Sept 17 at Mangia pizza from 6pm-8pm.  The menu is pizza.  The topics are agile and software engineering. (map)

I will be at Mangia pizza in NW Austin, TX for AgileAustin’s AskAnExpert (volunteer) meeting.  I’ll be available for questions on software engineering.  Come out for supper and some good agile software talk.  I’m volunteering my time for people to ask questions, but typically, everyone learns from everyone.  I’ll end up learning from you as well.

If you are interested in volunteering to host a future session, go here.

ASP.NET MVC in Action arrived at my doorstep today


I received my book today in the mail.  Some people on twitter have already reported receiving their copies, and if you have ordered it during the MEAP, you should have it today or tomorrow.  I want to thank my two co-authors, Ben Scheirman (who has received his copies also) and Jimmy Bogard for working with me on this book.  I could not have done it without them.  You’ll also see Jeremy Skinner’s picture in the book.  He was a terrific technical editor (recently accepted as an ASPInsider).

If you haven’t purchased the book, go to or your local bookstore.

And thanks to the Mohammad Azam for the plug in his screencast.

Mahendra Mavani teaching Refactoring workshop

On Sept 19, from 0900-1200, Mahendra Mavani is teaching a refactoring workshop in Austin, TX.  It’s free.  Just make sure to sign up to ensure your seat.

This workshop is going to be facilitated by Mahendra Mavani.  Mahendra is an agile software developer with 8 years of consulting experience. His consulting span accross working with esteem clients from 5 different countries (USA, South Africa, Netherlands, Singapore and UK). Mahendra initiated carrier with waterfall and RUP methodology but quickly jumped onto the track of Agile/XP. Personally Mahendra believe in designing simplest solution for the complex business process and hence strieve for architectue/design which is open for extension-close for modification with high degree of automated test coverage and one with least possible technical debt.

Mahendra has worked with combination of web and windows application development. Earlier phase of his career includes designning Use Case, IDEFØ diagram, Sequence diagram and Activity diagrams as well as honoring CMMi 5 quality standards. However his current inclination is towards user story based iterative development.

Refactoring Workshop:

This is session, full of code drive to demonstrate refactoring techniques mostly influenced by Michael Feathers in his book, “Working Effectively with Legacy Code”. The session will be lively by mean of audience interaction while demonstrating how to approach this refactoring for practical scenarios. Session will start with discussion on the topic of dependency and will go towards the direction of how to break those dependencies and introduce testing harness for any legacy code.

**This is a technically oriented session**

We ask that you bring a laptop capable of running Microsoft Visual Studio Express 2008 or Visual Studio 2008..  (More details on where to download will follow closer to the class date, emailed to attendees.) You should also be familiar with C#, .NET or be comfortable enough with programming to work in pairs or groups with those who are familiar with .NET syntax.

Productivity plug in Resharper, although not required, is highly recommended to have. 30 day tirl version of Resharper 4.5 can be found at 

All the Refactoring terminology, would be taken from following books:

"Refactoring: Improving the Design of Existing Code" by Martin Fowler (

"Working effectively with legacy code" by Michael Feathers (

An introductaring pdf about Michael work can be found at

Headspring hosts free Continuous Integration (CI) workshop Sept 15

Go here to sign up:

(see Eric’s blog post here)

Headspring has partnered with Microsoft to provide monthly workshops to the local developer community for free.  Usually on the 2nd or 3rd Tuesday of each month, these workshops focus on developer skills that are of critical importance to the market in our area.

Headspring provides a free afternoon of training and mentoring in an interactive classroom setting at the local Microsoft office, and registration is free.

This month, Eric Hexter and I are leading a CI (continuous integration) workshop from 1pm to 5pm on Sept 15th. 

This workshop will cover the core concepts of Continous Integration and show examples of implementing it for .NET applications and systems. The workshop will be presented by Eric Hexter and Jeffrey Palermo.

  • Introducing Continuous Integration
  • Reducing Risks Using CI
  • Building Software at Every Change
  • Continuous Database Integration
  • Continuous Testing
  • Continuous Inspection
  • Continuous Deployment

For more information about Continous Integration see the website: and the book: Continuous Integration: Improving Software Quality and Reducing Risk


Austin Microsoft Office
9606 N Mo Pac Expy
Austin, TX 78759