J’ai été tenté d’écrire un article sur les incroyables capacités et potentiel du langage scala et de son écosystème. Quel que soit l’article vantant les mérites de telle ou telle technologie, que ce soit de la lessive, une voiture, le C++ et maintenant scala, on retrouve à peu prés les mêmes éléments marketing :« Performant » « Puissant » « Efficace » « Bla bla bla ».

La technologie

Lorsque l’on compare les différents langages, les différentes technologies, l’efficacité / performance varie souvent d’un facteur 3. En effet, l’accompagnement au changement, comme par exemple la formation, la migration logicielle, les changements dans les process de développement, etc, sont couteux et font que ce type de solution est difficilement maitrisable.

Ce n’est qu’en cas de saut technologique que ce facteur peut être largement supérieur - je ne parle pas des dépliants publicitaires bien sûr -.

Sommes nous bloqués là ?

Quel est l’objectif réel lorsqu’on choisit une nouvelle technologie ? La raison est souvent : « déveloper plus vite ». Et pourquoi déveloper plus vite ? Pour livrer plus vite.

L’équipe

Livrer plus vite. Une solution est d’utiliser une équipe plus compétente ou mieux formée:

• la recette idéale entre le meilleur ratio développeurs-seniors (+cher) et développeurs-juniors (moins-chers) est toujours en préparation;
• le consensus est plutôt de bien maitriser la croissance de l’équipe et le « team building »;
• la citation « neuf femmes ne font pas un bébé en un mois » est toujours d’actualité.

En fonction de l’expérience, les développeurs vont choisir des solutions plus ou moins adaptées. La variabilité constatée est d’au moins entre 1 et 10, voire plus …

Livrer plus vite c’est bien, mais livrer quoi, telle est la question … ?

Livrer, c’est quoi ?

Il faut faire la différence entre:

• ce qui est livré : « la fonctionalité »;
• celui qui l’utilise : l’utilisateur;
• celui qui paye : l’acheteur.

L’acheteur paye pour livrer la fonctionnalité à l’utilisateur.

Voici ce qui peut arriver:

• peu de livraisons ou peu d’utilisateur = faible nombre de transactions
• valeur ajoutée fournie par la fonctionalité trop faible = transactions de faible montant
• pas d’acheteur = pas de paiement

La valeur ajoutée est déterminée en fonction du service rendu, et non pas en fonction du coût de production. Celle-ci pourrait concerner par exemple l’augmentation des revenus, la projection de la marque ou la rétention des clients.

L’organisation

Imaginons une organisation dont le contexte est le suivant:

• 1.000.000 de clients, en constant renouvellement;
• le coût du service est de 30€ / mois

Considérons une fonctionalité de rétention des clients:

• rétention de 5.000 clients / mois;
• bénéfice attendu = 150 k€ / mois
• coût de développement négligeable = 10j de développeur
• délai de livraison = 1 mois

L’organisation dispose de plusieurs paramètres pour optimiser son développement. Les voici ordonnée par impact financier:

• sélection de la bonne fonctionnalité
• réduction du délai de livraison - hypothèse de « déploiement continu » -
• réduction du coût de développement

On saisit rapidement l’impact des projets organisés autour de l’optimisation de la livraison de valeur ajoutée. La stratégie est tout simplement de commencer la livraison de la valeur ajoutée la plus élevée en premier.

On peut évaluer, au minimum, une différence de productivité (financiaire) de 1 à 100 entre les organisations qui tirent profit de ce type d’optimisations et les autres.

Et scala dans tout ça ?

Développer, en scala ou dans quelque langage que ce soit, ne me parait être en aucune façon une garantie de succès. L’impact de l’organisation sur le succès ou l’échec d’un projet me parait bien supérieur:

Impact de l’organisation : 1 à 100; Impact des équipes : 1 à 10; Impact des technologies : 1 à 3. Si pour vous « retrospective meeting » ne rime pas avec itération, les méthodes agiles peuvent vous apporter un vrai plus dans votre productivité quotidienne.

Si pour vous un « retrospective meeting » est indispensable après chaque itération; je vous fais totalement confiance car au final vous avez obtenu votre organisation avec les bonnes personnes, les bons profils, et les bonnes technologies. D’ailleurs, vous avez déjà décidé sur le fait d’utiliser Scala ou non, n’est-ce pas ?

CQFD : « Quel avenir pour Scala ? » n’est pas la question.