Why does adding more people to a late project make it later?

Question

It's a fairly common adage that adding more programmers to a late project will make matters worse. Why is this?

The term for this is Brooks's Law (http://en.wikipedia.org/wiki/Brooks's_law). — Macneil, Oct 26 '10 at 22:55
Advice: read Brooks' "The Mythical Man-Month". This will show where that adage comes from, it's a very readable book, and everybody in the field should read it anyway. — David Thornley, Oct 27 '10 at 15:12
For evidence of how productivity decreases with team size (beyond 7 team members you get into diminishing returns), see http://www.qsm.com/process_improvement_01.html — Joeri Sebrechts, Jun 27 '13 at 13:21
Adding more new people to the project. People who have no previous knowledge of the project, so they have to be taught. — Thorbjørn Ravn Andersen, Apr 23 '22 at 09:25

score 37 · Accepted Answer · edited Jun 16 '20 at 10:01

37

Introduction overhead

Each new developer has to be introduced to the code base and development process which takes not only the new person's time but also requires assistance from [a] senior developer[s] (guiding them through the build process, explain the testing process, help them with pitfalls in the code base, much more detailed code reviews, etc).

Therefore, the more new developers you add to the project the more time has to be spent to bring them to a point where they can actually contribute to the project.

edited Jun 16 '20 at 10:01

Community

1

answered Oct 26 '10 at 22:23

Baelnorn

816

So if you optimise 'Introduction' then the impact will be lessened? – Henry Oct 26 '10 at 22:58
9

@Henry: the problem is that you usually can't optimize that aspect to a degree where it's not the bottleneck. A new programmer at first knows exactly 0 about your project, your code and your processes. It's the same overhead that's always required when adding a new team member. But when a project is already running late the team often doesn't have the time to do a proper introduction, and if it does that time is missing from the actual development. Therefore it's usually a lose-lose situation for the team and the new person takes much longer until he can contribute meaningfully to the project. – Baelnorn Oct 26 '10 at 23:07
Regarding the cost of doing an introduction, can't it be video-taped once and then broadcast to many, so that it can train a large number of new programmers at once? (Examples: developer meetings or conferences.) – rwong Oct 27 '10 at 05:11
8

@rwong: It's not a bad idea, but this usually isn't practical. You can't just present the information, you have to make sure the new guys understand it. Plus, if they're really new (recent grads), there's usually too much information to present to them all at once. We've found that a wiki works well, as all the information is in one spot, and people can post questions if there are bits they don't understand. – TMN Oct 27 '10 at 12:05
One possibility is to assign a very competent new person, and have them do specific tasks without bothering the others. They will flounder badly and work slowly, and some managers and/or teams can't stand to see this. However, the new developer can be a net plus when managed that way. – David Thornley Oct 27 '10 at 15:11
@rwong: Your understanding of a codebase is very personal. You need to tailor the explanation to the person. If you try to cover all bases in a video, over 50% of it is going to be irrelevant for every viewer, and they're going to end up bored and distracted because of it. Presentations work for introducing theoretical concepts and example applications, but not specific experience about a particular codebase. – Flater Oct 25 '19 at 06:27
@DavidThornley: The floundering takes time to find and correct, which takes time from someone who knows the codebase (who otherwise would be developing). Yes, you could in theory let the rookies figure it all out themselves, but the scenario here is a project where you're already pressed for time and letting inexperienced coders figure it all out themselves is going to take longer than your acceptable deadline is. – Flater Oct 25 '19 at 06:29
@rwong, part of the problem is in assuming the knowledge transfer occurs just in the form of an existing programmer showing how in a very mechanical way. The reality is that most programmers aren't experienced educators, and on video they can't answer questions that haven't yet been asked. Also, the video would have to be constantly updated as the codebase changed (same as any documentation) - you might find this aspect of maintaining the training video actually took more senior time than just training new staff directly. – Steve Apr 22 '22 at 16:40
Yes, someone who is very good and can be given isolated tasks can be a net gain to the team immediately. Also depends on the state of the project. I had projects where the build/run instructions were “press command-b to build, press command-r to run”. That said, the value is still likely less than that person’s salary. – gnasher729 Apr 24 '22 at 10:10

score 33 · Answer 2 · answered Oct 26 '10 at 22:40

33

In addition to the other answers: Another factor to consider is communication.

The worst case for the amount of communication channels on a team (which isn't uncommon), is a complete graph. As you can imagine, adding in just 1 developer can increase the communication channels a lot. With more streamlined methods of communication, the impact is less... but it still adds up.

answered Oct 26 '10 at 22:40

Steven Evers

28,180

I was writing just the same at about the same time! but I didn't new it had a name (a complet graph) and your explanation is better, so there goes my vote. – Miguel Veloso Oct 26 '10 at 22:45
+1. Agreed, this is the biggest problem when adding more team members. – Martin Wickman Oct 27 '10 at 07:47
+1 for the more long term problem with adding people to a project. – indyK1ng Oct 27 '10 at 13:48
1

To my understanding this is why stand-up meetings have been introduced. Everyone hears everyone elses status in a very short timeframe, saving a lot of communication. – Thorbjørn Ravn Andersen Apr 23 '22 at 09:26

score 26 · Answer 3 · answered Oct 27 '10 at 03:48

The problem cited in the book the originally promulgated this law, The Mythical Man-Month, is communication. He starts off by saying:

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.

He does mention training as part of the problem:

The added burden of communication is made up of two parts: training and intercommunication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the work varies linearly with the number of workers.

...but notes that intercommunication is by far the larger factor:

Since software construction is inherently a systems effort -- an exercise in complex interrelationships--communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men lengthens, not shortens, the schedule.

It's also worth noting that Fred Brooks (the author) does have the background to know what he's talking about. Most of the book is based on his experience managing IBM's OS/360 project. Despite decades of adherents preaching all manner of "improved" management methods, and some even coming up with cool names (eXtreme, Agile, Scrum, etc.) when you get down to it, little of essence¹ seems to have changed since.

¹For the definition of "essence", see the same author's "No Silver Bullet: Essence and Accident in Software Engineering", included in the 20^th Anniversary Edition of The Mythical Man-Month.

John · Answer 4 · 2010-10-27T20:10:10.953

12

It's not merely adage; it's verifiable. Check out Brooks' The Mythical Man-Month.

edited Oct 27 '10 at 20:10

answered Oct 26 '10 at 22:21

John

1,037

1

It is an adage. It may or not be verifiable, but that does not stop it being an adage. – Peter Boughton Oct 26 '10 at 22:42
3

I don't have this book (obviously). Is this backed up by hard numbers or is it anecdotal? – Henry Oct 26 '10 at 22:59
2

@Henry: It's been a while since I read it but IIRC, both are present in sufficient quantity to make the point conclusively. – Steven Evers Oct 27 '10 at 00:07
@Peter: Edited my answer. – John Oct 27 '10 at 20:10
@PeterBoughton It is an adage. Also, it's not merely an adage. – SantiBailors Mar 09 '18 at 12:53

score 6 · Answer 5 · answered Oct 26 '10 at 22:24

Here are some thoughts on this issue ...

Need to use current resources to bring the new resources up to speed on what's going on with the project.
New resource might not be familiar with the code base, thus required more time to get acclimated to the code.

now, adding new resources for testing might not be a bad idea ... it might speed up the testing process (if your test cases are well written), and yes using testing tools will help too.

+1 for adding resources to testing, not development. – Baelnorn Oct 26 '10 at 22:29 — Baelnorn, Oct 26 '10 at 22:29

JohnFx · Answer 6 · 2022-04-22T15:22:59.350

Fred Brooks wrote an entire book "The Mythical Man-Month" answering this question.

Here's the quick-n-dirty version:

There is a limit to how much you can break a project out into distinct pieces to assign to more programmers.
Splitting a project out to more people increases the amount of communication required to coordinate all the parts of the application. More communication = More Work.
For every person you add to the project you add more than one communication channel that must be navigated to the team. This number grows geometrically and increases the amount of communication that must happen. More communication = More work.
There is a "J-Curve" when you add each team member. That is, the existing productive resources have to spend time getting the new people up to speed that they otherwise could have spent working on the project. Ultimately you may increase capacity, but it temporarily slows down the project. The later in the project the more that must be learned, thus the more pronounced the effect. Also, there is less time remaining in the project to reap the benefits of the newly trained resources.

score 4 · Answer 7 · answered Oct 26 '10 at 22:27

4

Because programming is not basic production line work. Getting up to speed on a software project takes time. New people need to ask lots of questions which leads to negative productivity (ie New person learning, old person teaching them -> no actual work getting done).

To simplify it, imagine a relatively simple one-man project which is scheduled to go for 1 week: on Thursday, you realise that it won't get done on time, that it would take the one programmer more like 6-7 days instead of 5. If you add another programmer at that point, they'll need to workn with programmer1 for at least a few hour or a day or so, ask lots of questions to get up to speed, etc. You probably won't get any net positive productivity for the rest of the week. The new programmer is likely to introduce some extra bugs too (since they won't know the existing code as well as programmer1), so that'll blow out the implementation and testing cycle by another day or two more. The project will easily last a full two working weeks instead of the original one! - And most likely longer than if the first programmer was simply given a couple of extra days to finish it themselves.

answered Oct 26 '10 at 22:27

Bobby Tables

20,576

Well, your example is a little contrived by the unrealistic short deadline left to the project. Change it to one month and you will see that it is not necessary true. Personally I think the quote was abused. It is true when considering run-of-the-mill, average/poor programmer. If you have good programmer, and the deadline is not something unrealistic like 1 day or 1 week, then the quote is wrong: it can be done (help the project). – n1ckp Oct 27 '10 at 04:30
@n1ck Its a generalisation - like "too many cooks" - the key point is that simply throwing manpower at the project won't necessarily cause it to be resolved any faster. 1 person to 2? Probably will. 2 to 4? Too many variables - it depends on the size and structure of the project. 4 -> 8? Definitely getting marginal (at the very least in terms of return on cost). – Murph Oct 27 '10 at 09:04
@Murph: you seems to be thinking mostly the same things as me but you forgot one very important variable in your equation: skill level of the added manpower. It was in my last comment so I find it strange that you missed it. Blindly adding manpower is of course not the solution. Adding very specialized manpower (you don't need many) can of course help and it is what was missing in the mythical man-month quote. That was my point. Otherwise I aldready know about what the quote mean. – n1ckp Oct 27 '10 at 13:41
Ok, the example could be better but the generalisation is still valid? – Murph Oct 27 '10 at 14:29
@n1ck: It doesn't matter how good a person is, that person will need to figure out what's going on and what's already there. I have no idea what you mean by "very specialized" here, unless you mean somebody with master-level knowledge of languages and technologies. – David Thornley Oct 27 '10 at 15:10
@David Thornley: yes it do matter. That is my point. You need fast learner that's all. If he doesn't need to learn much (know the current technology well, know what is important in a project, know what to look for (don't need to be trained by someone else), etc.), he can get productive very fast. I think that's doable. Why do you think it's not? Just skip the boring overhead. Get someone who know his stuff. – n1ckp Oct 27 '10 at 15:59
@Murph: well, yes and no. Did you read my comment? Read my new one and tell me if you still don't get it. Maybe I'm wrong on this but you seems to have missed my point at least. Prove me wrong if you think I am but you will need facts. The generalization is valid, but not for all case, that's my viewpoint. Do you "get it" better? I don't want to be rude, sorry if it sound wrong. – n1ckp Oct 27 '10 at 16:02
1

I've been through this enough times to know that it's one of those things that MIGHT work in very specialised cases, but 99% of the time it won't. No matter how good it looks in theory at the time. That said, yeah, it's not a black and white absolute. It's more like say, how open relationships don't work. The theory is nice, and tempting ;)....but the nature of the beast is such that in most cases it ends up failing. Sort of a "the exceptions prove the rule" thing. – Bobby Tables Oct 27 '10 at 20:14
@Guzica: I'm not sure about you're analogy to open relationship. It don't seem like a good idea for a multitude of reason to me. In that case I would go for the 99% estimate (it can work but you would need to be way too disciplined to be accomplished by anyone human). My estimate for the case of a project would not be that high at all. – n1ckp Oct 27 '10 at 23:23
@n1ck: I notice from your profile that you're 25. How long have you been in the industry? No offence, but it just seems to me like maybe you haven't been around long enough to see this play out too many times yet. It's just one of those things that looks good in theory, but often turns into a trainwreck in practice, despite otherwise very smart people and good practices being involved. You're sounding a lot like I might have 5 years ago or so - now I'm more jaded and not prepared to defend these "potential anti-patterns" anymore. :P – Bobby Tables Oct 27 '10 at 23:43
@Guzica: what's my age got anything to do with it? I think it's the other way around: I didn't have time to get desillisionned by the crappy workforce in place today. I still believe that good worker can exist. Why don't you? I think that maybe if it doesn't work in practice is exactly because of it. People are not motivated by their job like I am. – n1ckp Oct 28 '10 at 00:39
@Guzica: To answer your question, I'm not even in "the industry" yet. I have 5 internship experience as a lone programmer for a scientific calculation application where I had to do science stuff on the side (read papers and the like, not CS stuff though). I'm now working with a post-doc since the half of the 4th internship and it work great (he's (not too close) family related so that might help). I also have the basic projects experience from CE education where I'm between my last semester (doing my last year project) and began my master related to microscopy (my 5th internship actually). – n1ckp Oct 28 '10 at 00:46
@n1ick: It's not so much about having "good workers" or not, it's mostly a management problem. It's usually related to managers treating programming as if it was simple production work. They think that they can hire 9 women to make a baby in 1 month, not realising that software work simply has to go through its paces - and that even the best people have some pretty hefty "ramp up time" when joining a project that's already in progress. Like I said, there may be specific occasions where it works, but usually it's an anti-pattern which people fall into because it looks so good intuitively. – Bobby Tables Oct 28 '10 at 01:10
@Guzica: read my comments to rerun answer about pregnant women to see what I think about that quote. In short: it's wrong. – n1ckp Oct 28 '10 at 02:17
@n1ck: It's probably not the best analogy, but this is the reality of what happens in most of industry. People who make technical decisions are number crunchers who think programming work has zero ramp time and that allocating people to programming work is like allocating kitchenhands to various simple manual duties. It's the reality you have to work with in the industry. No amount of theorising changes that. This is why those of us who have had to fight this and actually experienced this kind of management in real life rail against it. – Bobby Tables Oct 28 '10 at 02:29
@Guzica: The analogy is still wrong. Read David's comment (in the same post) for a better one. I agree that the industry is pretty bad. This doesn't change my point. Just find god damn skilled (and motivated) labor. Not considering skill level is the problem. Hint: you just told us that you believe the industry doesn't have a clue. Do you read what I say or what? I feel like having aldready explained all of that. – n1ckp Oct 28 '10 at 03:11
@n1ck: The problem is that real life doesn't always go according to your idealistic academic scenarios. It's very easy to say "just find god damn skilled labour", but quite another to find a skilled person with a very specific skillset (and at the right price) to work for you on short notice, especially in certain markets. THIS is mostly where these issues come from, this gap between "ideal" and real conditions. This is something you just haven't seen if you haven't worked on sizeable teams in the industry yet. It's useless to talk about "ideal" conditions that can almost never be met. – Bobby Tables Oct 28 '10 at 03:32
@Guzica: I just love those people that always fall back to those, "oh but on the real world" bullshit. We live in the same world as far as a know. I am as much idealistic about this as you adopt the viewpoint of pessimistic management who doesn't have a clue. So drop your bs about the "real world" please. The real world is probably in between our two views. Next, get a clue about hiring, it's not my problem if you can't find skilled labor. The short notice can be alleviated by finding people on other project in your organization or putting a very high bounty (stop being a cheapass). – n1ckp Oct 28 '10 at 08:28
@Guzica: if you stopped crying that "it is too hard" and worked to find labor instead you would probably be able to solve your problem. Stop your whining and go to work if you want to accomplish something. That's just plain common sense dude. Also, pay the price that it takes if you want it. Of course it will not work if you want to have your cake and eat it too. Duh. Also, your point about needed very specialized labor is bull: you just need someone who have a clue. You don't need someone who can hack you a database while blindfolded (although it would of course probably help). – n1ckp Oct 28 '10 at 08:30
@n1ck: If you talk about the "crappy workforce in place today" without industry experience, you're mudslinging without a clue. You claim to be living in the same world as Guzica and me, admit your lack of experience, and still insist on telling us that our experience is wrong and your ungrounded ideas are right. In our experience, adding people to a late project is a really iffy thing to do at best. I still fail to see your obsession with quality here: most organizations have reasonably competent people, and the rule against adding people applies to even very able teams. – David Thornley Oct 28 '10 at 14:57
@David Thornley: The dead giveaway is how he thinks that you can "just hire great people" with no budget constraints and know that they will be perfect fits for the team in advance (communicate well, get along with others, be as good at the technology as they were at interviewing, pick up your quirky code base quickly, etc). This is something I didn't undestand until I actually worked on large teams either. The human frailties and variables really add up. There is no such thing as a perfect scenario where this stuff goes like clockwork. – Bobby Tables Oct 28 '10 at 18:03
@ni1ck: You know, this is the first time I've said anything like "in the real world...". I hate that kind of attitude generally too. But from the arguments you've been making, I don't know what else to say. In theory, it's actually all quite sound, and this is what makes it difficult. The problem is how it falls apart in practice, due to the way real world businesses are run, and human nature itself. Those of us who've lived and worked this imperfect corporate programming world for a while and seen this happen, just can't think in terms of it always going according to good theory anymore. – Bobby Tables Oct 28 '10 at 19:00
@David Thornley:I was extrapolating from my experience with people at my school. It's ok if you don't believe me but I'm not convinced that the rest of the industry is so much different. I'll have to shut up because I don't have proof (no experience) but nothing is telling me I'm wrong on this yet. I don't want to talk much anymore about this (and so you, most probably) so ok, I was maybe a little strong on this. I still think I had a point but I cannot bring you proof from my experience, so well, it was nice talking to you. I do have maybe a little more balanced view on this now because of it – n1ckp Oct 30 '10 at 15:39
Interesting conversation here. I've been in the industry >25 years. n1ck - I can tell you you are wrong. Some examples might help. In a business if you want to recruit a new person, how long does it take? To advertise, read CV's, interview, letter of offer, appoint - MINIMUM is 2 months (esp if the appointee has to give 4 weeks notice). And thats assuming you can get the right "good" person. If you have other people in your company or want to hire a contractor it can be faster, but this is still a very hit and miss affair. What if the only person in the company is not sufficiently skilled? – quickly_now Nov 24 '10 at 22:35
To then go on - once you appoint somebody they need to get to know the problem domain as well as the requirements and existing implementation. Some of this they can pick up by reading and looking, a great deal is done much faster by talking (but somebody else is pulled off their work to do the talking). My typical estimate for a new person to become truly productive is 3-6 months. A truly exceptional person (the 1 in 100) might be 2-4 weeks for a very limited scope. Expecting more than that is foolishness, few managers understand that. – quickly_now Nov 24 '10 at 22:38
@n1ck, I can only suppose you haven't worked on a truly large, complex project. Our main database has millions of records in hundreds of tables. And there are several other databases the new person would also have to be familiar with. Changes affect probably 30 or more applications. Business rules are very complex. Our last large project had a requirements document of over 800 pages and had probably another 50 associated long documents. No matter how good you are, it takes time to absorb that information and it takes time away from the developers already working to help you get up to speed. – HLGEM Jun 09 '11 at 13:45
@HLGEM: I agree with you that absorbing that information will take time. My point was mostly that the quote from Fred Brooks is too often quoten out of context and that adding a good engineer is rarely a bad choice as project are rarely overstaffed to the point that it would not help. But, yes, I understand there is overhead ("getting up to speed"). I don't think I was saying otherwise. – n1ckp Jun 09 '11 at 22:27

score 4 · Answer 8 · answered Jun 09 '11 at 13:38

Another factor that I haven't seen mentioned is that some tasks need to be done in a specific order. You can't do task 4 until task 3 is done because it is dependant on 3. It doesn't do any good to hire someone to do task 4 at the same time someone is doing task 3. Often at the end of a project, those tasks that need other things completed first are the remaining tasks.

They are also often some of the most complex tasks that need doing, the very ones which require the best understanding of the whole design to avoid breaking what has already been completed. They also usually require the most extensive business domain knowledge. I might after working on the project for months be able to do the task in a week or less. Someone new would spend more than a week getting up to speed (and pulling me away from my tasks for a good protion of that time to answer questions) and would likely even if extremely skilled take longer to to do the task. Not be cause he or she isn't competent but because of unfamiliarity with the actual structure of the project or the database backend.

+1. This was a major issue at my last job. The management was in mega "man month adding" craze for a major project without thinking things through. At one point, our team got drilled for being slow - because our stuff needed to integrate with that major project. But then, the new hires on the major project couldn't get up to speed fast enough, so WE got too far ahead (on stuff that needed their backends completed). At one point we were developing front ends for half-baked backends and test harnesses. Not a good flow. — Bobby Tables, Jun 09 '11 at 23:09

score 2 · Answer 9 · answered Oct 26 '10 at 22:45

2

The adage that is always worked for me is you can't get nine women to make a baby in one month.

answered Oct 26 '10 at 22:45

rerun

2,045
12
24

If you think a software project is like a baby, you don't live in the real world. There is some truth in the quote but this is the perfect example of taking things out of context: -1 – n1ckp Oct 27 '10 at 04:32
1

Its obviously not. But they people you have sell time lines too don't understand software development. Analogies are exactly for that purpose relating an unknown concept to a know entity. – rerun Oct 27 '10 at 12:14
2

Another analogy Brooks makes is to food in a restaurant. A well-run kitchen can make a lot of meals in parallel, but there's limits as to how fast it can make a single meal without undercooking or burning it. – David Thornley Oct 27 '10 at 15:08
@rerun: the problem with your analogy is that there is no worker analogy for a pregnant women. The women in your case could be more easily compared to the company, not the workers. That's why it fails so much in my opinion. The closest I can think of would be the food but that would be more like line of codes, so no, not workers. – n1ckp Oct 27 '10 at 23:25
@David Thornley: this one is better but I think it still fail because you way overestimate the staffing that occur in any project. Management rarely, if ever, would staff a project to the max, more like the minimum amount, don't you think? Also, stop discussing about quantity and think quality. Fire those workers that are useless and replace them with highly skilled workers. Now see why I disagree with the quote? – n1ckp Oct 27 '10 at 23:27
1

@n1ck: My impression is that you disagree because you don't understand it, to be honest. Brooks wasn't talking about replacing useless people with competent people, because he was in a situation where everybody still employed was considered competent. – David Thornley Oct 28 '10 at 14:06
@David Thornley: I don't know. From what I understood, the quote means that adding people to a late project will face a lot of problem and probably fail. My interpretation on this is that the "people" in talk here is the problem. Yes, it will fail if you keep the same hiring process. Competent is not enough for a late project. A study was done on related subject and resulted in the Dreyfus model where competent is level 3, Proficient is level 4, etc. Most of the people, the average, is not even level 3 (level 2, advanced beginners). The study was not about programming but I think it was done – n1ckp Oct 30 '10 at 15:47
on multiple discipline and I think it was corrected for problem related to people not in the field. ie it was done only for people IN a field, and still, most people were level 2. From that, it's not hard to extrapolate that if you hire level 2-3ish (a little better than average) people, it will be hard to get them productive in a short notice. Try at the other end of the scale, proficient/expert, and I don't see why this can't be done. – n1ckp Oct 30 '10 at 15:48
This isn't about hiring. Quite often a company has two or more departments with what is considered competent developers. If department A is late, it would be tempting to move a competent developer from team B to A. And it still doesn't work. – gnasher729 Oct 25 '19 at 20:54

score 2 · Answer 10 · answered Oct 27 '10 at 07:44

I'd also suggest "Peopleware" by DeMarco and Lister.

And "The Deadline" by DeMarco presents this, and a number of other software project management diseases and fallacies in a lighthearted and very readable fashion.

It also delves into the dynamics of people doing project / team work, and goes into some detail about just HOW things like communication and introduction deplete the available working time of a team.

These books are quite cheap, I'd suggest you get them (Amazon or The Book Depository have them) and have a read. The short answers here can't really do justice to the question asked.

score 2 · Answer 11 · answered Oct 27 '10 at 12:37

Because no one takes the time to have a well thought out, planned, tested process for: hiring, training, developing and supervising programmers let alone brining them up to speed on a particular project.

If you are managing a team of developers, you should have several contacts right now of people you would like to hire if you have an openning. Join developer groups.

How fast can you get a brand new development machine setup and ready to go?

Have you ever tested your project documentation and specs by showing them to a developer on another project? Did they look at it and determine they could start working on the project if necessary?

How up to date is any project schedule?

Save up for a rainy day because when a project falls behind it is more like a huricane.

score 2 · Answer 12 · answered Jun 09 '11 at 13:03

Aside from the communication issue (which I think all the other answers are talking about), it’s also very possible for a person added to a project to create bugs, because they don’t know the code very well yet.

Whenever I’m added to a project, I always try very hard not to break things. This means I’m much slower at fixing things at first.

score 0 · Answer 13 · answered Oct 25 '19 at 13:15

I would like to point out something totally ignored so far by the other answers.

By the time people are added to a late project, typically a lot has gone wrong throughout the organization. Management and the client are not happy. People have been pressured to get on with it. Things are pretty tense.

Now imagine you are on that team. Obviously none of this is your fault. Planning (none of which was yours) has been too optimistic. All the wrong decisions were made without consulting you. You are trying to make the best of it and all of a sudden a bunch of new people are being wheeled in. What message does this convey?

The people upstairs obviously have lost faith in you. They called in the big boys to make up for what you messed up.

Will you still be motivated to make this a success? Or... will you be ever more frustrated and would you rather see the whole thing crash after all?

Take your time :-).

Why does adding more people to a late project make it later?

13 Answers13

Introduction overhead

Linked

Related