Software Craftsmanship vs Software Engineering

자료: http://andymaleh.blogspot.com/2008/12/software-craftsmanship-vs-software.html
tuesday, december 09, 2008

***

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 process of choice for accomplishing that goal. Later, iterative processes such as the Rational Unified Process became better agents for accomplishing it. Finally, the agile movement with XP and Scrum provided the most effective practices for accomplishing that goal.

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

While engineering is about the macro goal of delivering economical software that is reliable and efficient, 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. Traditionally, the majority of software developers took a degree in Computer Science, Computer Engineering, or Electrical Engineering, and then proceeded to work after graduation with very little practical experience beyond relatively small school projects. Such developers tend to follow a lot of the theory they learned without personal validation or playing around outside the box of their education. Unfortunately, this ends up teaching them the hard and expensive way that they cannot take everything they learn for granted as they eventually remember that theory is simply distillation of reality and may always go out of sync or become inappropriate for certain work projects or situations.

Craftsmanship on the other hand is more about learning the skills gradually and practically with the guidance of a skilled journeyman or master while working on real projects. Theory is still useful in that case in the form of supplemental reading, but practical work always ends up validating the theory or revealing its weakness in a certain setting. 

That said, going the academia route is not in conflict with Software Craftsmanship as long as students end up validating their skills in the real world during their education or shortly afterwards (e.g. open-source projects or internship projects) with the guidance of other developers in the software community. That was the route I went in fact, and I'm greatly appreciative of the guidance I received from Kevin Taylor and Dave Hoover who are strong believers in craftsmanship 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.

Posted by Annas "Andy" Maleh at 8:04 AM