Software Craftsmanship (I)

I have spent most of my spare time last week to read an interesting book called SOFTWARE CRAFTSMANSHIP. The book basically evaluates the suitability of Software Engineering approach to Software Development; and compares and contrast its effectiveness in developing successful application. The book tries to emphasis the effectiveness of skilled Software developers (craftsmen). In essence, the author (Pete McBreen) is inclined towards stressing the role of craftsmanship as major factor in making software development successful, while advocating the Software Engineering should be left to huge projects.

I tend to agree with the author and i will attempt to touch upon some of the ideas that the book surfaces in this regard

In the beginning, let me articulate how IEEE defined software Engineering (1)

Software engineering is the application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software, that is, the application of engineering to software

(1) IEEE standard computer Dictionary, Software Craftsmanship ISBN 0-201-73386-2 page 7

the software that runs NASA space shuttle was developed using Software Engineering approach (2)

What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

But this amazing work comes with a price tag

"Most people choose to spend their money at the wrong end of the process," says Munson. "In the modern software environment, 80% of the cost of the software is spent after the software is written the first time -- they don't get it right the first time, so they spend time flogging it. In shuttle, they do it right the first time. And they don't change the software without changing the blueprint. That's why their software is so perfect."

"As the rest of the world struggles with the basics, the on-board shuttle group edges ever closer to perfect software. Admittedly they have a lot of advantages over the rest of the software world. They have a single product: one program that flies one spaceship. They understand their software intimately, and they get more familiar with it all the time. The group has one customer, a smart one. And money is not the critical constraint: the groups $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations"

(2) http://www.fastcompany.com/online/06/writestuff.html

But if we do not have the leisure to spend $35 Million per year, may be software engineering is not for us!

The book then raises an interesting point based on the team that created SCRUM software development approach

"If a process can be fully defined, with all things known about it so that it can be designed and run repeatable with predictable results, it is known as a defined process. and it can be subjected to automataion. If all things about a process aren't fully known -- only what generally happens when you mix these inputs and what to measure and control to get the desired output -- these are called empirical processes"

If you think about software projects that you were involved in, who close did you ever get to the defintion given above.

With this introduction to the subject, you have probably gotton a feel about what the book is about. I will try, in later blogs, to shed more light about other ideas the the book presents

Ammar Sajdi
www.e-ammar.com
www.realsoft-me.com
www.palco-me.com