Les constats

Avec les besoins grandissants des entreprises de se transformer ou de se placer comme un acteur clé dans l'IT, le besoin en développeurs a explosé ces 10 dernières années, générant des tensions et difficultés à recruter.

Les développeurs doivent créer des logiciels capables de servir des ambitions de plus en plus fortes en matière de features / coût / délai / sécurité / qualité et scalabilité, et pour y arriver ils s'appuient sur des briques existantes, des frameworks ou librairies souvent open source, plutôt que de tout faire eux-mêmes.

La DX c'est quoi ?

Au delà du buzzword, une façon simple de définir la DX, à l'instar de l'UX :

“La DX c'est l'expérience utilisateur quand l'utilisateur premier du produit est un développeur”

C'est un point de départ facile à appréhender à priori, mais voyons comment ce principe se décline et quels sont ses enjeux…

En fonction de l'activité de son entreprise, il n'est pas rare de se retrouver à gérer une population interne de développeurs, et en même temps adresser des clients développeurs.

Par exemple, dans des architectures N-tiers ou des micro-services on fait la part belle aux APIs pour maximiser la capitalisation et normaliser les couches d'accès au SI. C'est un bon exemple de cristallisation de la DX : une API est produite par des développeurs, pour des développeurs qui produisent des apps (et portent les usages).

Dans ce type de contexte, comprendre le "fonctionnement" d'un développeur permet de mieux connaître son client, et de limiter le turnover de ressources rares dans ses équipes.

"If software is eating the world, then developers are writing the menu" (SlashData)

Points clés de la DX :

S'intéresser à la DX c'est investir dans tout ce qui peut être en interaction avec un développeur et qui peut contribuer à améliorer son expérience: IDEs, outils, frameworks, librairies, écrans, claviers, documentation, APIs, SDKs, qualité, design patterns, méthodes agiles, mob programing, …

Des besoins matériels aux références culturelles, en passant par le coaching, la DX ratisse large.

La DX pourquoi ?

"Pourquoi investir dans la DX ?", il est légitime pour une organisation de se poser cette question.

Quelques arguments à prendre en compte :

Un développeur qui a une meilleure expérience s'épanouira davantage, travaillera mieux, sera plus fidèle (avec ses outils et son organisation), et deviendra un formidable prescripteur auprès de ses collègues, ses amis, ses pairs.

Les top produits l'ont très bien compris.

Quelques exemples :

• Netlify et son organisation originale
• Stripe : le modèle des APIs réussies
• Medium et ses checklists d'onboarding
• L'onboarding chez Asana centré sur la notion d'équipe
• Ceux qui ont su pratiquer le Dogfooding avec succès :
  • Google, Facebook sur la plupart de leurs produits (Gmail, Google Apps, Facebook Reactions Feature)
  • YouTube et son système de licence standard / creative commons
  • Oracle qui fait tourner ses bases sur son propre OS Oracle Linux
  • Hewlett-Packard avec son projet Alpo qui met en avant ses propres produits auprès des employés
  • Mircrosoft avec Excel

Comprendre ce qui est important pour un développeur :

• Fonctionnalité, d'abord : rien ne peut masquer ou combler une fonctionnalité défaillante, quel que soit le produit sans un fonctionnement efficient et stable il n'y a pas de DX
• Ticket d'entrée, faciliter la vie du développeur : en rendant accessible la documentation, en l'accompagnant vers un résultat rapide ; faire gagner du temps au développeur génère plus d'engagement
• Culture - s'adresser aux développeurs : cela parait évident, mais il suffit de commencer à s'adresser à la population des développeurs pour gagner du crédit, sur un site de documentation par exemple, identifier des cas d'usage spécifiques qui parlent aux développeurs installe une empathie qui sera bénéfique
• Transparence, clarté : les développeurs sont sensibles aux communications claires, transparentes, qui leur donnent le sentiment de parfaitement comprendre ce que fait le produit et qui leur donnent envie d'en savoir plus ; de plus, partager la vision produit au plus tôt avec les développeurs favorise l'engagement.

Identifier ce qui peut être rédhibitoire pour un développeur :

• Pointer du doigt : en cas d'erreur, plutôt accompagner et profiter de l'opportunité de s'améliorer que punir
• Deadlines : même si un jalon butoir existe toujours dans la vraie vie, on fait trop souvent l'erreur de le faire porter par le développeur, avec le risque et l'incertitude associés qui sont générateurs de démotivation
• Responsabilités diffuses : le but n'est pas de trouver des responsables pour les punir en cas de problème (cela reviendrait à pointer du doigt), mais bien de comprendre quels sont les périmètres de responsabilité respectifs des différents acteurs pour comprendre l'organisation autour du delivery et être ainsi plus efficace au quotidien ; or c'est malheureusement souvent un souci dans les organisations de grandes DSI françaises
• Incohérences : le développeur n'aime pas jouer à qui-perd-perd, cela signifie qu'il aime connaître les règles du jeu au début et savoir comment ses estimations de charge de réalisation vont être utilisées ; comprendre pourquoi sa présence à telle réunion est nécessaire et non contre-productive, sous peine d'être mal vécue et source de déception et/ou d'usure prématurée

Il y a également - surtout - le rapport au temps et l'organisation au quotidien qui sont très différents selon que l'on est un “maker” ou un “manager”, Paul Graham résume très bien le problème ainsi :

“When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.” (source : paulgraham.com/makersschedule.html)

Et pourtant, la plupart des développeurs aiment être impliqués et participer aux réunions, pour peu que l'ordre du jour soit correctement défini ; le souci c'est le zapping / l'enchaînement et la difficulté à rendre sa journée efficace et productive quand on est engagé sur du delivery.

Un début de réponse : accepter l'idée que la bonne granularité pour un développeur est plus proche de la ½ journée que de l'heure.

(source : tylerdevries.com/maker-manager)

Enfin, difficile de parler de ce sujet sans mentionner le software craftsmanship, discipline dont l'objectif est de promouvoir une forme d'"artisanat industriel" dans les pratiques de développement logiciel ; c'est un sujet relativement clivant dans le monde de l'entreprise et souvent mal compris, que l'on peut considérer comme l'une des armes internes pour aller dans le sens d'une meilleure DX.

(source : agilepartner.net/software-craftsmanship)

En entreprise, une bonne DX peut contribuer fortement à solutionner des problèmes comme l'absence de capitalisation sur les connaissances, le manque de motivation des équipes, un mauvais état d'esprit, une culture toxique, une qualité du code en berne ; autant de douleurs qui, si elles ne sont pas traitées, finissent par coûter très cher.

Personnellement, ce qui me plaît dans la DX, ce n'est pas tant le fait de mettre le développeur au centre de la réflexion, qui reviendrait à prendre les mêmes risques que toute posture trop centrée sur une population, mais plutôt le fait de comprendre qu'un développeur qui est considéré et se sent utile aura un potentiel de productivité décuplé ; ce qui peut aussi favoriser les petites équipes et alimenter un cercle vertueux.

Pour poursuivre sur le sujet, une base de connaissance intéressante et plutôt fournie : developerexperience.io.