How to evaluate the time of work on a new technology?

Question

I have been working on Flex in the last couple of months, and since this was the first time I really had to make Flex, I ended up underestimating the project's tasks that led to the delay. So, how to evaluate the time parameters of a project when working on a new technology?

Answer 1

I also recommend looking at this topic: Does anyone work with function points?

Function points are an “industry standard” (whatever that means) to measure how long it takes to complete something. For the most part, they try to determine what the program does, and THEN you insert them into an algorithm 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 with which I am connected from above tells about the "Precise Tips", which is an interesting conversation within and among themselves. I would study both of these subjects to find which one works for you.

The good thing about function points and story 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 will be higher for your particular system.

Answer 2

You can not.

You should consider this as research, and research cannot be evaluated.

Answer 3

I would give myself a certain period of time to experiment with new technology and study it before promising to deliver anything on a specific date.

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

Answer 4

Use Hofstadter's Law:

It always takes longer than you expect, even when you are incorporating Hofstadter's Law.

Answer 5

When I was working on a project to switch the mid-size development team to .Net, the only way I could evaluate the full conversion was to allow the initial stage of the research. This allowed some developers to get acquainted with the technology and fully realize a small part of the functionality. It was very important for me that the part of the system we were working on was refined to the production level.

Something that was also discussed was hiring a consultant who was familiar with this technology. This was decided against due to cost, but I think it would be extremely helpful if someone who had experience with .NET projects pointed us in the right direction.

The only thing that needs to be added is that when you are working on such a project, it is also important to evaluate how long it will take to bring other developers up to speed. Obviously, this will be less than the time required at the research stage. Although the developers who worked on the prototype should be on hand to help those who are currently gaining new technology.

Summarizing:

• You need to give yourself time to pick up a new technique before you can give real estimates.
• You need to evaluate the experience of a complete project, production standard.
• Don't be afraid to hire an experienced contractor to quickly learn best practices.
• Remember that everyone should learn this technology before they are freed from the warming code.

Answer 6

I usually evaluate the time spent on learning and the time spent on implementation separately. That is, I evaluate the project as if I knew what I was doing based on his perplexity, but then try to evaluate the time that it may take me to learn new technologies.

Answer 7

Not so 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 specific third-party widget library in this Flex application. I calculated how long I thought it would take a reasonable language such as Java, and then roughly doubled it to account for the new language. The problem was that Flex is not reasonable, it is not documented, there are a number of errors in the standard library, and, apparently, our third-party library perceives all the design features of the standard library, because it was also very broken. We ended up with a poorly functioning product with half the features and within the allotted time. Fortunately, management allowed us to continue working on it for some time (they changed the requirements, so they owed us), and we got it in really good shape. It still does not do everything we wanted, but we have cracked our way around most library errors, including mitigating the worst of performance problems (namely, creating an instance of UIComponent takes a LONG TIME, so instead of doing all this at startup, we do this as needed. This is not related to our third party lib).

So, in short:

• Always spend a lot of time learning the new system. In addition to learning the language, you need to learn the features. It is probably not possible to accurately assess
• Avoid Flex, if at all possible. I can’t imagine that direct Flash is better, since they share most of the library.

Answer 8

My rule is to double the time you think will be required. I found that you will always encounter some unexpected problems that will take time to resolve.

Answer 9

I assume that for projects of a certain size, give yourself time to make a simple, but still complete, rather than trivial prototype of some representative part of your project. Then you will have time to play with technology, as well as get valuable information about the time spent on creating the material.

Answer 10

When I worked with new technology in the past (i.e. when the new technology was central to the delivery of the project), I had good results, evaluating it as:

 New Project Time = Project Time * 1.5 

... but needless to say, this is a rule of thumb and YMMV.

Answer 11

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

Answer 12

Now I meet a problem like yours. After reading these comments here, I think they are at a level that wants to be deeply understood about new technologies. Firstly, just research in a short time for new technologies as raw materials (sketch drawing), after which there is work on the breakdown, now we simply set priorities and research more deeply in order.

Hope this is helpful.