Be a Better Developer 4 – Being a Plumber
This blog post is part of a larger series named “Be a Better Developer”. You can check out the intro, “Stop Being a Code Monkey” to get started from the beginning. Each post will have a link to the previous ones and a final summary post will contain links to all entries in the series.
“To be or not to be – that is the question.”
– William Shakespeare, Hamlet
“Don’t be a Plumber”: I’ve heard this many times from several people. I believe it originated from Brian Prince as he left one stage of his career and moved on to a position at Microsoft as an Evangelist ([listen to an MP3 of Brian](http://www.msdnevents.com/thrivedev/clickthru.aspx?UrlID=82&URL=/thrivedev/audio/26 - Dont be a plumber.mp3) discussing this in his Career series).
To get started, I want to define “plumbing” as it pertains to our field. Plumbing is that code that has to be there, but isn’t the purpose of the application. A great example are data access layers. Let’s say we are writing a Tax calculation component. The purpose of the code is to crunch numbers and provide a result; however, we must include code to read data from lookup tables based on the user’s zip code for instance. Clearly the data access is required, but it’s not what makes the application different than any other. What is more important are the algorithms we choose for the calculations and how the user interacts with the application. In this case I would call the data access code plumbing.
In the tax calculator example above, we could write the data access code by hand (in .NET that would mean straight ADO.NET code), or we can choose to select an Object Relational Mapper (ORM) framework to get that data for us and relieve us from having to write all that plumbing code. This is really the point that Brian is making in his statement, Don’t be a Plumber. He is suggesting that if there are frameworks that meet your needs for your application infrastructure to do data access, logging, etc., then don’t spend your time writing that. Instead, focus on the parts of the application that differentiate your application from the gazillion other tax calculators (or whatever your building).
Besides not spending your efforts writing this redundant, and often boiler plate, infrastructure code by choosing a framework you will also benefit from innovations to the framework you choose. Brian makes a good point that if you choose a framework with a vibrant ecosystem (either open source or 3rd party commercial) you will benefit from other people endeavoring to make that framework better. For example, in the .NET world nHibernate is a very popular ORM. There are new features and continuing development for nHibernate going on, which means other people are focused on making that tool a great ORM. Let them do that, and you focus on making a great tax calculator. I think Brian makes a great statement by saying, “Only write the code that only You can write”.
Don’t be a plumber is very sound advice.
So all that sounds good, right? From those points it’s hard to see why anyone would want to be a plumber at all. I mean, if not being a plumber means I can A) do less work and B) focus on making my tax calculator the best one out there then how in the world can following this advice be bad? Well, notice how I slipped in the phrasing, “frameworks that meet your needs for your application…”. Well, it turns out that little tidbit is very important. It can be interpreted to mean that it does what you need it to, but it can also be interpreted to mean it does things how you need/want it to as well.
So, from everything I typed so far it seems I’m saying that to be a good developer you should NOT be a Plumber. That’s contradictory to the title of the post, “Being a Plumber”. So should you be a plumber or not? To be or not to be. In my next post in this series I’ll provide a counter viewpoint (as well as point a few others who have done the same) and give you some tips on what to do if you have to roll up your sleeves and get out your plumbing tools.
Previous Posts in this series: