Recently my manager asked my team for some metrics on the code base, in order to budget for my team. These are the metrics requested:
I do not think this is a good way to go about it. Can budgets be estimated this way? I hope to learn some better alternatives than the above.
Level of effort and complexity are much better metrics for estimating work than lines of code (LOC). Furthermore, they can only be effectively estimated by the people who will be doing the actual work.
Using proxy metrics that don't map to actual costs is not a good way to plan a project or forecast a budget. Unless your company is actually paid for each line of code written, measuring LOC is probably not a useful way to develop the budget.
Assuming that there is some legitimate use for this data, the only ones who can tell you how that maps to budgeting is someone within your organization. You need to ask your management team to explain the process, though; no one outside your company can help you develop an internal budget, much less one based on a metric like LOC.
Can budgets be estimated this way?
No one outside your company can make business decisions for your organization. There may be a legitimate reason for this data, unlikely as it seems, so you need to ask your management team how this relates to budgeting. There is no substitute for active, internal communications!
As a general rule, using code base metrics for budgeting is an X/Y issue, where someone has likely decided to compare current code metrics against future projects to somehow arrive at headcount requirements, or to forecast a future project's productivity costs or potential runtime. However, even if you accept lines of code as a valid metric for productivity—something that is widely considered a bad idea in modern software development—this is unlikely to be useful in measuring the complexity, runtime, or level of effort of future projects. At best, you will end up with data that says something like:
Based on our current budget of M and our headcount of P, we can produce C lines of code per unit of time. Therefore, our projected costs for developing and maintaining projects slated for the next budget cycle will apply a fudge factor of F to our current budget for a total of
M * F.
At worst, you will end up with a bunch of useless or misleading data, and lot of failed expectations. If that's what the management team wants, go ahead and give it to them. However, the organization would be much better served by looking at the work projected for the next budget cycle, having the development and maintenance teams develop a rough level-of-effort estimate for it, and then using that data to baseline your budget forecasts.
I have no idea what he plans to do with that information, so I can't say if it's a good approach or bad, but I would struggle to do any meaningful budgeting with that information.
Generally, I'd look for how much work a given team accomplishes in a certain area from both a projects standpoint and support. I'd look at my demand for the coming year to see how that aligns with the team. If there is work to support it, relatively consistent teams have a tendency to be more effective, efficient, and productive, so I would look to fund teams for the year if possible. Scaling up and down creates the appearance of being more fiscally responsible, but there are a ton of costs with scaling up a development capability so incurring those over and over usually incurs a far greater cost than maintaining teams.
So, the direct answer to your question is: what have you needed in the past and how does demand for the next year compare to that.
I've been using Weighted Micro Function Points metrics to get initial quick estimate of time/budget (for development part) , and it works very well for me (since doing a manual estimate takes too long for client's first inquiries, as many get rejected).
