Le développement logiciel est une activité qui fait appel à la créativité. Il y a une part d’expérimentation. J’ai même envie de penser que c’est une activité artistique. Attendez, je ne m’intéresse pas à la beauté du truc. Le code c’est moche. Je parle plutôt du caractère unique de chaque programme, un peu comme une peinture qui est le reflet du sentiment du peintre. Lorsque je développe un logiciel, certes je reproduis des habitudes ou des choses que j’ai vu. Mais je laisse une part importante à l’improvisation et à la liberté. Je pense même que si je devais écrire un bout de code le matin, il n’aurait pas la même tête qu’un bout de code écrit le soir.
Nous avons deux choses à discuter : comment garantir que le logiciel respecte la demande du client tout en étant créatif ? pourquoi cette créativité est une bonne chose pour votre équipe ?
Pour garantir que le résultat est bien celui attendu par le client, nous développons par contrat. Le client exprime ce qu’il veut, nous écrivons alors des tests de recettes pour exprimer ce que souhaite le client. Nous exécutons ces tests, qui échouent initialement. Puis ensuite seulement nous écrivons le programme, nous lançons les tests, nous complétons notre programme, puis finalement nous pouvons dire que le développement est terminé. Donc la réalisation peut faire part à l’imaginaire, mais le résultat final ne change pas (voir la définition de Test Driven Development ou TDD).
La créativité en tant que telle est un facteur qui fait peur à votre chef de projet. C’est un critère non mesurable donc quelque chose qui l’inquiète. Cela se manifeste par quelques phrases comme « …mais c’est pas dans la spéc ? » ou ausi « …tu es sûr qu’il faut ré-écrire cette partie ?« . Tout ce qui n’est pas connu à l’avance fait peur. Soit.
Alors pourquoi la créativité est-elle une bonne chose ?
Elle permet d’apporter une capacité d’adaptation au problème. Elle permet ensuite de trouver plusieurs solutions. Elle permet surtout au développeur de se remettre en question et de ne pas résoudre le même problème de la même façon pendant 20 ans.
Lorsque nous travaillons à plusieurs, la créativité et la curiosité de chacun décuple la qualité d’un logiciel. C’est un garde-fou aussi qui nous évite de dériver lorsque l’on développe. La présence de plusieurs développeurs est important pour réaliser un logiciel. Il faut encourager la programmation en binôme, ou la réunion du matin pour partager ses connaissances, ses soucis et ses bonnes nouvelles.
Je le redis encore une fois : ce qui évite de dériver lorsque l’on développe, que ce soit en terme de coût ou de temps, c’est la présence de plusieurs développeurs. Il suffit de travailler en équipe et de partager à plusieurs les problèmes. Nous devons discuter des solutions, ce qui permet de trouver à plusieurs la meilleure solution à l’instant T pour résoudre le problème.
La curiosité me semble indispensable dans notre métier. Nos connaissances techniques vieillissent vites. Mon expertise sur JSF 1.2 ne me sert plus à grand chose aujourd’hui. Mes connaissances en expressions régulières en Perl me permettent de faire du Groovy, mais guère plus. Ne parlons pas de ce que je savais faire en Tcl/Tk, cela ne me sert à rien aujourd’hui .
Autant fabriquer un violon n’a pas changé depuis 200 ans, autant développer une application de gestion a bien changé depuis les années 90. Et cela ne s’arrêtera pas. Je pense donc qu’il est important de ne pas avoir d’ouvrier-informaticien, mais plutôt des artisans entrainés à apprendre, à chercher des solutions, et à l’écoute des dernières idées. Et un logiciel de génération de code peut en effet faire gagner du temps, voire même montrer les bonnes pratiques.
Etre développeur Java en 2010 c’est dur. C’est un apprentissage assez long. J’étais à la FNAC hier et un bon livre sur Java fait 640 pages. Bon courage à toi qui débute dans le monde Java. Il te faudra apprendre Spring, JEE6, Hibernate, JSF ou Struts 2. Puis un peu de GWT, de Wicket ou de programmation Android. Tu ferras ensuite un peu d’architecture si tu aimes bien modéliser. Tu seras peut-être un expert de l’intégration continue et des bonnes pratiques logicielles… Mais tout ceci te sera enseigné par des vieux développeurs, des bloggeurs, des gars à des conférences, des directeurs techniques passionnés, mais surtout des hommes. C’est la notion de compagnonnage proposée par Martin Fowler et Neal Ford qui seront à l’USI 2010 cette semaine.
Nous sommes un métier qui n’existait pas il y a 50 ans, qui change rapidement et qui demande de la curiosité. Nous sommes donc encore très artisan, et je ne suis pas certain que nous serons des ouvriers industrialisés un jour.
Et moi, ça me plaît.
Crédit photo : Women at work on bomber, Douglas Aircraft Company, Long Beach, Calif. (LOC), octobre 1942. Photo libre de droits tirée de la collection de la Library of Congress, Flickr.com.
0 no like
La comparaison avec le violon me semble maladroite, tant la lutherie est un art reconnu. Mais l’idée est passée.
Bon billet. Il en faut d’autres du même acabit.
Toutefois, la comparaison avec le violon me semble à moi aussi maladroite.
La spécificité de l’artisan tient plus du savoir faire que ne sait pas reproduire un procédé d’industrialisation. L’ouvrier est un maillon de ce procédé et n’apporte pas de valeur ajoutée qui lui soit propre (il est interchangeable)
Concernant l’artisanat du logiciel, il y a une mouvance qui commence à faire des petits. Elle a son propre manifeste : http://manifesto.softwarecraftsmanship.org/ et elle met en avant certains principes (dont j’ai proposé récemment une traduction sur mon blog).
L’apprentissage y tient évidemment une place primordiale. La communauté et le dialogue avec les autres artisans, que tu détaillais dans un précédent billet, aussi.
A cela, il ne faut pas oublier de rajouter le soin pris à faire son travail : si on réécrit une partie de code, ce n’est pas (ce ne devrait pas être ?) pour se faire plaisir mais parce que l’on se soucie de faire quelque chose de bien. « Nous donnons aux problèmes de nos clients l’importance qu’eux-mêmes y accordent »
La communauté et le soin impliquent en outre la présence de « règles de l’art », de « bonnes pratiques » que l’on se doit de suivre même (surtout ?) sous la pression. Bref, pas de travail baclé pour faire plaisir à court terme et en subir les conséquences à plus longue échéance.
Par exemple, le TDD, c’est bien mais sans le refactoring qui doit suivre on ne va pas bien loin.
Pour appuyer les propos, je préfère être un artisan plutôt qu’un ouvrier industrialisé, tel un Chaplin coincé dans les engrenages des temps modernes qui le dépassent. J’ai été formé pour être créatif et seul le fait d’être (ou l’envie d’être) artisan m’offre la possibilité de garder un esprit ouvert, curieux. Et je suis convaincu que c’est par cet état d’esprit que je pourrai répondre au mieux aux besoins de mes clients. On dit qu’un bon artisan doit avoir au moins 10 ans de métier. La plupart des annonces en informatique semblent mettre la barre à 5 ans (?)
Maintenant, il ne faut pas être seulement curieux des techniques (Groovy, JEE6, Play!, etc.) ou des pratique (Scrum, TDD, Kanban, etc.) qui apparaissent. Il ne faut pas oublier qu’il y a dans les sciences informatiques des concepts qui ne demandent qu’à être utilisés et qui offrent souvent des réponses aux problématiques actuelles. Ainsi, nous voyons petit à petit la programmation fonctionnelle resurgir aux travers des closures, de Scala ou Clojure. Les notions de méta-programmation, de AOP ou même de POO ont mis du temps avant de commencer à apparaître dans les entreprises. Et que dire de ces livres comme « Concepts, Techniques, and Models of Computer Programming » de Roy et Haridi ou le SICP (Structure and Interpretation of Computer Programs) qui présentent la simple programmation sous un angle qu’on ne connaissait pas. Bref, la Recherche est une source d’idée.
Franchement, artisan logiciel, c’est tout un métier!
Un petit lien: http://manifesto.softwarecraftsmanship.org/
Hello,
Je suis tout à fait d’accord…
La curiosité est l’élément qui peut faire un vrai différence entre deux individus.
Le champ de connaissance de notre métier est bien trop vaste pour se cantonner à l’utilisation récurrente des même outils ou même algorithmes.
Et je partage l’idée de @fsarradin : ‘Maintenant, il ne faut pas être seulement curieux des techniques (Groovy, JEE6, Play!, etc.) ou des pratique (Scrum, TDD, Kanban, etc.) qui apparaissent. Il ne faut pas oublier qu’il y a dans les sciences informatiques des concepts qui ne demandent qu’à être utilisés…’
Un bien beau billet, qui me donnerait presque envie d’apprendre à programmer proprement 😉
Tiens, un autre du même tonneau :
http://codingly.com/2008/12/29/degage-sale-programmeur/