Hidden Costs of Cheap Mediocre Programmers

There are multiple reasons companies hire cheap programmers. Some of those reasons are valid but there’s one reason that’s not only invalid but also dangerous. That reason is hiring them just because they’re cheap.

During my career, I have personally inherited and took over a few codebases written by cheap mediocre programmers. The codebases were so bad they negatively affected productivity of the new teams for years.

Who Are Mediocre Programmers?

By mediocre programmers I don’t mean beginning programmers who are often called juniors.

What I mean are programmers who are just not smart or passionate enough to ever become good programmers.

And it’s not about experience. They might have a decade of programming experience but still be mediocre. I have personally seen real life examples of this.

And I have seen examples of relatively beginning programmers that had just a couple years of experience, but were already good.

To be a great programmer, one has to have a good combination of a set of personal traits. If a programmer misses one or two of those traits, they might be just good programmers. If they miss most or all of them, they will never ever go beyond mediocrity.

It’s like if you’re a midget, there’s a very very low chance of you becoming a great basketball player. Especially given the fact that the professional basketball industry is dominated by exceptionally tall individuals.

There are endless other activities a midget can become great at though. Just don’t get into an industry where your success greatly depends on a physical quality you don’t have.

It’s the same in programming, except what matters here is not your height but IQ and a bunch of other traits. And far from every wannabe programmer that got into the industry just because it’s the current gold rush is going to be better than just mediocre.

Is the Loss of Productivity Really That Bad?

Some people might think that years of lost productivity is an exaggeration, but when you inherit a project, you’re expected to keep delivering new features on top of the existing codebase instead of starting everything from scratch or just refactoring the system all day long.

And since now you’re part of a more expensive team, management expects your team to be even more productive than the previous one. That only makes sense, right? Right. Except it’s wrong.

Imagine inheriting a project with a few hundreds of thousands of lines of code written by programmers stuck on the first level of maturity.

Add to that a shitty MySQL database with 200 tables each with a ton of columns. And not a single fucking foreign key.

Add to that a messed up MongoDB database that takes great advantage of being fucking schemaless but only in the sense that the schema was never properly defined and hence you never fucking know what you’ll get when you iterate over a particular collection.

And of course integer values are persisted as strings and hence when you try to look up a user with ID 2315, you don’t find shit because it’s actually "2315".

Add to that the fact that there’s duplicated logic all over the codebase. And all the instances of that logic are supposed to be kept in sync when changing things. Except you have no idea of all those instances. So to even ensure that you find all the instances of a single piece of logic takes a few hours every single day.

Add to that the fact that the system is already in production which means you’re not supposed to break any existing functionality.

And of course you don’t find even a single automated test. Hence when you change things, you have to be extra careful and spend hours testing the whole thing to ensure you didn’t break something.

What makes things worse is that there’s a lot of dead code and database tables/columns. They were either added as failed experiments that never got released, or were never removed after removing or significantly rewriting a feature.

Add to that a complete lack of any well defined architecture. Often it’s just a LAMP stack with NodeJS slapped onto it for WebSocket support.

Add to that lack of any deployment automation. There are 20 virtual servers each configured manually. And they’re named like web01, web02, web03, etc. Looks fine at first sight,┬ábut then it turns out that each of those Web instances is special because it has a different set of cron jobs running.

And all these fuckups are just the tip of the iceberg. I could write an entire book on all the fuckups I’ve inherited that significantly slowed me down.

It’s Not That Cheap in the End

To business owners that hire cheap programmers, it doesn’t seem to be any different between hiring a $15/hour programmer or a $75/hour programmer except the fact that the former is cheaper and the latter is more expensive.

What I often see in practice though is that eventually business owners end up realizing that there’s a difference. It seems to happen when their cheap mediocre programmers hit a wall, get stuck, and can’t move any further.

They either introduce so many bugs with each release that it becomes scary to even request new features. And fixing a bug introduces 7 more.

Or they hit a skillset limitation and can’t solve any problem that goes beyond the simple CRUD pattern.

Or the scalability of the system is so poor, the whole thing falls apart as soon as there are more than one users hitting the system at the same second.

That’s when business owners realize they need a more experienced and more expensive team of real professionals that will solve all those problems.

And they will. Except it’s gonna cost much more than it would have if a more experienced team started the project from scratch.

Imagine a very fucked up system being inherited by a 5 persons team each charging $75/hour. Now imagine that the current state of the project is going to slow that new team by 50% for the next 3-5 years.

Let’s do some math. 5 programmers. Each $75/hour. Each 40 hours a week. 3 years of unfucking the codebase. 50% reduction of productivity.

That’s $15K a week for the whole team. $2.34M in 3 years. $1.17M in lost productivity.

Now let’s do the math on the cost of the first 2 years of development by the initial mediocre team. It’s the same setup except each programmer charged $15/hour.

That’s $3K a week for the whole team. $312K in 2 years.

So the whole 5 years of development by both teams would be $2.65M.

Now, if the experienced team started the project from scratch, they would’ve probably came to the same result in 2.5 years. And that would’ve been $1.95M.

That’s $700K of wasted money. And what’s more important, it’s 2.5 years of wasted time.

Of course, these numbers are not exact and there are many different variables that go into the equation. Examples of those variables are time to market, ROI, missed opportunities, etc.

Another very unfair moment of all this situation is that the great team that inherits a fucked up system gets blamed for not delivering fast enough. It goes like “Hey, you guys cost 5 times more than the previous team but you’re not that much more productive”. Fuck yeah they’re not, you cheapass.

It Doesn’t Have to Be Black or White

In reality, you don’t necessarily need a whole team of great programmers.

A great combo would be a single great architect/programmer and a few good programmers.

If you can’t find enough good programmers, a team of 5 programmers can have one or two juniors.

So an ideal team of 5 programmers would be 1 rockstar, 2-3 good ones, and 1-2 promising juniors.

It’s important to have promising juniors because you don’t want even a single mediocre programmer on a team.

There are many promising juniors out there. They might have a year or two of experience, but they’re smart and passionate enough to one day become good or even great.

Conclusion

When you can’t fill a team with great or good programmers, it’s perfectly okay to have one or two cheaper but promising juniors. With proper mentoring and nurturing, they will evolve and become a valuable asset to your company.

But don’t, just don’t, hire cheap mediocre programmers just because they’re cheap. It will end up costing you much more in the end.

Published by

Elnur Abdurrakhimov

Elnur Abdurrakhimov is a software architect and developer with over a decade of real world experience.