Why cheap developers will cost you

I’m going to take a break from the normal techno-speak ASP.NET and SharePoint for a minute because I was recently reading something that really struck a chord with me as I’ve been experiencing a lot of it lately.  I was reading this article on The Daily WTF today, mainly because I had just submitted an item for their Code Snippet of the Date (CodeSOD) section.  For those of you who don’t know The Daily WTF and CodeSOD contain articles about real issues developers and IT professionals encounter on a daily basis.  I was reading this article on “Spaced Out” and I came across a comment by someone named Captain Kirk

As a customer your choices are:

1. Hire an experienced competent developer who understands the library functions, knows how to write properly structured code with appropriate variable scope and data types, or

2. Hire someone who will produce what appears to be exactly the same output.

As a customer who doesn't happen to be a developer himself, the above two options translate as:

1. Hire an expensive expensive expensive who expensive the expensive expensive, knows how to write expensive expensive code with expensive expensive expensive and expensive expensive, or

2. Save a bunch of money and get exactly the same thing.

At this time I thought to myself, been there, done that.  I kept reading and came across this comment

Cpt Kirk: who are you? Why don't you put this in a blog and post a link to it so we can all share it? Seriously, the sarcasm & wit may have made my day, but the point is actually very insightful...

That second comment was enough to make me write this post.

Captain Kirk’s comment was sarcastic in nature, but he was echoing the sentiment of the mistake I’ve seen many of my customers make time and time again.  A project I was recently on made the same mistake, hence why I was at The Daily WTF in the first place :).  My goal here is to illustrate why you should care about code quality, and how the upfront cost never really translates to the bottom line.

Software never ends at version 1.0

Anyone who has ever designed, developed or used any piece of software knows that software is never done at version 1.0.  There will always be another version.  Users are inherently unhappy with any software that is delivered to them (including myself) and good software just takes longer for users to be unhappy about.  A sign of a good developer is his ability to isolate pieces of functionality into neat and tiny boxes.  Low quality code ALWAYS is the opposite of this.  Imagine you are in a large department store, like Macy’s, and you want to buy a white t-shirt.  The only problem is, this “department” store has no departments.  Everything is just thrown together all over the place.  Some on racks, some in boxes, etc.  How much longer would it take you to find that white t-shirt?  The same issue applies to low quality code.  Anytime you need to make a bug fix or feature change/addition it’s going to take at least five times as long because the code is such a mess.  Something that seems like it should take 1 hour to fix could end up taking 2 weeks.  This same issue actually applies during development as well because we all know there are always bugs and changes before you even launch the first version.


Good developers also do another thing that bad developers don’t, they know how to write re-useable, centralized code.  This means that with bad developers you will get inconsistent behavior across your application because the same thing is done in different ways throughout the application.  Have you ever come across a sink where the hot water was on the right and the cold water was on the left?  This probably bothered you because the standard is to have the hot on the left, cold on the right.  When you are writing a custom application this inconsistency translates into bugs, and to compound the problem, when you fix these bugs you usually have to update the code in many places instead of just one.  So in many cases you can introduce more bugs by fixing the original ones.  In turn this results in longer development and test cycles.


This is a big one because most customers I come across don’t give this a thought.  They think that developers just build applications and they are going to work and respond well.  Good developers think about performance all the time, they don’t obsess over it, but it’s always in their mind.  Bad developers don’t even flirt with the topic, if they even understand the performance implications of what they are doing.  This means that unless your application is very small and for a very small set of users, you are going to spend a good amount of time at the end of your project doing performance tuning that you probably didn’t plan for.

Maintenance and Operations

Bad developers write the kind of code that your IT department loathes.  This is the application that is always breaking and causing them heartache.  In the long run this application is going to cost you a whole lot more to support and maintain then a well written one would.  Your users will have disdain for it as well, is that the kind of legacy you want to leave behind?

Get what you want

In the end the bad developers will probably satisfy the requirements, and they may or may not end up delivering the first version for cheaper than the good developers would have.  The reality is, you aren’t going to get what you want, they never are going to deliver more than expected and give you something that really blows people away.  Do you want something that just makes the grade, or do you want something that was better than you expected?  If you have a health problem and are looking for a doctor, do you look for the cheapest one that does what you need?  Or do you look for the one that will do the best job?


Writing this may not have any impact, but it did make me feel a little better :).  If I save just one project manager from this mistake then it was worth it.  Happy coding!

Comments (13)

  1. How will you distiguish between a good developer and a bad developer? It is very hard to hire a good developer because there is no good matrix to guide you there.

    The problem in my eyes is that with modern languages and frameworks, it is easier than before to write small programs. The issue is that more and more people claim to be developers because they know how to write simple "hello, world" type applications.


  2. Josh says:

    I completely agree with you there, it is very difficult to find a good developer to hire.  This is especially true if you don’t have any already on staff to interview candidates.  The point I was trying to make was the idea that just because a resource is cheaper doesn’t mean you will get the same output, even if it looks the same in the end.  My experience has been that no matter how much you pay you can get a good or bad developer, but when you pay more the ratio of good to bad is much better.

    I don’t know if I agree with you on the modern frameworks.  I remember writing BASIC programs years ago, it was pretty easy.  I think the problem is that as we have evolved in technology the need has increased faster than there were people available to do the job right.  Just knowing more than the people around you is usually enough to get you the job, but you might not truly have the skills to get it done.

  3. Jai says:

    I also tried to look at the same thing but from a different perspective:


    Truly, there is no equivalence between “cheap” and “bad quality”, as well as between “expensive” and “good quality”. Better start looking more from quality perspective rather than saving few pennies, I hope that is the point you are trying to make here.

  4. Sean says:

    While I agree with everything that you said, it’s interesting to me that you wrote this article considering you do SharePoint development.

    SharePoint is the result of awful, awful development. The UI is consistent, the API is far from intuitive and the application is so grossly difficult to extend unless you’re doing just about everything in a custom web part (at which point, I have to ask myself why you’re using SharePoint, to begin with). Honestly, I think it’s the worst product to EVER come out of Microsoft.

  5. Josh says:


    I don’t see the relationship between good/bad development and SharePoint.  

    I think the biggest problem with SharePoint today is the way it is being forced as a solution for everything, when the reality is that is not what the product was designed for.  If your needs are a highly customized transactional system, then SharePoint is definitely not for you.  If your needs are team collaboration, dashboard like portal views, or WCM, then I think SharePoint fills that space very well.  Regardless of opinion, SharePoint is flying off the shelves, so to speak.  There is a huge demand and I’m trying to help my customers meet that demand which is the main reason I author this blog.

    I’d love to discuss some of the troubles you have had with extending SharePoint, I’m always looking for new topics to post about.

  6. Josh says:


    The exact point I’m trying to make is quality vs. price.  In my experience over the past few years, quality and price are very closely related.  Not that all cheap developers are bad, and all expensive developers are good…not true at all.  The ratio of good/bad is much better when you pay a little bit more.  If you are looking for bottom of the barrel prices, you better have someone on staff that knows their stuff AND can interview, because there is a good possibility you will go through that many interviews before finding someone qualified.

  7. Andreas says:

    But you are aware that:



    -Maintenance and Operations

    are growing (often) towards the opposite of :

    Get what you want?

    So a good developper should keep that in balance right? Is it his responsibility(only)?

    I concur that it’s both the developer AND the requirements guy which need to understand and respect each other.

    Which reminds of another post i just read today..

    At the end off the day it seems that your statement is pretty obvious, but to realize that in a working company seems diffrent…

  8. Vadim Berman says:

    Captain Kirk should stick to USS Enterprise.

    Software written by cheap developers is as cheap and dirty as lead-painted toys and melamine milk: quality control is as important, and in some cases the results can be as harmful.

    Just like with any craft, it takes time to learn, and to improve. Just like with any craft, the skill always pays.

  9. Matt Smith says:

    I enjoyed this article and it has a lot of good points.  I hope too that at least one project manager reads this and makes the right decision.  Thanks.

  10. Aaron Smith says:

    This post does not make sense. I fail to comprehend in my mind why a developer who is cheap (money-wise), sucks in coding!! I have worked with a bunch of developers who were paid 60K/annum in my company and were literally rock stars. I think that is the baseline in which the world should go to. Companies should literally stop hiring developers for more than 60 – 70K/annum. Looks like the next 2 years our president is cracking down on the H1B’s. This sucks big time. During the recession how can companies take in native developers and pay them 100K?

    Thus a good developer does not necessarily mean he is expensive.

  11. Josh says:


    I would not consider 60k cheap.  I also know many people working in this salary range that are great at what they do.  My aim for cheap was more about contract labor, because that is where this type of decision is usually made.  Hiring someone for a contract job is much different than hiring someone permanently for a full time position.  In this situation the contracting house will usually charge 50-100$ an hour for the resource, but that person is probably seeing half of what their hourly rate is.  My personal opinion is that you can’t consistently hire good contract developers for less than $150 an hour.  I’m not saying they don’t exist, but they are few and far between.  If you are a project manager without a clue about the technology, and you don’t have anyone on staff that can do a good job interviewing, you better go for the higher priced resources.  If you don’t you’ll likely end up with a very low quality team.

  12. tj says:

    "If you lie to the computer, it will get you."

    Moral of the story

Skip to main content