Through colleagues and exit interviews, I have heard that at my small company I am "responsible" for anywhere from 3-10 times more code than I would be at another job. I'm trying to look for some sort of fuzzy metric that I can use to compare my workload with others in my field.

By "code responsibility", I don't mean "I'm the only one who knows area X of the code base" (though sadly, it's often true in a startup environment), but rather am referring to a number like "code_base_size/number_of_developers".

Are there any resources I can use to help me more accurately measure my work load than just counting lines of code?

  • 8
    Lines of code is not necessarily an accurate measurement of complexity or workload.
    – user1249
    Dec 30, 2011 at 16:51
  • 3
    Hence my last sentence :)
    – Michael
    Dec 30, 2011 at 16:55
  • 2
    @ThorbjørnRavnAndersen: "Accurate"? I think you might mean something else. It's about the only measure that really is accurate (and precise). Barry Boehm (Software Engineering Economics) demonstrated that it was about the only sensible measure. That makes it useless for project estimating. But as a retrospective measure that predicts effort and duration, it was much better than any other.
    – S.Lott
    Dec 30, 2011 at 17:05

5 Answers 5


The only concrete measure for an employed developer is the number of hours spend coding and fixing bugs, and the money you get paid for it. If you are staying late at night 6 days a week for 50K US$ a year, then you have a problem. No matter how many lines of code your boss want you to be responsible for, you won't handle more than you can do, taking account of a certain code quality of course. Developing poor quality code with no unit tests is a good way to handle much more code, but the company will have to pay the price of a large technical debt.

In small companies developers tend to be responsible for much more code than in large corp. The factor 3 to 10 you are referring to seems realistic to me.


I've known a three person team that managed a 1.5 million line codebase and wasn't drowning in it. The important measurement is not how much code you're responsible for, but rather how much code you need to change in a certain increment of time.

There's also the risk assessment angle. If you are the only person that knows a piece of code, what is the opportunity cost that would be lost if you walk under a bus? Small companies usually don't do risk assessment like that, but this means that the continued success of the business is left to chance.


code base size/number of developpers isn't related to the workload. If you have an huge stable code base that metric will be high. If you have a small code base still in development, that metric will be low. lines changes per unit of time per developper is more related to the workload. But even then, I've spent days to track subtle bugs whose fix was one line...


The code should be the responsibility of the group not of one developer. Support should be delegated fairly each week, it seems stupid to allocate it any other way. If that is not the case I suggest you speak to your management.

In the situation your describing one developer might be struggling to meet deadlines because of a huge amount of support from one area where other developers are under worked. Its a very inefficient management structure.

Also I suggest you move away from measuring workload in lines of code. Man hours is the only sensible metric I can think of

Measuring programming progress by lines of code is like measuring aircraft building progress by weight - Bill Gates

NB. I'm not saying equal I'm saying fairly. Its also worth noting that its fine to specialize in certain aspects of the code base, that happens naturally. Its only a problem if nobody else ever works on that code.

  • I should have been clearer - I was trying to find a way to measure my work load by AVOIDING saying "this code is my responsibility - and I alone maintain it." For example, if Facebook had 2 programmers, they would obviously be overworked - but HOW would you reach that conclusion? That's the type of the question I was going for.
    – Michael
    Dec 30, 2011 at 17:30

For example, if Facebook had 2 programmers, they would obviously be overworked - but HOW would you reach that conclusion? That's the type of the question I was going for.

This isn't a programming question, it's a management question.
There are a few easy questions to answer this and they have nothing to do with software.

  1. How many hours are you working?
  2. How many hours should you be working?
  3. Are deadlines being met?

Then follow this logic:

  • If 1>2, you need more people or less aggressive deadlines.
  • If 1<2, you need less people or more initiatives.
  • If deadlines aren't being met and 1>=2, you need more people.
  • If deadlines aren't being met and 1<2, you should go fire someone.

This is an oversimplification that has two glaring flaws.

  • People are not created equal.
  • There are ways to make people more production (upgrade their computer or something).

But you get the idea.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.