Book - Software Craftsmanship: The New Imperative

As you probably know, I recently joined a new community called Cambridge Software Craftsmanship. I finished to read one of the movement inspiring book and in this post I would like to share the most interesting things I found in it.

Even if the book is quite old considering the speed at which the world of the computer programming change, I have to say that the book is still very actual.

The book start introducing the definition of software engineering from IEEE:

IEEE - 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

The most successful project using a complete and robust software engineering approach was the space shuttle software. 

Space shuttle software was 420000 lines long with 1 error. It last 11 versions with a total of 17 errors. Commercial programs of equivalent complexity would have 5000 errors.

This is a proof that using a rigid and structured approach is very effective at developing safety critical systems. However the cost are usually exorbitant and in the average software development this approaches does not work very well. It is in this context the the term Craftsmanship has been introduced and compared/contrasted with the term software engineering.

Craftsmanship is a solution to the problem of delivering robust, high-quality applications to users in a relatively short time for reasonable cost. 

Software engineering is a solution to a different set of problems, involving life or safety-critical systems, real-time and embedded systems, and systems engineering projects. In these types of problems craftsmanship approach is not the best one. Incremental development and evolutionary delivery are not feasible strategies.

Other sentences about this topic:

Good enough software is a logical extension of the ideas of software engineering

Software engineering makes us forget that what really matters on a project is the skill, knowledge and experience of the individual software developers.

Craftsmanship is not a rejection of science and engineering, but rather a subtle blending of man, machine, and knowledge to create useful artifacts.

Software craftsmanship is a mindset and an attitude, rather than a body of knowledge.

This is the main point. At the foundation of everything, regardless of if you consider yourself a craftsman or engineer, there is the constant interest in improving yourself, in becoming better in what you do and learn from others and share with others. 

Learning and mentoring is a big topic and the following are significant sentences:

Working with masters is the best way to learn a craft.

Learning from each other is an essential part of software development.

Learn how to collaboratively deliver software is one of the key challenges new developers face when they start working on real projects.

Software development works best when the developer has a deep understanding of the requirements, design and source code.

Claims that good developers can pass the certification exams are made, but the hidden implication that passing the exam means you are a good developer is really the classical problem of confusing correlation with causality. The fact that a developer has passed a certification exam says nothing about that person's ability to develop a useful application, only that he has learnt how to pass the exam.

The concept of a single, responsible engineer signing off the complete work is not feasible for software.

If a person became an apprentice to a great developer instead of studying for a degree, maybe the outcome would be even better.

Rather than being known for their degrees, memberships, or certificates, the real credentials for developers consist of the applications on which they have worked.

Enthusiastic beginners not only renew the craftsmen, but also challenge the craftsmen by bringing in new ideas from outside. The power of this synergy has to be felt to be believed.

One of the traits associated with true mastery of any craft has been humility. Master craftsmen are always willing to learn and are able to admin their own mistakes.

Master practitioners ask lots of questions and then deliver what you really need (as opposed to what you actually asked for).

The key questions is: "Has he infected his colleagues with his enthusiasm and passion for the craft of software development?".

By reading and asking intelligent questions, apprentices will be able to pick up most skills without being formally taught.

Maintaining and enhancing live applications give journeymen the best environment for improving their craft.

Experiences developers should be involved in the creation of training courses for other developers.

Practise without feedback just reinforces errors.

In found particular interesting and challenging the following:

Software craftsmanship rejects the software engineering notion that it is impossible for one person to know the entire system. Instead, it celebrates virtuosity and talent.

One of the keys to high productivity is in-depth knowledge of the entire application

It is actually a fact that the most effective people on a team are usually the people that know a lot about the system. The problem here is how can you achieve this, how can you improve the communication across developers in order to achieve more productivity. The following sentences is an answer to this question but is it feasible?

Working in a closely knit team where everyone reviews one another's work on a daily basis means that, even without trying, a journeyman will gain a real breadth of experience about software development.

The software engineering metaphor makes us believe that software development is manual labor. It makes us believe that the division of labor is a good thing that should be used in software development. It makes us believe that there are standard best practises that everyone should adopt. This notion is not true, however.

By creating artificial specialities with narrow skill sets, software engineering makes it impossible for one person to understand the entire application. Rather than encouraging developers to cross-train so that they can understand all of an application, software engineering promotes the myth that what is needed instead is good documentation. Unfortunately, although documentation is very good for recording decisions and agreements, it is a very ineffective way of preserving and communicating detailed knowledge of how a software application actually works. Software engineering has given documentation a very bad name. Many projects practically run without any documentation because inexperienced developers rebel against this software engineering view.

I understood that the key here is to have small teams of great and passionate developers that are usually much more effective that a huge team with average developers.

Small teams produce better software.

Journeymen prefer to work in small team. There is little value in being part of a very large team, because their contributions are unlikely to stand out.

Software engineering fails to pay attention to the most important component of the software development process - the people. The most likely reason for this omission is that individuals show up only in small teams.

Technical knowledge is mush less important than the ability to integrate well with the rest of the development team. 

If co-location is impossible for your project as it often is for truly global projects, you need to pay special attention to communication. Make sure that you take the time to gather people together so that they can get to know one another. Although travel costs may be high, they will be offset by fewer misunderstandings and much smoother communication when people return to their normal locations.

One really good developer is more valuable to your project than five average developers.

It is a good practice to reward exceptionally productive developers, because they make the difference between success and failure.

An another important topic in the book is the relationship between users and developers:

It might seem counter-intuitive, but designing for a single user is the most effective way to satisfy a broad audience. Develop a close working relationship with a small number of users, and then create the best possible application for these users. Then the application will be ready for release to the mass market.

Customers just have to start insisting on high-quality, robust software and choosing their developers based on their reputation for delivering that kind of software.

Craftsmen enjoy being able to delight their users with the speed with which they can make changes.

A professional care about the quality of his job and base his reputation on that:

Craftsmen build their reputations based on the quality of what they deliver to their customers.

It is better to have a functional, rock-solid, minimal-feature release than an unstable, buggy release with features that don't quite work properly.

Good developers know how long things take and are rarely willing to sign up for delivering the impossible.

It is hard to find developers with 30 or more years of experience. Few remain as developers for a long time. This exodus is a real problem.

You should encourage you developers to get involved in local user groups and technical associations.

Once a developer is confortable presenting locally, the next step is to start presenting at conferences.

Technology is an another important topic related to the application lifecycle management:

Software craftsmanship values long-lived technologies and programming languages.

Very few applications have a planned life of less than five years, whereas few software development tools are designed to be stable over that time frame.

Why don't developers focus their attention on becoming really good at using the existing tools?

Think long and hard about why you want to use a new technology.

Treat software as capital. Make maintenance a priority during the initial development.

Start making your applications testable.

If you are going to build in flexibility, make sure that it will be needed. If you cannot predict how much flexibility will be needed, then make the application as easy to change as possible.

Consider whether your development tools are likely to remain stable for the lifetime of the application.

The major challenge when designing for testing and maintenance is to build sufficient diagnostics and instrumentation into an application.

The challenge the software craftsmen face is one of keeping up with all of the evolving technology so that they can create high-quality, robust applications even when using bleeding-edge technologies.

I would like to finish with some extra general sentences:

Good developers are more valuable than their managers.

Craftsmen take pride in completion.

Trust the craftsmen you know to recommend other craftsmen.

Evaluate Craftsmen based on their reputations and portfolio.

Creating an orphan application is not a good way to enhance one's reputation.

This book inspired me and I hope you found this summary useful and interesting. Everyone of this sentences is a good starting point for a discussion so feel free to add comments. I am eager to know your opinions on this topics.