The Manifesto for Software Craftsmanship is subheaded Raising the bar.

Indeed, we believe that this is the main issue at stake behind this movement's motivations. To create products that rock, you need to rely on people who know how to do it, enjoy it, and always strive to do it better.

It's not just about introducing a few practices. It's a genuine culture of development aiming at changing the mentalities, the team operations and the company.

But you can't decree a change of culture. So how can one introduce the values of Craftsmanship into one’s company so that they become a standard instead of an isolated case?

Values and vision of software development

Reaching for higher quality isn't a new stake, but it has got even more strategic in a society where software is everywhere. In this digital era, one has to be always faster to comply with the customer's needs and keep ahead of the competitors.

The word quality can hold many interpretations. I will use it here to refer to a well-designed and value adding software.

• Building a software of high quality doesn't mean looking for absolute perfection and building a cathedral for any new product.
• It's not either about quickly building an application that meets the requirement but might fall apart anytime.

Building a software of high quality is looking for a balance ; it's creating a system that meets every needs while relying upon sound basis.

The lack of quality has a cost, not only strategic but also financial: an application stuffed with flaws will always evolve more costly, and a trustless customer might not want to pay anymore.

Furthermore, an easily forgotten cost of a lack of quality is the human cost. To work in such an environment can be discouraging for developers, and the best amongst them might leave for another company. We believe that most people feel satisfied with a job well done, including developers who like to feel proud about their achievements.

To reach for a high quality level isn't only a matter of producing applications and quality code: it's a culture. A culture of quality software.

While it is important to look into the produced artefacts and the practices that allowed to achieve them, it is essential to understand the factors enhancing this culture within our companies.

All Craftsmen?

It would be a shame to assert that there are Craftsmen on one side, some kind of super developers gathering at meetups and always looking for perfection, and regular developers on the other, not sharing the same goal and lacking the right skills.

There are people, developers, who work within a team and a company. Some, often thrilled by their job, have already assimilated these values. Some even have the necessary environment to realise products accordingly to their values.

Unfortunately, many others have little or no knowledge that there is another way to develop software. Still today, many development practices that help build premium quality software are just not taught in schools.

Some other people think these practices are simply not applicable to their company. They believe they can't change anything.

So yes, we could call Craftsmen this first category of developer convinced by the values of this movement and separate them from the others. But the very goal of Software Craftsmanship isn't to rank developers. The other developers aren't necessarily bad developers or developers from a different category. They just didn't have a chance to try out this culture. The real issue at stake here is cultural.

How to address this issue, then? To some people, if you can't find the Software Craftsmanship values in a company, you need to change company. It can be an individual solution, but what can be done for those who stay? What can be done if your new company isn't so perfect after all?

I will relate my own experience as an example, and I'm sure some may identify with it. During my first years as a developer, I barely knew the existence of unit testing or continuous integration. I hadn't learnt about it in school, and neither did the people I was working with. Yet, I strived to do my best, to produce applications which made me proud. Then I met a passionate developer who passed on some practices and encouraged his coworkers to use them. Later, I took part in a project where this culture was central. And so on, until I wanted to pass on this culture myself, convinced that it was the right way to do my work.

I'm not saying that everyone should change and yield to some kind of Software Craftsmanship "religion". Some might not agree stricto sensu, but that's not the point of this article. I'm just convinced that we should share these values and that there is still a long way to go in many companies.

So, how to broadcast this culture? How to make a difference?

Adopt the culture of software craftsmanship

When we talk about Craftsmanship, we think software development professionalism and everyone's responsibility in the achievement of his work. A certain vision of the daily work of a developer allows the production of good quality products which fullfill at best a given need, the achievement of projects and their sustainability. It's a pragmatic approach: you don't look for perfection, you just strive to do your best with regards to the context.

Some practices appear as vital to reach this high quality efficiently. To name a few, that's the case of test driven development (TDD, BDD...), Clean Code standards, or Evolutionary Design.

Finally, we try to learn and learn some more, for our work is one perpetually and quickly evolving:

• reading books and blogs
• training, practicing new tools, new languages
• meeting other developers at conferences, meetups...
• identifying mentors

But each one individually adopting this culture is not enough. No matter how much TDD they do or how many meetups they attend, many developers feel alone in their company. They may not share some coworkers' values or they may be unheard by their management when they mention their own values.

Pass on values and practices

Most products are developed by a team, and these achievements are the fruit of team work.

Several practices will help spread the culture of quality among the team:

• Learn and pass on development good practices through pair programming and dojos.
• Secure a collective knowledge of the code through code reviews, by pair or collectively. Avoid any developer working on his own on a specific piece of code.
• Establish together development standards and keep them up to date.
• Rely on tools such as continuous integration to shorten the feedback loop.

For instance, on a previous project, we had planned a coding dojo ritual once every two weeks, during which we shared our practices with some perspective over the project. It was an occasion to experiment new technologies, assess their match for the project needs, share new coding techniques, and update our standards together.

These practices are fundamental to promote the culture of quality, but it's necessary to break a few habits anchored in the company to enable them.

The developer's work is all too often regarded as a lonely activity. This entails two downsides:

• non-tech members of a project regard collective development practices such as pair programming as an extra cost although some studies tend to prove otherwise.
• developers used to working alone may have difficulties working in a team, let alone showing their code and talking about it. On that matter, it's necessary to adopt a positive stance, to learn how to give and receive feedback without finger-pointing. The principles of Egoless Programming are a way of addressing this problem.

Fostering a team-wide culture of quality isn't easy. It requires leading a true change management. A couple of days of practices training won't make a team of hardened craftsmen. It takes time and you can't force people to change.

To achieve that, it's useful to rely on people mastering these practices. You can rely on a tech lead who will help the team improve until it becomes autonomous. And if there isn't such a person within the team, you can involve an outsider of the team who can raise awareness of these practices, train the team and accompany it.

A company-wide culture

As we have seen, the development of this culture is boosted by encounters with people who are willing to share their hard and soft skills, and who wish to learn more and more in our constantly evolving craft.

Developing this culture company-wide may seem like a daunting task. That's why the stakeholders must enable the conditions favorable to these encounters.

Several actions can be introduced:

• Supporting the continuous improvement practices such as code reviews, allowing the teams to self-organise. The developers are development professionals, it is therefore essential to grant them autonomy in their area.
• Providing meeting spaces for teams, fostering the emergence of communities of practice. At OCTO for instance, we host BBLs almost every day, and the third thursday afternoon of each month is dedicated to BOFs, where each one can share his experience.
• Allocating a learning budget to every projects, so that anyone can learn outside of his personal time, and so that people are provided with a collective learning time.
• Rethinking the organisation of space and offices to ease collective work
• Identifying influential leaders and granting them the legitimacy to spread their values and their practices by driving the community, accompanying and coaching other teams.

I'd like to emphasise that we must not try to scale out too fast. A few practices successfully adopted by one team doesn't mean they should be forced into the whole organisation. You can't change people, but you can inspire them, and a company-wide culture will contribute significantly.

Where to begin?

• Next time you face difficulties while coding, ask any coworker for help, and suggest a pair programming period or a collective code review session.
• Do the same thing next time you use TDD (or any other practice), offer to pair program with a coworker who isn't used to this practice.
• Take some time to discuss an interesting article with coworkers.
• Organise a dojo to try this new library you've been willing to add to your project.
• Go and meet this other team working on similar technologies and subjects, and exchange about each other's practices

What's happening? What comes out of these meetings? What have you learnt or passed on?

Conclusion

The Software Craftsmanship movement offers a vision on the developer's activity. This vision shouldn't only relate to individuals, but also define a company-wide vision of the developer's work, promoting a culture of quality and continuous learning. The software creation is a fascinating trade, and even a fun one actually, as long as you can practice it with diligence and professionalism.

That's fortunate, this issue is a critical stake for a company: our society relies broadly on software, and the trend is rising. It's our responsibility to adopt values and practices leading to high quality software, and the Software Craftsmanship movement embodies these measures.