Pourquoi faire simple quand on peut faire compliqué?

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. – Manifeste agile

La simplicité peut être plus difficile à atteindre que la complexité : il faut travailler dur pour bien penser et faire simple. – Steve Jobs

La complexité créée par un programmeur est inversement proportionnelle à sa capacité à la gérer. – Kent Beck

Parmi les vidéos de conférences proposées par l’Afup, Frédéric Bouchery nous offre une réflexion intéressante sur la complexité en matière de développement logiciel, lors d’une présentation au Forum PHP 2013.

Pour citer ses propos, la complexité d’un projet demeure une notion relative. Et ce qui s’avérera simple pour certains se révélera compliqué pour d’autres. Par ailleurs, on atteint souvent une simplification du code en tendant vers une complexification architecturale. Bref, c’est compliqué de faire simple. KISS!

Voici quelques points que j’ai retenus de cette conférence.

Facteurs de complexification d’un projet

Expression des besoins

  • Nombre de fonctionnalités.
  • Clarté de la demande / complexité business.
  • Faisabilité de la demande.
  • Changements d’avis.

Conception

  • Expérience des architectes:
    • Autant de visions que d’expériences.
    • Syndrome de la mouche sur l’écran (insatisfaction chronique).
    • Syndrome NIH.
  • Inexpérience des développeurs:
    • Un junior coûte moins cher.
    • Manque institutionnel de reconnaissance de l’expertise technique.
    • Des développeurs instables induisent un turn-over préjudiciable pour le code (code zombie).
  • Pour ma part, je rajouterais la négligence du code:
    • Négliger de soigner la lisibilité de son code lors du développement.
    • Négliger de tester automatiquement son code.
    • Négliger de refactorer son code, le plus tôt possible et de manière continue.
    • Laisser s’accumuler la dette technique, le code mort, les « todo », etc.

Inquiétante escalade de la complexité?

  • Principe de vie normal d’un projet sur le long terme, orienté en trois phases:
    • phase 1 : exploration (3 versions…)
    • phase 2: maturation: on casse tout, on rationalise, on simplifie…
    • phase 3: vieillissement, on enrichit, on grossit… ou on en fait des petits.
  • S’adapter aux compétences des développeurs:
    • Si les développeurs ne maîtrisent pas l’objet, ne pas faire des architectures trop complexes…
    • Importance de la maîtrise des outils par les développeurs => courbes d’apprentissage.
    • Le meilleurs frameworks? Celui que les développeurs maîtrisent…
  • Faire des paris gagnants. Gagner du temps à ne pas faire si on n’en a pas besoin pour l’instant. YAGNI.
  • Adapter les outils en fonction des besoins.
  • Surveiller le code, contrôler la qualité, communiquer sur les entorses.
  • Concevoir en binôme.
  • Former et entraîner les développeurs:
    • faire du coding dojo.
    • découvrir des nouvelles fonctions.
    • allez voir d’autres produits, d’autres librairies.
  • Revenir sur des choses qui ne marchaient pas car elles ont évolué.

Une réflexion au sujet de « Pourquoi faire simple quand on peut faire compliqué? »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>