IT Managers - Why bad programmers are expensive

Dear Mr./Ms. IT Manager,

As the former owner of a very successful software consulting firm, here are several "truths" that you should know about the real costs of employing bad software developers (programmers):

  1. Crappy developers (poor quality programmers) cost you time and money. Why?
    1. Poor developers are slow.
    2. The quality of their code is crappy.
    3. Eventually someone is going to have to fix that code, or, at best, you have to keep restarting things and baby-sitting them all the time. This means (a) you're paying for the code to be created more than once, (b) you can't make forward progress at great speeds because you're always back-tracking to fix problems.
    4. In the words of a Fortune 500 CTO friend of mine, you can't "institutionalize" poor quality code.
  2. Doing things the wrong way costs you time and money.
    1. Don't have a quality build process? How can you possibly know what's in Production? Does it work? Has it been tested?
  3. Poor-quality software costs you time and money.
    1. Once again, you can't "institutionalize" poor quality code, so you end up baby-sitting your "semi-automatic" processes, and that's more labor. A great philosophy you should have is "automate everything."

That's my rant for today. This comes from me not releasing a former employee long ago. I kept him on out of what I thought was the goodness of my heart, but now I see that our company has to pay the price for me being nice and generous to this person, who gave little back in return.

IT Managers: When it's your money or your reputation, and you see someone not doing a good job, you can only blame yourself for not trying to correct that behavior, or, to put it nicely, move on. The person I'm referring to was actually quite an average software developer ... but there's no place for "average" when you're reaching for excellence. And when that person is gone and you're baby-sitting their crap, you'll really know what I mean.

2009 Update

An employee leaves a company, and writes on Facebook, "Holy crap, that is some of the most unmaintainable code I've ever written. Thank goodness I'm out of there and don't have to deal with it any more."

(Um, dude, you were *paid* by your employer to write good code ... you wanna give some of that money back?)



Well, you may be right. I am forced to wonder why the employee was still a bad programmer after "...long ago...". I haven't met many bad programmers, as much as I have met "better than before" programmers. If you're really serious about the trade, you must help your coworkers become better, because you depend upon them helping you become better. This is what I learned from code review.

"...but there's no place for "average" when you're reaching for excellence..." Well, a journey of a 1000 miles starts with a single step. I worked very hard to become ""average", and I have continued to try to improve my skills as best I can. Actually, I want to live in a world where as I become better and better at my craft, I remain "average". (i.e., I want to be very, very good, not just better than all my peers)

All this said, if someone doesn't care about growing in their field, they are in the wrong field. Letting them keep the golden handcuffs and stay in the wrong place is not a favor.

Thanks for your comments. In a lot of ways I regret writing this article, and I may remove it from here. It might have been more helpful if I could have included some of the code this particular person wrote.

Some of the problem also lies with me and the approach of my former company on certain projects. On smaller projects we often let one person completely handle a project without any peer review, and that was one of the problems here. When I finally looked at the code on some projects this person worked on, it was (in my opinion) very poorly written. I was upset when I wrote this post because I trusted this person, I gave them several opportunities to improve (at their request), and in the end I felt very let down.

I think you're last paragraph came very close to the point of this situation. This person wasn't growing any more as a programmer, and in fact had their eyes on a career in project management.


How about the outsourcing model, in which software development is shipped to another country of "low cost" workers? I've heard good stories where the outsource'ees are a small team, but when sent to large companies (eg, India) the quality is variable because the work is treated more like a farm commodity and there is often much turnover internally.

There the quality solution there seems to be wrapping the effort into a strong process-standardization methodology like CMMI and hoping for the best. While this may succeed, I've only heard about cases involving the first build, not subsequent maintenance unless there has been a continuous business arrangement with the outsourcer all along.

In this scenario, I'm guessing the code quality is neither good nor bad, but "factory grade". Maybe a cooking analogy is in order; in-house (home) cooks may be good or bad, likewise outsourced cooking (industrial factories or restaurants), but direct comparisons may be difficult. Bad home cooking vs. MacDonalds ISO 9001 burgers? You decide.



I think the lesson learned here is that there is a difference between having a systems-driven business and managing by adbication. You can't leave somebody on their own for an entire project and not communicate your expectations to them clearly and expect the get the results you were looking for. That is extremely frustrating for an employee as well - it's hard to grow when you don't know the standards you are being held to. :) But with that being said, if you give those expectations to somebody and they can't meet them, and no amount of training or trying helps, you may need to move on.