Feedback loop please

I’ve been working on data transfer processes these days. The transfer time is ridiculously slow regarding the amount of data (about 100k records). By the way it is geographic data, so it might be normal. It irritated me though and made me think about feedback loop.

The importance of shortening the feedback loop between coding and watching the result is huge.

A short feedback loop helps you to achieve more in less time. It also prevents you to get bored and fall into procrastination.

Days spent waiting for feedback are long and make me feel depressed. Days when I get quick feedbacks are pretty cool, whatever I am doing.

Some idea to shorten feedback loop :

• TDD of course makes you write code that can be tested faster. Actually, taking much time to write test or wait for the test run to finish is a sign that you do something wrong. However TDD is not sufficient to test your whole app and you have to add system tests. They last longer.
• Avoid network. Your network is unreliable. Use a local database on your machine when it’s possible. It also will prevent to crash the shared database for respect to your colleagues.
• Automate what can be: to load your dataset, check the initial state of the system, test, cleanup.
• Reduce the amount of data you will handle during your tests, at least for early stage of development
• Ask for faster hardware in last resort.

This blog post is can of a truism. At least it will remain a note to myself!

The Software Craftsman

I’ve been asking myself if I should buy and read The Software Crafstman by Sanddro Mancuso given I already read The Clean Coder by Robert C. Martin. Both books deal with the same topic: professionalism in software development. Lately, I grabbed a copy from a colleague (thank you Jeff) and I read within a weekend (skimming a few pages, I admit).

There’s a lot in common between this book and the Clean Coder of course. What I appreciated though is that being younger than Bob, Sandro writes about experiences close to mines. He talks more about issues on Java projects than bugs in the early stage of computing with punch cards and teletypes.

What did I took from the book? The part about building a learning culture at work. Proposed ideas are great! I regret the overall tone of sarcasm against management though. The book is worth reading for managers too, not to blame them but to educate them.

Do you need to read it if you already read other book on technical agility, like the Pragramatic Programmer, Extreme Programming Explained or The Clean Coder? Maybe not. On the other hand, if you just discovered and feel attracted by the idea of software craftsmanship, this book is the perfect companion to start your journey on this path.

Refactoring, you're doing it wrong (en)

Some developers consider that refactoring is a huge chunk of work that needs to freeze the repository during a week. A week when every features are broken and rebuilt. Afterwards, another week is needed to merge the new features, once pushing on the central repo is authorized again. That’s so wrong, so costly!

It reminds me a talk by Joshua Kerievsky in which he explains more or less that I would try to remain the shortest time possible in the red while refactoring. With this principle, he keeps the ability to deploy continuously while refactoring the whole system. It’s been revelation for me. I like to feel I can deploy whenever I want, even if I don’t have the need to do so. In fact, I do not want to be in a situation where I block the repository, where I prevent my team mates to commit, where I’m sure I will spend painful hours to merge others changes one by one without feeling safe about it.

The ideas:

• Refactor in small steps. Consider that you will continuously refactor the application and not perform a big bang refactoring once in a while. Think boy scout rule.
• Consider refactoring only if you have a decent code coverage on the part you want. If you don’t, start with writing a test harness. At least system tests that will experience the code from the UI and check the outputs or the database. If you want to do refactoring that matters, you have to be damn sure that your are not slaughtering the application.
• Use your IDE. You have to know every features that lies in the Refactoring menu and use them rather than manual editing. Tooling won’t take any risk and they will ask you if they’re not sure of what they’re doing.
• Consider the “I build a huge amount of code that will work in parallel of the current system that I’ll branch when it’s ready” only when you have no simpler solution left.

Timebox your refactoring session. I promise you that you can do significant improvement within 30 minutes. Tell yourself that delivery is tomorrow, or in 1 hour or in 30 minutes. It will keep you motivated

(this post is a translation of an older one)

Draftsmanship

Some developer want to see their job as a craftsmanship. I really like the idea. SW craftsmanship is about focusing on code quality, and practicing and improving our skills.

More precisely about promoting a know-how instead of just theoretical knowledge. It is a thing to know about software development paradigms, design pattern, SOLID and TDD. It's another thing to know how to use them in practice. How to feel that a situation appeals to a certain pattern. Physical crafting is mastered through apprentice hands and software craftsmanship carries this idea.

However, the term craftsmanship sounds inappropriate for me. Physical craftsmanship is about creating tangible objects, which code is not obviously. Crafted items are made so that everyone can appreciate their beauty and the care put in their realization. Code has not this property.

For whom do we stress code quality? Customers? They do not care, they care of application stability, user experience, and ROI. If this is achieved with crappy code, it doesn't matter much. Working on legacy code is my profession as a developer, my client or user does not have to care about this detail. And I'm glad he or she doesn't.

We write clean code for our peers. We consider them as an audience. It's so pretentious! Every developer is not skilled enough to appreciate the pure beauty of craftsman production, they have to know about SOLID, Domain Driven Design, knowing that they should refer to unit tests if they want precision about how a piece of code works. Actually, they've to be craftsmen themselves, right? Better than that: they've to be egoless craftsmen since I think it's easy to consider your buddy's code as shit (that's why they pair program: to build collective shit ownership and accept this compromise)

Actually, I wonder how are the lives of self called craftsmen in regular and often junior development teams. Do they make recommendation? Do they impose coding dojo during launch time? Do they spend their hours refactoring team's pull requests?

Contrary to physical craftsmanship, the code we build doesn't last. Software is living tissue, and writing code is more like drawing mandalas with pigmented sand than curring a piece of wood. Stressing quality on this reclaim a great sense of zen and stoicism! You do not even write code for your peers, you write it for your SCM history!

So, for fun, I propose to use term Draftsmanship instead (^-^).

By the way, as I said in the intro, I do like the craftsmanship idea and I pretentiously see myself as one. Because I share the values of the manifesto. Because I read the books Pragmatic Programmer, Extreme Programming Explained quite often and I keep learning technical soft in spite of being in my 30s. Because gaining skills and focusing on quality, even to write disposable code and pointless applications is a quest of meaning in being a programmer. Sounds cheesy? Of course it is!

Creating Vs Learning

When I code for myself, I struggle to find a balance between willing to learn and willing to create something successful. As I lack of time (like all of you), I really have to work on this and keep these approaches as separate as possible.

When I mix both, I systematically get frustrated because I put a lot of energy on searching, learning and trying to find the right way to do things. Yet, my code reflects this learning process and it become harder and harder to get the features done and deployable. Step by step, I sadly abandon the projects in a forgotten github repository.

What are your expectations when you are learning? When you learn, it’s important to go deeply. For instance, rather than using JQuery upfront, you’ll try to write vanilla js, to figure out how things work and feel the pain by yourself. Of course you reinvent the wheel, but it’s OK as you don’t expect to deliver. It takes a lot of time and energy and you end up with a useless piece of code. You have to lower your output expectations. Find a simple objective (a simple game, a kata, a REST API and client) and focus rather on the process of discovering things along the way. Try a lot, acquire new practices, forge yourself an opinion about what you learn.

On the contrary, when you decide to create something, you have to focus on output. It’s the same goal as at work: get things out quickly with an acceptable level of quality. Start with what you know enough so that your lack of knowledge won’t prevent you to express what you have in mind. Don’t try to find and follow all the best practices, just do. You’ll be able to get back to your code later, if needed (if your app is deployed and is actually used). Try to be prolific and be ready to dismiss some of your creations: diversify your portfolio. The income of building things is not the knowledge you get but the feedback from your users (comments, money).

Of course, when you shape your mind toward creating, you’ll face situation when you’ll don’t know how to solve a problem, which can push you back into the learning spiral. Look for the easy path then: find the high level libs that do everything for you and don’t try to figure out what is done under the hood. Keep that for later, when you choose to go back to your learning phase. Examples:

• Want to build something that rely on push notification? Start with node, Express and Socket.io. Don’t use websocket from scratch.
• Want to build a REST client in Python? Search PyPI for an already existing lib. If not, use requests. Forget urllib for now.
• You struggle to get a nice web UI? Read this.
• …

This is a new mindset for me either. I want to learn but I also want to build stuff. Unfortunately, I have this tendency to reinvent the wheel and to avoid easy-to-use libs to prove myself that I am a badass programmer. Actually, I enjoy the process of editing code, trying things maybe rather than getting things done. Have to fight my demons now and craft a damn masterpiece!

Gary Bernhardt on testing

I like Gary Bernhardt’s talks. The first time have seen something from him was a kata on katacast and I’ve been so impressed by his speed in Vim!

Here is a talk from him where he nails quite everything I could say about testing.

• difference between system / integration tests and unit tests,
• objective in ratios between both,
• why speed matters,
• decoupling business logic from framework for testability,
• when unit tests take time to initialize, it’s a need to improve the design,

Refactoring, you're doing it wrong

Ce qui m'énerve avec le refactoring, c'est que certains considèrent que c'est un gros chantier, qu'il faut bloquer la base de code pendant une semaine pendant laquelle on aura cassé toutes les fonctionnalités existantes puis passer une seconde semaine à fusionner toutes les modifs. C'est raide !

Je me rappelle une conf de Joshua Kerievsky dans laquelle il expliquait en gros, si je me rappelle bien, qu'il cherchait à rester le moins longtemps possible dans le rouge lorsqu'il faisait du refactoring. En effet, cela lui permettait de garder la possibilité de faire du déploiement en continu malgré le souhait de refactoriser tout le système. Ç'a été une révélation pour moi. J'aime bien me dire que je suis en condition de déploiement continu, même si c'est loin d'être vrai. Je ne veux pas me mettre dans une situation ou je bloque le répo, ou j'empèche les gens de commiter, où je dois passer un long moment pénible à fusionner les modifications des collègues.

Les idées :

• Y aller par petites touches. Considérer que le refactoring est quelque chose de constant sur un projet et pas un déploiement big bang auquel on va s'astreindre tous les 36 du mois.
• Le refactoring se fait s'il y a une couverture de test qu'on estime suffisante. Franchement, rédigez au moins des tests système qui contrôlent que vous n'êtes pas en train de tout défoncer. Si vous n'en n'avez pas un minimum, codez en ou tant pis, laissez le code comme il est.
• Utiliser les outils de votre IDE. Même un truc tout pourri comme VS2008 possède des fonctionnalités permettant de renommer des éléments, extraire des méthodes, des interfaces. Utilisez les parce qu'ils ne prennent pas de risque. Il vous garantissent dans la plupart de cas l'absence d'erreur.
• N'envisager l'approche « je refais une grosse merde qui tourne en parallèle du code existant et je la branche quand c'est prêt » que quand vous ne pouvez pas faire plus simple.

Timeboxez vos sessions de refactoring. Je vous promets que vous pouvez faire des trucs sympas en 30 minutes et en faire profiter les collègues. Dites-vous que la livraison c'est demain, dans 1 heure, dans 30 minutes... Motivant, non ?

Par où commencer mon TDD ?

TL;DR.

Commencer par le service, caylebien.

Par où je commence ?

Dernièrement, je me suis posé la question sur la meilleure façon de commencer une implémentation en TDD sur un système plus trivial qu'un calcul de score de bowling. Un exemple : notre vénérable client souhaite disposer d'un service renvoyant la liste des collaborateurs travaillant au sein d'un service spécifique de l'entreprise. Plusieurs possibilités s'offrent à nous pour réaliser cette fonctionnalité.

3 possibilités

Les possibilités sont les suivantes :

1. Je peux décider de commencer par les détails, au plus près de ma source de données et remonter petit à petit vers l'interface de mon service (une méthode getEmployees(businessUnitId) par exmple).
2. Je peux déterminer quel sera le point central de mon design et développer de quoi le brancher d'une part au service et d'autre part aux sources de données.
3. Je peux partir de mon service et développer brique par brique jusqu'aux sources de données.

Comme souvent, il n'y a pas d'approche parfaite. L'approche 1 permet d'avoir une bonne connaissance de la source et de tout de suite l'adapter pour le reste du système. Elle permet de ne pas avoir d'a priori en terme de design. Une fois parvenu a un niveau d'abstraction satisfaisant, on peut implémenter notre service. L'inconvénient est qu'il faut tout de même garder en tête le comportement attendu. Celui-ci doit guider nos choix sur l'exploitation de la source : quelles données dois-je remonter sur mes employés via la méthode getEmployees ? Un deuxième inconvénient est qu'en déroulant cette méthode, cela peut prendre un certains temps avant de rendre le service disponible.

L'approche 2 permet de se concentrer sur la partie qui nous semble la plus compliquée sur notre fonctionnalité. On fait le pari que l'intégration avec l'interface du service d'une part et la source de données d'autre part sera simple. Cela peut être une approche satisfaisante dans le cadre d'un projet waterfall traditionnel pour répondre à un problème de staffing : on va concentrer l'effort sur la partie complexe du système en faisant intervenir ponctuellement des développeurs plus expérimentés et ensuite réduire la charge sur le branchement avec le reste du système. On peut bouchonner une partie si besoin pour pouvoir témoigner de l'avancement par anticipation. L'inconvénient est qu'il est nécessaire ici de rester conscient des besoins à la source comme à la cible, d'avoir une bonne idée du design avant de commencer le développement. Enfin, nous prenons un risque sur une étape non négligeable de la réalisation : il est possible que l'intégration ne se fasse pas aussi simplement.

L'approche 3 assure que le comportement attendu soit assuré au plus tôt, même si l'implémentation de la fonctionnalité est totalement ou en partie bouchonnée. Pendant l'implémentation, le service demeure disponible. On peut même envisager du delivery en continu. L'inconvénient de cette approche est qu'elle implique de réfléchir un minimum au design au fil de l'eau. En effet, partir sur une implémentation naïve de bout en bout à l'issue de laquelle on prévoit de faire du refactoring n'est pas envisageable : d'une part, cela prendrait beaucoup de temps pour valider nos test et d'autre part, l'étape de refactoring serait par trop longue et décourageante. Au lieu de ça, l'implémentation se déroule avec l'objectif de valider chaque étape abstraite en simulant les parties plus concrètes via des bouchons ou des doublures (mocks). On opère ainsi de notre interface (le pus haut niveau d'abstraction) vers la source de données (le plus bas niveau d'abstraction). Cette façon de faire est facilitée avec l'externalisation de l'injection de dépendance, en utilisant par exemple Spring.

Commencer avec le service

En ce moment, j'ai jeté mon dévolu sur l'approche 3, galvanisé par la lecture de ce post. Voici grossièrement comment je procède.

Tout d'abord, je commence avec l'implémentation de la méthode du service. Ma méthode getEmployees doit me renvoyer une liste d'employés ? Pas de souci, je la crée et lui demande de me renvoyer une liste vide d'employés. C'est pas terrible mais cela permet de mettre le service en ligne et de laisser la possibilité à mes clients de travailler. Je me concentre sur les paramètre d'entrées et de sortie, implémente les paramètres obligatoire, créer les éventuelle exception à renvoyer et teste les cas générant ces exceptions. J'ai rapidement un début de service correcte que je peux conserver pour la suite de l'implémentation.

J'implémente ensuite un repository qui me ramènera mes objets en interrogeant mes sources de données. J'implémente les contrôles nécessaires et lui fait renvoyer une liste vide.

J'implémente alors l'injection de mon repository dans mon service. Pour ce faire, j'utilise une bibliothèque de mocks (comme Rhino Mock en C#), ce qui me permet de créer un test rapidement me permettant que contrôler que mon service utilise effectivement mon repository. Le seul point noir à mon goût c'est que je suis un peu forcé de créer une interface pour mon repository. En même temps, cela découple bien les choses.

Pour la suite, je continue de construire mon service en adoptant la même démarche pour mon repository, en utilisant des mocks si nécessaire pour faciliter le travail.

Conclusion

Voici, en vrac les points positifs et négatifs que je dégage de cette approche :

• Le gros point fort est que l'approche est systématique : il n'y a pas besoin de réfléchir à l'étape suivante. On avance pas à pas en fixant le comportement attendu de la part des différentes couches.
• On teste dans les moindres détails. L'approche TDD est facilité par les mocks qui fournissent des implémentations instrumentées plutôt pratiques pour nos interfaces.
• La volonté de d'évoluer par petits incréments pousse à bien séparer les responsabilités. Il devient plus rare de revoir l'organisation des classes et la charge de refactoring se limite à l'organisation des méthodes à l'intérieur des classes. Cela permet de concerver une version fonctionnelle du code en évitant de péter nos interfaces tout en faisant du refactoring.
• Je pense que les mocks sont très utiles à cette démarche. Il faut toutefois prévoir de choisir une bibliothèque qui convient et un petit temps de prise en main.
• Il peut paraître frustrant de progresser par petits incréments et de bouchonner la Terre entière. En même temps, c'est du TDD mec.

Legacy remains legacy

Le code legacy, vous savez tous ce que c'est. Vous arrivez sur un projet, vous
regardez le code et vous faites une grimace.
Je suis sur un projet un peu comme ça. Toutefois, comme je suis joueur, je me
dis : "chouette, il y a pleins d'opportunités d'amélioration, on va bien se marrer !".
Alors sur mes premières interventions, j'ai essayé discrètement de remettre
le code à ma sauce, factoriser un peu tout ça pour faciliter la maintenance.
C'est alors qu'arrive une demande d'évolution nous proposant de réaliser un
tout nouveau module de l'application. C'était le début de l'été, on était à
l'aise... il y avait 2 packages PLSQL à coder. J'ai dit à mon stagiaire d'en
coder un et j'ai gardé le second.

J'ai réutilisé la structure du code existant -c'est une exigence du client-
tout en tentant de l'améliorer : en réduisant la redondance, en essayant de
faire un maximum de fonctions pour que cela reste lisible.
J'ai également écrit les 2 shells de lancement, en poussant les fonctions
communes aux deux scripts dans un troisième fichier. Ça marchait bien,
j'étais vraiment content du boulot qu'on avait effectué et j'étais persuadé
que le client allait être satisfait.

Après l'été, le module entre en VABF. Premiers griefs : qu'est-ce que vous avez
fait dans ce shell ? On y comprend rien, il y a des fonctions partout. En plus
vous avez mis les fonctions communes dans un troisième fichier ! C'est trop en
rupture avec l'existant, ce serait pas mal que vous nous relivriez, après avoir
recopié les fonctions communes dans chacun des deux scripts pour ne pas sourcer
de script externe. Au passage, une remarque en off : c'est pas si mal de factoriser, mais il
faudrait le faire pour toute l'application. Ben voyons, gratos, c'est bien
ça ?

Soupir, respiration, je modifie, je relivre et je me dis que c'est bon...

Peu de temps après seconde remarque : le code du package PLSQL que j'avais
rédigé n'est lui non plus pas conforme. Le style de codage est trop en rupture,
ce qui rend le code non maintenable (sic). Pluies d'anomalies, KPI en berne,
palabre avec le client. On refait le tout.
Il y avait une vraie ano fonctionnelle relativement minime, j'ai quand même
réécrit tout mon code... et ravalé ma fierté.

Essayons de comprendre le client. Celui-ci n'avait pas de TMA depuis plusieurs moi
et a dû prendre en charge évolutions et corrections sans équipe de développeurs
SQL chevronnés. Ceci nécessite de son point de vue :

que le style de codage soit uniforme et que tous les modules suivent strictement le même modèle ;

que le code soit abondamment (sur)commenté ;

que les fonctions un peu compliquées soient évitées. Quand ce n'est pas possible, elles sont très abondamment commentées.

En plus, mon code n'était pas cohérent avec celui de mon stagiaire... code qui au
passage est considéré comme meilleur que le mien (Nassim, si tu nous lis ;-)) !
Bref, une bonne douche froide et un suppo d'humilité pour moi. Je me remets en
question, j'hésite à démarrer une thérapie... Je me rappelle d'un passage du
livre Pragmatic Programmer, celui qui parle du good enough software... et de boiled frog.

En théorie, les anomalies du client devraient être liées à des tests
fonctionnels. Le comportement de l'application n'était pas celui attendu. Dans
mon cas, c'était effectivement le cas, mais je l'ai découvert moi-même par la
suite. La vraie ano que j'ai eu est "le code est complètement faux".
Dans les faits, bah, on retouche le code à la demande pour que le client soit
satisfait, assuré qu'il a une compréhension globale de ce qui est réalisé et
accepte la livraison. On promet qu'on ne prendra plus les mêmes libertés par la
suite. C'est la joie de la sous traitance.

À titre personnel, c'est un peu dur pour moi car je réfléchis toujours
au façon d'améliorer un système (c'est mon côté geek... ah pardon, lean), d'aller chercher une
meilleure maintenabilité pour faciliter l'évolutivité (c'est une belle phrase
ça, ça ferait un bon tweet). Par  exemple, j'imaginais mettre en place un framework pour la
partie PHP. Une telle idée me fait gentiment sourire aujourd'hui.
Au final, la situation s'améliore pour moi : à l'heure actuelle je ne code
quasiment plus pour cette application.
Dernier mot sur l'histoire de la boiled frog pour ceux qui n'ont pas lu le livre.

Si vous voulez cuire une grenouille en la plongeant dans une casserole d'eau
bouillante, celle-ci sautera systématiquement hors de la casserole. Si
toutefois, vous la mettez dans une casserole d'eau froide que vous portez à
ébullition, la grenouille restera dans la casserole car elle ne comprend pas
qu'elle est en train de se faire ébouillanter vivante !

Si vous bossez avec un client (une MOE) et que vous voulez organiser une évolution en
rupture dans un système, rappelez vous que vos solutions ne seront jamais
les bonnes tant que votre client ne se les ait pas appropriées. Faites en sorte
que vos propositions d'évolution deviennent celles de votre client, que ce soit
lui qui les porte. À vous d'être suffisamment malin... tout en restant
honnête à 100%, cela va se soi.

I iz a writer

Avec le mouvement software craftsmanship, il se peut que certains développeurs pensent qu'ils font de l'art, de la littérature. Je ne parle pas seulement des développeurs Perl ! J'ai vu une fois un commentaire sur un blog disant que les programmeurs pouvaient prétendre au droit d'auteur (je n'ai plus le lien alors vous êtes obligés de me croire).

Peut-on faire un amalgame aussi simplement ? Il est vrai que nous avons besoin de développeurs soigneux, qui aiment suffisamment leur métier pour avoir envie de le faire bien : tester le code, le relire et en améliorer la structure, le faire relire par un pair. Comme la littérature, programmer est encore dans la majorité des cas un travail d'écriture. Comme pour un texte littéraire, les programmeurs ont tous leur style et leur personnalité transparait dans leur travail. L'objectif est toutefois complètement différent. Le but d'un programme est d'être exécuté, interprété par la machine pour réaliser des actions. Nous écrivons des ordres qui doivent être clairs, non ambigus. Un lecteur humain aimerait-il lire des ordres ? Je ne crois pas : ça aurait peu d'intérêt. Utiliser interpréter sous entend que le lecteur extrait sa compréhension d'un écrit en faisant intervenir son intellect. La machine n'interprète pas. Elle exécute les ordres que nous lui passons. Si nous pensons que la machine interprète, nous donnons crédit aux excuses minables telles que "mais, la machine ne fait pas ce que je veux !". Non bleusaille, la machine fait ce que tu dit !

Heureusement, le lecteur humain est différent. Nous pouvons considérer qu'il interprète. Un texte littéraire fait appel à la conscience du lecteur, à sa culture, sa mémoire intellectuelle et sensorielle. Le sens d'un texte littéraire est unique pour chaque lecteur. C'est un peut comme si l'auteur plantait une graine qui poussera différemment à travers chaque lecteur. Nous sommes loin du déterminisme que nous recherchons à l'écriture d'un programme.

Amis programmeurs, vous pouvez vous prendre pour des auteurs. Toutefois, tant que vous n'exécutez pas votre code sur Skynet, vous le serez en écrivant pour des humains.

Le software craftsmanship c'est quoi

Je suis fatigué alors je vais faire un article bookmark.

Robert Martin a récemment fait une déclaration à ce sujet pour mettre tout le monde d'accord.

C'est là

Ça vend du rêve, non ?

Plus sur le site "Le Touilleur Express"

Bref, ça commence à prendre :). À quand un gros rassemblement de craftsmen en France ?

PS : sur le Yammer de ma boite (SSII internationale), le manifesto semble avoir fait beaucoup rire parmis les agilistes... S'ils savaient ce que je pense de Scrum...

Craftsmanship

Un courant dont on parle de plus en plus dans le monde de l'agilité est celui du software craftsmanship. C'est un point de vue d'avantage tourné vers les aspects techniques qui apparaissent comme parents pauvres de la conception de l'agilité aujourd'hui orienté gestion de projet et de ses ressources.

Les valeurs de se courant sont énoncées dans un manifeste qui se veut être un complément du manifeste agile. Le but avoué est de viser l'excellence technique, de devenir meilleur développeur, d'apprendre sans cesse. Le but n'est plus de livrer un logiciel qui marche mais un logiciel globalement bien construit. Un peu si on disait "bien sûr que le logiciel marche, mais dites moi plutôt ce que vous pensez de mon code source" !

On peut se demander pourquoi un tel mouvement émerge, alors que l'agilité est au départ orienté vers la technique, avec des pratiques comme la programmation en binôme et surtout le développement dirigé par les tests, lié à eXtrem Programming. Peut-être est-ce en réponse au fait qu'aujourd'hui XP est un peu oublié au profit de Scrum, qui a ceci de pratique qu'elle ne spécifie aucune pratique de développement ! Est-ce bien réaliste de demander à l'équipe de réaliser des livraison incrémentales installables en production sans un filet de sécurité offert par les tests unitaire et une non reg automatisée ? Je l'ai fait, il faut aimer l'adrénaline !

Ce principe d'artisanat (crafstmanship) prend une dimension aujourd'hui une dimension "économique" avec l'émergence des offres PaaS comme l'AppEngine de Google. Aujourd'hui, le développeur peut directement mettre son application à disposition avec une faible mise de départ. Plus besoin de couteuses études et d'acheter un serveur à plusieurs kilo euros. On développe, on déploie, on fait un peu de promotion et on voit si ça marche. Si ça ne marche pas, on abandonne et on cherche une autre idée. Et boum, tout un pan du management IT vient de tomber (enfin je plaisante, mais il faut réaliser que les choses vont peut-être changer).

Personnellement, les valeurs de ce mouvement me plaisent parce qu'elles remettent le développeur au centre du système. C'est la personne qui crée la valeur et il faut la motiver à devenir meilleure professionnellement. J'en ai marre de voir des gens qui s'arrêtent de développer parce que leur métier n'est pas reconnu, voire littéralement méprisé (oui, je veux parler de l'offshore).

Présenation Software Craftsmanship

L'artisanat, la première entreprise IT ?

Voici une belle présenation du mouvement "Software Craftsmanship". Si vous avez un peu de temps (1 h).

http://www.infoq.com/presentations/Software-Craftsmanship-Beyond-The-Hype