Harmonizing Software Size and Project Effort

Sometimes it can be difficult to understand that an IT project of 4000 hours can be smaller, in terms of product delivered, than an IT project of 1000 hours. It will be seen more clear if we isolate the concepts "project effort" and "software size" because not always exists the correlation that more size = more effort, and less size is equivalent to less effort.

It is very interesting: if you have a farm and you produce oranges, you will record, for example, how many kilos of oranges you produce, and how much time/effort you need to collect 1000 kilos of oranges. Even more … for sure that you will know that in certain circumstances 1000 kilos of oranges will be collected in more time or in less time; factors such as if the terrain is wet or not, or if the trees are bigger or smaller, would determine that you can collect more or fewer oranges in a given time. Here we talk about “size” (kilos of oranges), about “effort” (how much time, or persons x time), about “productivity” (kilos collected by day, for example), and about drivers that influence the productivity, for example if the trees are bigger or smaller.

If we have big trees, perhaps we will need to climb into the trees resulting in a lower productivity. For sure, other questions will arise and we need to be ready to have strategic information: is better to have big trees that produce more oranges by tree, or to have small trees with a higher harvesting productivity, regarding time to collect the oranges? Quality, productivity, market strategy and profit might be aligned. Perhaps to collect oranges from big trees is less productive, but the product has a higher quality, and we can sell it more easily and with higher profit margin.

The concepts of size, effort, productivity, and productivity drivers have been used for centuries. It will be difficult to find a small or big company that produces shoes or cars that cannot answer in less than one minute questions such as “How many shoes or cars did your company produce in the last year?”, or “Did you produce more or fewer shoes or cars than the previous years?”

Try to ask the same question to some IT software company: “How much software did your company produce in the last year?” Or, “Did you produce more or less software than in the previous years?” Be ready to hear, as answers, financial incomes; number of projects; number of employees working on IT projects; or just the project hours spent in IT activities. Perhaps, in some cases, you will receive a “financial” answer or an “effort” answer, but not the answer to “How much software did your company produce last year?”

The answer this question only can be determined by quantifying the product. In a car factory, the answer can be units of cars, in a farm perhaps number of kilos of product, or in a shoe factory the number of shoes produced. Even more, we would need to add a second axis that refines this info with the type of car, for example, because for sure it is not the same to produce 1000 economy cars as 1000 luxury cars.

A given software project can be developed using different approaches; in fact, there is a high artisan design component in developing software solutions. Externally you will see the same product, but if you have a look at the technical design and the software code, you will see different internal products. I have seen programs with thousands of lines for doing almost nothing, and programs of dozens of lines that do many things, even with the same technology and in the same program language level.

Who is more productive, a development team that creates in 100 hours a software application with 20 programs of 2000 lines of code each, or a second team that creates in 80 hours the same application with 10 programs of 800 lines of code each?

The first team has built a given application containing 20 programs and 40000 lines of code. The second team has built the same application with 10 programs and 8000 lines of code.

Just a detail: the product required by the customer is the same. If we talk about “Software Size” both projects are identical because they do the same things; both have the same Functional Size. So, one has been more clever and even the product will require less future maintenance.