The Artima Developer Community
Sponsored Link

Weblogs Forum
Estimate Archaeology - Unearthing Effort from a Repository

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Estimate Archaeology - Unearthing Effort from a Repository (View in Weblogs)
Posted: Oct 5, 2008 4:06 AM
Reply to this message Reply
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.

An Archaeological Approach

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.

Story Points

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.

Topic: Community Book Creation: Python 3 Patterns and Idioms Previous Topic   Next Topic Topic: Breaking Up The Monolith: The End of the Procrastination!


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us