How do I make the case for expensive programmers?

Question

In our company, we need to do many seemingly not complicated things, like develop Mobile UI.

Let's say the experienced programmers costs us 4x as much as the beginners.

Both are basically able to complete the seemingly simple things in the same amount of time.

The difference is, that the experienced programmers produce fewer bugs and their code is more stable etc. The beginner programmers waste a lot of time of everybody else (PM, clients, etc.). But they are significantly cheaper.

The counter argument is, that it takes experienced and beginner the same amount of time to make a table in HTML. Therefore, it is luxury to hire experienced programmers to do, what beginner programmers may be able to achieve as well.

Should we invest in more and better programmers or more and better PM, given that the difference between experienced and new programmer in our field can be 4x.

Answer 1

I have first hand experience of both theories being tried out in the real world - in the same project actually.

Before I arrived, the decision had been made to hire more expensive BAs and very cheap programmers - the idea was to have good quality specifications being followed slavishly by very junior programmers.

After 6+ months of the main project thrashing around I took over as development manager. Once I'd fixed a few hygiene factors, the problem of code quality remained. I had some spare budget and hired a very experienced programmer (well, more of a Solution Architect) with off-the-charts communication skills and a former life as a trainer in C# (the language the project was written in). The idea was to improve the quality of the other coders by providing mentoring and effectively free training.

After a month or two it became painfully obvious that even that wasn't going to work so the original team were removed from the project and a couple more top-drawer programmers were added. They delivered the project that the original team had completely failed to deliver in 8+ months of trying in 3 one month sprints starting from scratch because the original code was irredemable.

If your requirements are very basic you may be able to get away with using a very junior programmer, but the likelihood is they will cost a lot more in the long run. Sometimes "simple" requirements evolve into great complexity.

If I hadn't made the hard choice to change direction, they'd probably still be working on it :) - More seriously, in this example, lack of communications and competence by the original team meant they wouldn't raise issues with the specification but would just try to do whatever they were asked to do whether it made sense architecturally or not. A more experenced and confident developer asked questions and dug in to the underlying requirements and therefore ended up producing the right solution first time.

Oh, one other thing. Don't assume you can immediately hire a great programmer. There are a lot of folk out there with many years experience of mediocrity that will provide almost as bad an outcome as a junior but will cost the same as a superstar (sometimes even more). I have a very good "hit rate" but that comes with experience and I have a lot. That's the subject of a whole different conversation which is off-topic here...

TL;DR Good programmers are a bargain. The hard bit is finding them and creating an attractive enough work environment to keep them.

Answer 2

If you have extensive performance stats, you can make the business case with math. These could show that development speed would compensate the increase in price, or even better, that a robust design could save more in maintenance and development of subsequent versions. Unfortunately such figures aren't available that often - especially for newer technologies.

Another argument can be time to market. This is more easily understood by upper management. However if time is not really critical, this won't help.

In last resort, find a picture of Red Adair, the famous firefighter, who was called in in a major disaster after several unsuccessful attempts of less experienced guys. His famous quote:

If you think it's expensive to hire a professional, wait until you've hired an amateur.

...deserves to be printed in color and displayed prominently on your office door, so that everybody understands what it's all about ;-)

Answer 3

I like and upvoted mcottle's answer, but I want to cover some other dynamics and arguments that the other answers haven't yet brought up.

First, implicit in mcottle's answer is the fact that below a certain skill level, some problems are just impossible. Unfortunately, the way you find this out is by your team trying and failing, which is very expensive. After failing, there are two possible lessons to learn from this. One option is you learn that you need more competent developers and so you hire them and you complete the project significantly over-budget and over-schedule, but at least you're prepared in the future. The other option is that such a project is "too hard" for your team and such things shouldn't be attempted in the future, i.e. you give up on the project and effectively any similar ones. Of course, it will rarely be phrased as "we're too dumb to do this", but instead will be rationalized as "our systems are very complex" or "we have a lot of legacy code" or some others. This latter view can significantly warp a company's perspective on what's possible and how long/expensive development should be. "If it takes a year to fail to do X, maybe six months to do the much simpler Y is reasonable."

One question is, what exactly is your company's plan? Okay, they'll hire cheap, junior programmers. Three years pass, now what? What do they do with developer that's been with them throughout those three years? Did they just never give him/her a raise? The options here are the following:

• They give raises competitively to retain employees, in which case why would they have a problem paying senior developer rates now? I'll return to this though.
• They have stagnant rates which means they are eventually going to "boil down" to employees which lack drive and/or skill.
• They more actively remove more senior employees.

The second two cases imply a lot of employee turn-over which means loss of company knowledge and paying to ramp-up employees continuously. In the second case, you are essentially selecting for bad developers and so costs will rise in the form of increasing schedules. The way this will play out is everything is going fine on project X until suddenly Jim leaves, who was one of the better developers, because he hasn't gotten an raise in two years, now the project will "understandably" take significantly longer as you need to hire and train new junior developers who (presumably) won't be as good as Jim was. This is how you recalibrate expectations.

Even in the case that competitive raises are being provided, if all you have are junior developers where and how are they supposed to learn? You're basically hoping that one of them will learn good practices on their own in spite of their work environment, and eventually mentor others (as opposed to leaving for greener pastures). It would make a lot more sense to "prime the pump" with some good developers. More likely you'll develop a culture of Expert Beginners. The result is that you'll end up paying senior developer rates to people who are only slightly better than junior developers and are culturally toxic.

One benefit of, particularly, very good developers, that I'm surprised no one else has mentioned is they can readily be a multiplicative factor. It may well be the case that a junior developer and a senior developer take the same amount of time to make a table. However, a good developer won't do that. They'll make a table generator that reduces the time for everyone to make a table. Alternatively/additionally, they'll raise the ceiling of what's possible for everyone. For example, the developers who implemented Google's MapReduce framework were likely extremely qualified, but even if the users of MapReduce are utterly unable to make a massively distributed version of their algorithm on their own, they now easily can with MapReduce. Oftentimes this dynamic is less blatant. For example, better source control, testing, and deployment practices make everyone better, but it can be harder to trace to a specific person.

To argue the other side for a bit, maybe the higher-ups are right. Maybe more experienced developers aren't necessary. If that's the case, though, it would seem that development isn't a significant part of the company. In that case, I would just eliminate developers entirely and use off-the-shelf software or hire contractors on demand. It might be worth exploring why they don't just use contractors rather than an in-house team. If you're going to have a lot of employee churn anyway, then ramping-up contractors shouldn't be a problem.

Answer 4

This is not an either/or situation.

Especially on a larger project, you pretty routinely have a few relatively experienced people in senior roles, and a number of less experienced people in junior roles. This way the senior people can not only help directly on the project by writing code and helping make the harder decisions, but they can also help indirectly by mentoring the juniors.

With some care, this can also help prevent the senior engineers from burning out quickly by being asked to constantly do work that lacks challenge or interest for them. At least in my experience, even a little time mentoring some enthused junior-level (or even intern-level) people can make a sprint a lot more interesting.

In fairness, I should add that this sort of position probably isn't going to fit all senior engineers. It requires a greatly increased emphasis on architecture and design, communication, documentation, and so on. Especially early on, it also frequently requires a lot of discipline--for somebody who's made a career of writing code, it's tempting to just jump in write the code, rather than teach a junior engineer how to do it. It's also frequently tempting to do a complete rewrite from the ground up when code isn't how you'd personally prefer it--even if it is perfectly adequate for the job.

If, however, you really can't convince management to go with a mixture of experience levels, there's basically no question at all that you have to go for more experience. If you leave a project entirely to junior personnel, chances are pretty good that you'll simply never get a usable product at all. Worse, they won't realize that what they're doing isn't providing any real progress toward a usable product, so they'll continue working in a chosen direction long after a more experienced person would have realized that they'd made a fundamental mistake early on, and need to back up, regroup, take their bearings, and start off in a new direction to have any hope of arriving at a meaningful destination.

Answer 5

Any real-world project is driven by customer demand, and therefore involves tasks which are low complexity (e.g. building CRUD forms), and high complexity (e.g. building an event-driven notification system). The only way to have only low complexity tasks is to repeatedly tell customers the word "no", which no sales department I've ever heard of is willing to do.

If you have only junior-level developers it means you will only be able to do the low complexity tasks, and therefore only able to build a low value product and struggle harder in the market to differentiate your products. If you want to differentiate, you need to build high value functionality, which inevitably translates into high complexity tasks. After all, if it was easy it would not be valuable. That means you need people to execute those high complexity tasks and you need senior level developers.

If you have only senior-level developers, you will waste their skills on low-value work, have trouble retaining them when forcing them to do said work, as well as risking them going off into architecture astronomy land in trying to make simple tasks more interesting to work on. This means you need to also have some inexperienced developers to pick up those tasks.

A healthy team working on customer-driven products is usually a mix. The ratio between junior and senior developers depends on the ratio between low complexity and high complexity tasks, and that depends on your business strategy. If you actively seek out large volumes of low-margin easily understood cookie cutter work, you will not have many high complexity tasks and will probably hire mostly junior-level developers. If you actively seek to differentiate and target underserved niches at higher profit margins, you will have many high complexity tasks and seek out mostly senior-level developers.

Answer 6

In my answer I'll argue senior programmers don't necessarily code faster than junior developers. In fact, the fastest programmers are on average guys who just left university.

Domain knowledge is a key to senior developer. A good senior developer should have strong knowledge of the field, something that junior developer might not have. Experienced developers understand the problem, what to solve and how to solve it. They can solve more complicated problem for the business than most junior developers.

Programming is relatively a cheap skill set, it's the expert knowledge that counts.

Answer 7

Don't try to 'make the case' The market sets the price for employees. If the market is willing to pay 4x more for experience then its because companies as a whole have worked out that there is a 4x productivity increase.

Now obviously the market could be wrong, maybe its 3.5 or 5x but unless you are a digital agency, competing against the market or something such nuances are unimportant.

Your real problem is Are you good enough at interviewing to be able to distinguish between a good experienced dev and just an old dev who is blagging it.

Your second question of PM vs Developer budget. I would say that a developer can do without a PM but a PM cant do without a developer. Get your development engine sorted first, then get a PM to take the admin off thier hands.

Answer 8

You won't find anyone in your own country for a quarter the cost of a really good developer. You may find someone for half the salary, and that will be an absolute beginner. For someone at a quarter of the salary, you need to go outside the country, and then you will have problems with communications, people that blindly follow specifications, and all kinds of trouble.

You need one good developer. If you add more junior programmers, you need one good developer with strong communication skills, who is willing and capable of keeping an eye on the juniors. Without one good developer, you are lost. You may be lucky finding some extraordinary talented beginner, but once he or she figures out they are good, they will want a bigger salary.

If you don't have one good developer, you have nobody who sees the bigger picture, and nobody who can solve problems that can't be solved using stackoverflow. And you will have code that reeks and is unmaintainable, because junior developers don't know how to create maintainable code. They can learn it, but they won't without some good developer on the team.

Answer 9

There are a few hurdles your company would have to get over before you can decide if hiring better programmers would be cost effective. Sorry if I'm making some negative assumptions about where you work, but I'm not convinced they know what they're doing.

1. Have they accurately assessed how complex the software you build is? It sounds like they don't think what you're doing is very hard, so why hire better people? Have you made the case where mistakes are made and how better solutions and productivity would make money? Saving time is great, but many companies would rather waste an entire week's time of a programmer than give them the money to buy a mouse pad.
2. Is your company attractive to good programmers? Are they capable of identifying them? Nothing worse than hiring a Senior Dev, pay them more money and they drag the entire team down due to their lack of skills and/or leadership.
3. Can your company utilize a good programmer? If all they're going to do is throw shoddy specs at them and just tell them to just go build it, what's the point? Are they going to give them any freedom to do things their way? After all, a good programmer by definition knows how to better utilize her time. They impact those around them and cause other programmers to improve. They introduce better designs and architectures that the rest build on making the product that much better.

Sorry, but I feel like your company wouldn't know what to do with a good programmer, so you may want to convince them to hire better managers first and solve these internal problems.