L'outil n'est pas le problème...

(...ni forcément la solution)

Henrik Kniberg (gourou de l'agilité) utilise régulièrement cette image dans ses présentations:

Cela peut prêter à sourire, mais j'en ressort quelques règles:

• évaluez les outils avant d'en choisir un, vérifiez qu'il correspond bien à vos besoins
• connaissez intimement votre outil avant de l'utiliser en production: lisez des livres, retours d'expérience, internet est là pour vous aider
• sachez dans quels cas ne pas l'utiliser

J'ai vu des équipes choisir Ruby et Rails après des déboires en PHP, pensant que Rails "c'est mieux". Aucun test unitaire, aucun apprentissage des conventions,... bref, retour au spaghetti code et déboires.

D'autres mettent en place un Subversion et pestent contre l'outil car ils se retrouvent constamment avec des conflits à chaque commit. Le fonctionnement par lock était mieux.

Ne parlons pas de tous les projets bancals en Visual Basic car VB, "c'est simple !".

Contrairement aux slogans, l'informatique, la programmation sont de plus en plus complexes. Il est de la responsabilité du développeur de se former.

Ruby, Python, Git, Scrum... sont des outils très puissants. "With great power, comes great responsibility": apprenez à maîtriser votre pouvoir !!