Salespeople And Other Devils

In an answer to my previous post, Dave Hoover has pointed :

You said, "It is vital we keep this knowledge among programmers and out of salespeople's hands." Why would we want to keep knowledge out of anyone's hands? I feel like this statement fosters an "us versus them" dynamic.

Dave - thank you for your note. It made me think. Hard :^)

So...

> Why would we want to keep knowledge out of anyone's hands?

I realize it has more to do with my personal history than anything else. I've struggled hard in the past to get out of messy situations connected to this. After passing on knowledge within my company (whichever company it was then) I'd have to deal with half-baked subcontracts concluded by salespeople who would throw in keywords while not understanding the context.

With some hindsight, it looks to me now I was trying to get some validation from others in my company, the more validation the better. What was unsensible was, I was caring more about others' validation than my own sense of self-validation. So in a sense, I was inviting others to throw in keywords to feel happier. And I realize now how generous they actually were, daring talking about things they wouldn't fully understand instead of staying on safe grounds.

And I'm past this now (well - most of the times ;^) ).

These days, I tend to seek the company of people prefering acting rather than talking and speculating, and I focus on working with doers - essentially programmers. And although it's where my preference currently lies, you're right: keeping knowledge out of non-programmers will foster an "us versus them" dynamic. This won't help bringing balance and improvement to our field.

This brings interesting opportunities. There's no need to keep our technical knowledge out of non-technical people, and we may use the saved energy for other purposes. Such as sharing not only technical knowledge among programmers, but also relational knowledge - so that we have the ability to be centered talking about what we know and don't let others define what we're doing without our consent.

Software Craftsmanship: Fueling The Debate

John Daniels has invited me to be one of the panelists for the Software Craftsmanship Debate the SPA 2010 conference held last Tuesday. He asked me to prepare in advance a position statement that I would offer during the debate.

The debate revolved on voting for or against the following motion.

"This house believes that the notion of 'Software Craftsmanship' is a distraction from the things that really matter."

Here's what I've said.

I believe we are living in a cynical world, governed by short-term vision, driven by financial profits. In order to derive yet more money from our depleted environment, we are ready to blind ourselves and either make up stories legitimating what we are doing, or listen to such stories made up by others. We like to think there's no choice. That progress is unescapable, even if alienating. That globalization is a natural process which will eventually help the poors out of their misery, even if not in a short term. That human beings cannot be trusted and therefore must be controlled, even if it means generating more anger and violence on both parts - the contollers and the controlled ones.

The pieces of software we write largely help shaping this matter of state.

Still, no matter how improbable it looks like, I believe we always have the choice to act in the way we do - which means we can actually choose to act differently. I am convinced that, when we programmers are confident with our skills, when we don't fear getting fired the next day, when programming becomes less about technical difficulties and more about means of self-expression, we have the energy and the ethics to think not only about how we write code, but also about the impacts this code has on others' lives.

I envision a future in which programmers are the conscious repositories of a body of knowledge. A future in which they regain their craft, instead of tweaking frameworks they don't understand. A future, eventually, in which programmers say "no" to demands at odds with their ethics.

It is crucial to create ways, spaces and formats for programmers to share their knowledge with other programmers. It is vital we keep this knowledge (especially verbalized knowledge) among programmers and out of salespeople's hands. And it is urgent the IT crowd recognize software making as a craft, instead of a commodity.

This is what I look for - and find - in the Software Craftsmanship movement.

And yet, as in many things, this might be what the Greeks call a "pharmakon" - that is, both a cure and a poison. I believe we must be cautious about giving ourselves names, because it tempts us to give names to others. It fosters an "us versus them" dynamics that turns in the end into antagonization, mistrust and contempt on both sides. I'm suspicious when a group names itself to separate from other discourses, and to reify this separation. I'm equally suspicious about using analogies, especially medieval analogies, to describe what we do in the 21st century. And I'd rather see us gathering momentum around great software products rather than great manifestos.

In one hand, I think the expression "Software Craftsmanship" is nothing but noise at best. And on the other hand I remain convinced the very notion of Software Craftsmanship is at the heart of things that really matters - to me, at least.

Meanwhile, in Boulogne...

[Note: this post is the English translation of an article I've initially written in French.]

Now that things settle down a bit, I'm proud and happy to announce the website I've been working on as an extreme programmer for Delasource is now online and available to anyone. It's actually been so for the last two weeks.

The website hosts a contest for (French or Spanish) teenagers. The winner will be granted one day in the company of Taylor Lautner (if you don't know Taylor Lautner, don't over-beat yourself - immense is the universe of teens' stars) (plus, Google can provide you with all the clues you need without anyone knowing). S/he will also represent him during an event to which he won't be able to attend. In short, the winner will be dubbed "star ambassador." Sideways, various companies will advertise their stuff and everyone will get to send SMS and MMS as if they have nothing better to do.

> http://ambassadeurdestar.com

> http://star-ambassador.es

The project is run in full eXtreme Programming, by the book (first edition, of course). The website is developed in Ruby on Rails with TextMate, thus on MacOS. We add features everyday, and there has been at least one release a day since we've gone live. The team is currently composed of 6 programmers, 2 graphic designers, 3 moderators and a handful of stakeholders. The whole gang happily works together in an old, rehabbed shop in Boulogne, in the same room. The code is written full TDD (except for the HTML views). It's currently covered by 951 assertions spread over 563 automated tests, running in about 35 seconds.

In 4 months of work, we've used 150 flipchart pages, 15 markers, 100 index cards, 2000 sticky notes of various sizes and colors, 10 felt pens, 5 ballpens, 2 notebooks, 50 regular sheets of paper, 1 playmobil and 300 French croissants.

During these 4 months of teamwork I'll have grown a deep sympathy and a profound respect for my fellow coders, an entrepreneur-born former DJ and aikido blackbelt, a game designer gifted with Olympian calm, a bretonnian philosopher and former math teacher, a tireless Pole and an aesthet freelancer who cares about software (a lot).

I'm immensely proud of the results we've come up with, as much for all the right choices we've made at the right time as for all the obstacles we've overcome and turned to our advantage.

... and I figured you might want to rejoice along with me :)

Tips to set up your own coding dojo

Now that the idea of what a Coding Dojo is and what benefits it brings gets more widespead, an increasing number of people wonders how to set up one. The short answer, as Arnaud Bailly puts it is: "do it." For those of you like longer answer, here are few tips I like giving, based on my experience shaping up the Coding Dojo in Paris for the last five years.

Always meet at the same place and the same time

It helps to build a community and a "ritual" if you limit uncertainties about when and where the next meeting will be. We tend to meet on the same day of the week, too -- but we keep our options open to accomodate specific schedules. Most of the time, we meet in Paris on Mondays 6:30~8:30.

Let the process evolve when needed

We have decided to grow our process organically and to tune it, based on what we learn from retrospectives. We conduct a retrospective at the beginning of each session, looking back at what worked during the previous session, and what we'd like to change. Sometimes, we'll change the process on the spot, sometimes we'll call for online or after-hours discussions. We want to be disciplined about the rules we set, and at the same time, we want to be unafraid to change them when they don't suit us anymore. We've made many discoveries through fortuitous changes, decided on a whim, for the sake of it. An exemple of change: how about we keep track of a customer's satisfaction index? An exemple of whim: what if we shift our focus from the core problem to peripheral complexity and tackle with this first?

Trust your process

It's frustrating sometimes to do something without knowing exactly first why you do it. It's ok. Part of the learning experience is figuring out what is happening. It's also frustrating to realize that others might want to steer your dojo in a direction you don't feel great about. That's ok. Part of building the community is about finding out why you want to meet every week or so as a group. Answers will become clearer as time goes by, provided that everyone feels free to talk and listens to others' opinions.

Keep a collaborative journal

Encourage your community members to post articles about what they have got from the last session on a blog, a mailing list or a wiki. Use that medium to post the code you came up with as well. At the beginning it feels a bit narcissistic, but after a while, it's great to have archived data about what you've done, how long it take, how much you've improved, etc. We are keeping a journal of each session on a wiki, and we also have a blog. The blog is pretty inactive these days, but the wiki has been weekly updated since the beginning. If you're not afraid of reading French, you'll find there ideas for working on your own katas.

Encourage discussions, but on green bar only

Don't discuss about the code when it's in an unstable state. It's speculative for the audience, and very disturbing for the driver.

Use a kata to introduce a new language

It's fun to try out different programming languages, but it can be very frustrating for everyone if the group is stuck with some technical difficulties (this may happens in a randori). Someone having prepared a kata in that new language helps prevent this, and keeps the audience focused. If you're extreme, you may even prefer using a kata that everyone is familiar with.

Don't cram too much in one session

A retrospective takes about 30 minutes, deciding for a subject and doing some preliminary explorations takes another 10. That leaves about 80 minutes for coding -- if you start on time. It may seem short, but actually it doesn't matter. We've found that it's better to code less and accept we didn't finish what we had decided we would do in one session. First, it makes it a great opportunity to celebrate when we do finish what we had plan :) Second, we prefer discussing the reasons why we couldn't finish on time and improve, instead of masking a latent problem by adding 30 more minutes at the end. Third, going at the dojo after works gets everyone tired pretty quickly. We meet every week so that's ok if we don't do much in one session. "Sustainable Pace", as they say... ;^)

Make the sustain of the dojo everyone's responsibility

The first rule we've decided for was at the very first session: if nobody shows up at the next session, the dojo's dead. Therefore, it's every dojo member's responsibility to come and keep the dojo alive. We've then added another rule: if nobody has any subject to propose for the session (be it a kata or a randori), then the dojo's dead. What we want to assert is the dojo works because everyone feels compelled to feed its core. We don't have one single organizer, and we're ok to face the eventuality nobody wants to invest in the dojo anymore. Knowing the project could end very abruptly gives us the energy to work on new subjects and to show up every week.

I hope this will help you getting started. If you have questions, feel free to drop me a note. If you'd rather ask face-to-face, I'll be talking about the Paris Coding Dojo at XP-Days Benelux in late November.

Getting Back To Writing

I'm back on deliberate practice - writing 2 to 3 hours a day, some of it being code, some being plain text. I'm happy with what's coming out, and the feeling of actually producing stuff (instead of "just" coaching others) is great.

Here's a piece I'm happy with.

Incursions dans la pensée post-moderne

Pour programmeurs extrêmes

Qui se trouvent nuls d'écrire des bugs

My fellow agilist Rémy Sanlaville asked me to tell him more about postmodernism, after hearing me raving about it last year. So I'm telling more. I address in the article what touches me in pomo, and how I see it resonate with (agile) software makers' culture.

It's in French, mind you. If you can't read French, you may still pretend you do, wear a beret and smoke Gauloises and be cool anyway.

Reader-driven: A tutorial in which YOU are the hero!

A while ago, I wrote an article demonstrating what we do at a Coders' Dojo: code and talk in front of others.  It took the shape of a story in which YOU (yes, you) are the hero - you know the kind.  Although in the first place I intended it to be printed on paper, it was definitely crying out for a more suitable medium, namely hypertext.  It took me some time to do the transfer - and a nudge from fellow dojo attendees - but thanks to Google Sites, here it is.

I'll be delighted to hear / read your feedbacks about it.

Agile FAQ and MTA

A fellow agile coach told me recently about his project to write the Ultimate Agile FAQ list - solutions to problems people recurrently have when installing agility somewhere.  There were sparkles in his eyes.  My reaction may have been harsh.

I've started wondering why we feel compelled to write FAQs about agility when the Most Typical Answers are always the same - "Yes, it's important," "It doesn't matter (as long as you do it one way or another)," "Trust your judgement" and "It depends."

"Yes, it's important."

Typical answer to questions like "do I really have to write tests before production code?" or "I don't like pair-programming, do I still have to do it?"  Don't get fooled.  These aren't real questions - someone is just asking for permission to do something the easy way without having to face consequences (remember - "Mommy, do I really have to wash my hands ?").  You may decide the person is wise enough to understand the "right" (?) answer - I'm not going to tell you which it is - but were the person wise enough, they wouldn't ask the question in the first place.  They'd try and experiment not following a practice to see how it goes, and would accept to rock the boat on their behalf.  So be patient, smile and remain firm.  Yes, it's important to write tests before production code.  Do it.

"It doesn't matter (as long as you do it one way or another)."

Typical answer to questions like "What tool should I use to track progress - Excel or Marker&Paper?"  Yes, I know, you have your own preference and I have mine.  Face it, though.  It's not about how you (or I) would do it, but how they will.  I find it's more efficient to leave to the doer the responsibility of chosing the tools work best for them.  It engages them toward action instead of submission - or rebellion.  More important than your relationship with them is their relationship with their work. So take a deep breath, stop (believing you have the power of) controlling others, trust them and nurture them.  What's important is to track progress.  The way the tracker prefers doing it is important too, and it's up to them to choose.

"Trust your judgement."

Typical answer to questions like "On what practice should I focus for now?" or "What techniques do I need most beside agility?"  Typical answer could be "all of them" or "it doesn't matter" but that's not what the person's ready to hear, really.  Again, it isn't so much a question than an attempt to delegate you the responsibility of a learning process.  Unlike the "Do I really have to..." questions, "What do I need to do now?" questions bear some hope though, for they're open questions.  The person is ready to try out something, and maybe the best thing they could try out is thinking for themselves.

"It depends."

Typical answer to questions like "How do I get my manager support our learning TDD?" or "My team and I want to go agile - where do we start?"  I like questions that bring up "it depends" answers.  It means they're context-sensitive and that you'll need to assess the situation in some way before being able to give some practical, useful answer.  Since answers to such questions depend from context and every context is a bit different, giving more precise answers than "it depends" prior to knowing more of the context bears the risk of creating an illusion - that the person may follow blindly the answer you've given.  Of course, you may have valuable, relevent answers to more specific questions, wrapped with a context.  And here's the dilemma - the more precise the question, the less frequently it's going to be asked.  The more your answer will be valuable, the less it'll have its place in a FAQ list.

So - where does that lead us?

Should one write FAQs?  

Well, it depends.  The way I get it, being agile has more to do with experimenting different things at different times than with litterature knowledge.  And yet, FAQs on other subjects are useful. And also, others may know better than I do.

How do we get new ideas about what to try when we're stuck?  

It doesn't matter - as long as you seek to try something different everytime something isn't working for you. 

Is it actually important to find answers to our burning questions?  

Yes, it is important.  Honestly.

... And how much can we trust you on this?  

The answer to this question is left as an exercise to the reader ;^)