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?
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.