The most important dimension I could identify was the genuine care for quality beyond what’s necessary to just ‘survive’ in a company, and the conviction that the qualify of software depends on the quality of the people producing it. Therefore, it seems the right way to improve software is to improve software developers themselves, through deliberate practice and constant learning – including what we’re not taught in school.
Every community has a set of “core beliefs” and the points above are, in my view, the core beliefs of the software craftsmanship community. There are two kinds of people in this life: believers and critics. Believers often take critics for enemies, but critics actually help the community to evolve and to grow.
Helpful criticism: this is how we should label David Harvey’s recent presentation at QCon: Danger! Software Craftsmen at Work. David makes several points that are worth our highest attention:
It would be a great shame (...) to see a world in which we as a development community, because we become so obsessed about catas and dojos, apprentices and journeymen, actually lose contact with the businesses that we live in, the people who use our software. (...)
There is a great danger that, as the movement grows, there are parts of our community who will see what we are trying to do here as an excuse to separate themselves from the concerns of the business.”
David Harvey
- The Manifesto for Software Craftsmanship is empty of content because it is not refutable, i.e. it is not possible for a reasonable person to disagree. (Interestingly, refutability of theories, a concept made popular by Karl Popper in the 1930s, is at the foundation of modern science). I won’t address this point here, because I think it is true but not essential.
- The opposition of software craftsmanship to software engineering is pointless and may even give permission to software developers to ignore the lessons of software engineering.
- Metaphors, and the language we are using to describe ourselves and our activity, do matter. The people around us think of a craftsman as someone producing leather bags, not items you can rely on. Although software developers have their own definition of craftsmanship, what eventually matters is the perception of our customers. By choosing inappropriate metaphors, we are increasing the gap between those who build software, and those who use it.
To this list, I add my own point: if software craftsmanship is above all a personal attitude, what shall we do as a community; what is our call to action?
Software Craftsmanship vs. Software Engineering
Pete McBreen, in his seminal book Software craftsmanship: the new imperative, identifies software engineering to the waterfall development methodology. Instead of associating project failures to a specific approach to the management of software projects, he stigmatizes engineering itself. I respectfully disagree with that point, and notice that nobody I interviewed even mentioned the opposition of software craftsmanship to software engineering.
Producing any non-trivial piece of software is, above all, engineering work irrespective of the selected methodology or management practices.
Still, it’s worth some attention. I have a degree in mathematical engineering and consider myself an engineer. The scientist is someone who solves a direct problem: finding mathematical expressions that explain, and hopefully predict, the behavior of nature. An engineer is anyone who focuses on the inverse problem: given a mathematical model of nature, engineers design systems that solve a problem. Whether this system is mechanical, chemical, biological, electrical, or software, does not affect the definition of engineering. Producing any non-trivial piece of software is, above all, engineering work irrespective of the selected methodology or management practices.
Most criticisms to software engineering are actually objections to principles of management stemming from the the period between the Second Industrial Revolution (~1850) and Fordism (~1920), where the challenge of industry owners was to get mass production from masses of uneducated workers (only primary education was compulsory at this time).
Some regret the pre-industrial era of craftsmen and professional corporations. But should we? Ford’s management principles have been proven inappropriate for more than a half century, and the last decades demonstrated that they are totally wrong and counter-productive to all creative activities.
How many programmers still consider their job as a low-prestige activity and aspire to become ‘consultants’, ‘architects’ or ‘managers’?
The inadequacy of Ford’s management theory is not specific to the software industry. That’s what you would learn in management schools today. Let’s not worry about the past: the management theory has been fixed. However, how many of us developers still believe in this theory? How many programmers still consider their job as a low-prestige activity and aspire to become ‘consultants’, ‘architects’ or ‘managers’?
That’s how we get hordes of bad managers: because we promote people whose only knowledge of management is the ‘wisdom’ inherited from the first decades of the last century.
We can look backward to the pre-industrial era, but we can’t go backward. We as an industry are still facing pretty much the same problem as in the first days of the Second Industrial Revolution. We are still asked to produce a massive amount of software with a high scarcity of skilled workers.
We skilled developers will have to learn to work with less skilled developers. It’s not possible to meet the demand with just the top 5% of us. Furthermore, we skilled developers have the responsibility to make it easier for the less-skilled to produce good software. When we design new languages (consider the step made by Visual Basic, PowerBuilder, Delphi, Java, C# against C++) or new toolkits (PostSharp against plain C#), we don’t only make ourselves more productive; we allow less-skilled developers to produce better software. By lowering the bar on skills, we raise the bar on quality. So sentences like “everything written in Visual Basic is a code smell” are just elitist and irresponsible. If software developers have to serve the society they live in, they have the obligation to make it easier for average developers to produce high-quality software.
If software developers have to serve the society they live in, they have the obligation to make it easier for average developers to produce high-quality software.
There is, however, one difference between the mid-19th century and today: we can now affirm that talent does scale. Social scientists and psychologist have demonstrated that talent is not innate, that the best predictor of high-performance is passion and dedication, because only passion gives you the drive to practice beyond working hours. And here’s where the ideal of software craftsmanship comes back: we can raise the bar of our skills by practicing and by irradiating others with our passion so that they, in turn, get the drive to raise their skills.
Software Craftsmanship vs. Formal Education
There is a growing concern about the mismatch between the skills taught in formal education and what is really required by the software industry. This concern is neither new nor limited by our industry. There has always been a reticence within universities (especially those with a medieval tradition) to the idea that they should produce graduates who are tailored for industry. I tend to agree. Technical skills (languages and tools) are rendered obsolete every 10th year. A masters degree, as I have learned, provides abstract skills, it gives your brains the ability to learn, or design, whatever abstraction you may pick up.
But there is a body of knowledge that is neither tool-specific nor scientific. This knowledge is the sum of our experience, it is what we learned after we spent 10,000 hours building software, and what those who spent these hours cared to share in books. This knowledge is wisdom. Schools seem to teach science, not experience or wisdom.
Yes, there is a body of experience that’s being accumulated by our profession, and we refer to this as “the Craft”. Software craftsmanship says it’s not enough to learn the science, one has also to learn the craft. But is it a good reason to call ourselves craftsmen?
Metaphors Matter
What David Harvey tells us is that, if we call ourselves software craftsmen, people may take it seriously but they will not take note of what craftsmanship means TO US.
We can’t afford to ignore David’s argument. We are going to be treated as what we claim to be.
We have to find a better term to express our values and ideals. What does craftsmanship mean to us? What is our credo? So far, I’ve identified the following points to which I can subscribe:
If what we mean by software craftsmanship is basically an acknowledgement of personal responsibility and what it implies, is software craftsmanship the best term to express our ideal?
- We believe in people above processes. However, we acknowledge the importance of processes and the necessity for the industry to cope with less-skilled developers, and are committed to creating conditions for less-skilled developers to produce better software.
- We believe that our profession owns a body of knowledge distilled from experience which, because it is not genuinely scientific, is currently ignored by formal education. We want to ensure this body of knowledge is transmitted to software developers during their education or their first years of practice.
- We believe that the quality of software depends on the skills of the developers who produce it, therefore we acknowledge the obligation of raising our skills and those of fellow developers. Because only passion can give us the drive to practice and learn above what’s required to survive in our job, we are committed to spread our passion for software.
- We believe that the quality of software we produce directly influences the quality of life, safety and productivity of people or businesses who use it; we consider ourselves, developers, as ultimately responsible for quality, and refuse to deliver software that’s below our standard of quality.
So if what we mean by software craftsmanship is basically an acknowledgement of personal responsibility and what it implies, is software craftsmanship the best term to express our ideal?
We’re not the first profession to care about experience, skills and responsibility. Attorneys and doctors did it before us. They do not differentiate themselves by using medieval words. But they structured their profession to ensure that every new-comer gets the necessary body of experience.
The Problem of Action
The problem with software craftsmanship today is that it is merely a personal attitude; it does not seem to call for any action other than spreading the word and organizing local meetings where developers would practice the craft. This, alone, is not sufficient to raise the profession to the next level.
Look around us. We can get inspired from a lot of institutions. Associations such as ACM or IEEE already provide the structures we may be looking for. Already today, the IEEE Code of Ethics can be the foundation based on which software developers can refuse to work in conditions where they can’t guarantee the quality of their product. So what’s the problem with these associations? Why aren’t we all members? Are they too academic, too far from “the craft”? Perhaps, yes, but it’s something we can change.
Look at associations such as Toastmasters. Their only objective is the deliberate practice, and the diffusion of the art, of public speaking. With membership comes commitment - you’re either a member or not. You can’t just go to every third meeting. Yet still they meet the objective of raising the public speaking bar. They have an international structure; they offer a clear path for new members from any country to become, after years of training, excellent speakers.
Perhaps self-organizing online communities are not enough to bring our profession to the next level. Perhaps we’ll need more commitment. Perhaps we have to forget our “not-invented-here” syndrome and look at existing successful structures around us. But, certainly, we have to act to bring our profession to the next level; blogging and conference speaking is a first step, but it can’t stop there.