Do Developers Dream of Automated Function Points? (I)

Qualilogy - Automated Function PointsThe title of this post is transposed from the title of a science fiction novel that you might know: « Do Androids Dream of Electric Sheep? », from the author Philip K. Dick.

This book served as the screenplay for the movie « Blade Runner » by Ridley Scott, in which a detective must find and neutralize androids that nothing can distinguish from humans.

In this book, the detective has a sheep in flesh and bone, that he replaces, at his death, by an ‘electric’ sheep. And so he asks himself if androids dream of having a pet, in its ‘animaloïde’ version.

This work of K. Dick raises a reflection on the difference between the human and the robot, between the real and the automated, which came back to my mind when I thought about the differences between manual Function Points (FP) and Automated Function Points (AFP).

Today, more and more developers use metrics from source code analysis tools, statistics of tests, figures about corrections/changes, Technical Debt data, etc. as part of their project or their Continuous Integration process.
So, why these developers, more and more fond of measures concerning their code and their applications, usually are unaware of anything about Function Points. Could this interest them?

Function Points

I will not explain you what are Function Points: this is not the subject of this post and it would take many, many pages. Especially since there are different standards and methods, not to say different schools. Let’s just say that FP is a measure of the functional size of an application, based on transactional flows and data structures.

I know: this is not a precise, nor perfect definition, but again, I do not want to get into this discussion, but simply recall what are the main objectives for using Function Points:

  • measure the functional size of an existing or future application,
  • in a standardized and objective manner, regardless of the technologies and organizations, thus allowing comparisons (benchmarking),
  • with the result that this measure is often used to assess the productivity of developers.

Do developers know Function Points?

No, developers do not know Function Points. Well, at least, I’ve never met any developer who knows what it is.

One reason could be that, in my opinion, developers are not naturally interested in functional aspects. I’m not saying that it matters little, many developers specialize in areas of banking, finance, industry, etc. or in certain processes: Accounting, Logistics, Human Resources, etc. But we know that it is better to speak about new technologies, new programming languages, frameworks, possibly new methodologies, in order to get their attention, rather than business processes and functionalities.

Other reasons why they are not going to be interested, in my opinion:

  • It is complex to understand: developers know what is a transaction or a data structure, but good luck to explain them subtleties of concepts such as ‘application boundaries’ and other ‘FP adjustment factors’.
  • This is a manual process, usually long and tedious, but above all not automated. We’ll talk about it in a second part.

I think also that there are some cultural reasons. Anglo-saxon societies and knowledges are fairly oriented to quantitative numbers, while we european and latin peopre are more focused on qualitative estimations.

I remember my courses about labor sociology at the university. When a team of american sociologists wanted to study an organization – for example, a team of workers – and see what could be learned or how to improve it, they did favor observation and data collection in order to measure the duration of an operation, the time for a product to go from A to B, the number of products produced, the number of defects, etc.

A european team was beginning by interviewing the workers to measure their interest (or not) at work, their thoughts about the manufacturing process and its defects, their suggestions about the organization of the production chain, etc. The approach was essentially qualitative, not quantitative as well.
Many people also consider that it is not possible to measure the productivity of knowledge work and in general, any immaterial production.

Function Points and productivity

Another reason why Function Points arouse a greater interest in anglo-saxon countries rather than in our mediterranean countries: the measurement of productivity. The ability to benchmark project teams and outsourcers to check who is able to produce code (if possible of quality) as quickly as possible, is a kind of Holy Grail in the consulting community.

These aspects of productivity are not so important here. I remember an english manager to whom I explained that I met developers who did not want to use a source code analysis software, despite all the incentives and the efforts of their hierarchy. He immediately responded me that this would not happen with him because he would have fired immediately anyone against it. Which would be virtually impossible in most of our ‘latin’ countries, if not in France, at least in Spain.

Obviously, a developer can not refuse a direct order from his boss, but to impose a tool to a project team is unthinkable, without raising all sorts of objections, dangers and risks compromising the development of the next version, and finally to see the team falling into some kind of apathy verging progressively on total inertia on this subject. This is also one of the reasons why I always say that application quality comes from the developers and can not be decreed. Convince yes, impose no.

In addition, if many developers are usually very excited to discover new tools, they will be naturally suspicious enough if it is to control their work or productivity.

Do developers need Function Points?

I do not think that developers need Function Points.

They would of course be interested in accurate measurement of functional requirements to be implemented into software, but they are much more careful that these requirements do not constantly evolve during the development phase. Moreover, a good project manager with experience will be able to estimate the workload represented by these features. And he will know that there is also different factors that can hamper his team to deliver an application on time and budget: the use of a new technology not fully debugged, inadequate project processes, flawed or poorly integrated tools, lack of experience, etc.

I also think that developers do not need Function Points to get an idea of their productivity. Today there are so many metrics that allow us to know who does what in a project team, and how it is done: number of check-in/check-out, test coverage, number of defects found in QA, etc. Not to mention source code analysis metrics: it is very easy to know who duplicates code with Copy and Paste, who never comments its code, who ignores a best practice and needs some training, etc.

I sometimes intend to present to a customer a measure of the effort of development between two versions, without using Function Points. If I know how many components have been added, modified or deleted between these versions, and if I assign a workload to each task (depending on the complexity of these components, for example), I am able to estimate the number of days required for the realization of this new version.

Of course, I will not get very accurate results (1). However, I prefer an imprecise but easily understandable estimation to a measure claiming to be accurate but that we do not know exactly how it has been calculated. And my customer also: he wants to know, for example, if his outsourcer actually spent the 500 days he is charging him, and which look exaggerated in light of the work done. If my estimation is easily understandable to the point that he can use himself the formula in a fairly objective and realistic manner, a difference of 10% or 20% in the assessment will not really be a problem. But if our calculation results in 200 or 300 days of estimated workload instead of the 500 days on the bill, the outsourcer will have some questions to answer.

This works in both ways. Once I was asked a ‘blind’ audit for a critical application that was more than four months late. I say ‘blind’ because I could not qualify and get any information about the context and the history of this project (I hate that). I then found a very high number of components that have been added and deleted between the two latest versions, and I explained to the customer and his outsourcer that this did look to me characteristic of significant changes in functional requirements between the two releases. This is actually what had happened and that this customer had to agree, based on an admittedly imprecise but yet sufficiently objective estimate, to resolve a divergence with his provider, who was ultimately not responsible.

This example shows that such a measure is useful, and this is also the ‘raison d’être’ of Function Points, much more accurate than my simple formula. Now let’s imagine that the calculation of Function Points can be automated: would that be enough for developers to use this measure?

This is what we will see in our next post.

 

(1) I have noted however that the figures for 4GL like Cobol or client-server languages are slightly more accurate than for object-oriented languages.

This post is also available in Leer este articulo en castellano and Lire cet article en français.

6 thoughts on “Do Developers Dream of Automated Function Points? (I)

  1. Ian Alyss

    I’m not sure whether developers are the right target group for Function Points. Function Points are used to describe value of the software in the sense that you can put a number on the amount of functionality it offers, the amount of time the development team has or will put into it to build the software or the amount of money you have to pay the supplier to get the software you want. Those types of value are usually not the things a developer is interested in.

    I think the problem with Function Points is that it needs “technical” input (from a business perspective) that Business Analysts, Information Managers or Project Managers do not have or understand. If they don’t have or understand the input for Function Points, they will not buy the number that should display the value of the software they are interested in.

    Reply
  2. Jean-Pierre FAYOLLE Post author

    Thanks for your comment Ian.

    You are right: developers are not the first target for Function Points, but as said me a Project leader: “If I had it, I would probably use it”.
    I have seen repeatedly developers telling me that they were systematically late in their planning because they have to evaluate changes without enough knowledge of the code. When they get some metrics like Cyclomatic Complexity (CC), they know it will not be just 1 or 2 days to make changes in a component with several hundred CC points. I believe they could use AFP in the same way.

    Now, it depends on the kind of developers we are talking. There are teams where developers work on requirements directly with users, do the design, the program, unit tests, launch a build that will launch a source code analysis in a Continuous Integration process and have a look on the results to correct ASAP violations on programming best practices.
    If they can do that in some Agile way, they can understand and use FP. On more ‘taylorized’ teams, the division of all these tasks between different people will not allow to do that.

    You raise an interesting point about the need to understand how a metric is calculated in order for someone to accept it. When I present an assessment of the quality of an application based on a SCA analysis, I first begin to explain how the SCA tool calculates the measures or people will not accept the results.
    You don’t precise what is the “technical input from a business perspective” that you are talking on, although I believe it has to see with ‘boundaries’ but anyway, this is the kind of input you also need to configure a SCA analysis.
    Again, if the project team is using the SCA tool in order to improve the quality of their code, maintain or reduce the Technical Debt, “they will buy the numbers” as you say. But if AFP are used by some people external to the team in order to measure the productivity of developers or outsourcers, they will question, discuss and discredit the results.

    Reply
  3. enric jaen

    As a programmer, I have to estimate how much time I’ll need to implement a feaure. Can FP help me in estimating features?

    Kind Regards
    Enric

    Reply
    1. Jean-Pierre FAYOLLE Post author

      The next post explains a little bit more how to calculate FP. Basically, each can use this method with some software specifications, and then plays Planning Poker based on his FP estimation.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *