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!

Posted By Mike On Thursday, September 24, 2009
Filed under agile developer orm | Comments (7)

Submit this story to DotNetKicks   

Dylan Wolf - Thursday, September 24, 2009 10:17:38 AM

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.

Michael C. Neel - Thursday, September 24, 2009 10:24:08 AM

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.

Steve Barbour - Thursday, September 24, 2009 10:37:32 AM

"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.

Pete Shearer - Thursday, September 24, 2009 11:16:52 AM

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.

Steve Barbour - Thursday, September 24, 2009 11:33:30 AM

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. - Friday, September 25, 2009 10:51:51 AM

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.

ClintJCL - Saturday, September 26, 2009 8:22:17 PM

Awesome use of our cat Beavis! :)

Leave a comment



Your name:
 

Your email (not shown):
 
Will display your Gravatar image.

Your website (optional):



About Michael

Michael C. Neel, born 1976 in Houston, TX and now live in Knoxvile, TN. Software developer, currently .Net focused. Board member of ETNUG and organizes CodeStock, East Tennessee's annual developers conference. .Net speaker, a Microsoft ASP.NET MVP and ASPInsider. Co-Founder of FuncWorks, LLC and GameMarx.

Proud father of two amazing girls, Rachel and Hannah, and loving husband to Cicelie who inflates and pops his ego as necessary.

 Subscribe to ViNull.com |  Comments

Follow me on Twitter | Contact Me

Related Posts

Critical Thinking and Dissent is a Requirement

So the fires continue to burn, as Joel Spolsky’s internet access hasn’t been disconnected.  For someone who is supposed to be an idiot and irrelevant, ... Read more

Game Development going Agile

Game review site Giant Bomb has a great article about Mass Effect 2’s development process.  The article is written by one of the review staff, who ... Read more

XNA 3D Primer Published – Get a free copy!

In June of 2006 I officially became a professional author when ASP.NET Pro published my article “Google Can You Hear Me?”.  (So eager was I to be ... Read more

IncaBlocks Released, Thanks AgileZen and Kanban!

FuncWorks, LLC’s first XNA game, IncaBlocks, is now available on Xbox Live Indie Games (XBLIG)! This game represents the many hours and weekends Dylan, ... Read more

The Naked Truth of Knoxville GiveCamp 2009

This past weekend was a blowout of charity coding – Ann Arbor MI, Columbus OH, and Knoxville TN all had GiveCamp teams.  Nathan Blevins was the lead ... Read more

XNA 3D Primer by Michael C. Neel

XNA 3D Primer by Michael C. Neel
Buy Now: [ Amazon ] [ Wrox ]

GameMarx

CodeStock

ASPInsiders Member

ETNUG Member