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 ( 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 09-24-2009 9:40 AM by Michael C. Neel
Filed under: , ,



sergiopereira wrote re: Being a Duct Tape Programmer
on 09-24-2009 10:16 AM

"ORM frameworks encourage data-driven design, leading to a database friendly UX" ... My experience has been quite the opposite. Maybe you were thinking of simple ORM products like active record or L2SQL?

As far as the rest of your post, I think the term Duct Tape Programmer is very unfortunate. It evokes images of irresponsible and incapable people at work.

Thomas Weller wrote re: Being a Duct Tape Programmer
on 09-24-2009 10:33 AM

Generally, I agree with you, that software development in the real world is about finding the best solution under time-pressure and with otherwise limited resources at hand. That's totally different from the academic world.

But obviously you did not understand what ORMs are for and how they could be used. Otherwise you would never ever say things like "ORM frameworks encourage data-driven design...". The exact opposite is true: ORMs make your business layer persistence ignorant ("There is no database."), they encourage a _domain-centric_ design. That's the primary reason why they are in the world.

There can be (very) good reasons not to use an ORM (one of them would be the lack of knowledge...), but stating that an ORM fosters data-centric design is definitely not one of them. Rather, it's simply ridicolous...

sergiopereira wrote re: Being a Duct Tape Programmer
on 09-24-2009 11:04 AM

here's a very fitting and amusing extreme side of Duct Tape Programming:  (oh, by the way, look at the URL in the browser)

Dan wrote re: Being a Duct Tape Programmer
on 09-24-2009 12:49 PM

You have the use the right tools for the right job.  In the long run proper design will speed up addition of new features and maintenance.  Programmers need to evaluate the tools they are creating and design accordingly.  Sometimes a hacky approach is all you need.  Other times it becomes a huge time drain.

Mark J. Miller wrote re: Being a Duct Tape Programmer
on 09-24-2009 12:51 PM

th.weller - ORM's are a great idea, but in practice I don't think they keep things as separated as all that. In practice, what I've seen is because people believe ORM's to be database agnostic (we can just replace our database by changing the connection string) the ORM creeps further into the application layer. But what you realize your ORM needs to be changed (just as likely as needing to change database). If you're properly keeping your data access code separated from your application logic then I really don't see the benefit of using one over stored procedures (or some other specific data access technology). The benefit of isolating your data access code leans more towards testibility than database agnostic benefits. How many applications have you written where you swapped out the database? And if you were using an ORM did it *really* mean you didn't have to change *anything* other than the connection string?

Thomas Weller wrote re: Being a Duct Tape Programmer
on 09-24-2009 1:12 PM


I never said that ORMs make it easy to change the database - that really is mostly an irrelevant and academic use case.

The advantage of an ORM is to be persistence-agnostic, not database-agostic. While that may sound a bit pedantic, it means: You just don't have to care at all about saving/loading issues while developing your domain model (thus "There is no database.").

Hand-rolling data access code is like re-inventing the wheel for every single project - in most cases it's kind of stealing money from your customer.

You _can_ keep domain and persistence code 100% separated, if that's not done in practice, it's not because the ORM does not allow for it.

Tony wrote re: Being a Duct Tape Programmer
on 09-24-2009 2:03 PM

This makes me sad and happy all at the same time... I understand the usefulness of a sound design, abstraction, testing, or whatever but I like to write code that gets me to my goal. I struggle to find a balance.

Thanks for another point of view on the subject. I will find my balance someday. I am still young(er?). =P

DaRage wrote re: Being a Duct Tape Programmer
on 09-24-2009 2:35 PM

You're wrong.

Ollie Riches wrote re: Being a Duct Tape Programmer
on 09-24-2009 2:57 PM

'ORM frameworks encourage data-driven design, leading to a database friendly UX.'

ROFL - what an informed view...

Ryan Riley wrote re: Being a Duct Tape Programmer
on 09-24-2009 4:13 PM

'ORM frameworks encourage data-driven design, leading to a database friendly UX.'

Like several others, I'd have to say I find this quite the opposite, except for ORMs that use the ActiveRecord pattern (which is intended to match your data) and anything Microsoft releases. However, I also agree with your statement that SQL isn't hard. But b/c of this, why would I want to write the same basic code over and over. Any good ORM will allow you to step in and give it your own SQL when necessary.

More to the point, I find the whole thing utterly crazy. I think there is a type of Duct Tape Programming that is useful (polyglot and poly-paradigm), but your comments here is more like Masking Tape Spray-Painted Gray Programming. It's thin, tears easily, and serves few needs unless you want something that's fragile. (I'm using the ideas behind duct and masking tape literally here and not basing it off of Joel's post.)

You should use the best tool for the job in every scenario. Sometimes that's an ORM; other times that's a stored procedure or service call. So bring on the duct tape, but please use the real stuff. :)

Alwin wrote re: Being a Duct Tape Programmer
on 09-24-2009 6:47 PM

Do you want the app working on the release date, or do you want to be able to maintain the app in the long run?

Or you want both?! Then use an ORM! :)

Lee Brandt wrote re: Being a Duct Tape Programmer
on 09-24-2009 7:51 PM

I have to agree with sergio on this. I have had good and bad experiences with ORM and ORM-like tools, but overall the good ones, used right, help make development much faster and less error prone.

While I agree that the use of an ORM may not be the best for every scenario, I think dismissing them altogether in favor of writing your own is just as irresponsible.

Hope this helps,


Toran Billups wrote re: Being a Duct Tape Programmer
on 09-24-2009 8:43 PM

I must also agree with sergio when it comes to the comment about "ORM frameworks encourage data-driven design" - I find an ORM enables me to work with a rich domain model to the point that I don't even think about the database implementation until after I already have the behavior established in the system.  And writing code behavior first is often leads to more maintainable software in my opinion.

Arnis L. wrote re: Being a Duct Tape Programmer
on 09-25-2009 2:37 AM

No wonder that this article is voted with 1 star only.

Insane World wrote Ship it, or Ship Out
on 09-25-2009 5:14 AM

Joel , in his inimitable way, posted the flame bait of all flame bait posts yesterday , explaining the

DaRage wrote re: Being a Duct Tape Programmer
on 09-25-2009 4:42 PM

I told you you were wrong.

Tetsuo wrote re: Being a Duct Tape Programmer
on 09-26-2009 11:18 AM

I don't think ORM should be the central point to discuss...

Wes wrote re: Being a Duct Tape Programmer
on 09-27-2009 2:11 AM

How can you say that being a duct tape programmer as you describe above is agile?  Agile is about focusing on the customer, so yes reducing time to market is valuable, but equally valuable for most sane customers are flexibility, cost (maintenance too), product lifetime and quality (defects).  All of these are often violated when we just start hacking code together and try to deliver more than is reasonable in the given amount of time.  Why not establish a deadline that encompasses these values?  Why do we always have to assume deadlines are unreasonable?  Seems this is the case when we want to falsely impress our customers with rapid development of the initial version.  What I don't like about this, and have personally experienced, is the implicit dishonesty of not setting a realistic deadline in advance.  We need to look out for the customer in all areas that are valuable, not just short time to market.  Eventually, taking shortcuts and incurring debt we never pay down (let alone tell the customer about), leads to a tainted relationship and wasted time on everyone's part.  That's not customer centric so that's not agile.

Ben wrote re: Being a Duct Tape Programmer
on 09-27-2009 2:48 AM

Joel's article promoted getting the job done by any means necessary, regarding testing as an afterthought and beneath developers, and fire-fighting.  Design, sustainability, and maintenance are afterthoughts since the developer will have moved on or become filthy rich.  This is just nonsense.  Joel was never much of a developer (he was a PM) and doesn't live in reality.

An engineer would make trade-offs and try to balance constraints in agreement with the PM.  The technical debt would be documented and managed.  A short-term design may be acceptable for velocity, but done in a way to ease redesigning for the long-term.  The critical aspects would be high-quality, whereas features deemed acceptably buggy may be released early.  At no time would there be a fire-and-forget mentality.  While clean-ups may not be immediately scheduled, the debt would be documented and brought up regularly.

There is a clear difference between a poor programmer and an engineer.  Joel can't judge quality, but instead confuses it with results and personality.  An engineer sleeps sound every night, while a "duct tape programmer" fire-fights production.  Guess which one Joel would fire for being lazy and an under-performer?

Peter wrote re: Being a Duct Tape Programmer
on 09-27-2009 7:55 AM

I absolute resent the term "duct tape programmer" as a positive term. I believe Joel is trying to say that programmers should focus on achieving goals with as little technology and practices possible. I think that is a gross oversimplification and encourages throwing every kind of discipline and fore-thought out the window for "being faster".

Every framework, practice, etc is a solution to a problem, and brings new problems of its own (nothing is free and perfect). So there is definitely a trade-off, but that's what it is: a trade-off! ORM might be useful (or not), unit testing can be extremely valuable, but in the case of Joel: if only person works at a certain codebase/feature set with a good sense of what impacts what, they might get away with good manual regression tests too. 10 meetings with users vs an architect meeting, I wouldn't know, I would imagine that users can only tell you so much, and an architect might tell you things that would prevent disasters as well.

So it totally depends, and that's what Joel should be saying. As a developer, you should know what your biggest result driver is and what your risks/problems are, and improve based on those parameters. Just doing "duct tape" is stupid and does not do reality justice.

Casper Bang wrote re: Being a Duct Tape Programmer
on 09-27-2009 10:49 AM

"Hand-rolling data access code is like re-inventing the wheel for every single project - in most cases it's kind of stealing money from your customer".

That's a bold statement to make. I've seen plenty of projects where time spend on ORM research, understanding and implementation doesn't really add up in the long run anyway. It has led me to think JPA only really makes sense for CRUD stuff. That means I like to use SQL in an external file and a simple template system.

I donno if that makes me a duct tape programmer, I really don't care, I just happen to like KISS and not die in framework overload.

Andrew wrote re: Being a Duct Tape Programmer
on 09-28-2009 4:13 PM


I believe Thomas Weller's point was that hand rolling your basic CRUD DAL code is a non-value added event.  Anyone can do it, therefore you are paying 100K + a year (not to mention other opportunity costs) to do what a trained monkey could do.  Spending 1/2 your time on a project writing that code is a waste of time since tools exist that will do it better than you, not to mention the fact that an good ORM also adds additional value (caching for example).  

(Warning, numbers might not reflect what you are working on so should be taken with a grain of salt incoming)

You'd be surprised, but most projects that are your standard GUI -> Mid Tier -> Database more than 50% is DAL code.  If that DAL code is just basic CRUD, then why waste your time (and by proxy, your customer's time) writing it?  Use an ORM, preferably one that has Caching, and concentrate on what really matters, your domain/business logic.  DAL stuff is easy, don't let it become time consuming on top of that.

Thomas Weller wrote re: Being a Duct Tape Programmer
on 09-29-2009 6:25 AM


sure, learning an ORM takes far more time than hacking together data access code for one project. And also, an ORM is surely not the one-purpose silver bullet to end all hand-written SQL - whether to use or not to use an ORM solely depends on the specific project requirements. There are surely projects that are better off with some hand-rolled stuff, and it also may not pay in every case to invest in learning an ORM.

But regarding the canonical three-tier case (GUI-Business Layer-Database), I see an almost overwhelmingly strong reason for an ORM: Once learned, CRUD-operations and other, far more complicated stuff are a breeze and go so much faster than writing data access code on your own (and is so much less error-prone), that it's almost mandatory from a business standpoint to use an ORM. Or, as Andrew has put it: Why wasting time for hand-writing essentially the same DAL code again and again. How is it justifiable to take money for that?

- Thomas

Dave Schinkel wrote re: Being a Duct Tape Programmer
on 10-07-2009 9:31 PM

Dude, you talk about academics being the driving force behind common sense.  Are you kidding yourself?  I have heard this too from my boss and I just can't believe what I'm hearing.

WTF does academics have to do with smart project planning, not too much documentation (so you CAN get shit done) and a BALANCE between finding the critical path in your code vs. over architecting an app?

Any idiot would say that thinking about structure in code is overrated and code & run rules.

I love the lame analogies that you Joel, and others who just think that you should run to get a product out come up with to go against some sort of attention to detail/standards when you as a team are working to code maintainable code that is not going to bring the team to its knees in 5 years.

Right now I have to deal with what Joel describes, a pile because of a Code & Run situation where nothing was organized properly (physically and also layers) and so the business "wants it now" however you know what, they ain't gonna get it now because I have to sift through code that took this approach and I can't find shit that I need, names make no sense, file names make no sense and every BL method is crammed into one class because of this very mentality!

If you support this kind of approach to development, then you belong working as an intern who doesn't know any better than this.

Dave Schinkel wrote re: Being a Duct Tape Programmer
on 10-07-2009 9:39 PM

It's also extremely lame that Joel Spolsky doesn't allow comments in his blog.  Pu**y.  Just because someone runs a business doesn't mean they know jack about getting things done or code.  This is a prime example of carelessness with his post telling people that if you try to think about coding clean, that you're somehow trying to be "pretty".

If that's not the most lame extreme analogy I've read, then you tell me another because that's making the assumption that all programmers who care about writing maintainable code somehow spend 50% of their time trying to make it "pretty".

That's a statement from a monkey.

Dave Schinkel wrote re: Being a Duct Tape Programmer
on 10-07-2009 11:33 PM

I think everyone should read the comment from Ben above.   Well put.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)