Software Craftsmanship vs Software Engineering

I often hear a reference of Software Craftsmanship mentioned in opposition to Software Engineering, and I wonder: Are they really in conflict with each other?

The word engineering often gives people the feeling that a bunch of engineers are working very hard on a drawing board to solve big problems and come up with complete execution plans before getting to the implementation phase. Craftsmanship on the other hand gives the image of an apprentice humbly climbing up the ladder of competency by learning the craft step-by-step with a journeyman or master who is quite comfortable with delivering value to the customer.

Now, these are the touchy feely aspects of those two terms, and I can appreciate people leaning towards craftsmanship and seeing it in opposition to engineering with that regards.

However, I believe there is real value in knowing what software engineering is truly about as opposed to simply a common feel about it.

Here is one of the original definitions of Software Engineering (Naur and Randell, 1969): Software engineering is the establishment of sound engineering principles in order to obtain economical software that is reliable and works efficiently on real machines.

At one point, Waterfall was the only process for accomplishing that goal. Later, iterative incremental processes such as Boehm's Spiral Model and the Rational Unified Process became other agents of accomplishing it. Finally, the agile movement with XP and Scrum provided the newest practices for accomplishing that goal.

Now, with that definition in mind, is Software Craftsmanship in conflict with Software Engineering at all? No. Does Software Craftsmanship help with accomplishing the goal cited in the definition of Software Engineering? Yes.

While Software Engineering is about the macro goal of delivering economical software that is reliable and efficient, Software Craftsmanship is about the micro process that can help with achieving that macro goal.

One thing that can actually be considered the opposite of Software Craftsmanship though is academia without practice. Software developers study for a degree in Computer Science, Computer Engineering, or Electrical Engineering, and then proceed to work after graduation with very little practical experience beyond relatively small school projects. Such developers might follow a lot of the theory they learned without personal validation or playing around outside the box of their education. Unfortunately, this might end up teaching them the hard and expensive way that they cannot take everything they learned for granted without also properly analyzing the situation they are trying to address. Eventually, they remember that theory is simply distillation of reality and may always go out of sync with it as new knowledge is added or become inappropriate for certain work projects or situations without some new practical learning to augment it.

On the other hand, practice without academia is equally problematic and is the anti-thesis to Software Engineering. Aspiring programmers who do not learn the ins and outs of Computer Science and Software Engineering while attempting to apply Software Craftsmanship alone will end up perpetually deficient in basic software engineering knowledge and skills, and will get permanently stuck below true software engineers. That is software engineers who were passionate enough about their field to go through a 4-year computing-related degree joyfully (e.g. Computer Science, Computer Engineering, Electrical Engineering, Information Systems, Software Engineering, Math, or other fields of Science and Engineering that require computer programming), thus know both theory and practice, and can produce superior software. That is because they know that all theory is simply distillation of reality, and can always translate into practice. Those who do not understand that very simple fact and might blame academic education for being too theoritcal sadly miss the point of education altogether, and can never truly thrive in their work as much as those who do understand both theory and practice.

So, Software Craftsmanship is about learning software engineering skills gradually and practically with the guidance of a skilled journeyman or master while working on real projects, but only after having mastered the theory. Theory provides an invaluable shortcut to learning the lessons of millions of software engineers around the world faster in a distilled fashion. Afterwards, practical work validates the theory or reveals gaps in it under certain settings that need practical exploration to implement the right solutions.

As such, going the academia route is not in conflict with Software Craftsmanship at all. In fact, academia provides students with a faster path to excellence. And, if they apply Software Craftsmanship practices too along the way, they end up validating their skills in the real world during their education (through internships and open-source projects) and/or shortly afterwards (e.g. through real work) with the guidance of other experts in the software community.

That was the route I went in fact, and I am greatly appreciative of my Bachelor in Computer Science education at McGill University and my Master of Software Engineering education at DePaul University in addition to the on-the-job guidance I received from Kevin Taylor and Dave Hoover who are strong craftsmanship practitioners at Obtiva.

So to recap, Software Engineering is not about over-engineering or heavy-weight processes like Waterfall; it is about delivering economical software that is reliable and efficient. Software Craftsmanship is therefore not in conflict with Software Engineering, yet in fact in harmony with it as it helps accomplish its goal through practical learning of software development with the guidance of experienced developers.