4 liens rapides pour la semaine (2010-39)

Et hop :

  • Comment l’iPhone a changé la vie d’un aveugle, Austin Seraphin.
  • Un nouvel article de Ben Horowitz: la bonne manière de licencier, avec éthique et respect. A 3 reprises il a du se séparer d’une grande partie de ses salariés. C’était soit ça soit fermer sa boîte et mettre tout le monde dehors. Et il a sauvé la boîte.
  • L’histoire intéressante de l’équipe psychologique en charge d’éviter que les mineurs chiliens coincés sous terre ne s’entretuent.
  • Pour finir, une belle démo technologique HTML5 pour Internet Explorer 9. Joli 🙂

<< Semaine PrécédenteSemaine Suivante >>

Un beau métier? Architecte des étoiles!

La base de cet article est un pavé écrit par Venkatesh Rao de Ribbonfarm: celui-ci.

Pour moi c’est à lire absolument, et d’autant plus si vous êtes dans un de ces deux cas:

  • Vous travaillez avec un architecte des étoiles,
  • Vous êtes en train de modéliser la réalité pour en faire une application, et ça commence à faire mal à la tête.

Qu’est ce que j’appelle un architecte des étoiles? C’est un architecte perdu pour la cause dans son délire mégalo-maniaque de modéliser le monde entier dans son application.

Les symptômes?

  • Le modèle de l’application qui comporte trop de niveaux d’abstractions (faire un ETL avec un ETL, redévelopper SSAS dans SQL Server…),
  • Le modèle que plus personne ne comprend de bout en bout à part l’architecte des étoiles,
  • Le projet qui inclut le développement d’un framework (alerte rouge),
  • La documentation qui fait plus de 200 pages…
  • Le fait que les développeurs passent plus de temps à coder des « corrections » des outils de dev que pour implémenter l’application

Ce qui nous ramène à l’article de Ribbonfarm, qui vient nous expliquer comment naissent ces délires étoilés:

  1. Tout commence quand on regarde une réalité complexe et déroutante, avec pour volonté de l’analyser,
  2. Cette réalité étant complexe, on échoue à répétition à intégrer toutes les subtilités dans son analyse,
  3. On attribue alors cet échec (et la frustration qui va avec) à une irrationalité supposée de ce qu’on analyse plutôt qu’à ses propres limites,
  4. On invente alors une version de la réalité telle qu’elle devrait être,
  5. On impose ensuite cette vision comme vérité, quitte à détruire la réalité qui existait avant,
  6. Enfin on regarde l’impossible utopie élaborée avec amour échouer lamentablement

Toutes ces étapes sont naturelles, humaines, il ne sert à rien de vouloir les éviter absolument.

Ce qui est important, c’est que lorsque ça commence à faire mal (étape 3, étape 6), on arrive à mettre son amour propre de côté et repartir de 0. A force d’itération la connaissance et la compréhension vont s’améliorer, un modèle correct finira donc bien par émerger tôt ou tard. Bien évidemment, une itération prenant du temps, il faut donc mieux itérer sur des maquettes, voir des prototypes, pendant une grosse phase de conception, plutôt qu’itérer sur des cycles de développements complets à 200 jours-hommes pièce…

Vous pouvez maintenant vous demander qu’est ce qui différencie l’architecte étoilé de ses pairs, si la nature humaine force tout le monde à suivre le même chemin de croix? C’est son manque définitif de remise en question lorsque tout s’écroule qui l’identifie clairement: son modèle était parfait, ce n’est quand même pas de sa faute si les développeurs étaient si bêtes!

Les deux mondes de la BI

Vu chez Flowing Data, ce slide issu d’une présentation de Tableau Software:

Le slide est commenté par son auteur ici, je trouve sa réflexion extrêmement pertinente. La citation « big software, little analysis » pour décrire le datawarehousing est tellement vraie!

L’idée présentée dans ce slide est très bien résumée par cette phrase de Nathan Yau : « You have to get over the wall to really get something out of your data. Otherwise, you’re just a drone doing a computer’s work when it should be the other way around » (« Tu dois aller à droite du mur si tu veux tirer quelque chose de tes données. Sinon tu n’es qu’un drone qui fait le boulot d’un ordinateur alors que cela devrait être l’inverse.« )

Le message nous est en partie adressé, à nous les consultants qui fabriquons les applications décisionnelles, bien à l’abri à gauche du mur:

  1. nos applications doivent être conçues pour permettre aux utilisateurs de franchir le mur,
  2. nous devons accompagner les utilisateurs pour qu’ils puissent le faire.

En terme d’outils, à gauche du mur on retrouve SQL Server, SSIS et SSRS. Pour moi la brique qui fait le pont entre les deux mondes c’est SSAS. De l’autre côté, on a Excel (tableaux croisés dynamiques ou avec les fonctions cube), maintenant PowerPivot (gratuit sur Excel 2010) et les modules de données de SharePoint (ex PPS Monitoring). Cela plus tous les outils de l’écosystème Microsoft (Tableau pour l’analyse, Clarity Systems pour le BPM,…), ça ne fait pas de nous les plus mal équipés pour traiter le problème!

Alors va falloir s’y mettre! 🙂

Ps: J’ai testé Tableau, enfin leur soft, et je l’ai trouvé vraiment sexy. Par contre je ne l’ai encore jamais déployé ni vu déployé. A venir peut être!

Ps: Je cite Clarity ici parce que j’ai eu droit à une démo de leur produit, et leur module de saisie (objectifs, budgets…) est juste bluffant.

Dilbert du 19/09/2010

Tant qu’on est dans les bêtises, Civilization V est sorti hier aux USA. Désolé pour votre vie de famille…

Et voilà le strip, qui est tellement vrai:

Dilbert.com

Traduction approximative:

Boss: Je ne comprends rien à vos deux propositions techniques, et il faut que j’en choisisse une.

Boss: Normalement je fais ça au favoritisme, mais je ne vous apprécie ni l’un ni l’autre.

Boss: Donc je vais tester votre intelligence, et je choisirai la proposition du plus malin.

Boss: Si vous tirez une flèche depuis un avion vers un singe…

Boss: … et que le singe jette une noix de coco en direction de la flèche pour l’arrêter, mais la rate…

Boss: … comment pouvez vous deviner l’heure?

Dilbert: On n’a pas assez de données.

Collègue de Dilbert: On regarde notre montre?

Boss: La bonne réponse est: « Demander au singe en espérant qu’il n’est pas rancunier »

Parallélisme et Lookups dans SSIS

Todd McDermid a publié un très bon article il y a 15 jours sur le parallélisme et les lookups dans SSIS.

Son approche est excellente, ça vaut le détour, mais pour ceux qui n’ont pas le temps je vous le résume en 2 points:

  • L’interface graphique de SSIS nous ment très régulièrement. C’est une abstraction qui ne représente pas exactement ce qui se passe réellement sous le capot.
  • Conclusion: comme pour SQL Server et le T-SQL, dans 95% des cas il vaut mieux laisser SSIS optimiser tout seul le data-flow plutôt que déplacer les blocs dans tous les sens.

Nb: Je passe l’air de rien un lien vers la loi des abstractions foireuses de Joel Spolsky, mais je reviendrai dessus. C’est à mon sens l’un des meilleurs articles écrit sur l’architecture logicielle.

Vulnérabilité ASP.NET (Bulletin 2416728)

Tout le détail est ici, sur le Security Advisory.

Pour plus d’infos, confère l’article de Slashdot.

A moins de bosser sur un gros site web bien exposé, je ne crois pas qu’il faille faire rien de plus qu’attendre le correctif par Microsoft Update.

Update 29/09/2010 : Microsoft sort un hotfixe, encore une fois, le détail est sur Slashdot.