In the earlier post Function Points Are Fantasy Points I showed how Function Points have a number of problems, especially when trying to estimate, or when trying to apply Function Point Analysis to a contemporary web project. Francisco Lopez Lira Hinojo correctly observed that we did not mention “how much was the effort and how long the project took to finish.” We will address Francisco’s observation in this post, and look at some further detail.
Ex Post Facto Assessment
A relevant observation comes from Kirk Bryde in another linked discussion.
The only value I see in using FPs is in sizing projects AFTER they're completed. For example, to compare how one team, or methodology, or technology fared relative to another. [...] The problem with using FPs as an up-front estimating tool is that you don't know the FP metrics yet - and won't know them till the project's over.
While Function Points are a weak tool for estimating project, they do present this apparently interesting use case: after the fact assessments with Function Points give us a crude way to compare different projects. That is exactly what was done with the reference project: it was analysed after the fact, and not up-front.
Using Function Points to compare projects is a well known practice. It has been used extensively by Jeff Sutherland, in his attempts to describe how Scrum leads to Hyper-productivity. While it is debatable whether or not Scrum does produce Hyper-productivity, we notice the approach for demonstrating it. [SUTHERLAND-2008] states:
The best standard metric to compare productivity across projects is Function Points as it directly represents features delivered. Capers Jones demonstrated years ago that the number of features delivered in Function Points can be estimated by "back-firing" using lines of code delivered . While this is a less direct measure of business value, it is the best measure available to compare teams industry wide.
Back-Firing Function Points
The “back-firing” technique was invented by Capers Jones (see [JONES-1995], and [JONES-2000]). It is an attempt at establishing an equivalence between logical source statements of a programming languages with a Function Point. These equivalences are also translated into working hours. In [JONES-2007] we find that the average effort is 20 work hours per Function Point.
Therefore, in retrospect, the reference project which was sized to 1,504 Function Points would have required 1,504*20=30,080 hours, or approximately 752 ideal staff weeks. The team of 3 people delivered the project in 9 weeks, which (if ideal) would translate to 27 ideal staff weeks. Conclusion? My team was 28 times more efficient than the industry standard, since 752/27 = 28.
Is this a rare finding? Or simply some error in counting Function Points in the reference project? I claim it was a case of Software hyper-productivity.
Software Hyper-productivity
Software hyper-productivity is the capability of building production grade software at a speed that is orders of magnitude greater than the industry standard. The first case of hyper-productivity was reported by [COPLIEN-1994]. Coplien described the Borland Quattro Pro for Windows (QPW) project. His study was highly influential on the shaping of both Scrum and XP. [SUTHERLAND-2011] writes:
We were prodded into setting up the first Scrum meeting after reading Coplien's paper on Borland's development of Quattro Pro for Windows. The Quattro team delivered one million lines of C++ code in 31 months with a 4-person staff that later grew to 8. This was about 1,000 lines of deliverable code per person per week, the most productive software project ever documented. The team attained this level of productivity by intensive interaction in daily meetings with project management, product management, developers, documenters, and quality assurance staff. [...]Each developer on this project generated 1000 lines of production C++ code every week for three years. In comparison, productivity on the recent Microsoft Vista project was 1000 lines of code per developer per year. The Borland Quattro Project was 52 times as productive as the Microsoft Vista project measured by lines of code.
To reiterate: A team of 8 people delivered 1 million C++ lines of production code in 31 months. As of today, this is still the most productive software project ever documented.
Barbarians, not Burrocrats!
This was during the last years of Borland International’s legendary period (1982-1994), when the company was still lead by the original founder – Philippe Kahn – and fighting with Microsoft and Lotus for the top three places as a software super power. Borland International was extremely successful. For instance, it was the first company ever to make Microsoft withdraw from a market entirely (the Pascal compiler market).
Yet, in that fight, Borland International was the underdog. The company had to do things differently. Philippe declared in an interview [WEBER-1992]:
Absolute size is one thing but it's relative size that really makes a difference. Microsoft is, what, six times... five times bigger than we are? They're very large, so you've got to be better, you've got to be leaner, you've got to move faster.
“Better? Leaner? Faster?” – This sounds a lot like what is promised by current Agile (like Scrum, XP) and Lean (like Kanban) methods. How did it work out at that time, when these methods were unknown? [WEBER-1992] recounts:
Philippe Kahn was reading a dense history of Central Asia a few years ago when it struck him that many of the nomadic tribes of the steppes were actually far more ethical and disciplined than the European "civilizations" they were confronting.They were austere and ambitious, eager for victory but not given to celebrating it. They were organized around small, collaborative groups that were far more flexible and fast-moving than the entrenched societies of the time. They were outsiders and proud of it. They were barbarians.
And Kahn wants “Borlanders” to be like them. Barbarians not bureaucrats, as the high-flying software company’s unofficial slogan proclaims.
Now, many will say: aren’t “small, flexible, fast-moving, collaborative groups” what Scrum is all about?
Scrum does Not Lead to Software Hyper-productivity
While the premises seem to be very similar to those of Scrum, it is important clarify a few points before going into further details about software hyper-productivity.
Borland International’s methods contributed to the shaping of Scrum. They not only prodded Jeff Sutherland into inventing Scrum, but gave rise to two of the landmark practices of Scrum, the Standup meeting and the Sprint.
In [SUTHERLAND-2011] (and in many other earlier papers by Sutherland) we read: "The Coplien paper on the development of Quattro Pro for Windows at Borland triggered the first daily Scrum meetings and the monthly Sprint cycle."
One might believe that Scrum would hence duplicate the productivity rates of Borland International; but that is far from being the case.
Scrum has built a great deal of its success on the promise that it will make software organisations more productive. Now, it is undeniably easy to make any “traditional” software organization improve and deliver an increase in productivity. Scrum can boast about many such cases. That’s not a big deal.
The point is that, notwithstanding such improvements, they are all a very far cry from achieving hyper-productivity. Jeff Sutherland himself (see [SUTHERLAND-2006], [SUTHERLAND-2007], and [SUTHERLAND-2008]) has strived to get to the hyper-productive state. Very few scrum projects have reached the hyper-productive state. It is surprising how small this number is compared to the widespread and popular adoption of Scrum by many, many software development organisations. (Note that the promoters of Scrum usually counter by saying that you must “play it as its rules state” or you will fail [SCHWABER-2011]. This is a classical defense of any methodology proponent!)
Jeff Sutherland has more recently acknowledged that Hyper-productivity is an outlier, and that the results achieved by Borland International are unlikely to be replicated. Jeff Sutherland has categorized Scrum in various types (Type 1, Type 2, and Type 3) [SUTHERLAND-2005] to represent increasing capability levels. The important point is that lately Jeff Sutherland is attempting to bring Scrum to the whole organization as such, and not limit it’s field of action to the development team alone. This is truly revealing the major shortcoming of Scrum: the lack of system’s thinking and of organizational perspective.
(Note: I am sure that Jeff Sutherland and Ken Scwhaber have this perspective. Unfortunately they have failed to capture it in Scrum. It is the wide-spread adoption and implementation of Scrum, as dictated by the “simple” scrum rules, that misses the point entirely. There are even elements of Scrum that are just counter-productive to the purpose of reaching hyper-productivity. There are many more things to say about Scrum; but for the purpose of this discussion, the above is sufficient.)
Kanban does Not Lead to Software Hyper-productivity
Kanban has many extraordinary features that can make any software organization significantly improve on their earlier performance. Kanban focuses in particular on incremental improvements and not on quantum leap improvements which are characteristic of software hyper-productivity. While there is no evidence, I doubt that a series of incremental improvements will eventually sum up to orders of magnitude improvements – or at least that that can happen in a reasonable time scale.
Organizational Culture
The key to achieving software hyper-productivity is in the company’s organizational culture. Excellent technical skills are necessary, illuminated managers are necessary, technology and infrastructure are necessary, software processes and methods are necessary – all of these are necessary, yet insufficient. And organizational culture starts from the head.
Referring to Borland International, Philppe Kahn was “recognized as being among a small group of executives who have an intuitive understanding of computer software” [WEBER-1992].
Understanding the nature of software from a business and organizational perspective, does not mean getting into the technicalities of programming and coding – it means understanding the nature of human creativity, and the individual and social processes that foster it, in an organizational setting.
Communication is another key ingredient. [FISHER-1992] wrote:
The lowliest entry-level programmer can e-mail Mr. Kahn and expect a prompt reply. Borland insiders credit their "high bandwidth" communications with increasing the company's efficiency. "If a programmer has an idea he can raise it with everybody who matters in an hour, and have a decision made in two hours," said Hamid Mirza, Borland's vice president for data-base development.
What most will reflect upon when reading the above quote, is the “flatness” of the organisation; but that is not the key point either. The key point lies in the frequency and patterns of communication – the “flat” organisation just happens to enable such frequency and patterns of communication, but it is in no way a pre-requisite.
Coplien came to the most important insight: his study of the Quattro Pro for Windows case and Borland International’s internal communication patterns led him to appreciate – and above all document – the organizational patterns that can benefit software organisations ([COPLIEN-1996] and [COPLIEN-2004]). Within those patterns (and others) one can find numerous, real elements that lead to hyper-productivity.
Loosing Hyper-productivity
The best evidence that Software hyper-productivity stems from the company leaders and the culture they can instill in the organization, comes from Borland International itself.
In 1995, after considerable growth, “professional management” took over and replaced Philippe Kahn. After a series of management blunders and changes in strategic direction, the company declined and eventually settled on making “software test and quality tools” with a focus on “Application Life-cycle Management (AML).”
In the meantime the company had lost all of its original hyper-productivity. This became ironically evident in 2008, when Peter Morowski, then Borland International’s Senior Vice President of Products, wrote an article for the Agile Journal, [MOROWSKI-2008], telling how between 2006 and 2008 he had lead an “Agile enterprise transformation” programme.
Go figure!? The company that held the unmatched software productivity record, that had inspired Scrum and XP, that gave Coplien the raw material to develop his software organizational patterns; that company had now to learn to become agile. What had happened in the meantime?
In that article Peter Morowski presented the company as a “traditional software delivery organisation” (sic!) that became “sold on Agile,” and then adopted Agile consistently. Naturally, this produced some good; the article listed a number of benefits of the Agile transformation.
Though, the original hyper-productivity and the results thereof were never regained.
This sad case evidently demonstrates that while it might be of value if single development teams learn to become agile, it is way more beneficial and important if the company’s leadership understands the nature of software. It is about leading the entire organization to hyper-productivity. And just as leaders can lead a company to conquer the hyper-productive state, they can also make the company loose it.
No amount of Certified Scrum Masters or other team-level, “band-aid” methodologies can replace illuminated leadership.
The challenge is how to become an illuminated leader of a software organization.
Is Software Hyper-Productivity Transferable?
So if you can loose hyper-productivity, is it possible to gain it? or are hyper-productive software teams true outliers, that just happen to be “born” with a unique capability? The Quattro Pro for Windows case was used by SUTHERLAND-2003 to present hyper-productivity as an alternative to scaling:
It is possible to scale to a 500 developer effort with only 40 developers on staff and deliver the project in almost half the time.
If this is to be viable, then learning how to be hyper-productive must be a transferable skill – but Scrum is not (consistently) delivering on that (with the exception of those few projects documented by Jeff Sutherland himself).
The question remains: is software hyper-productivity something that can be taken from one organization to another?
The Chronologist: A Barbarian in Disguise
To reply to the question, I can only relate to my own personal experience. I was with Borland during the period when Coplien made the QPW study.
Naturally, I am proud to have been with Borland International at that time: that experience shaped my entire professional career thereafter. I have since continued in Borland’s tradition, and I have personal productivity records that are comparable to those cited. While I was there, I took up the methods and processes – and especially the mindset and attitude – that characterized Borland International at that time. And I have since continued to learn more about, and develop my own approaches as to what makes hyper-productive software organizations really tick and perform.
Allow me to refer to my own personal “productivity record” that was established in 1995-97, when leading the core team of a company developing a commercial banking application. The core team of four software engineers delivered 600,000 LOC of Delphi production code in two years. How does this compare?
(Note: here “Delphi” refers to the Object Pascal IDE developed by Borland, and currently a product of Embarcadero; this “Delphi” has nothing to do with the “Delphi” estimation technique!)
Let’s use Function Points again, and back-fire from Delphi code. According to [FUTRELL-2002] you need 29 lines of code of Delphi per Function Point: so that project of mine would be equivalent to 600,000/29 = 20,686 function points. In terms of productivity, this translates to an incredible 20,686/(12*2*4)=215 Function Points per staff month…
This is more than double the performance of the Quattro Pro for Windows team, and over 100 times the industry standards documented by Capers Jones!
I have too much respect for the Quattro Pro for Windows team (Hi, Bob and all!) to say that my team was more productive than them. On the other hand, I have no difficulty believing my team was several times more productive than the industry standard. These incredible numbers is what you get when you resort to Function Points, especially with the back-firing technique. The back-firing technique has a lot of fallacies, summarized quiet well by [DEKKERS-2000]. The productivity figure derived above is on the border line of being ridiculous, even considering the possibility of errors in deriving it. I take it with a grain of salt: it is exaggeratedly huge to be credible even to myself!
Granted, the application was much simpler to develop than Quattro Pro for Windows, and a lot of productivity gains were given by using a RAD environment like Delphi, rather than a pure C++ compiler like in the case of Quattro Pro for Windows. Discount even the fact that I had worked in Borland, that I had a deep knowledge of Delphi, and that the application was a simple CRUD application, just with lots of screens and data.
Function Points or not, those 600,000 lines of working Delphi code, delivered in 24 months by 4 engineers, remain. This was a real case of Software Hyper-productivity. (Besides, all this happened 3-5 years before the Agile Manifesto [BECK-2001] was published, and way before the current hype around “agile, scrum, XP, etc.” was popular!)
My early experience at Borland International allowed me to repeatedly achieve hyper-productivity well beyond industry averages, on a number of diverse projects, with different teams, different technologies, different countries, and different problem domains. So, to answer the question, at least according to my experience: Yes! Hyper-productivity is a skill that is transferable (and if you want to know more about this, stay tuned on this blog!).
A Good Use for Function Points?
On a final note, to continue on the topic of Function Points: examining the Function Point productivity figures for the reference case, the Borland Quattro Pro for Windows case, and my own productivity record, let us consider the Function Point figures as valid for the sake of discussion. These figure can be considered as evidence that there are ways to deliver orders of magnitude more productivity than traditional approaches.
It is also worthwhile to comment that in the reference project, hyper productivity was achieved not only because of the chosen methodology, but also because of the chosen toolset. The choice of using Ruby on Rails was done because of it’s claimed productivity advantage in making web applications (according to various, unverified claims that promoted Ruby on Rails, it was supposedly 6-9 times more productive than equivalent Java based web development). The reference project exhibited hyper-productivity. How much of that was due to the methodology, and how much due to the toolset is open for debate. However this stresses the point that making an effort estimation that ignores and discounts the underlying technology, as done by Function Point Analysis, doesn’t not seem to be particularly inspired by wisdom.
Jeff Sutherland uses Function Points to compare different projects, and determine productivity differences. I think that hyper-productivity is real; but using Function Points to demonstrate it is not an appropriate way to demonstrate it.
In my opinion, Function Points are a cargo cult, on the border of superstition. Function Points have the same credibility as numerology, astrology, biorhythms, anthropometry and other pseudosciences that try to gain a semblance of respectability by resorting to numbers in a manipulative and distorting manner.
As Jeff Sutherland has repeatedly shown, it is possible to use Function Point to sell Scrum – and apparently he’s been very successful in doing so. It is a sad state of affairs for the IT Industry, that there are people believing in Function Points and that you can resort to such pseudoscience in order to sell a methodology or to demonstrate achieving software hyper-productivity. Using Function Points makes no sense from a business perspective.
There are other metrics that are much more significant from a business perspective, like the Theory of Constraint’s Throughput (defined as the rate at which the organization generates money), which can demonstrate the business effects of achieving software hyper-productivity in an even more spectacular, and – more important – convincing and tangible manner, through bottom-line results.