Les 6 vérités de la programmation, se vérifient-elles autour de vous ?
Un développeur américain explique sur son blog que son expérience professionnelle dans le domaine de la programmation lui a permis de faire quelques constatations à propos des professionnels de l'IT et de leur manière d'écrire du code.
Les voici :
- Un programmeur passe entre 10 et 20% de son temps à coder, et écrit en moyenne 10 à 12 lignes de code par jour qui seront incluses dans le produit final (peut importe leur niveau). Les bons programmeurs utilisent le temps qu'il leur reste à penser, rechercher et faire des tests pour parvenir au meilleur design possible. Les mauvais quant à eux passent ces 80 à 90% de temps à debugger leur code en faisant des essais au hasard puis en regardant si cela fonctionne.
- Un bon programmeur est dix fois plus productif qu'un programmeur lambda. Un excellent programmeur, lui, est de 20 à 100 fois plus productif que ce dernier. Des études l'ont montré, et ce, depuis les années 60. Un mauvais programmeur quant à lui, n'est pas seulement non productif, en plus de ne rien créer d'utile, il génère des heures de travail et de maux de tête pour ses collègues (qui devront réparer ses erreurs).
- Les programmeurs très compétents passent très peu de leur temps à écrire du code (du moins du code qui se retrouvera à la fin dans le produit fini). Ceux qui passent la majeure partie de leur temps à coder sont trop fainéant, trop ignorants ou encore trop arrogants pour trouver des solutions existantes à d'anciens problèmes. Les programmeurs très compétents sont maîtres dans l'art de reconnaître et de réutiliser des schémas communs. Les bons programmeurs n'ont pas peur de réécrire leur code constamment pour atteindre le design idéal. Les mauvais, eux, écrivent du code qui manque d'intégrité conceptuelle, de hiérarchie et de schémas, et dans lequel se trouvent trop de répétitions. Du coup, c'est dur à réécrire, et il est plus rapide de se débarrasser d'un mauvais code pour repartir de zéro, que de le modifier.
- Une étude de 2004 a démontré que 51% des projets de logiciels connaîtront des échecs sur quelque chose de critique, et 15% connaîtront un échec tout court.
C'est mieux que 1994, où on notait 31% d'échecs.
Cependant, la plupart des programmes sont faits par des équipes dans une ambiance non démocratique. Une seule personne est responsable du design, tandis que les autres peaufinent les détails.
- Programmer, c'est du boulot. C'est une activité mentale intense. Les bons programmeurs pensent à leur travail tous les jours, 24 heures sur 24. Ils écrivent leurs codes les plus importants sous la douche ou dans leurs rêves. Parce que le travail le plus important est réalisé loin d'un clavier. Donc, la finalisation d'un projet ne peut pas être accélérée en passant plus de temps au bureau, ou en ajoutant plus de monde au projet.
- Les programmes obéissent aux lois de l'entropie, comme beaucoup d'autres choses. De ce fait, des changements perpétuels causent des erreurs, ce qui érode l'intégrité conceptuelle du design original.
C'est inévitable d'en arriver là, mais les programmeurs qui oublient de prendre l'intégrité conceptuelle en considération créent des programmes qui se dégradent si vite qu'ils deviennent inutiles avant même d'être achevés. Les problèmes d'entropie de ce type sont certainement la plus grande cause d'échec dans ce domaine.
Source :
Le blog de David Veksler
Ces vérités se vérifient-elles autour de vous ? Les approuvez-vous ? Les reconnaissez-vous dans votre expérience ?
Avez-vous quelques anecdotes à raconter qui illustrent ou au contraire contredisent les affirmations de David Veksler ?
