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?

Comments

Lines of Code is a bad metric

[crow]

You want to take any study that looks a lines of code as a metric with a grain of salt (or more likely, a full salt shaker). You really can't compare code on that basis when dealing with projects of differing inherrent complexity. For example, a single-threaded application program will be far less complex than re-entrant kernel code. If you're getting the same number of lines of code per programmer on each project, then you have much more experienced coders on the kernel project.

And to say the language doesn't matter is also nuts. Sure, you might find that if you select the right languages, but if you compare, say, assembly language to Java, you're not going to get the same results--and good luck selecting programmers with the same levels of experience to make a valid comparison.

The decision at hand really depends on how much time you have. If you start running out of time, then it's time to hire more help.