Le futur du décisionnel? Pas forcément là où on veut nous le faire croire…

Via Jason Kottke, cette jolie vidéo qui présente la chaîne d’assemblage de Tesla pour produire le Model S :

Prenez le temps de la regarder, elle est courte et elle vaut vraiment le coup d’œil.

Pour donner un peu de contexte, Tesla Motors est un constructeur automobile américain récent, spécialisé dans les voitures 100% électriques, lancé par Elon Musk, un Nikola Tesla moderne. Comme on le voit dans la vidéo, ils sont au somment niveau innovation.

Et un peu plus tôt, toujours via Kottke, il y a cette vidéo de l’usine d’assemblage NeXT, le constructeur informatique qu’avait lancé Steve Jobs avant de revenir chez Apple.

Ce qu’on peut voir dans ces vidéos, c’est pour une chaîne de fabrication le top en termes d’organisation, de flux de production, d’automatisation, d’intégration logistique, d’amélioration continue… (de lean manufacturing en sorte) qui mènent au top en terme de qualité et de temps de construction (3 jours pour une voiture, combien de temps pour un projet décisionnel?).

Et de là on peut faire le parallèle à notre activité de développement en décisionnel, sur SQL Server ou pas. Chez nous, pas d’usine logicielle, très peu de frameworks – ou qui ne font pas franchement rêver – le tout début de la génération automatique de code (il faut que je m’y mette), surtout des Best Practices transmises via savoir tribal et quelques Design Patterns (SSIS oui, SSAS et SSRS sont bien vides).

Ça c’est sur la conception, mais côté industrialisation on est aussi à la ramasse. Entre autres: un déploiement de toute une solution en un clic c’est encore trop risqué, un build complet ça n’est pas possible et ça ne sert surtout pas à grand chose, et si les tests automatisés fonctionnent bien en SQL OLTP, c’est encore dur de comparer des données en provenance de sources hétérogènes (SQL vs MDX vs DAX, à voir si ça n’est pas en train de changer).

On présente le futur de la BI comme étant un mix de Big Data, de Data Visualisation, d’in-memory, d’analyse prédictive, de stockage verticale ou encore de Cloud. Certes, mais je crois qu’avant cela il faudrait déjà qu’on rejoigne le présent du monde du développement logiciel. Ce serait déjà pas mal.

Deux points positifs cependant : on se rattrape sur les cycles d’amélioration continue : côté plateforme (base de données des bugs, templating, reporting sur l’usage et les performances…) et côté équipe (revue de code, plan de formation, plan de carrière, suivi des objectifs…). Et également avec la verticalisation, à savoir : on construit une fois, le plus proprement possible, et on réutilise sur d’autres projets qui utilisent les mêmes applicatifs sources. Mais ça ne marche que dans les marchés où les progiciels utilisés sont toujours les mêmes (compta d’entreprise, RH, CRM…), marchés qui sont finalement assez rares.

A nous donc d’arrêter de courir après les dernières modes, et de nous concentrer sur ce qui est vraiment important pour la croissance de notre « science » (dit-il tout en préparant un article sur Azure – spoiler : le IaaS c’est trop bien ;)).

That’s the spirit of it! (2/2)

(La partie 1/2 c’est par là)

Disclaimer : l’auteur des 3 lois, anonyme, est un brin vulgaire. Moi je trouve que ça va bien avec son discours, certains pourraient ne pas aimer, vous êtes prévenus.

Avant de parcourir les 3 lois du business, il y a un petit préambule. Tout d’abord c’est évidemment hautement satirique, et comme toute bonne satire, on y retrouve un bon fond de vérité… Ensuite, l’auteur entend ces 3 lois comme 3 lois qui s’appliquent aux vrais consultants, aux pros, ceux qui savent ce qu’ils font, ceux qui maitrisent leur sujet et connaissent leurs limites, ceux qui ont déjà fait leur preuve.

Et pour l’auteur, ces gens là…

  • …n’en n’ont rien à carrer du service des achats et de ses processus. S’ils se déplacent chez un client, ils sont payés, ou ils ne viennent pas. Rien n’est gratuit : No Freebies
  • …n’en n’ont rien à carrer des conflits politiques, des dress codes et de l’étiquette locale. S’ils se déplacent ce n’est certainement pas pour se retrouver dans une cours de récréation : No Backsies
  • …n’en n’ont rien à carrer des menaces. Si ça dégénère, il ne faut pas oublier qu’un pro ça change de mission en 48h, par contre un client ça reste avec son problème : GTFO

Oui c’est extrême, mais j’adore 🙂

Au-delà de ces 3 lois, sa « sagesse » s’exprime principalement autour d’articles courts qui sont de vraies perles, dont voici une petite sélection :

  • Les faits ne sont pas négociables – « Tu peux soit t’assoir, fermer ta gueule et apprendre quelque chose, soit me décrire comment ton idée n’a rien à voir avec le problème en cours »
  • La banque de la dette technique – « Des fois tu sais que tu n’arriveras jamais à finir correctement et à l’heure. C’est là qu’intervient la plus vieille institution connue des programmeurs : la banque de la dette technique, qui échange un peu de temps contre la qualité de ton code. Mais faut pas oublier que la banque se rembourse toujours à la fin »
  • Des améliorations jusqu’à plus soif – « Et toutes mes jolies fleurs sont mortes, saloperies d’incompétents
  • Test moi ça ! – « Encore une fois, si tu ne sais pas te servir d’un outil, pose le par terre et va t’en. Ou au minimum, recule d’un pas et demande toi pourquoi tu es en train de t’infliger ça »
  • Le Culte du Cargo – « La première des Best Practices ? Savoir ce que tu es en train de faire avant de commencer à pisser du code. »
  • Méthodes Agiles – « Si tu pensais pouvoir utiliser les méthodes Agile pour éviter d’écrire une documentation correcte, alors tiens toi prêt à Agiler ton derrière pour calmer le client en colère. »

Oui oui, quand on est tout rempli de colère et de haine après la Nième décision stupide prise par un directeur quelconque, ça soulage d’aller lire ou relire tout ça 🙂

Ca inspire non ? Ca donnerait même envie de remodeler sa boîte autour de nouvelles valeurs 😉

(MàJ : 30/08/2010 – sp)