Thoughts on software engineering

I was reading this post of Jeff Atwood that link this interesting article. One of the key point in the article was to consider two different kind of projects

• 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

alk.