Adding a new developer just before deadline is horrible. But what is not?

Question

Imagine a project is assigned to a team, deadline is estimated as 8 months. After 6 months it becomes apparent the project will most certainly not be complete on time(e.g a law changes or a hidden monumental hurdle is discovered, the lead dev gets hit by a bus, etc.). But the project is important (e.g. lose an important client on failure or have to pay reparations).

One solution we all agree is horrible is adding more developers, especially new to the company. They will need at least a month to get up to speed and occupy the rest of the team during that time.

One solution we all agree is awesome is prevention. But such situations do happen.

What is a reasonable solution in such a situation for the manager of the team, provided they have plenty of leverage for additional people, funding, client negotiation etc?

Answer 1

We have historically seen over and over again that there are two working and two non-working ways of combining the two fundamental constraints on software releases: dates and features.

1. Fixed date, flexible features, aka "release what's ready": you release at a pre-determined date, but you only release what is working. This is a model that is successfully used by Ubuntu, Windows, Linux, and many others.
2. Fixed features, flexible date, aka "release when ready" or "It's done when it's done": you determine the set of features beforehand, and then you simply work until the features are finished. Some Open Source projects work this way.
3. Fixed date and features.
4. Flexible date and features.

#1 and #2 have been shown to work well in many different projects. For example, both Ubuntu and Windows are released with a fixed 6-month cadence with whatever features are ready in time for the release. If you make the cadence fast enough, even if a feature misses the release, customers don't have to wait a very long time for the next release.

Linux actually uses an interesting staging of the two: as soon as there is a new release, there is a fixed-time "merge window" of two weeks, during which new features are added. When this merge window closes, the set of merged features up to that point is fixed, and a "stabilization period" starts, during which the fixed set of features is stabilized, any bugs fixed, etc. This process takes as long as it takes, there is no deadline. When everything is stable, a new release is made, and the process starts anew. It turns out that this actually leads to a fairly stable release cadence of 6-8 weeks, but the point is that this cadence is not enforced, it emerges naturally.

Note that this does not invalidate my assertion that #3 doesn't work: Linux development does not fix dates and features. They do #1, then make a cutoff point and switch over to #2.

#3 is always a big problem, especially with a larger feature list and longer timeframes. It is pretty much impossible to predict the future (many have tried), so your estimates are almost always off. Either you have finished all the features and are sitting around bored twiddling your thumbs, or, more likely, you bump up against the deadline and frantically try to finish all the features in a hellish death march.

It does work if you keep the feature list and timeframe short enough. E.g. this is essentially what a Sprint is in Agile Methodologies: a fixed set of features in a fixed timeframe. However, the timeframes are reasonably short (typically a Sprint is one week or two), and it is ensured that there is rapid and immediate feedback and adjustment. You generally have a Sprint Retrospective after every Sprint, where you gather all the problems and successes of the Sprint and incorporate what you have learned into the next Sprint. And of course there is a Sprint Planning Meeting where the team discusses the next Sprint with the customer and agrees on a set of features to be implemented during that week.

Weekly (or two-weekly) Sprint Retrospectives are still not fast enough feedback, though, so there is also a Daily Standup Meeting with essentially the same goals as the Sprint Retrospective, except being able to react even faster: check whether the previous day's goals were met, and if they weren't, figure out what the problem was and fix it. (Note, I wrote "what" the problem was, not "who"!)

It is also very important that every Sprint ends with the release of a working product, so that the customer can immediately start using the new features, play around with them, get a feel for them, and give feedback for the next Sprint what is good, what isn't, what should be changed, etc.

#4 almost always leads to never-ending releases with feature creep. Debian 3 and Windows Longhorn were famous examples that interestingly happened around the same time. Neither of the two had a fixed release date, and neither of the two had a fixed set of features. Longhorn took 5 years, Debian 3.1 took 3. In both cases, what happened was that they didn't want to cut features because the long release meant that people would have to wait even longer for the features to appear in the next release. But because of not cutting features the release date slipped even further, so they added even more features because otherwise users would have to wait even longer, but that made the release date slip, and so on and so forth. An even more famous example might be ECMAScript 4.

So, what can you actually do in your situation? Well, you are currently in situation #3, and that simply does not work. You have to turn your situation #3 either into a #1 or a #2 by either relaxing the release date or dropping features. There simply is nothing else you can do.

The damage was done 6 months ago, and it cannot be magically fixed. You are in the situation where the amount of features cannot be delivered in the amount of time, and one of the two has to give.

IFF you can manage to move the release, then you might have the chance to grow the team, but the thing is that once you get 5-10 members, you really won't get any faster. You'd then have to break this into two or more projects, each with its own feature set, release date, and team, but then you also have to coordinate those, and define stable interfaces between both the projects and the software deliverables.

Note that in terms of culpability, the three scenarios presented in the question are very different:

• If the applicable law changes, then it is perfectly possible to deliver the agree-upon features at the agreed-upon time. It's just that the agreed-upon features are useless for the customer. (Another good reason to be Agile.) In this case, it is actually in the customer's interest to re-negotiate the project, because if you just stuck to the agreed contract, they would have to pay for a completely useless result. So, this is essentially either a completely new project or a requirements change for the existing project, and both mean new prices and new timelines.
• If the lead developer gets hit by a bus, the culpability is squarely on the project manager. Making sure that the bus factor is > 1 is pretty much a core responsibility of the PM. Practices that can improve the bus factor are for example Collective Code Ownership, Pair Programming, Promiscuous Pairing, Mob Programming, Code Reviews.
• The "monumental hurdle" is a bit squishy. The question doesn't really define what kind of hurdle it is. If it turns out that the supplier massively underestimated the complexity, then it's obviously their fault. This can be mitigated by Spiking or Prototyping, for example.

However, regardless of who screwed up, we are still in the same place: we have an agreed set of features that cannot be delivered in the agreed time, so there is absolutely no way around the fact that one of the two has to give. There simply is no "non-horrible" solution.

Answer 2

Although I agree with the others on the need to work with the customer and things like that, if you for some reason really think you need to hire new people -- don't hire developers.

What you need to do is talk to the developers, and find out what other tasks and burdens you can take off their plate so they can be more productive:

• If they have a long commute, maybe put them up in a hotel nearby so they're less stressed out. Or hire a car service to bring them to/from the office if they have a family
• Coordinate getting food for them so they have less to worry about
• Reduce the number and/or lengths of meetings that they have to attend
• Make sure that management is available for whatever signoff is needed on changes, rather than their losing momentum as they have to wait a day.
• If they're both writing new code and supporting older stuff, have someone else take over the support tasks. (or at least triage them, so not all of it goes to the developer).

The goal is to not add more people, but to make your existing developers as productive as you can for the crunch time leading up to the deadline.

But don't just do it for them without asking, as you need to explain to the developers that you value them and their work. It might even be counterproductive if someone's slow lunch or commute is when they reflect on their problems and come up with creative solutions ... so you have to also give them the flexibility to cancel things if they don't feel they're working.

If you do bring in new developers, there's no time to get them up to speed on the project, so you'd be better off pairing them up with the programmers. There likely wouldn't be sufficient time to get the new hires up to speed on the project for true "pair programming", but they could serve a number of functions -- like an executive assistant, screening calls and/or visitors, getting snacks or running errands for the person, for 'teddy bear debugging' with a little extra feedback, as a typist for the experienced programmer to instruct, or even as just someone else to review code as it's being written.

You could hire non-programmers for the job, but typing skills won't amount to much if they don't know the programming language, even with an IDE. It's also important to find personalities that mesh well -- you don't want someone slowing the main programmer down asking 'why did you do (X)' and driving them crazy. You may need to have a pool of potential minions so the programmers can rotate through until they find one that they work well with.

And if a programmer doesn't want a shadow/minion/pair/intern/assistant whatever you want to call it, don't force one on them ... but it's possible that they might change their mind if they see it working well for others in their group.

Answer 3

The problem is elsewhere. The problem is the fact that you have one deadline for an eight months project.

Instead, the project should be a collaboration between you and your customer. It means that instead of working on a fixed set of requirements and attempt to deliver something eight months later, you'll be working on a dynamic set of requirements which could and will change on regular basis, while the customer discovers, through regular deployments, how the product appears to be in reality. How regular? It may be every two or three weeks, or it may be several times per day.

This also means that your first delivery should be done quite rapidly. Maybe not the first two weeks, but still, within a month from the beginning of the project, you should be able to show something to your customer. It won't have a lot of functionality, but it should have something. For some projects where infrastructure may be complex, showing a simple Hello World is already a great step.

Once you do your first delivery, the next key moment is the minimum viable product, or MVP. This is when you deliver something which doesn't contain all the features the customer expects, but is still something the customer could use if something goes completely wrong (the team cannot continue to work on this project, or the customer is out of money).

For instance, for an e-commerce website, an MVP should include the possibility to browse for products and actually order them, but it may not include the ability to create custom lists of favorite products, or share products, or give reviews, or ask for a refund through the web interface.

With this approach, when you finally get to your sixth month and something bad happens, it's still a problem, but not an extremely important one. After all, your MVP is already delivered months ago; for months, you added on regular basis the new features that the customer prioritized (i.e. the features that matter the most). All you need, then, is to inform the customer about the problem, and let him prioritize the features, if needed.

a law changes or a hidden monumental hurdle is discovered

If a change in legislation implies the change in the requirements, it belongs to the customer to inform you that the requirements are now different, and pay extra. Such situation happens frequently in financial sector, healthcare, or accounting.

In a case of a hurdle, where you need to redo a substantial part of the project, you need to discuss it with the customer to find an agreement. Sometimes, the discussion will involve the presence of the lawyers; but this is beyond the scope of this site.

Answer 4

Having additional developers trying to understand the project and writing code will clearly require a large learning overhead for the new developers, and take time from the current developers to help the new developers become fully productive.

But what are the current developers doing that someone else could do?

What if the "someone else" was not required to be kept productive, but only did something when it could help the current developers?

For example,

Are the current developers having to:

• Build their own PCs
• Spend time filling in time sheets
• Take their car to the garage to be fixed
• Investigate database performance problems when they don't already know the tools to use?
• Write CSS that works on all browsers
• Fix spelling errors in UIs
• Investigate why the network is being slow
• Answer the phone when the manager is in a meeting and yet another agent calls.
• Etc.

Answer 5

If "on time" is the only option then cut features until "on time" is confidently achievable. Add people only after this deployment. Have them work on the cut features if they're really that important.

If "on time" is flexible then stop using arbitrary deadlines to motivate people.

If none of that works then you need a different project. The sooner you tell people this the better.

Answer 6

You may hire 10 more developers if you want, but the onboarding time will delay their effective contribution, the increased team size will increase coordination effort afterward, and moreover the initial problem, might be amplified if you need to reallocate scarce time of current team for knowledge transfer.

There’s no magic solution here: you will not deliver what is expected in time. You need to acknowledge this change of perspective rather than trying to stick to an impossible plan. Share this reality and start to elaborate with the stakeholders a realistic solution:

• Can the deadline be postponed? Believe it or not, most deadlines are arbitrary. and allow for some flexibility. If you need to reinforce the team, take into account the potential delays to find a candidate and the onboarding effort to propose a realistic deadline.
• Can the scope for the deadline be reduced? Agree on the features that must absolutely be ready in time, and a new transition strategy that takes into account the temporary unavailability of the postponed features. Caution: this option might be more costly because additional work might be required (e.g. an interim interface with a legacy system?).
• Or is it mission impossible? If neither deadline nor scope can be questioned, you have to ask yourself if it’s worth to screw your health with a huge stress. Maybe you should think about offering your resignation. Maybe making such a decisive step could even help stakeholders to realize the seriousness of the situation and reconsider the previous options.

Answer 7

From some not so pleasant past experiences with large projects:

1. It is always better to have intermediate deadlines (sprints or so) to deliver results. This allows the supplier to adjust any estimates to reality, e.g. if you divide the project into 10 deliveries and the first two gets delayed by a week, it is reasonable to expect that the final deadline will shift by 10 weeks. The impact on one week's delay is smaller than a 10-week delay and allows both parties to revise their plans. Delivering in multiple releases demonstrates the customer what they are getting and adjust expectations.

2. The customer may push you to agree on a fixed deadline/scope/quality/cost and refuse to revise it. However, you have to have the guts to turn them down. Basically, to tell them that we either revise the plan to fit reality (e.g. a key resource disappearing, a law change, or estimates slipping) now or stop the project immediately. It is better to kill off a hopeless project half-way than wait until the final minute to realize that the objectives will not be achieved.

3. A monumental challenge can be only solved with a monumental force. Project manager's job is to avoid the buildup of monumental challenges. A project having one key person is a problem. Unclear responsibilities of what party is responsible if laws change is a problem. A buildup of TD is a problem. As others have pointed out, it is reasonable to involve the customer in the project in a collaborative manner. Thus, these issues become shared challenges with shared solutions.

Answer 8

It has become received wisdom that "Adding more manpower to a late project will make it later". But it is an oversimplification, the outcome depends on multiple factors:

• How experienced are the developers you have available? There is a big difference between adding junior developers who needs a lot of guidance and adding experienced developers who are able to research and figure things out on their own and get up to speed quickly.
• How well specified and documented is the project? Does all knowledge only exist inside the heads of the current developers, or can new developers work form documentation?
• How complex and interdependent is project? Is it possible to partition into more separate development tasks?
• What is the quality of the existing code? Is it modular with low coupling, or is it a big ball of spaghetti?

You will get diminishing returns by adding more developers, but that does not mean you necessarily will get no or negative returns. It might very well be worth the investment if the cost of delivering late is high.

Still, adding more developers is not the only solution. The major levers are:

• Reduce scope (remove features or postpone them to a later release)
• Add time (that is, move the deadline back)
• Add developers
• Overtime

Each have its risks. For example overtime will give a short-term boost, but will have diminishing returns. Adding developers is the opposite - it will be a short term decrease in productivity but long term benefit.

Reducing scope is absolutely the safest and least risky approach. If you go through the requirements, it may turn out some of features are not as critical as first thought. When negotiation with customers it is often easier to talk about postponing features rather than dropping them. Then reconsider for the next release.

You might want to combine multiple, e.g. reduce scope and postpone the deadline.

Importantly, you need to examine the reason for the slip in the first place. You mention a lead developer getting hit by a bus. This is an unpredictable event which is unlikely to happen again. But in the real world, the most common reason for late projects are:

• Scope creep
• Incomplete/vague specifications
• Overoptimistic time estimates
• Many bugs and regressions

If you suffer from scope creep, adding more time or more developers will not help. It will likely just increase the rate of scope creep. So you need to manage that before anything else.

Incomplete specifications makes it very hard to manage a time-bounded project. Some agile projects does away with specifications altogether, but notably these does not have fixed scope or fixed deadline. If you have a fixed scope and deadline, you also need a spec.

If the delay is because some tasks turned out to be more time consuming than expected, then you should expect that other yet unfinished tasks will also overrun the estimates.