Reading this line "“Well, Feature X took 75 KLOC to implement, and we think that Feature Y
will take twice as much effort. So, we’re currently 15 KLOC in after a
week, and figure it will take 10 total weeks.” Or something like that." at https://dzone.com/articles/alternatives-to-lines-of-code-1 reminded me of the day, about 20 years ago arguing with my manager on why I will not use the Function Point Analysis to determine the effort that will be required to execute a project.
The situation was that there was a team in our organization which was writing an application in Visual Basic (good old days of VB glory). Another client wanted to develop another application (no way related to the application that was being developed in VB) in Java. The timesheets of the team members working on the VB project were being maintained. The function points being addressed by the VB project was being maintained. Given these inputs my manager wanted me to
1. Calculate the productivity of the VB team in terms of Function Points
2. Estimate the function points for the new application to be developed in Java
3. Translate the productivity computed in VB to Java (using industry standards ahem..)
4. Use this computed productivity to calculate the effort required to execute Java project.
The points to be noted are as under
1. The VB team members were filling in timesheets only because there was a mandate to fill them in. A sample timesheet would have shown
Developer A - 8 hours of Development
Developer B - 8 hours of Design
Developer C - 8 hours of Meeting (just joking)
And the productivity of the VB developers was based on these timesheet numbers
2. There were no benchmarks of productivity of the team members in the Java team in any technology.
3. The application being developed in VB was no way similar in functionality to the application to be developed in Java.
4. One can think of an productivity translation from VB to Java only if it were the same or at least similar application and similar teams.
Despite all of these facts my manager refused to accept that what I could give from my gut feeling based on the understanding of the functionality and its complexities would be better than what can be done in terms of function points.
I will not be surprised if it still happens today.
The situation was that there was a team in our organization which was writing an application in Visual Basic (good old days of VB glory). Another client wanted to develop another application (no way related to the application that was being developed in VB) in Java. The timesheets of the team members working on the VB project were being maintained. The function points being addressed by the VB project was being maintained. Given these inputs my manager wanted me to
1. Calculate the productivity of the VB team in terms of Function Points
2. Estimate the function points for the new application to be developed in Java
3. Translate the productivity computed in VB to Java (using industry standards ahem..)
4. Use this computed productivity to calculate the effort required to execute Java project.
The points to be noted are as under
1. The VB team members were filling in timesheets only because there was a mandate to fill them in. A sample timesheet would have shown
Developer A - 8 hours of Development
Developer B - 8 hours of Design
Developer C - 8 hours of Meeting (just joking)
And the productivity of the VB developers was based on these timesheet numbers
2. There were no benchmarks of productivity of the team members in the Java team in any technology.
3. The application being developed in VB was no way similar in functionality to the application to be developed in Java.
4. One can think of an productivity translation from VB to Java only if it were the same or at least similar application and similar teams.
Despite all of these facts my manager refused to accept that what I could give from my gut feeling based on the understanding of the functionality and its complexities would be better than what can be done in terms of function points.
I will not be surprised if it still happens today.
No comments:
Post a Comment