Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
8  
Lines of code is not necessarily an accurate measurement of complexity or workload. –  user1249 Dec 30 '11 at 16:51
3  
Hence my last sentence :) –  Mick Dec 30 '11 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 '11 at 17:05
add comment

migrated from stackoverflow.com Dec 30 '11 at 16:45

This question came from our site for professional and enthusiast programmers.

5 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
    
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. –  Mick Dec 30 '11 at 17:30
1  
+1 just for that quote. Haven't heard that one. –  user606723 Dec 30 '11 at 17:30
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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