I haven't used FP's myself but all those who've tried that I know of have said they wouldn't recommend it.
An estimate based on lines of code is about as accurate as asking the fortune teller.
I'd suggest generating relative, abstract estimates (you might call it "complexity" or you could call it "wazhingle points") for all functionality you want in the system and then implementing one thin slice of the system. That slice won't take an enormous time to implement and it sufficient for calibrating your relative estimates.
This approach would have the benefit of spending a relatively low effort in estimation ("This is twice as complex as that, that over there is about the same as this, ...") and you get more trustworthy estimates because they're based on history data (the slice) instead of pure speculation.
I wholeheartedly agree with that approach. One thing you'll notice right off is there's not conversion formula from complexity to days or man-hours or anything like that. The first time you do it for a given team and customer and technology, there's no good guideline. If you take a few tasks early on and work them, you can start to develop that relationship. Maybe tasks with effort or complexity of 8 jelly beans take about 4 days.
If you have the luxury of a few days and dollars, get Mike Cohn's books on stories (a hip word for right-sized tasks) and estimates
Having done this re-platforming or re-engineering gig a couple times, I can point out some opportunities for horrific mistakes. View everything as freshly as possible. Don't assume everything in the current system is important or necessary or was ever a good idea. Don't duplicate the bugs Learn the idioms and capabilities of the new language or platform and be prepared for those to make some of your favorite bits of the old design unnecessary. [ September 30, 2007: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
What exactly do you mean by "reengineering", and why do you want to do it?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 31, 2006
Thanks Lasse Koskela & Stan James. I agree with you with the approach. I have done this to some extent. We already have some historical data on the effort required for "simple", "medium" & "complex" use cases. Some analysis has been done to come up with the list of use cases and classified based on the complexity.
This is some sorta informed gut feeling type of estimation I had done. However, I am not very confident. So I want to verify with some other method.
Hi Ilja Preuss , Reengineering, I am not sure will be the right word or not. Maybe it is plain refactoring. But here is the situation. The said product is in java & jsp codes and we want to do architectural changes.
Now I have loads of jsp & java files. I can come up with LOC per file and also come up with a a figurative complexity of each file, maybe like cyclomatic complexity [ some tools are readily available for that] and classify each file to a type complexity like again "simple", "medium", "complex".
Based on the above classification, I can put some rough figure for each type of file by doing, as Lasse Koskela was suggesting, a recoding of the file in the new architecure.
Are there any plans of re-using existing code wherever applicable like - business layer, data access layer etc? This can affect your estimation
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Joined: Jan 29, 2003
Any mention of "use cases" and estimating scares. I'm not against having such documents, but from experience, they are much too large to use in estimation, work breakdown structures, assignments, tracking, etc. Misusing use cases and reusing old use cases led us directly to some of the nightmare scenarios that I hinted at above.
That's one reason I emphasized Mike Cohn's work. The finer grained your list of "things the customer wants" the better. I prodded my old team to switch from S,M,L estimates of 25-30 use cases to 1,2,4,8 estimates of 350-400 stories and it helped the team in many ways.
Follow up on some XP, Scrum or Story books to get more on how stories are used.
Originally posted by Ingudam Manoranjan: Reengineering, I am not sure will be the right word or not. Maybe it is plain refactoring. But here is the situation. The said product is in java & jsp codes and we want to do architectural changes.
The best way to do this I know is doing it while implementing new features, in very small increments.
It sounds like you want to do it at one fell swoop. Can you tell us more about the reasoning?