Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

How Many Developers to Maintain Large Project? 18

Posted by Cliff from the grinding-out-the-numbers dept.
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 discussion has been archived. No new comments can be posted.

How Many Developers to Maintain Large Project? More

How Many Developers to Maintain Large Project?

Comments Filter:
  • I am not sure you will find an even close to decent metric. It depends on complexity, seperation, abstraction and a ton of other things ABOUT the application.

    5000 lines of horribly written code can be a nightmare, and 100,000 lines of wondefully written, documentent code that comes with unit tests can be a dream.

    You have alot of control over how maintainable the code is: Make sure it is documented, and generate documentation often. Make sure it is unit tested, and run those tests every time you change something. etc etc...

    As a rule of thumb, if you are working over 10 hours a day, 5 days a week, and the work is growing not shrinking, look for a Jr. level coder to assist you. Maybe just a highschool kid, or someone going to college.
    • if you are not using PHPUnit and PHPDoc already, you really should be. :)

      [PHPUnit's]
      http://phpunit.sourceforge.net/
      http://sourceforge.net/projects/gpfr/ (has another php unit on its pages)

      [PHPDoc's]
      http://www.phpdoc.de/
      http://sourceforge.net/projects/phpdoc
      http://www.callowayprints.com/phpdoc/

    • How the big boys do it (Score:2, Informative)

      by itwerx ( 165526 )
      It's called function points. The best resource I've ever been able to find on the web is SPR [spr.com]
      Unfortunately, I just looked at their site and it's being redesigned (most of the content is unavailable right now).
      A search [google.com] 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!

  • Time better spent? (Score:2, Insightful)

    by Anonymous Coward
    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.

  • Lines of Code is a bad metric (Score:3, Insightful)

    by crow ( 16139 ) on Thursday November 22, 2001 @02:56PM (#2600989) Homepage Journal
    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.
    • For me the main issues are:
      1. How critical is the code? If it must work 24/7 then you are going to need more people than if it can stay down for a little when it breaks.
      2. How F___ed are they if you leave? Since your the only person that has contact with the code you are a single point of failure. (hit by a bus, decide to persue you dream of becoming a Tuvan throat singer, etc.) The significance of the code is a major factor in how much you should invest in having a group of people who can maintain it.
  • 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.

  • How tall is tall ? (Score:3, Informative)

    by Eivind ( 15695 ) <eivindorama@gmail.com> on Thursday November 22, 2001 @04:47PM (#2601421) Homepage
    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.
    • He obviously thinks he needs more help, since he's writing to slashdot, however having established, respected metrics and guidlines for software development would help his argument when it comes down to asking management for that extra body.
  • 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.

  • It's not that simple! (Score:4, Interesting)

    by SecretAsianMan ( 45389 ) on Friday November 23, 2001 @12:54AM (#2602720) Homepage
    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.
  • Hi

    Well, i don't think anybody can answer your question the way you want. In fact, the most important thing to know is the way this project has been built.

    Using PHP classes or modular code can make tasks a lot easier and this way, one full time developper should be enough in my opinion. But if scripts are not structured, the project will need more than one developper, as there will be a lot of tasks to accomplish for each update or new functionnality implementation.

    Hope it will help :)
  • 40,000 lines = 2 full time developers!

    Would you believe it! You got it right first time. Well done.
  • You need at least 5 programmers for every individual who can authorize changes to the project.
    Anything less and you into problems like 'But, sir, if I am still in the middle of changing all the graphics to be 'more interesting', I can't work on the new online questionnaire until next week'.

  • there cannot be what you ask for. You might or might not need help, but metrics like lines of code have nothing to do with it.

    Remember, when you have just a few programs (less than 10 in general) you all know each other, talk to each other, and know each others code, so you can modify anything. this makes you more productive. Eventially you reach the point where you can't keep track of what everyone does, so you specialize. This greatly cuts productivity over one programer working alone, but because of the number of specialists work gets done faster.

    Adding programs makes a late project latter. However if the project is not late you should take the time to hire a backup who knows the code, just in case.

    Once you have backup programers it is a management decision. Adding programers cuts producity, but if done right doesn't cut it by as much as the new person adds. However when you add a programer beware that you have to push out deadlines while you train the new guy.

Slashdot Top Deals

Neutrinos have bad breadth.

Close