Petite réflexion autour de l’accélération des technologies

En ce moment l’écosystème décisionnel Microsoft est en ébullition. Avec la sortie de SQL Server 2012, c’est tout un camion de nouvelles technologies qui débarque dans notre petit jardin: le DAX, SSAS Tabular, PowerPivot, Power View, Data Explorer, des gros morceaux de SharePoint qui s’incrustent, Windows 8, les évolutions SSIS, le T-SQL version 2012… On a un peu l’impression d’avoir un nouveau langage / environnement à apprendre tous les 3 jours.

Même en dehors de Microsoft le décisionnel bouge beaucoup, et on commence à parler Tableau, Qlikview, SpotFire, qui eux aussi requièrent une certaine expertise voir une expertise certaine.

Et si on revient chez Microsoft mais qu’on sort de la BI, on voit que ça bouge beaucoup, et que ça en fait s’interroger plus d’un !

Oh mon Dieu, du DAX!!!
Oh mon Dieu, du DAX!!!

Alors je crois que c’est le bon moment pour un petit rappel qui nous vient de 2002, de chez Joel Spolsky :

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can’t fire at you.

Traduit approximativement :

Pendant mon service militaire, un général s’est adressé à nous pour un petit cours de stratégie. Dans les batailles d’infanteries, nous disait-il, il n’y a qu’une stratégie: tirer en mouvement. C’est à dire se déplacer vers l’ennemi tout en tirant dans sa direction. Le fait de tirer lui fait baisser la tête, ce qui permet de se déplacer sans qu’il vous tire dessus.

Qu’il applique à la technologie, quelques paragraphes plus loin:

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

De nouveau traduit approximativement:

Pensez à l’histoire des protocoles d’accès aux données issus de Microsoft. ODBC, RDP, DAO, ADO, OLEDB, ADO.NET – tous tout neuf ! Etaient-ils technologiquement incontournables ? Ou le résultat de l’incompétence du groupe de design concerné ? Peu importe, le résultat c’est un tir de couverture : pendant que la compétition passe son temps à adapter son code elle n’a pas le temps d’écrire de nouvelles fonctionnalités.

Et nous autres, les utilisateurs de ces technologies, on est pris au milieu de la bataille.

Les juniors sont découragés par le nombre de technos à apprendre, les séniors s’offusquent d’avoir à apprendre encore un nouveau langage.

Tout ça c’est du « Fire & Motion » de l’éditeur, il est important de ne pas y succomber, car ce n’est pas notre guerre. Pour l’éviter : déterminer quel est votre objectif – réaliser des projets ? – et accomplissez le sans vous inquiéter de ne pas maîtriser l’ensemble des technologies de l’offre.

Ce qui est important c’est :

  • d’avoir les bases, la théorie essentielle indépendante de la techno : parler à un client de ses besoins, la modélisation dimensionnelle, de la gestion de projet élémentaire…
  • de maîtriser au moins une technologie, et connaître ses limites,
  • de savoir apprendre les autres, uniquement au moment où vous avez besoin d’elles et uniquement ce dont vous avez besoin
  • de savoir demander à l’aide.

Pour tous ces points, il y a la communauté. Abonnez-vous aux blogs, participez à FrenchConnection.BI et au GUSS, contactez les experts, bref, ne restez pas tout seul dans le noir ;)

Jusqu’à la fin de votre vie, plus vous apprendrez, plus vous réaliserez à quel point vous en savez peu. C’est de la philosophie de bas étage, mais c’est à garder en mémoire devant l’énormité du travail de veille technologique qui attend tout développeur / consultant qui se respecte.

Bon courage ! :)

4 réflexions sur “Petite réflexion autour de l’accélération des technologies

  1. Sans vouloir polémiquer, je pense qu’un architecte se doit, non pas de connaitre dans le détails ni de devenir expert, mais de connaitre parfaitement chaque brique technologique (car c’est lui qui oriente la suite du projet).
    Evidemment, c’est en parallèle du travail de modélisation qui nécessite comme prérequis de connaitre la modélisation dimensionnelle en général.

  2. Mais tu ne polémiques pas Jean-Pierre, puisque je n’ai pas dit le contraire :)
    Pour les spécialistes comme l’expert technique ou l’architecte, le niveau de connaissance des produits attendu est bien entendu plus élevé que pour le consultant / développeur.

    L’expert technique se doit de connaître les technologies dans les détails. L’architecte lui doit connaître les avantages et contraintes de chaque produit, et savoir choisir le bon en fonction des besoins du client. Je ne crois pas qu’un archi doit être expert de tous les produits, en tout cas moi je ne le suis pas, mais il doit bien comprendre comment ils s’articulent entre eux et comment ils forment une solution complète.

    Ca te convient comme précision? :)

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s