Long story short, we've recently had a lot of work to do at my job and in order to fill that vacuum my boss has been hiring temporary workers. At first he hired three which stayed for about two months, but after the client moved up a deadline he hired one back recently.

I've been very cautious about delegating work to them as they've been making a huge mess of the code base and then when a push to production approaches I'm approached about making it workable. My boss is getting a little picky about this and made a comment to me about them being here to help, and I need to give them something to do. The problem is he's not a developer, so he doesn't have the perspective of what it can take to fix or patch together bad code; he only has the perspective that he's paying for them.

I wouldn't have a problem giving them things to do if I didn't know (as it's happened numerous times now) that in a few weeks they'll leave and when something breaks I'll be the one who's tasked to fix it in record time. The last time this happened a temporary spent almost two weeks writing out code that I was then expected to fix in one days time.

How do I convey this without seeming like a perfectionist who just wants to do it all himself?

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Oct 10, 2018 at 6:34
  • 3
    Are you involved in the hiring/vetting process? Do the new hires undergo technical tests? Are they actually temp workers or freelancers?
    – jcaron
    Commented Oct 10, 2018 at 11:24
  • Did you manage to fix 2 weeks worth of temp's code in one day? Commented Oct 10, 2018 at 12:01
  • 13
    If the manager isn't in software, what field is he in? Is it possible you can make an analogy that hits home for him better?
    – corsiKa
    Commented Oct 10, 2018 at 17:25
  • 3
    @mathreadler Complete and utter nonsense. Any boss worth his salt is capable of listening to his subordinates when they point out that a strategy is creating more problems than it solves and is ultimately increasing costs. Sure, there are terrible bosses, but that doesn't mean you don't even try to make them aware of the problem.
    – jpmc26
    Commented Oct 14, 2018 at 22:56

10 Answers 10


You might want to take some arguments from the book The Mythical Man-Month by Frederick Brooks. Although it was originally written back in 1975 (overhauled in 1995), it is still one of the most important works regarding management of software development teams.

It is most known for codifying Brooks's Law:

adding human resources to a late software project makes it later

The reasons are:

  • New developers must be taught about the existing architecture of the project before they can do something useful. This takes time away from the existing development team.
  • There is an upper bound to how many people will be able to make useful contributions to a software development project at the same time. It is often not possible to find reasonable sub-tasks to assign to new people.

Good software development requires a stable core team which works together from start to finish.

Your manager might not be aware of this rule. So he tries to help you in the only way he can think of: Add more people to your project.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Oct 13, 2018 at 22:55

The issue with temps and contractors (disclosure, I am one) is that there is often no comeback if the delivery is awful.

It may be worth having a chat with your boss about the quality of the temps. Hiring cheap means moving the costs further down the road, but eventually he'll be paying to fix the code.

You might also ask to be involved in the hiring process by providing a small coding test to make sure the temps are actually worth hiring. Nothing too dramatic, less than an hour of work to get an idea of ability.


What you wrote actually raises a number of red flags suggesting the only viable solution is changing your job. You wrote your manager ignores the importance and value of unit tests, I assume it's the same with the analysis and design as those misconceptions usually come in bundles. You also say that he thinks adding a temp dev for a month will bring anything else than a further delay. Apparently your manager has little idea how the software development project should be run and there are little to no chances that he's going to change his mind

Yet, you can try.

While a 9 women to deliver in a month is a popular way of "proving" that adding people doesn't necessarily expedite work it usually doesn't work on someone who is not into real understanding the problem but knows better instead. Rather than that use the example of digging a well.

Let's say you need to dig a well that is 1m in diameter and 15m deep. One man needs 15 hours to dig it. How many men will it take to do the task in 1h?

The answer most managers (and most people in general) will give you will be that it'll be 15 men but that's not true and it's simple to show to anyone who has no idea about the coding well digging at all. Just like in coding you can replace one digging person with another one. You can (to some level) share your work. But only one man fits in a hole 1m wide to work at all. If you add second person inside, the first one will be obstructed by them and won't be able to do their work.

You can expedite work a bit swapping an exhausted person with a fresh one so a second person will help a bit. It'll not be 1/2 of the time, a save will be probably no more than 1/3. But adding a third man most probably won't help a bit. The two will be exchanging every hour or so, having time to regain their stamina. So if you insist on using the third worker inside the hole, the only effect will be that you lose more time when they swap or simply more men are waiting for their turn, being paid but not bringing any extra value. No gain at best, a loss at worst.

So, you can use the third person on some auxiliary tasks, like removing the excess of dirt from the well neighbourhood. Fine, it adds maybe 5% time save for the cost of a full worker.

But how can you utilise a fourth man, not to mention another 11? If you really insist on using all of them, you'll start having additional costs like communication, time for swapping etc. So starting with the fourth man you're going to add only delays with no benefit at all and additional extensive cost of people.

And that's assuming all workers are skilled. What if digging a well requires an extra precision and you hire an untrained temp for that? You need to teach them so you'll spend the first hour on showing how to properly make well walls so that they do not fall apart and how to achieve that perfectly round shape. Then they'll be working at 50% of the trained man speed and their work will still not be perfect so the perm guy will have to do the fixes, losing some time of his work. In reality before the new person can bring anything but delays the well will be ready. And it will take longer than if the skilled worker digs alone. You can still use a temp for those auxiliary tasks or the simple ones (while I'm having a break dig in the middle, leave the walls untouched) but that's still 5, maybe 10% gain at best. And if the temp hits the wall the trained worker have to fix all that and it is no longer a gain at all.

And it's something as simple as swinging a spade. Coding is way more complex.

Summarise it with something like that:

It's obvious that you need to train a dev and 1 month is a minimum to make them run at the basic productivity level if they are skilled. During the training you need to invest time of one regular dev into the training and the work of temps has to be reviewed anyway so adding anyone to the team for less than 4-6 months is nothing but waste.

The other idea suggested you could be involved in the hiring process. That's a good advice to reduce the time of introducing a new person into the team and limiting number of errors in their code but it'll still require training (a lead in). So a temp, even a skilled one, for one month is a waste. At best, you can use them to write auxiliary things. Like unit tests ;-)

If your manager can't comprehend such comparison, your last option is to hit the job market again.

  • 13
    "Let's say you need to dig a well that is 1m in diameter and 15m deep. One man needs 15 hours to dig it. How many men will it take to do the task in 1h?" this in particular is fantastic, as unlike the overtly obvious pregnancy example, it provides the "gotcha!" angle that's synonymous with what's occurring with trying to hire more devs, so it's more cognitively relatable as a metaphor, in terms of providing that superficial "well it SHOULD work this way!" first impression. We use a "one month ramp up" for every position, even non devs, and even that ignores the cost to the rest of the team.
    – taswyn
    Commented Oct 10, 2018 at 19:40
  • 4
    The fun thing is that in many cultures this is a typical math question at the primary level with the accepted answer "1h". I think it might be the core source of later misconception that adding more resources always reduces time in a linear way. After all that's what they taught you in school!
    – Ister
    Commented Oct 11, 2018 at 7:02
  • 3
    "it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead." - Edsger W. Dijkstra
    – JimmyJames
    Commented Oct 11, 2018 at 13:45
  • 2
    The well example is probably better than you make it - one man has to dig, lift the spoil out the hole, and pile the spoil in a heap, two or three men the project naturally breaks down to complementary tasks (digging, lifting, piling) but adding more staff than the number of complementary tasks doesn't help - either you add a digger and they get in the way of each other, or you have people waiting around as the amount of spoil to lift or pile is not enough to keep them busy. Commented Oct 12, 2018 at 11:22
  • "You wrote your manager ignores the importance and value of unit tests..." Yeah, no. I've seen the garbage that passes for testing sometimes. Unit tests are not magic. If the person writing them is not both competent and experienced enough to recognize bad code without them, they'll be a net cost both initially and in the long run. Quit acting like they're a silver bullet and using pie in the sky approaches to talk about software development.
    – jpmc26
    Commented Oct 14, 2018 at 22:59

This ventures into general software development advice....

  1. If the code anyone writes breaks something add an automated test so that you can see it earlier next time.

  2. Review pull requests, don't merge anything until you're sure nothing else breaks.

  3. Tests make a good spec. TDD is a good way to ensure that what you're getting is what you want. Give someone a task to write the code you need (as exemplified by the tests you already wrote).

  4. Peer programming might be an option. You can correct things immediately and answer questions as things go on.

  • 18
    I'll also add to this excellent answer, that if they're writing code for 2 weeks without any reviews of what they're doing, then that needs to change. Give them tasks of 1-3 days and you can review and catch errors much earlier.
    – BenFreke
    Commented Oct 10, 2018 at 3:10
  • 5
    Not that this answer isn't correct, but given the OP's description of their workplace, I doubt that "testing" even enters the boss' vocabulary. And code reviews? OP's boss will only see money going down the drain... :-/
    – Aaron F
    Commented Oct 10, 2018 at 16:23
  • You're probably right. But at that point you need to talk to the boss and make it clear that hiring and letting go of temp workers will cost far more than doing things the right way.
    – xyious
    Commented Oct 10, 2018 at 16:30
  • This is the right answer, the problem is not the temp developers, the problem is lack of discipline and organization. @Aaron-f You don't need to tell your boss about your tests cases any more than about your variable names. You write code with tests, period. If it doesn't have tests, it is not finished. Best way to be sure that this is true: TDD Commented Oct 11, 2018 at 8:10
  • 1
    "Tests make a good spec. TDD is a good way to ensure that what you're getting is what you want." Categorically untrue because the people who determine the requirements most likely can't read them. Even then, the unit test code won't be any higher quality than the rest of the code someone writes, meaning that if you have a person who isn't competent, you'll get bad tests along with the bad code, which makes managing the code even more expensive.
    – jpmc26
    Commented Oct 14, 2018 at 23:07

How to approach boss that keeps hiring temp workers only to have me finish something?

You already have. All you can do is persevere with telling the boss.

Meanwhile there is a solution, the reason you're having to redo work is because you found out it was rubbish too late. You have an opportunity to practice some skills and take on more responsibility, but you're not doing it. It's not an esoteric problem, it's just a way of looking at a problem and resolution methodology. Well worth learning.

This is one of those times that micromanaging is critical. Assess the situation as a whole (including the people, they're a resource) and make a plan of resolution, use the manpower efficiently on those terms. This is the ONLY way to do it, you don't let even experienced people deviate from your plan, they don't have the full picture, you give them small tasks and check everything they do, they report to you at every step.

The most important bit is to understand the problem wholly and have a solid plan. Then break it up into simpler tasks wherever possible and don't rely on anyone to do their bit unsupervised.

  • 1
    Good answer -- OP managing resources in detail is the only real answer that accomplishes the desired business objectives.
    – Thomas W
    Commented Oct 14, 2018 at 23:49

If you can get away with logic arguments like the 9 months to make a baby analogy, that's great but, in my experience, this argument only works with people who already get it. And even when they do, it will often be followed with questions about what the optimal number of team members will be.

What might help if logic fails is to put together some data showing how work is actually getting done and focus on which people's work needs remediation. If you pull this together, you can show a pretty dramatic graph of who is actually adding to the output and who is detracting from it.

Part of the problem is that managers are under pressure to deliver and they need to show that they are doing something to make it happen. Doing nothing could make them look ineffectual and irrelevant. You can help with this by offering up some changes that your manager can make that will help (better machines, laptops, whiteboards, a build server, different hours, isolated work space, etc.)


The skill level of the temps is likely dependent upon the amount of money your manager is investing into them. As they are only temps he obviously doesn't want to be wasting too much funding. As you say your boss is not a developer and likely just assumes that a coder can code.

However, if it's increasing your work load in the long term and it's affecting your current work. You need to pull him for a 1x1 and just convey your issues and the reason that you are not delegating as much work down to them and your worries for the future if you do delegate work to them

You want to make sure you don't come across as if you're having a go at your boss but at the same time you need to get the message across as he doesn't understand what happens within development. If you simply mention that you would be happy to delegate the work but only when you feel safe to do so.


I find it useful to discuss a specific example. Take one case of something a temp did that took fixing by you. Describe the issue being worked on. Make a careful timeline of the events, showing when the temp got asked to work on it, how long the temp worked on it, when the problems were discovered, how the problems were fixed, and when the code was ready or at least back to usable. Compare with an estimate of how it would have worked with a stable development team. You can admit that you cherry-picked the example, but also have a list of many issues where this has transpired.

Now discuss your solution, which seems to be hiring a permanent addition to the staff. How long will it take to train this person (but you only do it once, not once per temp), how do the costs compare (as best you know), etc.

It sounds like your boss/company is not understanding that there is too much work for you to do. Hiring temps makes sense when the overload is temporary, but is a very costly solution when the overload is permanent. You need to make this case.


The other answers are all very good. However, I would suggest another tack. If this is a recurring problem, then perhaps it is, as your manager seems to think, an indication that your workload is too high for his expectations to be met by you alone.

You're pointing out that his solution to this doesn't work, and you may very well need to explain to him why. The other answers cover most of the possible arguments you could make in this regard. But if you want to see a change, the best way to accomplish that is generally to suggest your own alternative solution.

Maybe instead of continuing to hire temp workers, he might consider a permanent addition to the team. If you are actually willing to delegate tasks, but can't because the code quality isn't up to par, then that's the part you need to fix. However, if you want someone to invest in learning your architecture and coding style, they need to have some expectation that investment will pay off. A permanent addition to the team does come with additional costs, but the improved quality of their contribution and the reduced need for supervision/rework can easily pay for itself in the long-term.


Unit tests

This answer suggests that you should write unit tests and have them code to the tests. That's one approach, but it leaves your job as writing unit tests. That may not be what you want. And to get best results, you have to write great, comprehensive tests and have good developers. Because tests control the outcome rather than the process. It's entirely possible to write lousy (hard to maintain and modify) code that passes tests.

Another approach is to switch things around. Instead of you writing tests, have the other developers write the tests. You continue writing the code that you were going to write anyway. If it passes the tests, great. If it doesn't, you can then consider why. If the reason is that the test sucks (meaning that it doesn't match the actual requirements), delete the test. Anytime that you do that, record that decision.

You can also review the passing tests for usefulness as well. Again, if they aren't useful in codifying the requirements, delete them. Record the decision.

This relies on it being easier to review tests than code. So it is much easier to see if a developer can graduate from writing tests to code than to determine if the developer's code is good enough on its own.

At the end of the temporary developer's tenure, write up statistics on how many tests were useful versus deleted. That is then the information that you present to your boss when arguing against hiring more temps. Include how much time it took to review the tests versus how much time it would have taken to write the final test suite. If that number is net negative, then the company paid money for a "developer" to make your software worse. Even if it is net positive, compare the cost of the temp to what your cost would have been.

In my experience, bosses respond best to financial arguments with evidence. Without the evidence, they can reject the argument. With technical but not financial evidence, they won't necessarily understand the evidence (some may but many won't). So express any technical evidence in financial terms.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .