Ouarzy's Blog

Ouarzy's Blog

De la révolution électrique à la révolution numérique

“Je suis une société qui produit des bougies. Bonjour M. Thomas Edison, je sais que vous vous y connaissez en électricité, et on m’a dit que pour survivre  à ce nouveau siècle, j’allais devoir comprendre et intégrer l’intérêt de l’électricité. J’ai une superbe idée, vous pourriez me concevoir un objet qui utiliserait l’électricité pour remplacer la bougie. On va appeler ça l’ampoule. Par contre, comme c’est moi qui vais financer, j’ai besoin de savoir : votre ampoule elle sera disponible dans combien de temps ?

  • Euh…      ben c’est-à-dire que…
  • Non mais attendez c’est juste un fil et de l’électricité, bon on va noter 3 mois.“

ampoule.png

[Image 1]

 

Vous êtes développeur, et pourtant cette situation vous semble familière? C’est parce que dans notre fonctionnement français actuel, on travaille à peu près comme ça.

Evidemment je caricature, mais l’idée est là: nous développeurs passons notre temps à inventer. Ou du moins à essayer de donner vie à l’invention d’une société (même si cette société peut être la notre). Certes on peut se reposer sur des méthodes, des patterns, des frameworks. Mais au final l’assemblage de tout cela reste une invention, unique à chaque fois. Une invention qui répond (du moins en théorie) à des besoins précis, qui sont la justification même de la création de ce logiciel.

 

2011_11_15_life_of_a_swe_png_pagespeed_ce_2kEDNYhstS.png[Image 2]

 

Nous construisons de l’immatériel. Et en tant que processus immatériel, la conception d’un logiciel n’est pas prédictible. Pas plus qu’on a su prédire le temps qu’il faudrait pour concevoir les plans de la première cathédrale ou pour faire marcher la première ampoule. Nous construisons de l’immatériel, et c’est pour cette raison que le produit de notre création  est plastique, adaptable. Pourtant, on aimerait figer dans le marbre (ou dans Word, c’est vous qui voyez) ce que devra être le logiciel, de façon à ce que des exécutants n’aient plus qu’à transformer ces informations en code.

 

Mais dans notre métier il n’y a plus d’exécutants, car il n’y a plus de tâches répétitives à faible valeur ajoutée. Pour être exact, ce n’est pas que ces tâches n’existent plus, c’est que ces tâches sont automatisées (compile, build, tests, voir deploy). Le développeur a donc la responsabilité continue et permanente de concevoir le code qui permettra au produit de prendre forme. Car même en se basant sur une spécification, aussi complète et détaillée soit elle, il y aura systématiquement une part d’interprétation pour le développeur. Il y aura systématiquement différentes façons de l’implémenter. Il y aura systématiquement des choix importants à faire pour cette personne qu’on aurait voulu priver de réflexion. Des choix qui peuvent avoir un fort impact (en terme de sécurité, de performance, d’ergonomie...) Des choix qui risquent d’être mauvais si on mâche le travail du développeur pour qu’il n'ait aucunes questions à se poser.

 

En fait ça revient à demander à un mec à qui vous avez mis des œillères de vous ramener chez vous en voiture. Rien de compliqué puisque vous lui avez donné une carte détaillée de la route à suivre. Mais que se passe-t-il si cette personne, habituée à conduire, connaît un chemin plus rapide? Moins dangereux? Plus économique? Que se passe-t-il  si Bambi ou sa maman surgit d’un bois et que votre chauffeur ne le voit pas à cause des œillères que vous lui avez collées?  Et oui: des bébés biches orphelins, des millions d’enfants qui pleurent dans le monde, et même pire, un pare choc à changer.

 

bambi.jpg[Image 3]

 

En résumé: puisque nous construisons de l’immatériel, la conception est très peu prédictible. Puisque nous construisons de l’immatériel, nous concevons des produits adaptables. Toute cette conception (appelée plus communément le développement) nécessite le travail de personnes étant capable de produire de la valeur. Et au cas où vous vous poseriez la question, la production d’un document Word de 300 pages a une TRES faible valeur (Oui la production de 300 dalles de marbre à la limite, ça peut avoir une valeur esthétique).  

 

Il faut donc être adaptable (y compris sur sa façon d’estimer la conception), et avoir une forte confiance en ses collaborateurs. Les responsabiliser afin qu’ils aient une implication dans le processus de conception. C’est pour toutes ces raisons que l’agilité est actuellement  le moyen le plus légitime pour organiser le développement d’un logiciel.

 

Les entreprises qui réussiront dans ce nouveau siècle sont celles qui auront compris ces états de fait. Et oui ami développeur, tu n’es pas (ne peux pas) être un simple exécutant si tu veux être un développeur professionnel, qui créé de la valeur. Et si ton entreprise ne le comprend pas, il te suffit de partir, de toute façon elle ne représente pas l’avenir.

 

Merci encore au DevLyon pour la relecture!

 

 

 

 

 

 

Image 1: //blog.logic-immo.com/2011/04/j-amenage/le-point-sur-l-eclairage-domestique/

Image 2: un tweet de Vincent Janelle

Image 3: //eilonwyandwiggins.blogspot.fr/2013/01/les-morts-les-plus-tragiques-de-disney.html

 



25/04/2014
0 Poster un commentaire
Ces blogs de Informatique & Internet pourraient vous intéresser