How Many Developers to Maintain Large Project?
edrugtrader asks: "I am the sole developer for a corporate intranet site. New complex features are always being added, and old features are always being updated. The source code for the site is in very terse PHP, and sums up to about 2MB of code (i would guess around 30,000+ lines). Are there any standards or studies about how many developers it takes to maintain such a large and changing codebase? I am looking for something like, '40,000 lines = 2 full time developers', or '2MB of code = 3 full time developers'. I can currently handle everything fine, but I want to know at what point I should be looking for new hires. I have read studies that a developer writes 1 line of debugged code at the same rate no matter what the language is, so the fact that it is PHP should probably not come into play." As a metric, I think the number of lines per developers may not be perfect, but it is fairly intuitive. Has anyone actually looked into what this ratio is in their shop, particularly for large projects?
This reminds me of the thread a while back on "Do we need a new mail server?"
Why ask a general question about metrics, when you have so much more information than the general case? You know how much work you do to maintain the code. This information makes you the absolute best person in the world to answer your question.
Let's not stir that bag of worms...
How tall is tall ? How far is far ? There can be no objective, or even half close to sorta-objective answer to these kinds of questions.
The number of developers needed migth be proportional to the rate of changes in a codebase, and perhaps to the complexity of the internal and external apis. But the number of lines of code by itself is fairly irrelevant.
It also makes a *huge* difference if these are fresh or experienced developers, if they know the project already or if they need to spend the first months getting acquianted with it, and simply if they're good or not.
I really think there's no substantially better method than simply to estimate from your current situation. Do remember though, that 5 programmers working on a project are typically not 5 times as efficient as one. That's because they have to communicate internally, spend time understanding code which others have written and so on.
It's called function points. The best resource I've ever been able to find on the web is SPR :)
Unfortunately, I just looked at their site and it's being redesigned (most of the content is unavailable right now).
A search brings back enough other links to get you started though.
I've never used it quite the way the rest of the world does, mostly because it's rather time consuming.
In essence, a "function point" (which I won't explain here - too long!) takes different numbers of lines of code, depending on the language. E.g. ASM might take 300 lines, SQL might take 6 to accomplish the same end.
There is also a limit to the number of [debugged] lines of code different programmers can produce per day.
If you start skimming through the Google results and pay particular attention to the numbers (tables) you'll find A - many references to SPR (they practically invented the concept) and B - enough info to get you started without $10k of training.
Using these numbers and your own knowledge of the project and the skills of the available programmers, you can make pretty good guesses about what you can accomplish on your own and when you'll need more bodies.
I never thought these sorts of numbers could be terribly accurate until I started using them myself out of desperation (similar situation to yours, actually).
The most important part though, is to know the programmer(s)! The easiest way to do that, I've found, is to take existing projects written solely by the person in question, look at the number of lines of code and time it took (real-world time, meetings and such, including other duties, do count!) and then figure out each person's numbers that way. The function points just serve to let you compare dissimilar (or unwritten) projects.
In summary there's no short answer.
Good luck!