Is there a good way to calculate how many man hours it would take to add about 1000 lines of code to a Visual Studio MFC program This would include a dialog or two and a class.
My way of calculating is to guess that it would take x hours and then multiply those hours by 4. I know. Just keep the jokes to a minimum.
Calculating Man Hours
warble
Dagarsd, do they actually teach that in schools ! I suspect they have to teach something. You'll find the reality is a bit different. Alongside these method, you should also read The Mythical Man Month.( not my favorate book, but should be required reading for every programmer/software writer/manager).
Such analysis are fundamentally flawed, even if the calculations performed are accurate, because of the assumptions and inputs required for an anylsis. For example, the complexity of a project: any given project is simple or completely impossible, depending on who is doing the assessment.
The basic and most reliable premise is for the project to be broken down into component tasks, covering timespans of hours (no more than a few days). This will establish a project duration.
In addition, such studies very rarely take into account the Uncertainty Principle (human nature): the more the task whch requires human performance is measured, the more unreliable the results of such measurement. Also, just like six-sigma, ISO9000 (and other such rule-based application), following the rules never delivers the expected outcome that the rules are designed to produce (invariably because those following the rules don't actually understand the intent).
The common factor with all methods of establishing project duration, time to write code, etc. is plain and simple experience.
VikasAgr
hi!
there actually is that kind of course for teaching a sytematic and integrated approach to develop a software from pre-coding phase to maitainance phase. The pre-coding phase comprises of defining the project and its scope along with system requirements. This then helps in estimating project time and economic cost through methods desinged by professionals in this field.
A small project can always do away with this approach but when one institution is asked to build huge allpications(as in present day world) they have to follow a systematic aproach (much like coding standards etc.) so that project ends up satisfying the client completely even after being developed-tested-maintained by diffent coders at differnt phases of its creation.
hope it left no doubt in your mind about utility of these methods, but if there is then do ask me.
obvioulsy no estimation can be accurate but there exists some methods which can give best results.
regards
sumit dagar
karthik asok
I have true story to tell about the only technique that I think is really good.
Like many estimating stories, some background is required to make it fully understandable. I used to work for Digital Equipment Corp and I was originally from the field instead of Central Engineering which had many many groups in many locations. I started to say my specialty was host-based shadowing but I invented it in the field so it was more than a specialty and many corporate groups wanted consulting on various high-availabity solutions. One group I was involved was particularly disadvantaged because they were tasked with producing a multiprocessor high availability solution on VAX/VMS and they were newly assembled after the discontinuation of an entirely different hardware and software architecture. I would often visit them to notice that there was an engineer who was responsible for Sysboot and who would ask me questions like “What’s a longword ”. So I was pretty anxious for this group. I remember correctly this group have one hundred people in it and it dawned on them that they had no clear estimate on how long it would take to deliver the entire project. So they decided to use a very sophisticated but exotic estimating system called the Delphi Oracle. If it sounds mystic that’s because it almost was mystic. Here’s how it worked:
The entire group assembled for three work intensive days.
Each individual stood up and presented a thumbnail of their project, what it entailed, what was required and then identified the pieces they saw. It was the groups job to listen intently and then vote on how many weeks they thought would be required. All votes were tallied, averaged and counted. The interesting thing about Oracle was that the hi and low outliers were asked to speak to their concerns or lack of them or to be very specific about why they had made the highest or lowest votes out of one hundred people. Low votes suggested that people either weren’t thinking about the problem or had identified a much better or faster approach. As for high-liers, these people were really paid attention to because possibly they knew something that the rest of the group didn’t.
BUT THEN - After much discussion they would vote again and after hearing the discussion very frequently the Mean, high and low had changed. Again, we had those discussions. Again we voted and discussed. And the process was really convergent. Over three days grueling days, we did this for about one hundred subprojects. Management confidence levels were very high about the Oracle. On the surface it, looks expensive. One hundred people in the group, and three days or estimating cost 1.5 person years. But in a project with one hundred people in it, I’m not sure that 1.5 years out of a total of 200 person years was a high price to pay.
I appreciate a method like this. I think it does the opposite of what most estimating techniques do not – it gives engineers dignity. I don’t think the bean counter formulaic ways really do.
So how successful was this I don’t know. I was hired away by VAX/VMS with the understanding that I was to develop fault-tolerant shadowing there. I did. I don’t know whether High performance systems survived or not. But the Delphi Oracle method really was as impressive as it was exhausting.
dlackey
Once I was in a project management course and being a feminist, I made my responses in terms of person hours. I was asked what a person hour was and my response was "About two man hours". It brought the house down.
Jokes aside, OOP is designed such that lines of code is a pretty meaningless metric. The entire idea of OOP in a way is the ability to to an awful lot in one line of code.
Some code like state dependent GUI code is very tricky and slow, some code is very fast to develop which suggest an average number of lines of code per hour but I think that's even deceptive.
With OOP I haven't found a better way to estimate projects beyond simply by knowing exactly what's required and saying, I think it's going to take this long with X amount of certainty. Much experience is required to do that. I almost agree with you. Normally I work about 16 hours a day and estimate the number of 40 hour weeks that would be required. I'm always on time. But I have to work exhaustively to do that.
Igor Antunes
Ironically, a 4x multiplier is about right...
1 to do the job, 1 to handle the problems that arose while doing it, 1 to document it and 1 to debug it: then it needs to be tested :)
Philippe Delodder
having done a course on software engineering (for structured aproach to S/W development), I can suggest some popular methods.
You can use functional point analysis for calculating man-hours without even knowing actual no of lines in your code.
Another method would be to use CoCoMo analysis where one has to know no of lines in the code.
further can is available at ifpug.com or en.wikipedia.org.
regards
sumit dagar
MagicM
I am just restating what has already been said.
There is no formula for calculating how many hours a development task takes. You will work from estimates based on your experience. The best estimate is if you try to break the task down in many minor tasks that you already have experience with.
rocky_don
Thanks for all the information. I've read the posts but haven't had time to look at any of the links. Keep your comments coming. Next week will be quitier than it was this week so I'll be able to look more closely at your comments.
gabit7
SemiTransparent
I think it is really good that they teach ways to estimate a projects costs and duration but my point is that there are no formulas. Project estimates are from experience. I only restate mine and others point...
My most important point is that you (or your team) must break the work down into as small pieces as possible (without being silly).
How long does it take to make a image manipulation program
How long does it take to load an image
How long does it take to change a color
How long does it take to change a pixels color
How long does it take to save an image
Just as an example, you are probably not able to estimate how long it takes to make a image manipulation program as you do not know what is expected from that software. However if I ask how long it takes to load, change a pixels color and save you might have an idea and it can be estimated.
Any formula that give best result is probably just luck....
A correct estimate made with confidence always has some history to base it on...
Kapoulkine Arseny
I have to reiterate the consensus here: proper estimates cannot be accomplished by inexperienced people. The experience an engineer has, the more accurate his/her estimates become. Any book that claims to give you a formula for estimating projects based on man-hours is not worth the paper it's printed on.
By way of anecdotal evidence:
When I first entered the profession I had, obviously, never professionally developed software before. Sure I had developed software on my own, but never as a professional software engineer. The organization I worked with took "mentoring" very seriously, and inexperienced junior engineers always shared office space with journeymen or master software engineers (for lack of better terms). I shared office space with a man who had been a software engineer for more than 20 years. He'd forgotten more about software engineering than I'll probably ever learn in the first place.
We were having a conversation one day when another colleague of ours entered the room. He had been around for about 5 years on various projects. Our boss happened to be walking past the office we were in. Our boss had little-to-no actual software engineering experience. He was a retired Lt. Col. who was, quite simply, a program manager. He hired good people and relied on them to be honest with him. He stopped and came into the office. As usual, all conversation halted and we turned to him (everything stops when the boss walks in, right ) He went on to describe some work that the organization was bidding on, and gave us as many details of the project scope as he could recall off the top of his head. He asked us, each in turn, for an estimate of the work.
I didn't hesitate: "Should take about 3 weeks," I said, confident in my newly-discovered development skills. After all, it was a simple three-tier app with an Oracle (7.6.4, haha) back end. I could write the GUI in my sleep and unit test it during naps. I was the first one to arrive at the office every day and the last one to leave at night. When I would get home at the end of the day, my computer would be booting up AS I was taking my coat off.
My colleague (the one with 5 years of experience) stopped me and said "That's a little too aggressive. You need to take into consideration some other factors first. I'd say it's closer to a 3 month project. People aren't going to work around the clock like you do."
My officemate chuckled and shook his head. "This project won't even see the first phase of QA for at least 10 months, and THAT is being optimistic guys! I haven't even seen a design, and I'm highly doubtful one even exists yet."
My boss, after hearing all of the input, said "Let's call it 10 months for now," and left the room.
Fast forward 11 months: the first QA build hits the staging server. It ran over 10 months because of poorly-managed scope creep (well...when you know which side your bread is buttered on, you often allow a certain amount of creep to keep a client happy) In our case, the client was the U.S. Government.
There are no hard and fast rules about software project estimation. Only experience can guide an engineer to determine how long it will take to complete a task. There are so many variables to take into consideration, and you'll never have all of that information when you need it. What might take me 5 months to accomplish would take a colleague of mine 18 months minimally.
Man hours are, quite frankly, creatures of myth. They don't exist.