MD Blog

Suite à un intéressant article de Nicolas Martignole, ça buzze beaucoup ces temps-ci autour du Software craftsmanship et ça me donne envie de réagir. En particulier quand je vois les tentatives de récupération (je n’ai pas mis de lien pour ne pas les encourager ;-).

Le mouvement du Software Craftsmanship constate que les bons logiciels sont faits par de bons programmeurs. Notre profession aura atteint la maturité lorsque les bons logiciels pourront être faits par de mauvais programmeurs ou même, sans programmeur du tout.

Le Software Craftsmanship : commercialement anxiogène

Comment terroriser nos clients : en leur expliquant que la seule manière de leur apporter de la valeur c’est de réunir des développeurs expérimentés, membres de la communauté des Software Craftsmen (sorte de compagnonnage). Pour que le projet fonctionne il leur faut l’élite : tous ont fait leur Tour de France et réalisé leur Chef d’Oeuvre. Sinon, c’est l’échec assuré.
En toute logique, le client part en courant acheter un ERP (au fait, qui met en place les ERP ? En tout état de cause pas des Software Craftsmen. Pourtant ça fonctionne plutôt pas mal, et ça crée de la valeur chez leurs utilisateurs).
Je pense qu’un client sera bien plus rassuré si on lui explique que le projet ne repose pas exclusivement sur des individualités, mais sur une entreprise qui, par les processus mis en place, par sa capacité à recruter, mais aussi, à former et à encadrer, par ses outils et ses infrastructures, lui garantit une qualité de service éprouvable et surtout, répétable.
C’est justement la différence entre une boîte qui « vend des CV » (donc des individus) même bons, et une boîte qui vend un savoir faire d’entreprise.
Si ma boîte n’apporte rien de plus à mon client que la somme des qualités individuelles de ses salariés, je passe freelance immédiatement.

Le Software craftsman et le Renard (Jean de la Fontaine)

L’idée d’une « Communauté de professionnels » est intéressante par son aspect « partage de bonnes pratiques » : c’est exactement ce que je recherche en participant à des conférences ou à des séminaires professionnels. Elle l’est beaucoup moins par son aspect ségrégationniste : il y aurait donc deux sortes de gens. Ceux qui en sont, et les autres.

Evidemment tout ce discours s’adresse aux premiers. Ceux qui adhèrent aux valeurs et qui ont signé le Manifeste. Ceux qui sont de « bons » artisans qui, jours après jour cisellent leur code pour en faire un chef d’oeuvre.
Les bons programmeurs seraient donc les gardiens des bonnes pratiques qui se transmettraient leur savoir faire « de bouche de druide à oreille de druide ».

Sauf qu’en fait, il n’y a pas de ségrégation : tout le monde se reconnait dans le manifeste. Tout le monde veut (ou croit) être un partenaire productif de son client, membre d’une communauté de professionnels qui apportent de la valeur en créant du bon logiciel (sic).

C’est en fait une grosse ficelle. Il s’agit simplement de développer l’esprit de corps.
Pour une SSII, faire l’apologie du Software Craftsmanship, c’est du clientélisme. C’est flatter la communauté dans le sens du poil en espérant ramasser des CV.
Et Uncle Bob, dans ses conférences comme dans ses posts est sur la même longueur d’onde. Il espère mettre dans sa poche son auditoire en lui jouant du violon : « comme vous ête forts, vous les programmeurs quand vous vous efforcez de faire de la belle oouvrage ».  Ca marche plutôt bien, il parait qu’il ya même des SSII qui l’écoutent… Cette leçon vaut bien un fromage sans doute.

Software Craftsmanship : un constat d’échec

Quelqu’un se souvient-il de ce que signifie le premier « I » de SSII ? « Ingénierie » ! Nous sommes censés être des ingénieurs. Pas des artisans.Et notre métier est considéré comme « industriel ».

Et bien en fait non. Nous sommes encore (malgré un demi siècle d’existence) un métier où le savoir faire individuel reste plus important que le processus et l’outillage.
L’existence même d’un mouvement comme le Software Craftsmanship est un aveu d’échec pour notre profession. Ca me désole mais, je dois bien l’admettre, on ne sait pas, aujourd’hui, fabriquer du logiciel comme on fabrique des voitures. D’ailleurs, si c’était le cas, il n’existerait pas de « petites SSII ». A-t-on déjà vu un « petit constructeur automobile » ? Oui, il y a un siècle, quand le métier balbutiait.

Le Software Craftsmanship est donc un pis aller pour pallier notre incapacité à industrialiser la production de logiciel. Et bien mon objectif personnel n’est pas de me complaire là dedans mais plutôt de tenter de faire changer les choses !

A contrario d’une réaction au post de Nicolas, j’ai l’impression que les initiatives de type Centres de Service vont plutôt dans le bon sens de ce point de vue. L’industrialisation d’un processus de production, la mutualisation des moyens ne sont pas antinomiques du développement du savoir faire individuel des programmeurs, au contraire. En créant un environnement communautaire et en lui donnant plus de confort, il favorise le partage des connaissances au quotidien, il permet la répétabilité et l’amélioration des processus, il autorise l’investissement dans l’outillage. Le seul inconvénient est le possible éloignement du client ou de l’utilisateur final qui peut être compensé par une organisation distribuée (par exemple des products owners délégués qui font la colle). Et évidemment, le MDA est un autre avatar de la même ambition industrielle.

Je voudrais tout de même terminer sur une note un peu plus positive par rapport au Software Craftsmanship. Ne vous méprenez pas, je reconnais bien volontiers (mieux, j’apprécie et surtout je revendique), le caractère créatif de notre métier. Je suis sensible à l’esthétique, voire à l’élégance d’un programme (ou à sa laideur). Et, pratiquant le coaching, je suis souvent amené à tenter de partager mon expérience avec de jeunes Padawan. Je suis juste un peu déçu, de voir que c’est ce genre de sujet plutôt passéiste, qui tient le haut du pavé dans notre profession. J’aimerais bien pouvoir m’enthousiasmer pour des idées vraiment nouvelles, des « changements de paradigmes » ou des « révolutions technologiques » plutôt que pour ce qui me semble fortement teinté d’un conservatisme confortable.

PS Les commentaires sont réactivés

Pas de rapport direct avec le MD (sauf à l’utiliser comme “modeleur collaboratif”, ce que certains ont déjà réalisé) mais je publie sur le blog d’Objet Direct une série de posts sur le buzz du moment, Google Wave.

J’ai participé la semaine dernière (18/09), comme spectateur, au passage à Paris du Google Developer Day.

Un petit retour rapide sur deux des présentations auxquelles j’ai assisté :

Android

J’ai eu envie d’en savoir un peu plus sur Android, un des buzz à la mode. Malgré un présentation plutôt sympa, pas d’annonce fracassante ni d’exclu juteuse. On n’a même pas pu voir le G1 « en vrai » !
Petite confidence « off » du conférencier : « j’ai un iPhone et un G1 et je préfère quand même l’iPhone » :-)

Un truc très sympa : un gagnant français du concours de développements Android (Android Developer Challenge) organisé par Google à parlé de son appli : un central de gestion de covoiturage (avec paiement éventuel et gestion de blacklist) intégrant la géolocalisation. A suivre probablement.

Au passage le concours en question, très bien doté puisqu’au total, ils ont distribué 5 millions de dollars, leur a permis de se constituer une logithèque de qualité (~2000 softs) avant même la sortie du mobile !
La vraie question est : nous, développeurs d’applis de gestion, devons-nous nous pencher sur le développement mobile ? Devons nous investir, nous former ?

Autant vous le dire, la présentation ne m’a pas apporté la réponse :-(

M2C : même si le rapport au mobile est aujourd’hui très « personnel » voire privé, il me semble que son coût extrêmement faible au regard de la technologie qu’il embarque devrait (moyennant un peu plus d’imagination que ce à quoi nous avons habitué nos clients) nous permettre d’explorer de nouveaux « use cases ». Désolé, ça reste vague, mais je pense que ça viendra probablement de la BI pour qui la diffusion d’informations, leur présentation, la dimension « aide à la décision » devraient être des moteurs. Je vais en causer avec mes voisins de bureau…

Google App Engine

La présentation pour laquelle j’étais essentiellement venu m’a laissé sur ma faim. Il m’a semblé que les deux conférenciers (non « Googliens ») avaient juste passé deux heures de plus que moi sur le sujet (j’avais téléchargé le SDK la veille et déroulé le « Hello World » : 10 mn montre en main) ! Ils ont déroulé le Hello World en une demi-heure puis passé en revue les services disponibles. A leur décharge, on ne peut pas dire que Google nous « arrose » d’informations sur le sujet !

Pour résumer, qu’est-ce que le Google App Engine ?

• Vision commerciale : c’est l’offre « cloud computing » de Google (essentiellement en réponse à EC2 d’Amazon).
• Vision technique : c’est un serveur d’application hébergé exclusivement chez Google et qui s’appuie sur son infrastructure et met à disposition ses services : authentification, mail, persistance dans « BigTable » (LA base Google), accès aux Google Apps…

Concernant la technique, plusieurs points peuvent faire « tiquer » : un développement pour Google App Engine est exclusivement pour Google App Engine ! Google n’a pas eu la volonté d’implémenter, avec ses ressources, un serveur d’appli « standard » (J2EE ?). Tout est un peu « exotique » : l’authentification nécessite d’avoir un compte Google (la page d’authent est la même que pour votre GMail), la base n’est pas relationnelle, le langage de programmation est Python… et, aujourd’hui, aucune solution connue (en tout cas utilisée dans ma boîte, Objet Direct) ne permet de développer facilement (c’est le point important !) des IHM web pour GAE.

Ca veut dire, investir pas mal pour un business à peine émergent (GAE n’existe que depuis avril !).
La donne va changer dès que les API java sortiront (ce qui ne devrait tout de même pas tarder, même si, même sous le sceau du secret, ils ont refusé de nous dire quand !).
Il est donc urgent d’attendre (mais pas longtemps, j’espère).

Une chose très sensible : ce sont des maniaques du secret. Je pense que même après douze bières, il est impossible de leur faire avouer quand java sortira sur GAE. Il doivent avoir un flingue dans le dos (et en tout état de cause, ils sont très, très « briefés »).
A part ça je confirme que l’accueil était très sympa et l’esprit (faussement !) startup affiché (allez voir les photos, il y a même une preuve que j’y étais !). Une bonne occasion de faire du networking » et/ou du recrutement ou tout simplement de croiser des gens sympas « en vrai » (salut Samuel :-) ) ou de vieilles connaissances.

Et, comme prévu, malheureusement, pas de MD chez Google pour le moment :-(

Je sais ça n’est pas du tout MD (encore que : quelle sera la première plate-forme à générer du code GAE ?)

Didier Girard organise un test de stress sur une appli Google App Engine (il va vraiment falloir se mettre au Python, à moins de le générer).
Donc, demain (vendredi 23 mai 2008) 16h, entraînez-vous à la frappe rapide.
Le post original est là (au fait, il se trompe d’heure : en été, la France est à GMT+2 et non +1 ; il risque d’avoir tous les étrangers à 15h !).

Dans tous les cas, je pense qu’on se doit de regarder GAE qui
- est un vrai changement par rapport à nos habitudes actuelles
- est poussé fortement par Google
- est un des trucs qui fait méchamment flipper Microsoft

Il existe un blog pas mal sur le sujet avec quelques liens intéressants.

Bienvenue sur le Cloud.

Qu’est-ce qu’ un DSL (Domain Specific Language ou Langage Dédié pour les intimes) ? Le dernier buzz word à la mode dans la communauté MD ! Si des gens aussi estimables que Martin Fowler prennent la peine d’écrire un livre sur le sujet, ça doit être un peu plus que ça.

J’ai glané quelques définitions sur le web (les traductions sont personnelles) :

(Lire la suite…)