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!!!

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 ! 🙂