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.

Inconsistencies

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.

Performance

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!