This method consists in deriving the number of function points according to the application from its physical size, measured in lines of code (LOC), using a constant conversion factor depending on the programming language. The IDEA has much appeal, since the counting of lines of code can be done through automatic tools and consequently, the number of function points COULD be derived immediately. For example, using a conversion factor of 80 LOC / FP for Java and having an application written in 80,000 lines of Java code, we get to 1,000 function points for that same application.

However, often, this technique has considerable errors when confronted with a manual count of function points of an application. This is because it assumes a linear relationship between functional size (in function points) and the physical size of the program (in lines of code), which are different concepts. Another aspect is that there is no consensus in the various organizations that publish these relationships. The numbers shown may differ as much as 100%. 

When you have a developed system scenario with a mix of programming languages, the issue is more complicated. 

Some of the reasons for this wide variation are: different assumptions in defining what is a LINE of code, and projects databases with many different features. Hence the necessity to calibrate the conversion factor for the reality of the projects developed by the organization. However, to make this adjustment, there must be a representative sample of projects developed by the organization in a particular language and an experienced and qualified professional to INTERPRET the results and understand the reasons for this possible distortion for this conversion factor.

Due to these factors, applying backfiring to obtain the size in function points from lines of code is a risky technique and characterized by a large margin of error. Hence, IFPUG highlights in their FAQ, that it can even be used (with caution) in legacy systems, where a manual count is unworkable in practice and accuracy is not a critical factor. Some professionals argue that backfiring is a quick and cheap way to get the size in function points of an organization applications portfolio. Others, argue that cheap comes out expensive: it is better to invest in a manual counting of function points and have reliability of these data, with compensation in the long term.

On the other hand, many models of software estimating such as COCOMO II, use as primary data their size in lines of code. In these cases, it is very often to do the opposite: get the number of lines of code from the size in function points. This is because in the early stages of a software project, is easier to estimate or measure its size in function points than in lines of code. Even then, the above considerations remain valid on backfiring.

This method consists in deriving the number of function points according to the application from its physical size, measured in lines of code (LOC), using a constant conversion factor depending on the programming language. The idea has much appeal, since the counting of lines of code can be done through automatic tools and consequently, the number of function points could be derived immediately. For example, using a conversion factor of 80 LOC / FP for Java and having an application written in 80,000 lines of Java code, we get to 1,000 function points for that same application.

However, often, this technique has considerable errors when confronted with a manual count of function points of an application. This is because it assumes a linear relationship between functional size (in function points) and the physical size of the program (in lines of code), which are different concepts. Another aspect is that there is no consensus in the various organizations that publish these relationships. The numbers shown may differ as much as 100%. 

When you have a developed system scenario with a mix of programming languages, the issue is more complicated. 

Some of the reasons for this wide variation are: different assumptions in defining what is a line of code, and projects databases with many different features. Hence the necessity to calibrate the conversion factor for the reality of the projects developed by the organization. However, to make this adjustment, there must be a representative sample of projects developed by the organization in a particular language and an experienced and qualified professional to interpret the results and understand the reasons for this possible distortion for this conversion factor.

Due to these factors, applying backfiring to obtain the size in function points from lines of code is a risky technique and characterized by a large margin of error. Hence, IFPUG highlights in their FAQ, that it can even be used (with caution) in legacy systems, where a manual count is unworkable in practice and accuracy is not a critical factor. Some professionals argue that backfiring is a quick and cheap way to get the size in function points of an organization applications portfolio. Others, argue that cheap comes out expensive: it is better to invest in a manual counting of function points and have reliability of these data, with compensation in the long term.

On the other hand, many models of software estimating such as COCOMO II, use as primary data their size in lines of code. In these cases, it is very often to do the opposite: get the number of lines of code from the size in function points. This is because in the early stages of a software project, is easier to estimate or measure its size in function points than in lines of code. Even then, the above considerations remain valid on backfiring.