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

It's not that simple!

[SecretAsianMan]

As previous replies have explained, estimating the cost of maintenance of a software package is a much more complex issue than what what you are imagining. Here are my own points that explain how this can be:

• Lines of code (LOC), when you mean the number of physical lines that are not blank or comments, is not a good measure of code size. What you really should measure is the number of logical operations that code does. At least one formal software engineering method calls this 'logical LOC' (LLOC).
• Even when measuring with LLOC, any kind of LLOC/hour estimate is going to depend on all sorts of stuff:
  • Complexity of the product. Is it a RTOS, or is it a database front-end?
  • The programming language used. Which takes more thought per LLOC: VB, C, or 68K assembly?
  • The Software Engineers. How fast does Jim write code? How many defects does Jim's code usually contain? What is the cost of finding and fixing those defects?
  • Corporate culture. How much time will Jim spend writing code? How much time will he spend in meetings, code reviews, design reviews, and other distractions?

Getting good, consistent, trustworthy answers in an environment like this is hard, and it takes a good bit of analysis (with an emphasis on 'anal') and statistics (mmmm... multiple regression...). In a highly successful software engineering firm, this stuff is what (skilled) managers are for. If you are going to find yourself in that position, you really should read some of the more famous texts on software engineering and its formal methods.

The bottom line is this: when software projects require a team of developers, you've got to view it from the point-of-view of an engineer instead of that of an artisan.