Slashdot Mirror
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?
Number of lines of existing code is largely irrelevent.
Number of lines of changing code is very relevent. If the codebase is quite stable you do not need very many people to maintain it. If your saying 'No' to implementing new changes because you don't have time then you should bring someone else in. if your not planning stuff out properly because you don't have time, then bring someone in.
Would your time be better spent planning implementation changes than implementing them yourself? Are there enough small maintenance issues that it could be beneficial to bring someone in even though, theoretically, you could do the workload? You might want to bring someone up to speed for an expected increase in workload.
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.
first things first. if you're the ONLY developer on a corporate project, then theres something very wrong with that picture. a wise corporate management droid knows to have at least 2 - that way they can back each other up. its actually a wise decision since you wanna be able to not be supporting the code 24/7/365.
and i agree with all the above comments - lines of code is a horridly bad way to judge how many developers you need. you need what you need. it depends on the project, and the methodologies and the toolset. and of course the architecture.