Voilà un article fort intéressant de Codding Horror que je ne m’empêcher de traduire, tellement les conseils sont selon moi avisés…
[ces conseils proviennent d’un livre: Facts and Fallacies of Software Engineering (Agile Software Development)]

Les gens
1. Le facteur le plus important dans le développement est la qualité des développeurs.
2. Les meilleurs programmeurs peuvent être jusqu’à 28 fois meilleurs que les pires programeurs.
3. Ajouter des gens à un projet déjà en retard ne l’accélère pas.
4. L’environnement de travail a un impact profond sur la productivité et la qualité.

Outils et techniques
5. Les modes (pour les outils et technologies) sont un cancer pour le développeur.
6. Les nouveaux outils et techniques créent une perte initiale de productivité et de qualité.
7. Les développeurs parlent beaucoup d’outils mais les utilisent peu.

Estimation
8. L’une des deux causes pour un projet en déroute est une mauvaise estimation.
9. L’estimation arrive le plus souvent au mauvais moment.
10. L’estimation est faite la plupart du temps par les mauvaises personnes.
11. Les estimations ne sont la plupart du temps pas corrigés durant l’avancée du projet.
12. Ce n’est pas une surprise que les estimations soient mauvaise. Mais ce sont elles qui nous font vivre ou mourir demain!
13. Il y a une déconnexion entre les managers et les développeurs.
14. La réponse à une étude de faisabilité est quasiment toujours “oui”.

Ré-utilisation
(je dois dire que j’ai eut du mal à traduire ce morceau là… pas évident du tout à traduire, pour les anglophiles mieux vaut se fier à la version originale)
15. Ré-utiliser ponctuellement du code peut résoudre votre problème.
16. Ré-utiliser globalement du code ne résoudra pas vraiment votre problème.
17. La ré-utilisation globale marche mieux dans une famille ou un système similaire.
18. Les éléments ré-utiliables sont trois fois plus dur à construire et devraient être testés dans trois environnements différents.
19. La modification d’un code ré-utilisé est particulièrement source d’erreurs.
20. La ré-utilisation de Design Patternes est une solution pour résoudre le problème de ré-utilisation du code.

Besoins
23. L’une des deux causes de déroute d’un projet est des besoins instables (fonctionnalités demandées).
24. Les changement des besoins (et donc de fonctionnalité) sont les plus coûteux durant la production.
25. Les besoins manquants sont les fonctionnalités les plus dures à corriger.

Design
26. Les conditions explicites ‘explosent’ alors que les conditions implicites pour une solution évoluent.
27. Il y a toujours une solution de design triviale pour un problème logiciel.
28. Le design est un processus itératif complexe. Le design initial est le plus souvent mauvais et pas optimal.

Code
29. Les ‘fondamentaux’ des designers vont rarement de pair avec les ‘fondamentaux’ des développeurs.
30. COBOL est un langage vilain, mais tous les autres sont bien pires.

Supprimer les erreurs
31. Supprimer les erreurs est le processus le plus long du cycle de vie d’un programme.

Tester
32. Une application est souvent testée au mieux sur 55 à 60% de son tout.
33. Tester 100% de son application est tout de même loin d’être suffisant.
34. Tester les outils est essentiel, mais rarement fait.
35. Les tests automatiques sont rarement mis en place. La plupart des tests ne peuvent pas être automatisés.
36. Un mode-debug créé par un développeur, se doit d’être rajouté dans la liste des outils à tester.

Reviews et Inspections
37. Une inspection rigoureuse peut enlever jusqu’à 90% des erreurs avant même le premier test.
38. Une inspection rigoureuse ne doit pas remplacer les tests.
39. Des rapports post-livraison, postmortem et rétrospectifs sont important et peu ou jamais fait.
40. Les rapports sont techniques et sociaux, les deux facteurs se doivent d’être présents et adaptés.

Maintenance
41. La maintenance consomme entre 40 et 80% du coût de votre application. C’est sans aucun doute la phase du cycle de vie de votre application la plus importante.
42. Les améliorations représentent en gros 60% des coûts de maintenance.
43. La maintenance est une solution - pas un problème.
44. Comprendre le produit existant est la tâche de maintenance la plus difficile.
45. De meilleurs méthodes amènent plus de maintenance et non moins.

Qualité
46. La qualité est une somme d’attributs.
47. La qualité n’est pas la satisfaction de l’utilisateur, la satisfaction des besoins, rentrer dans les coûts et le planning ou la fiabilité.

Fiabilité
48. Il y a des erreurs que la plupart des développeurs font.
49. Les erreurs ont tendance à se condenser.
50. Il n’y a pas qu’une seule approche pour la résolution d’un problème.
51. Les erreurs résiduelles resteront persistentes. Le but doit être de minimiser ou éliminer les erreurs sévères ou critiques.

Efficacité
52. L’efficacité vient plus souvent d’un bon design que d’un bon code.
53. Un langage de haut niveau peut être à 90% aussi efficace qu’un code similaire en assembleur.
54. Il y a un gouffre entre optimiser le temps de réponse et optimiser l’espace occupé.

Recherche
55. La plupart des chercheurs tentent de convaincre plutôt que d’investiguer.

Après ces 55 faits, l’auteur nous présente donc 10 erreurs communes, qui ont l’apparence de la vérité…

1. Vous ne pouvez manager ce que vous ne pouvez mesurer.
2. Il est possible de suivre la qualité d’une application.
3. La programmation n’est pas une question d’ego.
4. Outils et techniques: un pour tous.
5. Les applications ont besoin de plus de méthodologies.
6. Pour estimer le coût et les délais, estimez d’abord le nombre de lignes de code.
7. Des tests au hasard est un bon moyen d’optimiser les tests.
8. “Given enough eyeballs, all bugs are shallow”. (celui là j’ai pas vraiment réussi à le traduire correctement donc je le laisse comme ça)
9. Pour prédire les futurs coûts de maintenance, il faut regarder dans les projets antérieurs.
10. Vous apprenez aux gens à programmer en leur montrant comment écrire du code.

Aucun doute il me FAUT ce livre… apparemment pas encore traduit en français, mais qui liste une bonne partie des problèmes qui existe dans notre profession.
Evidemment certains de ces faits sont difficilement praticables (surtout dans un contexte web), mais c’est cela que tout bon développeur et travailleur du web doit tendre.

Des réactions?

Articles éventuellement en rapport:

• Les liens de la semaine…
• 100 applications Mac
• Jour de grêve... bis repetita
• Ubuntu (GNU/Linux) - Microsoft - Dell / Love-Hate-Love
• Pratique: vérifier une adresse email...

Cet article a été posté le Wednesday 26 March 2008 à 4:33 pm et a été classé dans la catégorie Développement, Gestion de projet, Organisation, méthodo..., Outils.