Savoir faire des choses compliquées ne fait pas de vous un bon développeur

Savoir faire des choses compliquées ne fait pas de vous un bon développeur

Cet article est la suite de « la complexité une affaire de charge cognitive ».

On me demande souvent comment reconnaitre un « bon » développeur. La réponse à cette question est, par définition, assez compliquée à donner.

Parmi ces éléments, il en est un qui est souvent mal interprété. Pour beaucoup, la capacité à savoir-faire des choses compliquées, est le signe d’un développeur compétent et expérimenté.

En effet, j’ai pu observer, dans certaines communautés et entreprises, une certaine propension à glorifier des solutions particulièrement compliquées, jusqu’à aller les présenter lors d’une conférence.

Et là, vous avez sur scène des intervenants qui se vantent d’avoir réussi à construire des systèmes aussi compliqués, et une salle qui est impressionnée par la prouesse.

Malheureusement, ce que ces gens prouvent, c’est qu’ils sont capables de travailler dans un contexte de très forte charge cognitive.

Et ce faisant, ils compliquent d’autant plus le travail de leurs futurs collègues en les obligeant à devoir absorber une plus grande charge cognitive pour pouvoir intervenir sur le projet.

Très souvent, vous êtes vous-même ce futur collègue. Vous savez, ce moment où l’on se dit : « mais qui a pu écrire un code pareil ? » et que l’on se rend compte que l’auteur du code n’est autre que soit même…

Dans le même temps, ces développeurs risquent d’augmenter très fortement la complexité accidentelle du projet et tomber dans le piège de la sur-conception (over-engineering).

La problématique vient d’une confusion entre la complexité d’un problème à résoudre et la complexité de la solution associée. Un problème complexe ne veut pas dire que les éléments constitutifs de la solution doivent être complexes.

En effet, un grand principe d’une architecture logicielle est de réussir à développer un ensemble de composants simples, qui assemblés, permettent de résoudre un problème complexe. C’est le principe d’émergence appliqué à l’architecture logicielle.

Et c’est là que se trouve la réelle prouesse, car réussir à mettre en place une solution simple à un problème complexe est particulièrement difficile !


Si vous avez apprécié l’article

  • Partagez l’article sur twitter, Linkedin, ou sur Slack.
  • Abonnez-vous à la newsletter pour recevoir les nouveaux contenus : articles, vidéos & podcasts !

Merci à @davidnotset, @SebastienChemin & Olga Cojocariu qui m'ont apporté leur aide pour l’écriture de cet article