Software Craftsmanship
– Between Science, Engineering and Art

November 22, 2016 Paweł Zajączkowski

We have been creating things for thousands of years. We’ve drawn pictures on cave walls and papyrus, built castles and bridges, forged horseshoes and swords, constructed mathematical proofs and research equipment, written poems and novels, designed ships and factories. And, for a brief amount of time, we’ve been developing software. Let’s look at how it all started, evolved, what software development actually is and why it is important to understand this.

Computer science

First, there was the science. It depends on the definition, but we can assume that the first computer program was written over 150 years ago by Ada Lovelace for Babbage Analytical Engine, not actually built until 1990. Modern computer science was born way before we had any computers – it was pioneered in the thirties by Alonzo Church, Stephan Kleene, Emil Post and most profoundly by Alan Turing. The first Turing – complete machine, the Z3, was constructed in 1941 and the first fully electronic one, ENIAC, in 1946. First people to write (or punch) computer programs were scientist in white coats. Since access to these machines was very expensive and limited, the code, or machine instructions, had to be constructed very carefully and under mathematical rigor. If you made a mistake, you were likely to wait a few days to have another occasion to run the program, so the hey let’s code it and see if that works approach was largely ineffective. There were very few people who were doing this and they were creating alongside the scientific field.


When computers became cheaper and more popular, more and more people were programming them, not necessarily in connection with any sophisticated science. Today we have millions of programmers, most of them just pushing data from database to frontend and back again. Ask how many of them developed a new algorithm this year. I’m not saying we are not creating anything new of course, there is plenty of new technologies every month, but mostly it’s not really a science anymore. It’s different.

Software engineering

As science was fading away, and the business (or military, remember that the first computers were used for ballistic tables calculation) grew, we started to create larger programs and systems. There was a need to organize a team, or multiple teams, in order to achieve a goal of writing a program with a complexity beyond capabilities of a single mind. A new profession was thus born: the software engineer. A person with some scientific knowledge to understand what to do, but mostly an engineer who has to create a source code in particular programming language. The source code that allows to build the final product: list of instructions for physical machine. We can think of it as the design. While in classic industry we have engineers who design goods and workers who manufacture goods based on the design and using machines, in software development we are working on the design all the time, coding, rewriting and testing. The manufacturing process is cheap, it’s just a continuous integration system which takes source code and manufacture and deploy the product automatically over and over. It’s one way to look at this.


However, the traditional approach to software engineering in sixties and seventies was to create a monstrous paper design up front (think: “true” engineers) and hand it over to programmers (think: “true” workers) to write code. It is an approach taken from the factory, where engineers and managers optimize production and tell workers exactly what to do. But writing software is not a repetitive manufacturing process. It is the part of design. In the end, the source code is an exact design of software. This is why modern agile methodologies emphasize importance of working software over extensive documentation. You need exact and extensive documentation for the tank in order to hand it to the tank factory to build tanks for you. You don’t need piles of papers to create software. Of course, some documentation is important for a software project, but what you mostly need is a source code to hand it to your CI system which will build you the software exactly like you want it. Or at least how you coded it. Manufacturing is fully automated, cheap and repeatable – as many times as you want. Each time you can manufacture one copy, or a million, it doesn’t really matter much. The process of writing software is not really manufacturing or engineering anymore, it has something more to it.

The art of programming

“The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music.”
Donald Knuth

Donald Knuth wrote eponymous The Art of Computer Programming and is known for his comparisons of software development to art. Are we artists then? According to some tax laws yes, but let’s not go that way. We are building things that are unique, require imagination and creativity and are often beautiful. This beauty can be a result of a nice graphical user interfaces or other visuals (e.g. in game programming) but it can also mean technically beautiful. We can look inside the system, at particular piece of code and tell if it is pleasant or not. But the same can be done with bridge or car design. Or a mathematical proof for that matter.

Art is sometimes put in contrast with science in such a way that science is knowledge and theory which art is skillfully putting into practice. The original Latin meaning of art, or ‘ars’, was ‘skill’. For sure, software development requires skill, but so does many other things. And many other things are called arts.


I like the comparison to martial arts here, which became somewhat popular with the raise of agile. Think of programmers as warriors who are honing their skills and perfecting their art through years of training, practice and commitment. There is an idea of kata in martial arts, where you repeat choreographed movements over and over until they become your second nature. Similarly, there is an idea of programming katas, where you solve the same small problems and use programming idioms over and over again until they become your second nature. Muscle memory.

Martial artists need many skills and talents to be effective, not only the knowledge how to execute a set of particular techniques well. There is reflex, balance, fitness, strength, speed, awareness, patience, humility, leadership. Software developers also need much more than simply ability to code in particular language. There are networks, databases, hardware, environments, tools, technologies, frameworks, algorithms, precision, curiosity and soft skills but also engineering practices and scientific understanding. Software development seems to be somewhere between art, engineering and science.

Software craftsmanship

In 1992 Jack Reeves suggested, that software development is more a craft than engineering discipline and drawn a parallel between modern programmer and medieval craftsman. In 1999, in the first book under the Pragmatic Programmer label, Andrew Hunt and David Thomas talk about the developer path from apprentice through journeyman, true craftsman to master. We could compare it easily to typical programming job grades like junior, regular, senior and lead. However, people often don’t understand, especially in younger software development markets, that being a developer can be proper and successful way of career for the entire life. It is common practice instead, to think like: “Oh, I will code for a few years and then I have to go into management to get better money”. Software development and management are two different, parallel paths. The idea that one is extension of the other comes from traditional factory management where you start as unskilled worker and if you are smart and patient, you can work out your way to the office and tell other workers what to do. But mind that we are nowhere near the factory. Today’s manager job is to help as much as possible and remove obstacles, not to instruct software developers. It should be normal, that manager “manages” software craftsmen who earn much more money than she is. It’s utterly ineffective to force a competent technical person into pure managerial position just because there is nowhere else to go up. These are different paths; I can’t stress this enough. Of course, with experience, craftsmen tend to take up leadership roles, but it’s about leadership, not management. About guiding less experienced fellows and helping them in their own path to mastery. There is also an idea of The Coding Architect. A person that despite vast knowledge and higher pay grade, still sits with the team and writes code daily, instead of being on top of ivory tower, dropping silently UML diagrams on those below him.


Craftsmanship is about attitude. True craftsmen care, spend their private time and money to get better at what they do, because they love what they do. They willingly share knowledge, form professional communities and stand behind their creations. It’s not about sitting at the desk from 9 to 17, doing dull tasks and forgetting them instantly after work. It’s about understanding the purpose of things, real client needs and striving to refine the surroundings, be it source code, environments or processes. True craftsmen advise and educate their clients about effective software development, because it’s their domain. And they are not afraid to say “no” if needed.

So what?

What is the point of all those philosophical disputes? Efficiency. Psychologically, most people have an innate drive to do their job well, to achieve mastery, to have a purpose and autonomy. Sitting at the keyboard for 8 hours and being told to do detached series of Jira tickets is no way to go. As a result, software products are delayed and of mediocre quality, clients are unhappy, developers are unhappy, managers are unhappy. No one wins. All it takes is a slight change in the mindset on both sides. Programmers have to realize that they, not their companies, are in control of their path. Leaders should support that and guide programmers instead of attempting to control them.

For further information on this topic you can refer to two nice books on the subject, by Pete McBreen and Sandro Mancuso, or to the Software Craftsmanship manifesto itself.

Photo Credits: Andreanna Moya,

Last posts