Egoless Crafting: Practicing Software Craftsmanship with Ego-Resiliency

In 2009, the Software Craftsmanship Manifesto was published as an extension of the Agile Manifesto, to fix the drift of part of the Agile movement in recognizing the importance of technical excellence.

Unfortunately nowadays, the Software Craftsmanship movement observes its own drifts, and aspiring software craftspeople can sometimes be seen as gatekeepers, elitists living in their bubbles due to a posture issue often linked to ego.

Egoless Crafting is a proposition inspired by Egoless Programming from Gerald M. Weinberg. It is thought as an extension of it, in order to improve the current posture of the Software Craftsmanship Community. Egoless Crafting consist of 10 principles, themselves divided into 4 categories. Those categories are inherited from the 4 imperatives advocated by Gaston Bachelard in The Formation of the Scientific Mind.

Egoless Crafting is not a manifesto or a movement. This proposition should be used as a personal frame of reference which aims to improve one's own social skills.

Egoless Crafting at a glance (tl;dr)

Special thanks to Yoan Thirion for the infographics.

Egoless Crafting: deep diving the principles

Intellectual and emotional catharsis

Intellectual and affective catharsis consists in getting rid of one's prejudices and opinions

1. You are not your practices

No practice is perfect and you have to accept that someone can criticize practices you use. Criticism of your practice is not a criticism of yourself. Keep in mind that practices evolve, adapt and eventually become obsolete when their limitations get in the way of meeting the ever-changing challenges of technology.

2. Don't be a survivor

Just because you successfully applied a practice in a previous experience, doesn't mean that it will work in all cases: Context matters. Each context is different, the parameters that ensured this previous success may not exist in all situations.

Most of the time, we forget that People matter in context, and that's the most important variable you need to consider. You must identify the pains people are struggling with. Only then can you suggest a practice according to its benefits in relation to these pains. You must accept and recognize that each team evolves at its own pace, balancing operational hurdles and learning curves.

What saved you, might not work for others, so don't push it. Consider the fact that you might be doing this only to convince yourself you made the right choice at the time.

3. Challenge the outcomes, don't push for your opinion

When you're asked to review a solution, it's tempting to try shaping that solution to your liking. There are always several solutions for the same problem. Don't let your personal preferences bring unproductive entropy into discussions.

During a review, whenever another implementation comes to mind, try to ask yourself whether both solutions observes the same benefits. If it's not the case, begin with improving the first solution in its logic before proposing an alternative implementation, without forgetting to consider the possible disadvantages.

Repeat the above, replacing "implementation" with "decision" and "practice".

Reform of the mind

The reform of the mind consists in educating the mind not by saturating it with knowledge, but by teaching it to reform itself constantly and to avoid getting bogged down in intellectual habits.

4. Software is not only about code

Well-crafted Software is a value featured on the Software Craftsmanship Manifesto. Unfortunately, some aspiring software craftspeople seem to only care about code. This is partly due to the fact that most popular practices in the crafting toolbox are code-centric -- e.g. Clean Code, Test-Driven Development or Katas.

However, code is not software. By writing code, you only make assumptions on what the users actually need. These hypotheses are validated (or not) when the users interact with your production environment: so Production matters. Frequent delivery to production is the only way to steadily add value. Adopting a practice like Test-Driven Development will have a really limited impact on the quality of your product, if you only get feedback on what you're building once or twice a year.

We don't get paid to create software just for kicks. Our technical know-how must serve the business. Therefore, building productive partnerships with our domain experts is necessary to best meet the needs of our users: Business Domain matters.

"It's not stakeholder knowledge but developers' ignorance that gets deployed into production." Alberto Brandolini

5. Software is produced by an organization, not by individuals

There is a common false belief which states that developers produce software, which leads to a kind of Hero Syndrome. As stated above, development skills are not enough to build software. It is your multi-disciplinary organization that produces software.

The Influence of Organizational Structure on Software Quality: An Empirical Case Study (Nagappan, Murphy, Basili - 2008) demonstrated that the quality of the organizational structure was a better predictor of failure-proneness than traditional metrics -- such as Code Coverage, Code Complexity or Code Churn -- in the case of Windows Vista.

No matter how skilled you are, communication and collaboration will always have a bigger impact on the designed system and you can't design a system alone. Be curious and pay attention and respect to other actors involved in building the software: Design and Organization matter.

6. Software Craftsmanship is about everyone, not only crafters

It can be very tempting to stay between crafters to save yourself the trouble of having to convince. However, this philosophy generates a self-segregation and locks the crafters in a deleterious bubble of means that are never challenged.

The crafting toolbox will quickly become obsolete without being questioned by outside views and without benefiting from complementary expertise from the entire community of software professionals. Your ability to respond to new challenges will be greatly limited.

This is also why the manifesto is subtitled by raising the bar: the goal is to help the entire professional community. By helping, we learn and discover contexts that are out of our ordinary, different ways of thinking.

When working with people outside the movement, keep in mind that you should never sell a practice as an injunction of means, but always convince by the benefits that this practice brings. In other words, if you "sell" Domain-Driven Design by explaining that it's the best method on the market to model a business domain, then you're "selling" it badly.

People try to do their best in contexts where they are pressured into compromise by local authorities. So do not pass judgment on the shortcomings of what has been done. Identify the actual pains of these people and see how you can help them. However, remember that you should provide help, never inflict it.

Rejecting the argument from authority

Rejecting the argument from authority means rejecting any argument whose sole evidence is the opinion of some authority, and not on a logical demonstration or empirical observation.

7. Do not Cargo cult

Just because you replicate someone else's practices, tools, and processes doesn't mean you'll achieve the same success. As mentioned above, Context matters. This "someone else" person might have means, constraints or enablers that you don't.

Be careful, your activity is not the same as that of large IT companies. Just because Google uses Kubernetes doesn't mean you need Kubernetes and that it will meet your needs.

Always analyze the problem space and define your needs before thinking about a solution. Don't let the hype and authority figures dictate you what to do.

8. Usain Bolt's Coach doesn't run faster than Usain Bolt

Having more seniority or being a coach doesn't make you a better developer than the people you help. You'll learn things from your mentees, and they might even be better than you in some ways. And that's okay: no one expects you to be the best at everything. You must let others express their potential, and help them to do so.

Do not use your authority to impose your opinion. Software Craftsmanship is a community of doers. Do not build yourself an ivory tower from which you will throw your knowledge "above ground" in relation to the reality of the field. Likewise, beware of preachers in their own tower. Lead by example and by doing, organize pair or mob programming sessions with people where you interact while building the software.

Respect and treat others as your equals whatever their level so that the transmission of knowledge can be done according to a horizontal approach, avoid the vertical approach which has the unfortunate drift of creating cults. Listening and humility are essential to building a productive partnership and trust. Software development is teamwork.

Make reason uneasy

Make reason uneasy consists in not letting one's reason rest too much, in exercising one's critical spirit and one's freedom of judgment.

9. Tools and practices are not a guarantee

Software Craftsmanship is choosing the best tool for the right situation. The downside of powerful tools is that you end up thinking they are enough to ensure success. Tools and best practices are models that were created to best suit a particular use case. Sometimes, these models can be successfully applied to new use cases for which they were not originally thought out, with some adaptations.

But all models have their limits: they will never be suitable for every existing situation and won't always be equally effective. There is no Silver Bullet. In addition, the limits and efficiencies of each of our tools are only very poorly documented scientifically (through rigorous studies).

This is why you have to know how to leave room for experimentation with new tools, whether they are "Craft-approved" or not. Once again, it's more important to focus on the outcomes of the practices in place, rather than on the means. This is the only way to innovate.

Keep in mind that there is no mention of any tools like Test-Driven Development or Kata in the Software Craftsmanship Manifesto. Using them will not make you a craft person, just as not using them does not disqualify someone from being a craft one.

10. Don't be a believer, doubt drives improvement

When one is convinced by the merits of a movement, one easily turns into an evangelist. But this posture can quickly become a prison of belief, maintaining its own escalation of commitment to the movement by embarking an entire structure towards a programmed failure, while creating exclusion around oneself.

A firm belief in something is often seen as a strength, however:

• When someone firmly believes that crafting is about tools, they create stooges.
• When someone firmly believes that crafting is all about means, it generates Cargo cults.
• When someone firmly believes that crafting is about goals, they fall into scoring obsession.
• And when someone firmly believes that crafting is a passion, they become a gatekeeper.

Dogmatism is a poison that treats doubt as a weakness. But doubt is actually a vector of improvement, through questioning. Questioning will always have a positive outcome: either highlighting a practice's weakness that could be improved, or improving the understanding of the person who expresses the doubt. Doubt is a fundamental disruptive pillar of scientific thought.

Wrapping up Egoless Crafting

Egoless Crafting attempts to refocus Software Craftsmanship, not on practices, tools, or code, but on human behaviors. They must reflect the values ​​of the manifesto. In other words, Culture matters and is the only way to correct the excesses that can be witnessed today #egolesscrafting.

“Culture eats strategy for breakfast.” Peter Drucker

Further Content

Death of a Craftsman: A software developer identity crisis - Einar Høst (English).

Y’en a marre du software craftsmanship ! - Julien Topçu et Yann Danot (French).

Software Craftsmanship : Le début de la fin - Benoit Gantaume (French).

Contributors