4 liens pour la semaine (2012-42)

Bientôt le weekend, courage!

  1. Bill Waddell d’Evolving Excellence avec une excellente réflexion sur la futilité des indicateurs employés pour comprendre l’économie. Cette réflexion s’applique d’ailleurs complétement à notre petit monde du décisionnel, et rappelle des points évoqués par Venkatesh Rao tantôt.
  2. Ted Dziuba sur la bureaucratie qui empoisonne nos organisations. Par contre à mon sens son cheminement de pensée est incomplet. On a essayé sa solution, l’outsourcing, et ça n’a pas vraiment donné les résultats espérés. L’étape d’après c’est plutôt du côté du Lean qu’il faut la chercher, avec des gros morceaux de Simon Sinek dedans.
  3. Jeff Atwood de Coding Horror sur les applications de gestion de to-do list, et plus globalement la gestion de la productivité personnelle. Je suis assez d’accord avec sa conclusion (mettez tout ça à la poubelle), mais c’est un « luxe » que tous ne peuvent pas se permettre (pouvoir assumer d’oublier des taches dans sa liste).
  4. Leigh Beadon de Techdirt qui nous donne un argument massue contre ceux qui clament que le piratage met en danger la musique. Vous connaissez mon avis sur cette question.

______________________

<< Semaine Précédente – Semaine Suivante >>

4 liens rapides pour la semaine (2011-17)

Que du bon cette semaine!

  1. Ted Dziuba sur les problèmes d’Amazon en tant que plateforme Cloud (EC2/S3). J’aime beaucoup sa franchise.
  2. Andy Ihnatko sur comment rattraper une journée mal partie.
  3. Seth Godin: après les économies du « scale » (d’échelle), les économies du « small » (des petites entreprises).
  4. On commence avec une citation d’Einstein trouvée sur le blog de 37 Signals pour conclure avec Kevin Meyer sur le cout absurde de la complexité.

______________________

<< Semaine PrécédenteSemaine Suivante >>

Programmer comme on cuisine au McDo

Ted Dziuba, programmeur et co-fondateur de Milo (comparateur de prix local), a écrit un article très intéressant fin octobre sur une méthode de programmation qu’il a intitulé « à la Taco Bell ». Comme nous n’avons pas de Taco Bell en France je l’ai traduit par McDo dans le titre!

Le concept?

The more I write code and design systems, the more I understand that many times, you can achieve the desired functionality simply with clever reconfigurations of the basic Unix tool set.

Ou en français (mon emphase en gras):

Plus je code, plus je réalise que la plupart du temps il est possible d’atteindre la fonctionnalité attendue avec une reconfiguration intelligente des commandes de bases d’Unix.

Avec un pas de recul, on peut appliquer cela à n’importe quel environnement de développement (la BI Microsoft par exemple), voir même à la méthodologie projet. C’est une attitude à contre pied complet de l’architecture interstellaire et pour l’avoir déjà mise en œuvre, qui donne de bons résultats.

Les principaux avantages sont la minimisation du risque et l’amélioration de la qualité du code par la maîtrise de bout en bout de toutes les fonctionnalités utilisées. Ted Dziuba le dit dans l’article : faire appel à des services tierce partie, des boîtes noires, c’est introduire du risque dans la solution.

Cette méthode amène de plus une réduction dans le choix de l’implémentation lors du design, et toute réduction de choix est bonne lorsqu’elle correspond à une réduction de l’effort nécessaire pour sortir de la procrastination et passer à l’action.

Le point négatif est évidemment le biais humain qui pousse au culte du cargo: ce qui est initialement une bonne pratique, un objectif, peut rapidement dégénérer en dogme et mettre en péril le projet. Il restera toujours un pourcentage de fonctionnalités qui nécessitent d’utiliser un service tiers spécifique, une technique spécifique, et vouloir les recoder dans les briques de base ne peut que conduire à une catastrophe (recoder un cube en TSQL – 300 tables d’agrégats à maintenir – ce n’est pas une bonne idée).

Un autre point négatif est qu’il faut disposer de collaborateurs capables de faire des reconfigurations intelligentes. Si l’intelligence manque en interne, autant s’appuyer sur l’intelligence qu’on peut trouver dans un service clef en main, tout le monde se sentira bien mieux.

Et par rapport à la gestion de projet, découper les périmètres complexes en briques élémentaires maîtrisées ça ne vous rappelle rien? La méthode agile oui, il me semblait bien 🙂