Software Craftsman creates useful and enticing systems.
(entice - verb: attract or tempt by offering pleasure or advantage.)

Craftsman vs Engineer

A bucket and a bucket

a bucket and a bucket

An Overlap

Engineer solves problems by making useful things. He cares how effective the thing is for the problem. Well engineered thing is also efficient and reliable. Craftsman is also an engineer, but he makes things that are enticing to use, not only serve a function. Well crafted thing is also a well engineered thing, but you, a user, have a clear preference for one of them.

A beautiful product that doesn’t work very well is ugly. Jonathan Ive🡕

Difference

Engineer makes generic and versatile things. The more the thing is usable in different environments the better. It doesn’t matter who uses it. Craftsman, on the other hand, cares deeply about how fit the thing is for the target user. It is tailored for him.

Fundamentally, sensitivity to the context - where it is used and by whom - separates a crafted thing from an engineered thing. Engineer optimizes for efficiency and versatility. Craftsman strives for fit and attractiveness to the user.

The difference is substantial. Craftsman needs to take perspective of the user to make a thing useful, just as an engineer does. But to make a thing enticing to use, craftsman needs to understand the psychology of target environment and the target user.

This understanding and care is what separates craftsman from engineer. Craftsman is user sensitive, while an engineer can and often does play a more self indulgent game of making things efficient for it’s own sake, agnostic to the context of use.

A touch of artistry

Craftsmanship is an amalgamation of engineering and artistry. But to make a thing enticing to use, not just useful, it has to have a sort of a character that entangles the user. Adding this character is where artistry comes into play.

You become a craftsman when you can and want to be artistic in what you do.

The trick in this art is to make it fully about the user and the use, not about yourself.

Software Craftsmanship - a natural fit

Here’s the thing though - the reason I am writing this post: craftsmanship is not only useful but a crucial concept for building IT systems. It is crucial because the substance from which we create systems - information - is so malleable. It is all thought-stuff. There are no mechanics and physics that drives and constrains our thinking, like say in civil engineering. That’s why Information Technology is an excellent matter for a craftsman. It is very fit oriented.

This fitness is found through understanding the users and the environment of use - the domain. Fundamentally, information is data in use. The use, use’ability, use’cases, use’r - is the single source of constrains, inspiration and opportunity to be use’ful. The fit to the domain is the fundamental concern for IT system creators. You have to craft that system.

Understanding Driven Development

Due to complexity of domains, often contrived, this understanding process has to be an iterative, discovery, trial-error learning experience. It is done directly between craftsman and the users who “try-on” the system in the making. The skill in this iterative process is the only thing that will also make you a good software systems engineer. Every other knowledge or skill, of which you need lots of in IT, is secondary to it. Everything else will align itself to this fundamental skill of understanding. Eric Evans (the DDD guy) calls this process knowledge crunching🡕.

At the minimum, understanding the essence of the domain, will allow you to create a simple model of it in code. Simplicity is not easy. Fundamentally, it is about untangling of concepts and events and putting them into right places. What matters more goes into foreground - the core domain, what matters less is pushed into background - generic subdomains.

In essence - a good design is a simple design. Simplicity is the thing that will make your system reliable. Reliable systems are maintainable systems. Simplicity will make your system modifiable, extendable and, less intuitively perhaps, it will make it performant. It is because well designed system uses resources for the things that are actually required, and for little else.

Simplicity is the minimum benefit you can offer from this iterative understanding process. It is one big minimum. Distilling this simplicity into your model is really gratifying. You are fitting your system with users.

The reason software craftsman strives for a simple, well-fitting system though is that well-fitting system is the bedrock on which an enticing system is built. That’s when the real fun begins - you are crafting a system that offers opportunities.

Craftsmans’ drive

The driving question in Understanding Driven Development is: what is the most useful and usable for users of the system.

The driving question sounds simple because it is. It is not the question that is asked in a typical Playground IT though. If the above question is driving your thinking, if you go with it to the end - you will create an enticing to use IT system. A system that is super-fitted to its users.

You will not barf-out a bunch of data for the user to sift through (a typical scenario of Playground IT systems where nerds push their toys onto users). More likely, you will present an opportunity to the user of your system through Inductive UI.

This doesn’t only apply to systems with UI, not at all. Clojure programming language is a great example of a well crafted IT tool. As crafted things are, clojure is sensitive to the context of use. It has an opinionated fit to it. The fit is for data-centric systems. If you accept that context and put data in command - clojure will entice you with it’s affordances. You will notice that you are pretty much writing prose in clojure. Prose about sculpting and transforming data. It just feels good.

On the other hand, tools that come from google engineers are excellent specimens of just that - IT tool engineering. Kubernetes comes to mind as a prominent example. It is generic as long you are deploying containers - who isn’t nour days. It is not sensitive to the context - what is running in them or who is using it. In fact it’s power is in its genericity. It is performing it’s function in this self contained space. And does it really well.

Typically, software craftsman is dealing with a complex domain. So anything that doesn’t help in making the system fit, useful and enticing to use is a nuisance - complexity that annoys him. Software craftsman weeds-out complexity not only from his system. Software craftsman knows value and importance of the right tool. Right tool is fit and precise for the problem he is solving. You will often, not necessarily though, find him using a low-tech tool because it is providing that precision.

High-tech tools attract low-tech people.

This drive for simplicity is again in complete opposite to ubiquitous playgrounds where nerds are playing with their IT toys and pushing them onto users.

Rebellious Teenagers of IT

Craftsmanship is not invented in IT. It was however hijacked by loud-mouth recommended practice sellers of our pop culture driven industry. It is not due to their malice or even salesmanship. To understand our recommended-practice-driven-practitioners, lets look at what they are saying. Their message, the key word in it is - “professionalism”.

Now, this should already be giving you a clue about their game and the setup. It is not for example “creativity”, not “simplicity”, not “user-centricity”. Not even a sellable buzzword for user-centricity - “Domain Thinking”. There is nothing in there about the fit and care for the user.

Don’t believe me? Take a look at their manifesto🡕. First sentence: “Raising the bar of professional software development by practicing it”. The manifesto, in essence, is a collection vacuous managerial talk with added tribalism of “community of professionals” veiled in a cloak of nobility with “craftsmanship”. The community will accept you (you will reach the bar) if you practice their “professional” practices.

Our loud-mouth-recommended-practitioners illustrate professionalism with examples:

Such analogies are hopelessly unfit for creating software systems from pure thought-stuff. I would say they are absurd actually. But we are trying to understand our recommended professionals here - not call them simpletons.

The key understanding from their analogies is that by “professionalism” they essentially mean training. A book The Checklist Manifesto🡕 is touted among our well-trained-practice-practitioners as the manual for utmost professionalism. “It is a mandatory read for pilots!”.

I really do want my pilot to go through his professional checklist. A surgeon probably even more so. But it won’t be a concern when choosing an architect for my house. Or a garden designer for my new dwelling. And certainly not when I am choosing a problem-solver/opportunity-creator for my organization, who is likely using IT as his instruments. In fact, if a candidate is putting to the foreground his processes and practices I will recognize a playground nerd.

I keep coming back to how inapt their thinking is for crafting software systems. But this gives plenty of understanding of our practice-performer-checklist-tickers’ minds. Their game is not even remotely about craftsmanship. They are glorifying their routines. They are playing with themselves, but this time in tribes of “cool” rebellious teenagers.

The Professionals

Does this sound familiar - “I did a recommended practice - therefore the result is good”? Yes! It is our Nerds’ Playground! As you know, nerds’ playgrounds reside within Managers’ Dollhouses. In the context of Managers’ Dollhouse, the word “professional” is actually fitting and organic.

Managers love “professionals”. They do what they’ve been told. They perform tasks in predictable, controllable, safe processes. And most importantly - they are accountable. Accountable from the word “accounting”: you’ve been given this much resources (two weeks of time, typically) - now you owe me this much features. In accordance with the “agile” process, professionals have to commit themselves to the number of features every two weeks. Conveyor is running - the “progress” is guaranteed.

Our professional-routine-devotees are playing into infantilized, simplistifi’ed Managers’ Dollhouse game! To understand them, we need to see their role in this context.

Recommended-practice-driven-developers are rebellious teenagers in a Manager’s Dollhouse who rebelled against their stupid daddy - the incompetent manager.

To be fare, the Dollhouse Manager really is grossly incompetent, at least when it comes to crafting IT systems. But his innate go-getters’, simplistifi’ers’ thinking is that building an IT system is done by hiring pools of programmers. His pool will be assembled from large, safe, competence-pools of the market. Market competence-pools filter for conformant, generic, expendable, safe resources (programmers) who will build a system for him. The bigger the pool - the larger the supply - the faster the progress.

Resource supply - tick, resource safety - tick, resource costs - tick. Economies of scale. Just as in the best-of-breed MBA training. He is kind of beginning to feel proud of himself. What’s the problem? …And then the Agile happened.

And then the Agile happened

Agile movement was a rebellion of the resources. The Agile Manifesto🡕 is a masterfully packed little bomb of understanding for the culture of software development. In essence, it is a culture of trust. Trust between management and programmers. Between customers and the programmers. Especially notice the last point: “Responding to change over following a plan”. It requires responsible - “response’able” people to respond to change.

As we know, our simplistifi’er go-getter manager is not in a business of trust. He is in a business of control. Ironically, the message of trust had zero chance to be reified in the system he is in. Responsible people have to be trusted. He cannot do that. He needs accountable resources. That last bit of the last point - “over following a plan” - is particularly blasphemous for him. His plan has to be at the centre.

Thing is, the “trust” was already simplistifi’ed. It was quantified and negotiated with go-getters/simplistifi’ers on the customers’ side and put into contract. Though the contract is “Agile” now: what was promised to whom will be duked-out by both sides throughout the project. On the “Agile” side, Product Owner will hold the fort, or will try to sell more complexity to the client. Depending on the contract. In either case the system will not be built for its users.

The “Agile” was simplistifi’ed to do exactly the opposite. “Doing agile” means to control for adherence to managers’ plan. Notify him if something is slipping from it and course-correct. By sourcing more resources for example.

But what about all that other stuff that goes with “Agile”? What about autonomous teams? What about sustainable pace? What about technical excellence, good design and simplicity? The agile movement is demanding that resources have a say too! There’s a mutiny brewing in Managers’ Dollhouse. To “do agile” our simplistifi’er has to give them some voice.

This is where our professional-practice-practitioners come in.

The Clean Practice Game

As we know, devs that Managers’ Dollhouse self-select, love to give away their responsibility to the processes and rules. That’s what makes them “manageable” a.k.a accountable. But now, the dollhouse nerds have heard that the good ones do TDD. The good ones are doing SOLID and microservices. The ones that are doing good practices are clean developers and the ones that don’t - are dirty developers. The dollhouse nerds now have their own processes and rules - The Clean Practices. They are big boy professionals and don’t have to listen to their stupid incompetent daddy - the dollhouse manager. They don’t have to ask daddys’ permission to be “professionals”.

They are rebellious teenagers of the Managers’ Dollhouse. Like teenagers tend to do, they band together into tribes of rebels alike. They even have a “cool” uncle in there who teaches them the rituals of “professionals”.

Their message is tribal, cult like, because all you have to do is practice their practices to enter the tribe. The practices themselves are mindless. That mindlessness serves a purpose of initiation to the tribe. You have to give-away your skeptical, reasoning mind to enter. By doing that you are signaling the strength of your commitment to the tribe. In this respect they are flat-earthers of IT.

To see the mindlessness of their practices take a look at them with a skeptical, reasoning mind. SOLID stands for what? Besides S, which says separate things have to be separate - thank you professor - what do those things have to do with good design? Do they lead to good design? Two of them are only fit for object oriented paradigm for example…

Take a look with that mind at TDD. Why are we talking about it? It is not even an idea, it is somebodys’ way of doing things. It is not about testing either… Testing whether a hypothesis you wrote in code works is done by a responsible person. Managers’ Dollhouse filters-out responsible people. It selects for accountable people. If you demand that the dollhouse dev has to account for testing - he will write tests. And then write code that passes the tests. Does that lead to well designed, enticing, simple system? Or will it lead to the testable system that pushes the “clean”, tested function of it onto the user? The clean, “professional” dollhouse dev will even use it as a point of pride: “Look how many tests I wrote! All of them are green! What’s the problem?”

Microservices… They have to be small. Small is good. Large is bad. Nuff said. P.S. My microservice is smaller than yours.

If you zoom-in further, there is a myriad of “antipatterns” that a clean dev is signalling his “professionalism” with. Switch statements that “have to be” refactored to visitor pattern, etc.. This is all superfluous to the understanding of our clean-practice-recommended-professional-practitioners. We have a picture of our infamous Playground Nerd. Completely self absorbed, without a hint of care for the user.

Illustration of Software Craftsmanship

Product companies are the main beneficiaries of IT crafsmanship mindset. But So far I found only two prominent examples of craftsmanship culture in organizations:

  1. The best example is Spotify: How Autonomy Saved One of Spotify’s Most Loved Features🡕. Notice how the search for fit is the central question for their developers. They’ve learned that nerd’y guesses about what’s going to work are mostly wrong.
  2. Second place goes to Netflix: A Day in the Life of a Netflix Engineer🡕. Notice how many times the user, usability, engaging the user, is mentioned in the talk. What do they say about management structure? They do call themselves “Engineering Driven Organization” to emphasize that the ideas come from the bottom. But the merit of those ideas are assessed only in the light of how they lead to crafting an entertaining system. They are an entertainment company, IT tools are just means to an end.

P.S. You don’t have to like people to enjoy understanding them.
[Add comment]