How to estimate times when working on a new technology?

Question

I have been working on Flex for last couple of months and as this was the first time I had to actually do Flex I ended up underestimating the project tasks which resulted in a delay. So how does one estimate the project timings when working on a new technology?

Answer 1

I would give myself a set period of time to experiment with and learn the new technology before promising to deliver anything on a specific date.

After that first period, make some rough estimates, and make sure your superiors know how rough they really are.

Answer 2

You can't.

You have to consider it as research, and research can't be estimated.

Answer 3

I guess for projects of a certain size, give yourself some time to make a reasonably simple yet still complete and not trivial prototype of some representative part of your project. Then you will have some time to play with the technology, and also earn valuable insights with regards to the time it takes to create stuff with it.

Answer 4

When I worked in a project to switch a medium sized development team to .Net the only way that a full conversion could be estimated was to allow an initial research phase. This allowed some developers to get familiar with the technology and implement, in full, a small part of the functionality. I found it very important that the part of the system that was worked on was completed to a production standard.

Something that was also discussed was hiring a consultant who was familiar with the technology. This was decided against because of cost but I think it would have been enourmously helpful to have someone who had experience of .NET projects to point us in the right direction.

The only other thing to add is that when you work on a project of this nature it is important to also estimate how long it will take to bring other developers up to speed. Obviously this will be less than the time that the research phase took. Though the developers who worked on the prototype should be on hand to help those who are now picking up the new technology.

To sum up:

• You need to give yourself time to pick up the new tchnology before you can give real estimates.
• You need to baseyour estimates on experience of a full project, to a production standard.
• Don't be afraid of hiring a contractor with experience in order to learn best practices quickly.
• Dont forget that everyone needs to learn this technology before they are let loose on procduction code.

Answer 5

When I've worked with a new technology in the past (i.e. when the new tech. has been central to the delivery of the project), I've had good results with estimating it as:

New Project Time = Project Time * 1.5

... but it goes without saying, this is a rule of thumb and YMMV.

Answer 6

One thing you can do - besides hiring someone or not estimating - is to estimate the relative complexity of your tasks and then compare the actual implementation time to the complexity level. Over time, the ratio will converge toward a stable value.

Answer 7

I usually estimate the time spent learning and the time spent implementing separately. I.e. I estimate the project as if I knew what I was doing based on it's perplexity, but then try to estimate the time it might take me to learn the new technology.

Answer 8

Not too long ago, I had to work on a project in Flex and I had never used Flex (or Flash) before. I was also forced to use a certain 3rd party library of widgets in this Flex application. I estimated how long I thought it would take in a reasonable language like Java, then approximately doubled it to account for learning a new language. The problem was, Flex isn't reasonable, it isn't documented, there a number of bugs in the standard library, and apparently our 3rd-party library took all the design features of the standard library to heart, because it too was very broken. We ended up with a poorly performing product with half the features and over the allotted time. Thankfully, management allowed us to continue working on it for some time (they had been changing requirements, so they owed us that much) and we got it into really good shape. It still doesn't do everything we wanted, but we hacked our way around most of the library bugs, including mitigating the worst of the performance issues (namely, instantiating a UIComponent takes a LONG TIME, so instead of doing them all on startup, we do it as-needed. This is unrelated to our 3rd party lib).

So, in short:

• Always estimate lots of spin-up time for learning a new system. Beyond learning the language, you need to learn the idiosyncrasies. This is probably impossible to accurately estimate
• Avoid Flex if at all possible. I can't imagine straight Flash is any better, since they share a large part of the library.

Answer 9

I also recommend looking at this thread: http://stackoverflow.com/questions/118023/does-anyone-work-with-function-points

Function Points are an "industry standard" (whatever that means) for estimating how long it takes to do something. For a most part they try to map out what the program does, and THEN you put them into an algorythm like this:

long GetManHoursForProject()
{
    long   Count_of_Function_Points = GetFunctionPointCountFromAnalyticalPhaseOfSDLC();
    double Average_Complexity       = 1;  // .8 for easy, 1 for normal, 1.2 for hard
    long   Programming_Language     = 130; // for C++ (higher level languages have higher values)


    double Man_Months = Count_of_Function_Points * Programming_Language * Average_Complexity;


    long   Man_Hours = Man_Months * 20 * 8; // 20 days per month, 8 hours per day

    return Man_Hours;
}

The thread I linked to from above talks about Story Board Points, which is an interresting conversation in and among itself. I would look into both of these subjects to find which one works for you.

The nice thing about function points and story board points is that they have a language multiplier. The same way of thinking is used for all languages.

If you are learning a new language, then the complexity would be higher for your specific system.

Answer 10

My rule of thumb is to double the time you think it will take. I've found that you will always run into some unexpected problems that will take time to resolve.

Answer 11

Now, I meet a problem like yours. After read these comments here, I think there belong to level which to want to be deep clear about new technology. As first, just research in a short time for new technology as raw( a sketch figure) after that there have a breakdown works already, so now just prioritize and research more deep by order.

I hope this is useful.

Answer 12

Use Hofstadter's Law:

It always takes longer than you expect, even when you take into account Hofstadter's Law.