Preface

Before we begin, there are two issues we need to deal with in order to ensure that you, my gentle reader, understand the frame of reference in which this book is presented.

On the Term Craftsmanship

The beginning of the twenty-first century has been marked by some controversy over language. We in the software industry have seen our share of this controversy. One term that is often called out as a failure to be inclusive is craftsman.

I’ve given this issue quite a bit of thought and talked with many people of varying opinions, and I’ve come to the conclusion that there is no better term to use in the context of this book.

Alternatives to craftsman were considered, including craftsperson, craftsfolk, crafter, and others. But none of those terms carries the historical gravitas of craftsman. And that historical gravitas is important to the message here.

Craftsman brings to mind a person who is deeply skilled and accomplished in a particular activity—someone who is comfortable with their tools and their trade, who takes pride in their work, and who can be trusted to behave with the dignity and professionalism of their calling.

It may be that some of you will disagree with my decision. I understand why that might be. I only hope you will not interpret it as an attempt to be exclusive in any way—for that is, by no means, my intent.

On the One True Path

As you read Clean Craftsmanship: The Disciplines, Standards, and Ethics of One Software Craftsman, you may get the feeling that this is the One True Path to Craftsmanship. It may be that for me, but not necessarily for you. I am offering this book to you as an example of my path. You will, of course, need to choose your own.

Will we eventually need One True Path? I don’t know. Perhaps. As you will read in these pages, the pressure for a strict definition of a software profession is mounting. We may be able to get away with several different paths, depending on the criticality of the software being created. But, as you will read in what follows, it may not be so easy to separate critical from noncritical software.

One thing I am certain of. The days of “Judges”¹ are over. It is no longer sufficient that every programmer does what is right in their own eyes. Some disciplines, standards, and ethics will come. The decision before us today is whether we programmers will define them for ourselves or have them forced upon us by those who don’t know us.

¹ A reference to the Old Testament book of Judges.

Introduction to the Book

This book is written for programmers and for managers of programmers. But in another sense, this book is written for all of human society. For it is we, programmers, who have inadvertently found ourselves at the very fulcrum of that society.

For Yourself

If you are a programmer of several years’ experience, you probably know the satisfaction of getting a system deployed and working. There is a certain pride you feel at having been part of such an accomplishment. You are proud of getting the system out the door.

But are you proud of the way you got that system out the door? Is your pride the pride of finishing? Or is your pride the pride of workmanship? Are you proud that the system has been deployed? Or are you proud of the way you built that system?

When you go home after a hard day of writing code, do you look at yourself in the mirror and say: “I did a good job today”? Or do you have to take a shower?

Too many of us feel dirty at the end of the day. Too many of us feel trapped into doing substandard work. Too many of us feel that low quality is expected and is necessary for high speed. Too many of us think that productivity and quality are inversely related.

In this book, I strive to break that mindset. This is a book about working well. This is a book about doing a good job. This is a book that describes the disciplines and practices that every programmer should know in order to work fast, be productive, and be proud of what they write every single day.

For Society

The twenty-first century marks the first time in human history that our society has become dependent, for its survival, on a technology that has acquired virtually no semblance of discipline or control. Software has invaded every facet of modern life, from brewing our morning coffee to providing our evening entertainment, from washing our clothes to driving our cars, from connecting us in a world-spanning network to dividing us socially and politically. There is literally no aspect of life in the modern world that is not dominated by software. And yet those of us who build this software are little more than a ragtag batch of tinkerers who barely have any idea what we are doing.

If we programmers had had a better grasp on what we do, would the 2020 Iowa Caucus results have been ready when promised? Would 346 people have died in the two 737 Max crashes? Would Knight Capital Group have lost $460 million in 45 minutes? Would 89 people have lost their lives in Toyota’s unintended acceleration accidents? Would the 228 people aboard Korean Air 801 still be alive?

Every five years, the number of programmers in the world doubles. Those programmers are taught very little about their craft. They are shown the tools, given a few toy projects to develop, and are then tossed into an exponentially growing workforce to answer the exponentially growing demand for more and more software. Every day, the house of cards that we call software insinuates itself deeper and deeper into our infrastructure, our institutions, our governments, and our lives. And with every day, the risk of catastrophe grows.

Of what catastrophe do I speak? It is not the collapse of our civilization nor the sudden dissolution of all the software systems at once. The house of cards that is due to collapse is not composed of the software systems themselves. Rather, it is the fragile foundation of public trust that is at risk.

Too many more 737 Max incidents, Toyota unintended acceleration incidents, Volkswagen California EPA incidents, or Iowa Caucus incidents—too many more high-profile software failures or malfeasance—and the lack of our discipline, ethics, and standards will become the focus of a distrustful and enraged public. And then the regulations will follow: regulations that none of us should desire, regulations that will cripple our ability to freely explore and expand the craft of software development; regulations that will put severe restrictions on the growth of our technology and economy.

It is not the goal of this book to stop the headlong rush into ever-more software adoption. Nor is it the goal to slow the rate of software production. Such goals would be a waste of effort. Our society needs software, and it will get it no matter what. Attempting to throttle that need will not stop the looming catastrophe of public trust.

Rather, it is the goal of this book to impress upon software developers and their managers the need for discipline and to teach those developers and managers the disciplines, standards, and ethics that are most effective at maximizing their ability to produce robust, fault-tolerant, effective software. It is only by changing the way that we programmers work, by upping our discipline, ethics, and standards, that the house of cards can be shored up and prevented from collapse.

The Structure of This Book

This book is written in three parts that describe three levels: disciplines, standards, and ethics.

Disciplines are the lowest level. This part of the book is pragmatic, technical, and prescriptive. Programmers of all stripes will benefit from reading and understanding this part. Within the pages of this part are several references to videos. These videos show the rhythm of the test-driven development and refactoring disciplines in real time. The written pages of the book try to capture that rhythm as well, but nothing serves quite so well as videos for that purpose.

Standards are the middle level. This section outlines the expectations that the world has of our profession. This is a good section for managers to read, so that they know what to expect of professional programmers.

Ethics are at the highest level. This section describes the ethical context of the profession of programming. It does so in the form of an oath, or a set of promises. It is laced with a great deal of historical and philosophical discussion. It should be read by programmers and managers alike.

A Note for Managers

These pages contain a great deal of information that you will find beneficial. They also contain quite a bit of technical information that you probably don’t need. My advice is that you read the introduction of each chapter and stop reading when the content becomes more technical than you need. Then go to the next chapter and start again.

Make sure you read Part II, The Standards, and Part III, The Ethics. Make sure you read the introductions to each of the five disciplines.