Being a Duct Tape Programmer

imageThings I’ve said in a session before:

“Friends don’t let friends ORM”

“ORM is a pattern, not a framework”

“I like typed datasets, and I cannot lie”

It’s not that I’m anti-ORM, or believe popular ones like NHibernate, Linq2Sql, and EF are useless (okay, maybe EF is).  It’s the mindset that you need an ORM Framework bloating your app from the start.  It’s the common:

“Hey, new project!” “Awesome, which ORM should we use!” – WTF!?!

While I’m busy loosing friends and respect, I’ll state this is an “anti-agile pattern” – if you were truly agile and doing iterative development, there isn’t a whole bunch of plumbing to write at once.  SQL isn’t hard, and is too important to performance to let a tool codegen it for you.  ORM frameworks encourage data-driven design, leading to a database friendly UX.

Last night I read The Duct Tape Programmer by Joel Spolsky and added Coders at Work to my Amazon queue (no Kindle edition, so they missed an impulse sale).  I love this post and the description of a Duct Tape Programmer.  I hate the term pragmatic – the word itself sounds academic, and I don’t think a pragmatist (another suspicious term) came up with it.  I think the academics made up the word cause saying short sighted made them look bad.  That’s really what many mean when they say “pragmatic” – Oh sure, he got the app out, but his code is awful, and he has tons of technical debt, and it will all have to be rewritten, and how far do you think an app like that can scale without an Enterprise Service Bus?, and I bet there isn’t even an Inversion of Control framework, and I know he doesn’t have good test coverage and any tests he does have are only integration tests, and…

The Duct Tape Programmer is driven by a different force than the Academic.  The Duct Tape Programmer is looking at the release date, and only values stuff that gets the app working on that date.  She would rather have 10 meetings with users than one meeting with a Systems Architect.  She would tell you KISS when you asked if you should extract an interface for a single widget.  She lives Agile and Lean on a subconscious level, because to her it’s just common sense.

Joel ended his post saying you can’t just be a Duct Tape Programmer.  I’ll add to this – you can become one.  Move your focus off the code to the app, and more importantly, the user.  Expand your knowledge base horizontally – learn multiple languages, frameworks, systems.  Do some raw socket programming, and write a graphics shader.  Install Linux on a Sparc 10.  Make an app for your mobile phone.  Question the accepted wisdom, and be an old school hacker.

I’m off now to convince Cicelie (DragonTee.com) to design a “Duct Tape Programmer” t-shirt, in the meantime you can tell me why I’m wrong below.  Don’t be shy, I’m used to it!

  • http://www.dylanwolf.com/ Dylan Wolf

    From the initial comments on Twitter, this sounds like it’s going to start an argument. :) So here’s my take on the debate.

    When you get right down to it, we need both types of programmers. We need programmers who are going to force us to use better technologies and better practices and to unit test. But we also need duct tape programmers who are going to balance that out by enforcing the fact that good enough really is good enough.

    I think the trend right now is to be… whatever the opposite of duct tape programmers are. So I don’t think the point of the article is that the Duct Tape Programmer is the <em>best</em> type of programmer, merely that it’s OK to be one. If nothing else, it helps people like me who are going to be self-conscious about what technologies they use and how perfect their code is, rather than focusing on just writing code that works.

  • http://www.vinull.com Michael C. Neel

    Those would be "Red Tape" programmers (thanks @nathanblevins!).

    I agree, and one of the reasons I think we work so well together with FuncWorks is we each play to different strengths. Duct Tape programmers do their thing by taking the awesome parts created by Deep Thought developers (a nicer term) and mashing them together.

  • http://www.steverb.com Steve Barbour

    "SQL isn’t hard, and is too important to performance to let a tool codegen it for you."

    Sounds like premature optimization to me. I have better things to spend my brain cycles on. Eight times out of ten, the ORM generated SQL will be good enough, and if it’s not you can hand craft where necessary.

    I’ve found that the developers who misuse ORMs are exactly the developers you don’t want writing SQL by hand.

    On the other hand, I agree that data driven design is putting the cart before the horse.

  • http://www.peteonsoftware.com/ Pete Shearer

    Data driven design is only putting the cart before the horse if the data you store is only incidental to your app or if you only have a "single serving" application. If your data needs to be used for multiple applications, handle incoming and outgoing feeds, and serve the occasional report (we can’t all have data warehouses), then data driven design is a smart decision. We aren’t all writing Twitter or YABE (Yet Another Blog Engine), some of us are changed with writing large systems that run large corporations.

  • http://www.steverb.com Steve Barbour

    To be clear, I wasn’t (and I don’t think Michael was) saying that no database design is necessary (or desirable), but that the design of your data store should be driven by how that data is being used. If your data will be used by multiple systems and needs to be reportable you need to deal with that as well.

    And all of this ignores the fact that a good portion of apps use pre-existing databases to some degree or another.

  • Gabriel.

    Honestly I didn’t follow Mike’s corollary to Joel’s blog post. I assume it’s due to my unfamiliarity with .NET, but I presume from Mike’s post that the state of .NET ORM’s is such that the debate over which to use is so bad he’d rather not use one at all.

    Which is pretty hilarious.

    As for the actual argument, use one or don’t, but for the love of pete be honest enough to know that whichever path you choose is irreparable. There will never be a time where adding in an ORM tool will be the highest priority, and if it is, it’s likely because you’re working on a dead project.

    I’ll add an opinion piece in to say that an ORM tool should be used because it speeds up development time and lets you concentrate on getting code out, not to compensate for a fellow developer’s lack of SQL-fu.

    And… to counterpoint Steve’s comment… If you have developers that can neither figure out ORMs nor SQL… Uh… you’ve got bigger problems.

  • http://clintjcl.wordpress.com ClintJCL

    Awesome use of our cat Beavis! :)