What facts and sources can I use to convince a manager I'm currently working with that rewriting a project of ~20'000 lines of code in a month is a completely unrealistic plan, and that writing ~5'000 lines of functional code in 3 weeks is actually a good result?

  • 1
    How about starting with how you arrived at your own estimates? Where's your supporting data for that?
    – Todd A. Jacobs
    Sep 2 '16 at 5:03
  • 3
    Neither of you actually have supporting data, both figures are essentially made up. Ask if you can see how much you can deliver in a week and then extrapolate. Sep 2 '16 at 6:17
  • 2
    @XenoMind the point was to create your own data, because data from any other team is not your team and won't reflect reality for you.
    – RubberDuck
    Sep 2 '16 at 9:44
  • 1
    @XenoMind and that reality is that no two teams will do the same work in the same amount of time.
    – RubberDuck
    Sep 2 '16 at 10:45
  • 1
    Possible duplicate of What are Acceptable SLoC Rates?
    – Thomas Owens
    Sep 2 '16 at 12:41

A previous answer that I wrote here on Project Management Stack Exchange provides high/low/nominal values for source lines of code written based on project type per staff-month. More specific data is always better - using historical data from your past experiences or past projects at your company of similar size and scope - would be more relevant. As you can see from that data, even 5000 SLOC/staff-month is well outside of nominal ranges for every application type and size.


There's more to estimating/evaluating a project than just the lines of code that need to be (or were) created/modified. Size and nature of the modification/addition, complexity of the code, code re-use, programming language, verbosity of the code (you can have one line do the exact same thing as five lines - and this may be good or bad depending on situation and opinion) and use of external packages, to name a few. And many of these will change, not just on a team-to-team basis, but on a project-to-project basis.

The only people who are really equipped to give any sort of reasonable and realistic estimation, given all of these factors, are the people who actually do the work. If a manager tries to estimate what is 'realistic', their estimate is going to be coloured by other factors - such as timelines and other constraints - which would falsify such estimates even if the manager did have the ability to otherwise properly estimate the work.

A more effective system is for the developers to make the estimate, the manager to trust the developer's ability to make estimates (if the manager does not, that is a separate problem that must be addressed), and then the manager must make a decision on whether the value added by the work is worth the estimated effort expended to accomplish it.


Since you are talking about lines of code, you could check a popular github projects graphs to see how many lines are committed in similar time periods


  • 1
    1. Open source dev happens in spurts. 2. You referenced Microsoft, Microsoft as a benchmark? I'm willing to bet very few companies can match the churn rate MS does.
    – RubberDuck
    Sep 2 '16 at 13:35
  • 1. you can check individual contributors who work on the project continuously for a period of time 2. again, check individual contributors to cancel out the effect of companies having more devs
    – Ewan
    Sep 2 '16 at 14:25

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