Summary
An attempt to answer the question - given 1 million lines of code in the repository (i.e. SVN), is there some rule of thumb as to the number of developers we have to keep on staff just to maintain those 1 million lines of code?
Advertisement
This question came from a friend faced with a large body of tools in a game/animation production house and having to come up with budgets for code maintenance. Whilst much of the code starts life as a throwaway solution, it often ends up being needed for long enough to need maintenance.
Given 1 million lines of code in the repository (i.e. SVN), is there some rule of thumb as to the number of developers we have to keep on staff just to maintain those 1 million lines of code? I am looking for way to justify either (1) Ask for more staff or (2) decline request for to maintain certain parts.
Any discussion involving numbers has to have some to start with. Until you have at least some classifications of work and estimate recorded against them, you can't have a meeting about it. Once there are classifications and figures, people will start to debate them.
I suggest starting with an analysis of the svn logs.
How about just starting with an arbitrary allocation of one point per commit, to determine relative amount of effort.
You could also factor them by taking an arbitrary assumption of working hours per developer, say 25 hours/week and distributing over the range of dates of the commits.
These both assume you can derive some rough linking of commits to actual projects, based on directory structure.
http://kanemar.com/2006/01/28/story-points-as-spicy-ness-using-rsp-to-estimate-story-points/
I like this - I think it could be fun and keep a good momentum going, the only danger being that it may converge on estimates based on surface impressions of stories - again it all comes down to judgement and making sure that difficulties are made obvious during story creation.
Previous Topic
