|
|
|
Sponsored Link •
|
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.
For new development, and to support the historical estimates, I suggested exploring a Story Point approach.
http://safari.oreilly.com/9780137126347/ch08 Mike Cohn's "Agile Estimating and Planning"
http://www.agilegamedevelopment.com/2006/03/hours-vs-story-points.html
http://www.extremeplanner.com/blog/2006/11/agile-estimating-how-long-is-ideal-day.html
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.
Have an opinion? Be the first to post a comment about this weblog entry.
If you'd like to be notified whenever Andy Dent adds a new entry to his weblog, subscribe to his RSS feed.
 | Andy is a free-lance developer in C++, REALbasic, Python, AJAX and other XML technologies. He works out of Perth, Western Australia for a local and international clients on cross-platform projects with a focus on usability for naive and infrequent users. Included in his range of interests are generative solutions, software usability and small-team software processes. He still bleeds six colors, even though Apple stopped, and uses migration projects from legacy Mac OS to justify the hardware collection. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit