Hello, I thought you might be interested in this email about how they compute man-hours. In effect, if you take a look at the number of developers who have contributed code to a project like Bacula, you can come up with an extremely low estimate of the total man-hours that went into the project, because to do it correctly, you must consider that some of us such as myself spend more than 8 hours a day working on and thinking about Bacula, and even more importantly, a one or two line bug fix that a user contributes may have represented 40 hours of research and debugging. If you count all the time that users have spent tracking down problems over the years, you quickly realize that the total "man-hours" represented by the current code is far more that would be the case if the code was created in a proprietary environment without the extensive input we have had from the users.
Regards, Kern ---------- Forwarded Message ---------- Subject: Re: project 'Bacula'> Date: Thursday 27 July 2006 03:04 From: Jason Allen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Greetings Kern, I apologize for the delay, but I wanted to share some details. Feel free to forward to the userlist if you find this useful. Cocomo overestimation Guessing a codebase's cost is, as you can imagine, very difficult when gauged solely on a project's Lines Of Code. While we at Ohloh have more information than just LOC to work from (the actual developer's historical activity, number of checkins, languages, comments, etc...), we chose not to use that information because we do not feel we have the expertise to come up with a better algorithm than the one offered by Cocomo. By relying on Cocomo we essentially remove ourselves from being the expert - we simply report what a well- known method produces. However, it's also interesting to realize that the Cocomo model tries to account for more than just the development / coding time. It attempts to include all the costs associated with the preliminary and ongoing design work, spec-writing, documentation, stabilization (bug fixing, etc...). For example, at Microsoft (where I used to work), we typically had a 1-1 ratio between developers and Q.A. engineers (testers). We also had a ratio of about 1:3 program manager:developers. In effect, there were 2.3 (1+1+1/3) people behind every LOC written. I don't know how Bacula's org works, but I suspect there are many unaccounted man-hours associated with users reporting bugs, testing out new configurations, etc... Empirically, I've found that it tends to be more accurate when assessing mature, large and stable projects. On the other hand, it can be very wacky when applied to newer, unfinished codebases. Hope this helps. Feel free to email me directly with more questions or comments. Sincerely, -jay [EMAIL PROTECTED] > From: Kern Sibbald <[EMAIL PROTECTED]> > Date: July 19, 2006 8:00:25 AM PDT > To: "Heigl Florian - Munich-MR - external" <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], "bacula-users" <bacula- > [EMAIL PROTECTED]> > Subject: Re: project 'Bacula'> > > Hello, > > A very interesting link. I've copied the list because maybe they > will find it > interesting. > > On Wednesday 19 July 2006 12:59, Heigl Florian - Munich-MR - > external wrote: >> hi, >> >> (kern I just cc'ed You for info, so You can speak up if You feel >> overworked :) >> >> at http://ohloh.net/opensource/software/bacula >> >> the effort estimation for bacula shows 48 man years - >> well, have a look at the activity statistics and the project >> start date. the statistics (and common knowledge) show, >> that Kern Sibbald does over 80% of the engineering / coding >> work and the project has only going for four years, so a) >> the estimate is dead wrong, unless You base it on incredibly >> lazy and incompetent designers/coders AND the estimate >> is missing a logic check, unless Kern's days have 240 hours >> each. > > Well, I admit 48 man-years seems like a lot, but that depends on > exactly how > one defines a man-year. Compared to the estimates they show for other > projects, it is at least consistent. > > I find their statistics very interesting, and it is clear that they > have > managed to figure out the major contributors to the project and the > periods > they worked -- probably by examining the CVS activity. > > Also, at least in the case of Bacula, the final commercial dollar > value of the > software they estimate is probably quite reasonable. > > By the way, I actually began coding on the project in January > 2000. It was > only in April of 2002 that I felt it was sufficiently ready to > release it for > public use. In terms of man-years, two years probably is not a > lot, but if I > have indeed done 80% of the software development in the last 4+ > years (I > don't know, but probably reasonable), then those two years would > represent > mor than one third (35.7%) of the total effort to date (assuming > 6.5 years > total development time). ------------------------------------------------------- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
