Keeping a project alive with a "skeleton crew"? Bad/good idea?

Question

For political reasons, management seems intent on keeping a project progressing, but stripping away the most senior developers to perform other higher-priority tasks. Instead one more junior developer will be working on the project while consulting periodically with senior devs. Ostensibly the project will keep progressing, but at a much slower pace on the back burner. This seemingly satisfies both those that need the senior devs to fight fires and those that want to see the project continue to be worked on. In theory the senior devs will come back full time 6 mos from now to finish off the project.

Is this a good idea? What problems could this cause? Would it be better to completely staff or completely halt the project and finish other stuff?

Answer 1

Taking developers of a project, that has no urgency, is always a good idea. Nine mother's can't make a baby in a month. Basically, team performance scales poorly with team size. You would like it to scale linearly, but it's far worse then that.
In some cases, two people will be more than twice as productive as one person (due to complementing skills and other synergies). But generally, if you strip a team down to a skeletton crew, the efficiency should be expected to rise.

Now if you do all that, just to give a customer the impression, that the project is not simply on halt, leaving some straw men on the project, all the while you're actually planning to resume the project with the full team later, then this is not a very good idea. You will possibly have some crap code produced and some poor features implemented (because junior programmers are unable to manage customer feedback). And as you resume actual development, your customer will be frustrated, because the project seems to stall or even to regress, as you rebuild/remove what has been added during the 6 months.

Answer 2

Questions I would ask - Is there an original project plan and are you meeting those timelines (i.e. the client's timelines) with this delay of 6 months?

I can foresee mgmt asking why would you need senior devs back after 6 months as the junior would be fully up-to-speed by then. That's a typical management non-understanding of the project risks. There would always be another fire to put out for the seniors - so it's not guaranteed that they will be back.

If this project needs to be fully delivered as per the client's requirements - then I would assume you need the best guys to work on it and complete it. If the client is not worried about a delay, then it's an internal risk management.

There's always the likelihood (happened to us once) that the junior dev screws up things - and creates a nice little fire for the seniors to get back to.

Answer 3

I would be worried that I never see the seniors again. The seniors tend to be most fascinated with the early technology and architectural design decisions in a project and are rarely eager to do tail-end work on a lengthy project. In other words you will be fighting both management and the seniors themselves about their return date.

If you are not yourself capabable of determining whether the juniors are actually making good progress, then I would attempt to book an audit or code review session with the seniors on e.g. a byweekly basis. Slow incremental inclusion of new features isn't necessarily good progress. If your juniors are making elementary mistakes in the process (e.g. duplicating code), your are probably making negative progress

Answer 4

There is some overhead that occurs from moving people off and then back onto a project. However, if another project is a higher-priority task then you don't have many other options if this project can't be completed quickly.

Answer 5

Ignoring the political side, it hardly makes any sense. Under such conditions, the project is likely to evaporate(*) anyway, so every extra cent spent on it is wasted. There mere fact that the completion date of the project apparently doesn't matter, is a strong indication that the whole project is probably pointless.

(*) an evaporating project is one that doesn't exactly fail, but over time simply ceases to exist

Answer 6

Assuming that this plan was hatched by stakeholders of the project rather than enemies of it, having a Jr. dev work on it without real supervision for 6 - 12 months is a worse idea than simply letting the project lie dormant for the same amount of time.

The reason it's worse is that the Jr. dev likely does not know the system or the design well enough to implement any of the features to the specifications required by the seniors and will do a sub-optimal job. The seniors, upon their return, will have the challenge not only of re-acquainting themselves with a long-forgotten system but will have an added hurdle in that the system will have been changed such that it no longer behaves the way it did when they left it so the cost to "get back into the game" is raised both by the amount of change and the lack of quality in those changes. At best, the dev will make sub-optimal but passable progress on a project in which he or she is ill-suited. The middle-case is that the Jr. does a poor job but the Seniors realize it early on and throw out all the changes made in the 6-12 months they were away and pick up as though it had never been touched. The worst outcome is that the Jr. does a poor job and the Seniors mistakenly believe that they can trudge forward anyway and complete the work as-is, but find themselves stuck in quicksand because of the poor quality of the Jr dev's code. In all the above cases, the Jr. dev's time is probably being ill spent, and the salary could be better used on a more productive project. As to the senior dev's time and salaries, that depends entirely on the value of the project they've been moved to vs the value of the project that they've been moved from.

If on the other hand the plan was hatched by enemies of the project, they did a bang-up job of setting it up to fail while covertly appearing to make concessions to support it. By that measure it's a stellar plan.