The field of software development is relatively young, but it has progressed very quickly. In just a few decades it has undergone maturing processes that have taken much longer in other fields. During the last decade Agile methodologies have gained wide spread acceptance, and are becoming mainstream. Transitioning to Agile is undertaken both by well established “traditional” software development organizations, as well as by more rudimentary “cowboy-style” development shops. In this post I examine the reasons why this transitioning is taking place, and what consequences come out of it.

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.

In the LinkedIn discussion Project Estimation using “Function Point Analysis” helps in Project Success or a Nightmare? which originally prompted us to write the previous post (Function Points Are Fantasy Points), we find Simon Harris comparing Function Points and Story Points, and offering this point of view:

Story Points are all ‘Function Points’ in philosophy if not detail.

When, we critique Function Points and happen to mention Story Points in the same context, it is frequent to receive the objection that Story Points are like Function Points. The similarity is only superficial. In this post we examine the differences.

Function Points are a well known metric for software sizing. If you are unfamiliar with the concept, take a look at Wikipedia’s entry for Function Point. In this post we argue that Function Points are an inadequate tool for estimating modern applications – and in particular contemporary web applications.

In our previous post about Software Craftsmanship Management, we highlighted the importance of the “resistance of the medium”, and suggested that increasing friction is a way to improve performance. In this post we will explore what this means.

That is an oxymoronic title, with the words ”Craftsmanship” and ”Management” side by side! Isn’t the essence of craftsmanship skilled individuality? While management is the process of controlling people? Is there not a contradiction of terms here? What is this all about?

If you are in the business of making software, the fundamental process of creating software is really simple: it is just about transforming some idea into executable code. Behind the simplicity of this idea, though, there is a whole universe to be discovered. It is almost expected that any software project will miss out on scope, budget or time. Why is that?

For the solo programmer, the process is straightforward: thinking and coding are just two sides of the same coin. As soon as more than one person is involved, the ideas that need to be transformed into executable code need to be communicated between the participants – and this is when things start to break down.

Imprecision and Vagueness of Human Communication

While human communication can easily survive the imprecision and vagueness of expression that we deal with on a daily basis, any imprecision and vagueness becomes detrimental when transformed into code. Legendary programmer Donald Knuth in an interview [SHUSTEK-2008] expressed this very neatly…