Software Craftsmanship: The New Imperative

I struggle to find the right way to express how to make software development right.  I can’t say that I subscribe to every idea that is put forth by Software Engineering.  The Software Engineering Institute does drive software development forward.  However, having had the opportunity to listen to a few of the speakers that work for the SEI, I can’t say that I feel like they’re in touch with reality.

The appealing thing about this book, Software Craftsmanship- the New Imperative, is the opportunity to take a different perspective towards software development.  I’ve always felt in some ways that building software was about getting a feel for the users, the technology and making them come together.  The idea that you don’t build software you craft it is certainly appealing.

The whole book puts forth the idea that we think about software wrong.  We take the few examples of large projects and expect that the experiences gained there will apply to every software project.  There have been numerous observations that the software development practices that we know, from these observations, lead to better software are routinely ignored or not followed.  Although there are many reasons for this, the reality is that we don’t do what we are taught to do.

The other end of the spectrum is the apprenticeship model that’s practiced in many other professions either from a formal structure or informally. Most trade professions have some sort of a process from taking apprentices and making them into professionals.  This is an approach that the author proposes we should be doing with Software Development.

In my own experience, I can say that both are needed – and the idea of software as a craft is widely under discussed in professional articles and books.  Despite this it’s the primary way that I teach, and learn, about software development and how to make it better.  As a coach and mentor I train developers to remember to watch error handling, to test, to think about boundary conditions, to care about the resulting code, and all of the things that make up good software.

They learn not through the one time reading and single verbalization of these ideas but through the continual reinforcement of the ideas and the continued application of the ideas to their work.

I learn through work with my colleagues.  They teach me their approach and I teach them mine.  Whether I alter my approach or they alter their approaches, we’re both better for the exchange.

The book is somewhat repetitive in places and over the top in others, however, it’s a good read if you can put aside the details and focus on the core message and evaluating it against the way that you do software development today.