The other day, someone on the Crafters’ slack posted a video where someone argued about software craft vs. engineering and asked for opinions from the community. Let’s elaborate on my reaction to watching that video.

Just in case you want to see the original video for yourself, here you go:

Go ahead, I will stay with my thoughts until you watched it.

Edsger W. Dijkstra

First things first. In the video, the author references Edsger Dijkstra yet fails to point to a more relevant piece from Dijkstra for the topic of Software Craft. I recall lots of discussions on the Software Craftsmanship mailing list late in 2008 and early in 2009 when the movement started to take shape. The piece discussed heavily back then was On the cruelty of really teaching computing science authored in 1988.

Dijkstra’s main point here is how universities are good at producing scientists, not necessarily good software developers. Companies in the software field, however, are looking for more software developers, not scientists.

Pete McBreen tried to come up with an answer to this problem described by Dijkstra. Actually, he wrote the book Software Craftsmanship – A new imperative as a reaction to this to solve the basic education problem for good software crafters. This book motivated Uncle Bob Martin to take on his son Micah Martin as an apprentice and prepare him for the software development field. Micah Martin later on founded 8thLight in Chicago on the premise of taking on new apprentices and helping them in their journey to become journeymen and maybe eventually masters in the field. Some of the early discussions that led to the Software Craftsmanship movement were taking place in 2008 at the 8thLight offices in Chicago, and in 2009 8thLight swapped some of their crafters with crafters from Obtiva, also located in Chicago.

Having been around for a while, I notice how this important part of the early motivation for Software Craftsmanship seems to have been lost to time. As the video author states while picking on the Software Craftsmanship manifesto, nowadays craft seems to revolve around “well-crafted code” and what the next shiny thing in the technical sphere might be to hunt after, or the next best way to test-drive your development.

Instead, the author picks on the results of the discussions we had when thinking about the Agile manifesto and the value pairs represented in it. Of course, value statements can be misguiding, as they are seldomly actionable on their own, and subject to interpretation for the reader. Or as Michael Bolton extended on an earlier Jerry Weinberg statement:

For any abstract X, X is X to some person, at some time.

Watching the video author arguing about the manifesto appears to be a weak argument here to me. In fact, back in the day we were fully aware of this fact and started to discuss our equivalent for the twelve more guiding principles behind the Agile manifesto. To recite them from my earlier treasures of Software Craftsmanship entry:

We Care
We consider it our responsibility
  to gain the trust of the businesses we serve;
    therefore, we
      take our customer’s problems as seriously as they do and
      stake our reputation on the quality of the work we produce.

We Practice
We consider it our responsibility
  to write code that is defect-free, proven, readable, understandable and malleable;
    therefore, we
      follow our chosen practices meticulously even under pressure and
      practice our techniques regularly.

We Learn
We consider it our responsibility
  to hone our craft in pursuit of mastery;
    therefore, we
      continuously explore new technologies and
      read and study the work of other craftsmen.

We Share
We consider it our responsibility
  to perpetuate the craft of Software;
    therefore, we
      enlist apprentices to learn it and
      actively engage other craftsmen in dialogue and practice.

All of that is not taken into consideration by the video author which makes his whole argument on why crafting is something he would rather not identify himself with a strawman argument for me. I would even claim that he did not get the notion and background of what motivated us back in the day.

Hindsight is 20:20

Looking back nearly 15 years later, I get another clue about what happened back in the day. Uncle Bob Martin held a keynote at the Agile 2008 conference on the forgotten fifth element in the Agile manifesto:

We value craftsmanship over crap.

Later on, that one got refined to “We value Craftsmanship over execution” as for the other value pairs in the Agile manifesto, the right side has some recognized importance, and that obviously does not hold for crap.

As Gojko Adzic describes in his blog entry from the keynote, he could see just this problem happening back then. Visiting the vendor booths at the conference, there was a higher emphasis on things the whole Agile movement did not stand for at all, i.e. the shiniest tool for managing your Sprint Backlog, Agile Project Manager education, and stuff like that.

In hindsight, I would claim that the Agile movement had high influences from the organizational culture in the competency culture of the Schneider model. Around 2008 that competence domination was taken over by more and more people from a control culture background. Uncle Bob Martin sparked a new movement dominated by the competence culture in the Software Craftsmanship movement as a counter-force to the Agile tool-vendor-driven era we were about to enter. By his own experiences, Uncle Bob had trained apprentices for quite a while at the time, and sought to overcome the “at least my work does not stink as much as it used”, or motivate investments into the delivering zone in the Agile Fluency model.

To some extent, it worries me how this early inspiration got lost merely 15 years down the road – of course also thanks to such strawman arguments as made in the video.

The author put Dijkstra in there, yet fails to recognize the motivation for using the craft analogy in Pete McBreen’s book and how it all got started: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html I think the author lacks some important nuances on where it came from. My read in hindsight is to re-focus on competence once the control culture started to more and more dominate the Agile community at large in 2008.

His whole argument is somewhat weak as well. “Engineering” vs. “craft” vs “art” is just using analogy to talk about some things that are similar in other fields, while of course, some things are different. Software development is neither craft nor engineering nor art in all ways you can think of. I think Chris McMahon wrote something similar on Software Testing as well, either in Beautiful Testing or How to reduce the cost of Software Testing. Craft vs. Engineering is a false dichotomy. As the author explains in his video, Engineering supported Margaret Hamilton to gain respect from rocket engineers at the time. Craft helps to solve the problem of educating good software developers. Both pick on some technical nuance to solve a particular problem. Neither is a complete picture on its own of what software development consists of.