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.

  • 18
    Experienced programmers will produce code more quickly and with fewer bugs, but they'll also get bored fast working on simple projects.
    – david25272
    Commented Mar 15, 2017 at 22:28
  • 18
    Let's say the experienced programmers costs us 4x as much as the beginners. -- That is unlikely. The ratio is more like 2x or 3x. If you're paying programmers that poorly, what you're really doing is hiring amateurs and training them to do the job you need, only to have them leave your company for greener pastures once they get a minimal amount of experience under their belt. Commented Mar 16, 2017 at 0:25
  • 4
    Both are basically able to complete the seemingly simple things in the same amount of time. -- Well, the experienced programmer saves substantial time in the long run because you didn't have to give him more specific instructions on exactly what to do. Commented Mar 16, 2017 at 0:25
  • 8
    @jules: In order to outsource/offshore, you have to write a very detailed specification, a process which could take as much time as experienced programmers would take just writing the actual program. Don't take my word for it, talk to anyone who's attempted offshoring. I have. Commented Mar 16, 2017 at 2:40
  • 2
    @Ewan: Please give an example of a large company that has left London in the last two years to find cheaper software developers elsewhere in the UK.
    – gnasher729
    Commented Mar 16, 2017 at 11:47

9 Answers 9


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.

  • 3
    I would swap "Experienced" with "Good" in your tl;dr for the reasons you point out just above it. Also, it's quite possible (but still difficult) to find good programmers with relatively little or no professional experience. I will admit though, that unlocking the potential of these developers does require grooming, and it's very likely that the OP's company doesn't have a suitable culture to do this. One benefit of having a great programmer is being a role model of good behaviors and practices and to contrast to mediocrity. Commented Mar 16, 2017 at 3:42
  • 1
    @Derek Elkins - Good suggestion, done. Agree with your second point. At one job I was extremely constrained for budget and still managed to assemble a very good team from one experienced incumbent programmer and 3 very junior programmers (no degrees, very little experience) as new hires - one of which was particularly exceptional. But I "spent" a lot of money going through some depressingly bad CVs before I found them and more time / money training them myself by pitching small tasks at the right level and letting them own their solutions and celebrating their achievements.
    – mcottle
    Commented Mar 16, 2017 at 3:54
  • Yeah, my experience is similar, though I find depressingly bad junior CVs much less depressing than interviewing a "senior" dev with 15 years SQL experience who doesn't know what an outer join is. There are some payoffs, though, of the training cost in terms of company fit, loyalty, generally improved morale, and, frankly, once they are trained up they are likely better and cheaper than a "typical" senior dev. It definitely is an investment though, and the time to payoff can often be too far out to be useful, even if it would otherwise be a net win. Commented Mar 16, 2017 at 4:47
  • Great post +1. I would just add the caveat that delivery time is a very blunt tool for assessing developer quality. We had a "superstar" contractor who was massively in demand initially due to his development speed. Once people tried to pick his stuff up, the wheels soon came off - hacks, hard coding, monolithic code, lack of unit tests - he was soon sent packing post haste...
    – Robbie Dee
    Commented Mar 16, 2017 at 13:11
  • Furthermore, premium developers spend far less time coding than their juniors as they're heavily in demand for the assistance in helping others, code reviews, architecture, devops, brown bag sessions, workshops, training etc etc.
    – Robbie Dee
    Commented Mar 17, 2017 at 14:19

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 ;-)

  • I think this is the best answer I've seen and since there are a lot of answers already, I'll add that the value of a senior professional developer is not to do the same repetitive thing with less errors. The idea is to get someone who can eliminate repetitive work and raise the level of abstraction and to mentor and guide junior team members. We need more mixing of senior and junior people in development in order to get out of the constant recycling of old bad ideas that don't work in the long run.
    – JimmyJames
    Commented Mar 16, 2017 at 14:31
  • I think the search for easy to assemble stats to assess developer quality was called off long ago be it lines of code, number of defects, cyclomatic complexity, code coverage or whatever. The golden goose is a predictor for the right mix of developers that can be assembled for the least cost to produce good enough product.
    – Robbie Dee
    Commented Mar 16, 2017 at 15:03
  • @RobbieDee There is no need of a perfect model: just a pragmatic approach. For example, If you estimate systematically the story points corresponding to development tasks, the implementation time and the seniority level of developper in charge, you will over the time collect very interesting averages. Of course these stats will be relevant only for estimating similar activities with same technology. And they are only averages and not a crystal bowl. But you may get data that helps to show the trend and justify the seniority price ratios.
    – Christophe
    Commented Mar 16, 2017 at 18:45
  • @Christophe Story points are for comparing the complexity of one task against another - they're not designed for measuring time although they are massively abused that way (2pts = 1 day etc).
    – Robbie Dee
    Commented Mar 17, 2017 at 14:07
  • @RobbieDee that's my point: if you want performance stats you need to compare task performance time and task complexity. All the difficulty is to get an accurate evaluation of complexity. The stat is feasible in practice only if you can easily get an approximation. If FP is used it's very accurate. But FP evaluation is time consuming and not very agile friendly. Story points are less objective but they are easier to get. Of course, you are right: you need to linearize the scale if you want to make averages. In project management this approach is called "parametric estimating".
    – Christophe
    Commented Mar 17, 2017 at 17:54

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.

  • Contractor might be a very viable answer to this OP if they need the skill levels of a senior but cannot afford a full-year, full-time salary of one. Find a local contracting company that is trustworthy. I'd say the contractor idea should be expanded into its own answer.
    – rwong
    Commented Mar 16, 2017 at 7:35

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.


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.


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.


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.

  • Although this could be correct in the economic sense, markets in isolated areas e.g. small towns, rural areas, could be very skewed. University towns might be better.
    – rwong
    Commented Mar 16, 2017 at 7:33
  • true, but your business is in a place.
    – Ewan
    Commented Mar 16, 2017 at 8:40

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.