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.

How tall is tall ?

[Eivind]

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 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.