How to Determine # of Programmers needed for a project

Question

How do you know how many programmers a particular project needs to be successful?

The company I work for fulfills orders for client companies. We have written an in-house warehouse management system that handles location based inventory management, order processing, bill-of-lading generation, invoicing, freight auditing and reporting (probably 50 reports). It also has barcode scanning functions and a client portal along with dozens of other smaller features. It also includes a full employee timeclock. It integrates with Quickbooks, UPS and FedEx. It handles work for at least 50 clients all differing slightly in their functionality. For example, we import orders from files the customers send but each customer sends a different file format (csv, excel, flat file and web services) so we have well over a dozen order conversion methods setup. Exports are the same story.

The project is complex and growing in complexity every day with over a quarter million lines of code. It's about 250,000 lines of VB.NET code, 6,200 lines of Ruby code and maybe 5,000 lines of PHP. It also has a MySQL database with about 200 tables.

Because of the constantly changing requirements and differing needs of dozens of clients the code itself varies greatly in the quality from extremely poor to relatively good code.

Currently, this project has only a single programmer - myself. I also currently do all the product support for our company of 75 people or so. That includes troubleshooting and setting up new clients and any new features that are needed. Plus, we're trying to rewrite the whole thing to be 100% Ruby on Rails based. And we would like to market the whole system within the next year or so to be used by other companies.

Currently, we have only myself as a programmer but I don't believe that is sufficient. Does anyone have any recommendations for how many programmers a project of this magnitude should have or how we should go about determining the answer to that question? Particularly given the fact that management would like the product to be commercial quality by next year?

Answer 1

Welcome to the oft times difficult world of resourcing!

The issue isn't one of Project Size vs Team Size. That's a very common misconception which often hides other problems which are usually management related. The issue is all about Scope. You need to decide what it is you can achieve with your current resources - aka you. Then you need to decide if your capacity for handling the workload is sufficient to handle the task within the time frames you have been allocated. Thus your project needs must be identified and scoped.

• Do you want to spend time cleaning up the existing code base?
• Is this a fundamental requirement to ensure the success of the project?
• Do you have new features to add to the system? What are the most important aspects of your project that must be dealt with, and what are the minor items that are on the wish list?
• Can any of the requirements be either abandoned, or at least put off until the next maintenance release?

When you have an idea of the scope of your requirements, you can more easily determine the workload required to achieve a result within a certain time frame. If your resources are likely to be overutilized, then you will need more staff. If your resources are likely to be underutilized, then you may find yourself able to either move your deadline closer, or increase the scope of your project.

If your gut-instinct tells you that you don't have enough staff to manage the project, you may be correct, but you need to understand why it is that you gut is telling you this. It's not enough to simply have a feeling. Instead, you need to be able to examine the problem scientifically in order to provide proof to back up your instincts, and you need to be prepared to face the possibility that you instincts might even be wrong. Once you have gathered your evidence - I.e.: scoped the project, then you really need to sit down with your management and make a case for either reducing the scope of the project, or increasing the resources available to ensure the success of the project, based on the evidence at hand.

Answer 2

The success of the product / project will depend on the commitment of the company whose paying for it. If they're going to hire more programmers / support staff, there will be an inherent decrease of productivity from the one programmer, who know has to train, teach, manage, etc.. not that it's a bad thing.. but there will be a decrease before any increase is realized.. there's also the need for business analysts, managers, sales, and the support of the product once it's commercially available..

Hosting a commercial application is much more than just creating a solid platform. there's support requirements, technical support, bug fixing, user training, etc..

do you have any good analysis / spec / estimation procedure in place? if not, start now, you can do this by yourself.

are you working your brains out right now? If so, be prepared to work twice as hard if you're expected to manage this process and continue developing (raise due?) ..

and here's the answer from my previous experience being in a similar situation in the Southern California area pricing:

5-6 people && ~500k

• 1 Lead Developer / manager wearer of all hats (~100k - 120k)

• 2 Sr. (very capable, self driven) programmers with good DB understanding and Skills (2x ~80 - 100k)

• 1 Project Manager to interface with Management ($$?) this person should also be able to understand the needs of the app, and communicate those needs directly to the programmers

• 1? (HTML / UI) developer? with javascript skills (i hate programming UI / Markup code)

• 1? Database person? however, most good programmers have no problem creating scalable data structures, however, if you're going to get into optimization concerns, you'll at least want to have a consultant

Answer 3

I would say at least 5 persons. One for test, one for spec, support and documentation and 3devs. There is a lot of things to be tested in you case, so a 50% dedicated tester should not be unreasonable. A person writing down the requirements and having customer support setting up your infra structure for testing etc should be there. Three developers I feel is quite low for a project like this. A large back end that is integrated to many third party systems, and a complete fronted with extremely many customized reports. I would like to have.

1. A good back end developer (persistence / business layer)
2. A good middle end / front end developer making action classes and JavaScript CSS Design.
3. A good alround developer acting architect but also making code in all layers with expert help from the two other. This developer can also do things like setting up JUnit framework Maven Jenkins Git branching and so on.

What happens if you leave, becomes sick take vacation etc. One person per project is never smart. Neither is it good to be alone as you don't evolve professionally without coworkers. I work quite often alone, setting up new architectures and so on, often in teams of say 5 developers but I never evolve as much as when I say to a coworker lets set up this together and we lock our self up a week talking, discussing and choosing frameworks. Pair programming is extremely giving and can not be done with one dev, and who will make code reviews if you feel uncertain? If you get stuck who will help you? I would only undertake a one person project if it was part of a larger scope and could get expert resources called in if needed. You as a developer should not be stressed from the outside therefore the customer support guy mentioned earlier could act as a Scrum Master blocking all external impediments and he could prioritize support, new CRs and reason with the end customer if they want to change requirements as you were afraid of.

Answer 4

1 programmer on a large codebase with all the responsibility of configuring, testing, communicating, supporting, documenting and bug fixing isn't going to have much time for writing new code or adding features (or even refactoring old code).

Break your week down by the percentage of these mandatory tasks that don't expand the business and you'll be surprised at how fast management hires extra help.

Large projects have a certain amount of associated overhead that won't go away (especially if implementing/testing with new clients all the time as you seem to be). This is the reason you have support rotations and support in general; so some of those on the team have time to work on new features.

You might also want to look into books on software estimation. These books may not sound like they have much to say, but they contain interesting case studies from a variety of fields and back their claims up with evidence.