We are late into a client project, and the codebase is significantly large if I might add. There are opposing arguments in the team.
My manager is all up for getting “new talent”, but I feel anybody who is not significantly senior in their role, would have to be given a primer to the codebase, and wait until they get a hang of it; which would waste consider amount of resources in terms of time.
I have heard and read many times that if there is a project that is past deadline, in the interest of rushing it out and finishing it - DECREASE the amount of individuals working on it. You'll get more done with 5 than 50!
Think of a race car. If you're trying to accelerate to win the race do you add weight to the car? You would probably cut off any excess weight you didn't need to make it as light as possible instead!
Compare coding with a group of people writing a word document. Can several people edit the same document at the same time? Yes. Can several people work on the same sentence at the same time? That probably won't help the sentence get written quicker. Different people can work on different paragraphs if the structure is outlined in a compatible way. It's going to be difficult for everyone to work on the same sentence though. Even a group of people working on the same paragraph can be challenging. There is a point where throwing more people at a problem won't help solve it.
Can't speak for anyone but myself, but as a Junior, I have to concur.
I recently joined a new job and got sent to a client, primarily for ticketting, until I was given a project to work on from scratch. I have to say, the codebase was quite big and most of all needlessly complex, and I had to take three days just to get a quick grasp at the code section on which I had to work (a single Symfony bundle with dependencies). The ticket itself took me barely half a day to resolve.
So basically I'd say it depends on factors such as the project, complexity of codebase, the amount of time you can spare to show him/her the code and answer his/her questions, and such. It also depends on the estimated time you will gain once this new person will be effective. So if you truly are in a hurry, and a big one, I'd say it's not worth it.
Bringing people into a project late isn't a problem as long as you ensure that you provide them with work that is focused. The more focused it is, the less they will need to learn to get up to speed. Simply adding more programmers and expecting things to happen faster can do more harm than good!
Edit: as an example, the last startup I worked with hired 3 intern programmers to "speed things up", however as the most experienced developer in the team I bore the responsibility of managing them, and ended up not doing very much programming. Ultimately not a lot got done as they constantly had questions (understandably) and by the time they got up to speed in any given area the time saved was mitigated by my time lost. Unfortunately I wasn't part of the decision process that lead to that, or I'd have nipped it in the bud and hired a single other more experienced developer instead.
Your boss talking about "new talent" sure sounds like he wants you to bring in a jr. developer as an innovation factor, to add the certain "something" to the project.
What I think is that he is wrong (don't tell him that, though...). Software, even when considering innovation and talent and fresh ideas, needs those things in advance and has to be well planned out. Good software is planned software. Whenever you just go 'n write stuff, it will, at some point, bite your a*s. We had some Facebook link here a few days ago which stated just that: Facebook has some 500 developers working on some 180000 classes just for the iOS app, which really is hardly more than a simple news-feed with comments. Instead of fixing the root of the problems, Facebook just throws more developers at the problem.
Don't be Facebook. Instead, program the stuff you planned the way you planned them. Don't go and get a new "talent" with their own ideas how to solve problems, who "hack their way and move fast". It's too late for that and it will result in problems. The only thing you might ever consider is a "code monkey": some person who implements stuff exactly the way you tell them to (without thinking about it).
What you might tell your boss, though, is that a new "talent" might be a good idea for a new project or once you released the current product and want to think about new features and improvements.
Historically it's been true and there is even a classic computer science text book called "The Mythical Man month".
I suggest every serious software engineer to read this book even though it's old it talks about Large Software projects and challenges involved.
Depends. It's more like chance! If that person is skilled enough, had experience in domain, then it is nothing and he can in fact help the team in huge way. Even if he doesn't have domain knowledge, it wouldn't be a problem as long as he is skilled.
But if that person is not skilled enough, and need some training or something, then yes, he is more of a burden then of help for the team.
Tommy Hodgins
CSS & Element Queries
Mev-Rael
Executive Product Leader & Mentor for High-End Influencers and Brands @ mevrael.com
You must have a:
If you don't have something, then it must be done before bringing a new engineer into the team or whole team's productivity will go down.
Nevertheless, fresh minds are always needed, otherwise, there wouldn't be seniors to come from and senior would't be able to grow if they will need to code full-time everything themselves. Fresh minds also may give you many good ideas.
To sum up:
It depends and there are always tradeoffs in any case.