- Project A will eventually cost about a million dollars and produce value of around $1.1 million.
- Project B will eventually cost about a million dollars and produce value of more than $50 million.
And the conclusion is that *control is more important in project A and not in project B,*and another astonishing sentence in the article was
the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?
The problem is that we always wish to work in B-like project, but the reality is that sometimes the only project to work on is A-like, and this is outside our control. If there would be a choice, A-like project never existed because no one would ever want to work in a project with such high risk of loss.
In the end , the conclusion of the article was that software engineering is like an illusion, because a software project has too many points that cannot be measured, or controlled; thus building a software is much more craftsmanship than engineering. I must admit that in my experience this is really true, but I think that there are more to know.
Think to a carpenter, it is the typical craftsman, it is the one that can take a raw piece of wood and create a furniture. Such a work has little to do with engineering. In software world this translate to the typical small team of 2-5 persons, where communication is simple and keeping the whole project together is quite easy. The team analyzes the need of the customer, and from a blank project they create a program that bring value to the customer.
Then think to a medium size or big project, where we have more than one team of developers, with a dedicated team of analysts etc. In craftsmanship world there is not an analogous situation. If we consider the carpenter sample, I hardly imagine 50 carpenters working together to create a big piece of furniture without some form of control or measurement of the process.
I completely agree that it is impossible to gain full control over a software process, like that can be reached on civil engineering or mechanical engineering, but a software project needs always a certain degree of measurement and control, and the acceptable level arise with the size of the team.
With small teams we can have little control, adopt some agile process and proceed with success. With medium size or big teams we need more control and measurement, to avoid too much slip scheduling or the complete failure of the project. Too many craftsman working together with no control is surely a situation of high risk