L'an dernier, l'équipe WikiSpeed a interloqué le monde en appliquant les techniques agiles à l'un des secteurs les plus lourds : l'industrie automobile. Elle a créé une voiture écologique en trois mois, prouvant ainsi que les voitures n'ont pas besoin de dix à quinze ans pour être développées.
Leur nouvelle voiture a été réalisée pour répondre aux plus hauts standards de qualité et ce, grâce au développement dirigé par les tests (TDD, Test Driven Development). En trois jours, l'équipe a créé une magnifique carrosserie. Le châssis est le plus léger au monde à obtenir l'équivalent de cinq étoiles pour sa sécurité. Tout cela a été possible parce qu'ils ont été consciencieusement modulaires dans leur design. Ils pouvaient passer d'une convertible à un pickup, simplement en changeant le châssis.
D'après le créateur de l'équipe, Joe Justice, leur succès est dû en particulier aux facteurs suivants. L'équipe WikiSpeed a :
- Utilisé moins de choses
- Activement travaillé à réduire les coûts de changement
- Collaboré en équipes distribuées avec une forte implication morale
- Travaillé par paires pour réduire le temps d'apprentissage et de documentation
- Visualisé son workflow pour identifier le temps passé à résoudre des problèmes de façon créative
Bien que le succès de WikiSpeed ne soit pas nouveau pour la communauté Agile, il a en soi d'importantes implications pour Agile. En particulier, l'application de la méthodologie en dehors du développement logiciel montre à quel point le style de management des autres secteurs peut être contre-productif, mettant en évidence une accablante inefficacité.
En réduisant le cycle de vie du produit de dix ans à trois mois, l'équipe a été au moins quarante fois plus performante que celles du secteur automobile. Alors que le produit est le même, les outils utilisés restent accessibles à un lycéen au budget serré. Les participants n'étaient pas des professionnels mais des amateurs idéalistes et dévoués.
Le résultat de leur travail met en exergue l'importance du process et de la culture agile. Plus particulièrement, l'équipe a cherché à supprimer tout ce qui pouvait freiner la résolution créative des problèmes. En ressort, l'impact du process dans le monde automobile mais également dans les autres secteurs.
Pour les créateurs de produits, le process est un mal nécessaire
Lorsque vous avez un problème spécifique à résoudre, peu importe que la solution soit :
- un logiciel
- une procédure à suivre
- un objet qui fait quelque chose
Quand vous avez un mal de crâne, vous voulez qu'il parte, par n'importe quel moyen. Vous voulez une solution.
Comme le dit Ted Levitt : "Les gens ne veulent pas acheter une foreuse longue d'un quart de pouce, ils veulent un trou d'un quart de pouce". Ils veulent un trou d'une taille spécifique, le reste est sans intérêt, y compris la façon dont c'est fait. Dans ce cas, le process est le système commercial, mis en place par un entrepreneur, pour délivrer cette solution.
La création de produit est un process en soi. Il est souvent fait en équipe et peut résulter en un logiciel, un nouveau process ou un objet physique qui répond au besoin identifié. En cas de succès, ce processus de création de produit augmente les bénéfices financiers de l'entrepreneur et de ses futurs actionnaires.
Pour faire simple, le process est un mal nécessaire pour de nombreux créateurs de produits. C'est un mécanisme de livraison pour répondre à un besoin et qui permet d'organiser votre travail. Sur le long terme, un bon process génère de la valeur et assure la santé financière d'une entreprise. Cette dernière génère des revenus et augmente sa valeur. Il est dans l'intérêt de tout le monde de garder le process léger, il faut qu'il soit facile à vivre si on doit travailler avec. L'équipe WikiSpeed a prouvé qu'un process léger peut faire toute la différence en termes de productivité.
La dette de process
Dans ce contexte, la dette de process est ce que l'équipe WikiSpeed a cherché à éviter en réduisant le coût des changements. La dette de process est une accumulation de raccourcis, rustines et impasses dans un process existant. Au fur et à mesure, tout s'emmêle, comme des spaghettis, en tirant sur l'un, vous récupérez la moitié de votre assiette. La dette de process est l'équivalent de la dette technique mais côté business, c'est une complexité inutile. Plus important, la dette de process pourrait être évitée par des discussions constructives. Les gens se cachent derrière le process, les "bonnes pratiques", plutôt que de discuter et de résoudre les problèmes. Le process institutionnalise le "Non". Les membres potentiels de l'équipe se sentent aliénés et privés de leurs droits.
Si les rustines s'accumulent sur plusieurs années, sans que rien ne soit fait pour améliorer les choses, vous payez des "intérêts" en temps pour les raccourcis empruntés dans le passé. Ces raccourcis sont un transfert de temps. Un problème aurait pu être résolu plus tôt et une bonne fois pour toutes, cela aurait évité qu'il se présente encore et encore. Et pire encore, ce problème peut affecter d'autres départements qui doivent également le contourner, ce qui peut causer d'autres problèmes. Au bout du compte, tout cela a un impact sur le client, qu'il s'en rende compte ou non.
Dans le cas présent, la dette est comptée en temps, celui des employés en particulier. Un raccourci emprunté à un point dans le temps, engendre une quantité importante de travail dans le futur. C'est ce qu'on considère généralement comme la "dette technique" standard, un problème bien connu. La dette technique est une sous-partie d'un problème plus large de "report de temps" côté business.
Si votre raccourci technique est mis en production, l'équipe opérationnelle doit perdre du temps pour le contourner. Elle a besoin d'un entrainement et d'une documentation supplémentaire pour travailler avec cette complexité ajoutée. L'équipe de développement crée une dette technique qui a un impact sur toute l'entreprise, ce n'est donc plus de la dette technique, c'est un problème généralisé.
Comme le notait Steve McConnell, à propos de la dette technique, son importance est contextuelle. La dette de process est similaire à une dette financière. Prendre un prêt est parfois bénéfique, une dette peut vous aider à atteindre un but stratégique. Vous prenez par exemple un prêt pour acheter une maison, vous louez la maison et cela couvre le coût de celle-ci et de ses intérêts. A contrario, certaines dettes détruisent votre santé financière, vous pouvez avoir une carte bancaire avec 0% de frais sur les transferts d'argent les quinze premiers mois mais ce n'est pas nécessairement un bonne idée.
Comme beaucoup de développeurs le savent, un processus peut souvent être automatisé, des logiciels peuvent remplacer celui-ci comme mécanisme de livraison. Un script peut permettre d'automatiser et de remplacer efficacement un service. Comment être "agile" si mettre en production demande des efforts surhumains ? Cette idée est très présente dans la mouvance DevOps actuelle, en particulier en ce qui concerne la Livraison Continue.
Si vous pouvez scripter votre processus de livraison, vous avez une définition totalement différente de l'agilité. La livraison continue peut sembler centrée sur le code mais c'est en réalité centré sur l'idée d'avoir un processus simple qui se résume à appuyer sur un bouton. Cela permet également à l'équipe de développement de se concentrer sur des problèmes plus importants.
En tant que client, une dette de process importante vous empêche d'obtenir rapidement ce que vous voulez. Comment va votre mal de crâne au fait ?
La dette de process est différente de la dette technique
Dans le fond, la dette de process est une complexité excessive du process côté business, tout comme la dette technique est une complexité excessive du code. Elle dépend de la corrélation entre le langage utilisé pour parler du problème et le domaine du problème lui-même. Si vous êtes capable de produire le même résultat de façon moins complexe, vous ressentez les effets de la dette de process plus lentement. Elle raffermit tout doucement son emprise sur vous. Si vous avez déjà essayé de traduire un process existant en script pour en arriver au point où vous découvrez une montagne de besoins inconsistants, redondants, émanant de plusieurs départements de l'entreprise, vous savez que ce n'est pas la même chose. Il n'existe pas encore de code. Comment cela pourrait-il être une dette technique ?
Les deux types de dette impliquent des conflits de logique non résolus dans le workflow.
- Pour la dette technique, cela inclut les variables et fonctions qui ont une mauvaise portée, la séparation floue des responsabilités ou encore les effets secondaires inattendus
- Dans le cas de la dette de process, cela indique des buts mal définis, des rôles mal établis dans l'organisation, une identité d'entreprise confuse, des effets secondaires inattendus causés par un manque de communication entre les départements
En 1968, Melvin Conway a dit : "La structure d'un système est à l'image de la structure de communication de l'organisation qui l'a conçu". D'après la loi de Conway, la complexité se répand jusque dans le code mais provient, au fond, d'un manque de communication entre les personnes impliquées et d'un manque de confiance. La dette de process crée la dette technique.
La plupart des entreprises éditrices de logiciels subit une forme de dette de process. Pour certaines, cela peut être intentionnel, stratégique même, comme le prêt pour la maison vu précédemment. La plupart des dettes de process restent cependant non-stratégiques, tout simplement parce que les entreprises ne s'en rendent pas compte. Si, par exemple, votre logiciel n'a pas de dette technique mais que votre mécanisme de déploiement n'est pas entièrement scripté, vous avez de la dette de process.
Comment gérer la dette de process ?
La majeure partie des conseils ci-dessous tombe dans la catégorie "Je le sais mais je m'en occuperai plus tard". Occupez-vous en maintenant et plus particulièrement si ça vous ralentit, ça vous empêche de prendre de la vitesse. Cela fera plaisir à vos clients, surtout si ces derniers se plaignent de votre manque de flexibilité ou de vitesse.
Clarifier agressivement sa stratégie
D'après Fortune Magazine, plus de 70% des entreprises gèrent mal leur stratégie. Dans The Strategy Fortune Organization, Kaplan et Norton ont découvert que bon nombre d'entreprises passe environ une heure par mois à discuter de stratégie, le temps restant étant dédié au travail. Si les entreprises parlent stratégie, cela se limite à quelques seniors décisionnaires discutant à huis-clos. Cette approche empêche la bonne application de la stratégie et risque une réaction hostile des employés qui doivent changer leur façon de travailler.
À l'inverse, dans Motivate Like A CEO, Suzanne Bates affirme que le rôle d'un CEO est de communiquer en permanence sur la stratégie, de l'intégrer dans l'activité de tous les jours. Idéalement, cette stratégie doit pouvoir se résumer en une phrase d'accroche. La stratégie se découvre en groupe, en impliquant tout le monde dans l'entreprise. Cela permet de déterminer le plus important à accomplir. D'autant plus si le CEO accompagne chaque jour les employés dans leur application de la stratégie. C'est une démarche qui reste difficile alors même que la stratégie est claire, c'est pour cela qu'elle doit être d'une transparence complète pour que chacun puisse agir en adéquation.
Dans le contexte d'un club à but non lucratif, j'ai pu me rendre compte de la complexité de cette tâche. En m'adressant à chacun, individuellement, j'ai aidé le groupe à décider quels étaient les buts majeurs de l'association. Une fois cela mis en évidence, ma mission a été de communiquer ces priorités de façon pertinente afin que chaque volontaire ressente l'utilité de sa contribution. À la différence d'une entreprise, les volontaires n'étaient pas payés pour leur temps ou leurs contributions, ils cherchaient avant tout un sentiment de satisfaction, se sentir utiles en aidant les autres. En établissant ensemble la liste des priorités et en communiquant dessus tout le temps, j'ai permis à l'association de doubler ses effectifs en un an.
Une stratégie floue amène à une exécution floue. Éclaircir les "points stratégiques" permet d'en tirer avantage. Avec la bonne stratégie, atteindre vos objectifs est facile. Penser et raisonner clairement vous permet de produire beaucoup avec peu.
Il est inutile de s'occuper de la dette de process tant que votre stratégie n'est pas clairement établie. Cette derrière va définir quels sont les processus adaptés et lesquels peuvent être éliminés. Rien ne sert d'améliorer votre rendement si vous n'avez pas un sens clair de l'efficacité. En d'autres termes, aller plus vite est inutile si c'est dans la mauvaise direction.
Simplifier son workflow avec des logiciels
Une fois votre stratégie clarifiée, vous pouvez automatiser un processus utile ou en remplacer un qui ne l'est plus. Pour un éditeur logiciel, l'automatisation du travail est ce qui produit le plus de résultats.
Les comptables de l'un de mes clients passaient pratiquement une semaine par mois à produire des rapports pour les actionnaires. Cela commençait par une extraction manuelle depuis une base de données, suivie par la mise en forme des données de façon à les envoyer. Au fur et à mesure que de nouveaux investisseurs entraient, les rapports devaient être de plus en plus personnalisés.
C'est là que le geek (moi) entre en scène. Après quelques scripts VBA, liés à des listes déroulantes remplies par des requêtes SQL, ils étaient capables de produire les mêmes rapports en quelques secondes. Du point de vue de leurs investisseurs, les rapports étaient équivalents et produisaient la même valeur ajoutée.
Plutôt que de leur prendre des semaines, avec une méthode manuelle, laborieuse et sujette à l'erreur, un développeur avait réduit le tout à une poignée de secondes. D'une semaine à cinq secondes : 12 096 000% de gains de productivité. De plus, une fois la logique des rapports établie puis validée par le client et ses investisseurs, le processus ne risquait plus du tout d'erreur. Les comptables pouvaient travailler sur des tâches, discussions et analyses bien plus intéressantes, ils étaient ravis.
Éliminer les dépendances
Un process introduit souvent des dépendances, en particulier lorsqu'il y a plusieurs usages d'une même ressource. La concurrence pour son usage se transforme en goulot d'étranglement. Le progrès est ralentit de façon significative.
Le développement de logiciel multithread est une bonne analogie. Dès que deux threads entrent en conflit pour l'utilisation d'une ressource, on utilise un mutex pour s'assurer que les threads n'écrasent pas les données. En fonction du contexte, cela peut créer un blocage. Supprimer ce blocage permet souvent au code de passer d'un temps de suspension indéfini à une vitesse d'exécution presque instantanée.
Si vous développez par exemple une application multithread et que celle-ci souffre de problèmes de performance, suite à l'ajout d'une fonctionnalité, cherchez les gains rapides. Concrètement, cela veut dire chercher les threads qui bloquent et empêchent d'autres parties de l'application de fonctionner tant qu'une tâche n'est pas terminée. Si les threads bloquent, vous aurez typiquement des messages qui s'empilent dans une queue pour alimenter le thread en attendant que celui-ci se libère.
Don Reinersten, l'auteur de The Flow of Product Development, considère les fonctionnalités non publiées ou à moitié terminées comme le fléau de la plupart des initiatives de développement logiciel. "L'état du développement d'un produit s'observe par ses effets : le temps de cycle qui s'allonge, une retour qui tarde à venir, des priorités qui changent et des rapports d'erreur". Lorsque les fonctionnalités non terminées s'empilent, le responsable est généralement un blocage dans le projet. Les dépendances entre projets finissent doucement par les tuer.
Supprimer ces dépendances est la façon la plus efficace d'améliorer la rapidité de livraison d'un éditeur. Idéalement, cela signifie moins de projets, ce qui vous permet de vous concentrer sur les produits et les clients.
Il est plus facile de rendre les clients heureux quand les fonctionnalités sont livrées plus rapidement, ils ne passent pas leur temps à attendre.
Réduire le nombre de variables en supprimant les détails inutiles
Si vous avez une importante dette de process, vous obtiendrez des gains significatifs en réduisant le nombre de "symboles", variables et sources de données avec lesquels vous traitez chaque jour. Cela augmente le ratio signal/bruit de votre communication et vous permet de vous concentrer sur des problèmes plus intéressants.
Concernant le code, les systèmes de contrôle de versions des 90' traquaient chaque fichier séparément. Aujourd'hui, la plupart de ces outils traquent le projet dans son ensemble. Pour un système large, composé de nombreux fichiers et de parties qui intéragissent, vous réduisez beaucoup la complexité en utilisant un numéro de version unique pour tout le projet. Il devient plus facile de parler de problèmes spécifiques, vous avez besoin de moins de documentation. C'est une forme de dette technique qui a un impact sur le process. Une fois le système de contrôle de version mis en place, les tests, la livraison et autres opérations sont simplifiés.
Cette approche est accompagnée de certaines difficultés comme la gestion de versions des paquets de base de données ou un planning de livraison inconsistant entre les composants. Faire face à ces difficultés vous force à réduire la "friction" causée par un process trop compliqué.
Limiter ses engagements
Le manque de confiance cause un certain nombre de problèmes qui poussent les managers à mettre en place des techniques qui forcent une certaine forme d'engagement, détruisant ainsi une part de la valeur ajoutée. De nombreux outils, comme MS Project, tentent de créer un planning détaillé à partir du nombre de dépendances et des deadlines. Bien que ce niveau de détail soit censé produire un planning fiable, s'engager inutilement sur des deadlines intermédiaires fait que l'on perd de vue les vraies priorités. Dans le meilleur des cas, vous optimisez localement, mais pour un coût global élevé. Un projet est livré à temps au détriment des autres. Cela réduit la confiance dans le planning, ce qui pousse à une planification encore plus détaillée.
Dans MS Project, la dépendance de tâches "Finish-To-Start" (FTS) gère la majeure partie de la dette de process inhérente à la gestion "waterfall", c'est la gestion de dépendances par défaut de MS Project. Avec FTS, vous devez terminer certaines tâches avant une date donnée, il faut donc régler la date de démarrage des tâches dépendantes assez tôt pour pouvoir finir l'autre tâche à temps.
Cela peut sembler une bonne chose, vu de haut ("commencer avec la fin en tête"), mais au niveau des tâches, cela réduit inutilement la flexibilité. Avec TFS, vous vous engagez à respecter des deadlines précises, ces deadlines ont un impact sur le travail qui les précède : s'il y a beaucoup de tâches, il devient plus difficile de définir lesquelles sont prioritaires. Les dates prennent préséance sur les priorités, à moyen terme, vous oubliez ces dernières, tout le monde se concentre sur la date de livraison.
La mouvance #NoEstimates a commencé à prendre place chez les professionnels du logiciel. Elle refuse toute évaluation de temps ou d'effort. Les partisans de #NoEstimates considèrent que forcer un développeur à donner une estimation oblige le business à fonctionner comme FTS. Cela nuit au travail du développeur à cause du stress que provoque l'attente de résultats. Ce stress empêche de résoudre un problème de façon créative. Au final, cela crée un conflit inutile entre les développeurs et la couche business.
L'impact d'un engagement inutile sur un process va bien plus loin que le développement. Beyond Budgeting de Hope et Fraser reproche beaucoup au process de budgétisation traditionnel. Bien que la budgétisation ait été un bon moyen d'imposer une certaine discipline fiscale aux grosses entreprises automobiles dans les années 50, elle peut également causer beaucoup de gâchis. Plusieurs mois sont perdus à débattre sur ce à quoi doit ressembler le futur et quel est le budget nécessaire pour ensuite s'engager sans réellement savoir de quoi sera fait ce fameux futur. Au lieu de cela, il serait beaucoup plus simple d'analyser ce qui marche ou non aujourd'hui.
D'autres approches existent, comme Activity-Base Costing (ABC). ABC calcule les profits et pertes par activité, client et produit à un rythme régulier, si possible tous les jours. Cela donne à tout un chacun la possibilité de prendre des décisions et d'avoir un retour rapide sur l'impact financier qu'elles peuvent avoir. L'information n'est plus discutée à huis-clos mais accessible librement. Tout le monde en bénéficie, y compris les employés qui sont en première ligne. Un retour immédiat influence leurs décisions qui influencent à leur tour la rentabilité de l'entreprise, c'est un cercle vertueux.
Donner le temps d'écouter à ceux qui corrigent les problèmes
Dans un contexte bureaucratique assez large, il est fréquent de créer des murs artificiels, de poser des limites pour "contrôler" la complexité. Malheureusement, cela signifie le plus souvent que les informations les plus importantes ne circulent pas. Personne n'agit par manque de vision d'ensemble. En donnant une voix à tout le monde, cela permet de faire remonter les plus grosses frustrations. En général, les employés du rez-de-chaussée ont une bonne idée de ce qui cloche dans l'entreprise, ils sont simplement ignorés. Lorsqu'ils ont la parole, leur message ne porte pas assez loin, ils ont peur des conséquences négatives, personne ne veut être vu comme un rabat-joie.
Si vous pensez que donner une présentation en public est dur, essayez d'en donner une devant vos collègues. Cela peut sembler farfelu mais c'est en fait une technique utilisée par les comiques d'improvisation pour parfaire leur talent. Les participants ne connaissent pas le sujet avant de commencer mais doivent arriver à établir une connexion sur scène.
En résulte qu'ils sont capables de trouver une réplique à chaque phrase. Cela permet de voir ce qui coince, de construire naturellement. La créativité systématique vient d'une écoute très attentive.
C'est l'exemple parfait d'une collaboration créative. D'après Tom Salinsky dans The Improv Handbook, le principe d'improvisation du "Oui, et" permet de diriger le flux créatif de l'équipe. Pour créer un sketch, deux comédiens entrent en scène, uniquement équipés de leur imagination. Dès que l'un commence, l'autre répond aussitôt à "l'offre" du premier. Cette offre devient "réalité" pour la durée du sketch. Le fait qu'ils s'accordent sur l'offre la rend "concrète" dans l'esprit des spectateurs. Aucun acteur ne sait ce que l'autre va offrir, c'est de cet imprévisible que nait la magie. Ça ne marche que lorsque les participants s'écoutent attentivement, ce qui requiert un haut niveau de concentration et de confiance.
En ce qui concerne le dialogue, un comédien d'improvisation accepte toujours ce que le précédent a dit. Dire "Non" ou "Oui, mais" coupe la créativité et la dynamique de la scène. À l'inverse, "Oui, et" pousse la collaboration en avant. Un environnement dans lequel chacun construit sur les idées des autres favorise l'arrivée de nouvelles idées.
En improvisation, l'accent est mis sur la qualité de l'intéraction. À chaque étape, le "Oui, et" permet à l'équipe d'avancer. Vous découvrez ce que vous faites au fur et à mesure (pensez à Deliberate discovery de Dan North). Cela demande d'être très attentionné, de faire attention à ce que font vos collègues, pour répondre à chacune de leurs offres.
La même productivité peut être atteinte en utilisant "Oui, et" durant le développement d'une fonctionnalité ou d'une architecture logicielle. La structure idéale est inconnue au commencement puisqu'elle dépend du problème à résoudre. L'équipe doit discuter des aspects du problème, diverger, explorer plusieurs formes possibles du logiciel. C'est une série d'offres "Oui, et". L'équipe finit par converger vers certaines solutions et la meilleure est conservée. Les idées entrent en conflit mais les participants s'en tiennent toujours à l'attitude "Oui, et".
Le process... barre la route. Il institutionnalise souvent le "Non" et le "Oui, mais", tuant ainsi la créativité qui aiderait à résoudre les problèmes. Bien qu'une certaine forme de process soit essentielle, un process qui détruit la créativité ralentit toute l'entreprise.
@theagilebastard : "Les gens et les intéractions passent avant le process et les outils" Nelson Mandela, de sa cellule en 1985. #Philosophie #Agile #Kanban
La bonne nouvelle
En réduisant la dette de process, vous :
- Accélérez votre capacité de livraison rapide
- Réduisez le nombre d'erreurs
- Rendez son énergie à votre entreprise et remontez son moral
Dans le meilleur des cas, vos process de développement et de production peuvent être gérés de façon logicielle, quelques scripts flexibles au sein d'un mécanisme de construction qui compose votre produit en fonction des besoins de vos utilisateurs. Vous pouvez diriger votre processus de livraison par une Intégration Continue qui lancerait une suite de tests unitaires et de tests d'acceptance et pourrait même pousser en production, en fonction du logiciel que vous créez (une application web par exemple). Certaines équipes comme celle du grossiste Etsy.com pousse en production 30 à 50 fois par jour.
Le meilleur process, ce n'est pas un process, simplement un bon script. C'est l'essence du problème, une solution à la portée d'une pression de bouton. Cela permet de résoudre les problèmes de façon créative. Les membres de l'équipe peuvent donner tout leur potentiel sans avoir à répéter les mêmes tâches encore et encore.
Malgré l'accent mis sur les process en agile, en particulier par les débutants, il est facile de perdre de vue leur raison d'être. Ils sont volontairement légers pour permettre de se concentrer sur les individus et les intéractions. En retirant le poids du process avec agile, des gens fantastiques peuvent être très performants, demandez à l'équipe WikiSpeed.
Si vous souhaitez réduire la dette de process de votre entreprise, rendez-vous sur Overcoming Process Debt pour télécharger un cahier d'exercices gratuit.
À propos de l'auteur
Lukasz Szyrmer a plus de 12 ans d'expérience en développement logiciel, gestion de produit, prise de parole publique, mentorat et activisme communautaire. Il aime le challenge, distiller les problèmes techniques complexes jusqu'à leur essence, de façon à ce que d'autres en profitent. Il a inspiré de nombreuses personnes vers l'amélioration systématique. Il développe actuellement des logiciels de finance temps-réel et multithread en C++ et C#. Luke a appris à coder enfant, fasciné par les logiciels, assez pour devenir développeur C embarqué après un diplôme d'Économie. En plus d'être diplômé en Économie et Finance, il est également Chartered Alternative Investment Analyst. Enfin, il tient un blog.