La dernière réunion du Cigref (Club informatique des grandes entreprises françaises), s'est focalisée à juste titre sur le concept de l'entreprise numérique: le client est un consommateur numérisé, la part du numérique dans la valeur ajoutée de l'entreprise s'accroît, l'importance des collaborateurs branchés aussi.
Et du coup on s'intéresse aux nouveaux modèles d'organisation, en espérant la fin du hiéarchique et l'avénement du collaboratif. Selon Rogers en effet, 50% de la productivité d'une entreprise vient du collectif et 20% seulement de l'individuel.
Et on cite la fameuse comparaison d'Eric Raymond, souvent décrit comme co-créateur du terme "open source" sur le développement façon cathédrale des logiciels traditionnels ou façon bazar dans le monde du logiciel libre. Elle date de mai 1997.
Du coup, j'ai eu envie de relire les fameuses "leçons" d'Eric Raymond sur les avantages du mode bazar, je vous les liste ci-dessous et je trouve quelles peuvent s'appliquer à beaucoup de situations dans l'entreprise et pas seulement au développement de logiciel. Une bonne piste pour chasser les bugs!
1. Tout bon logiciel commence par gratter un développeur là où ça le démange.
2. Les bons programmeurs savent quoi écrire. Les grands programmeurs savent quoi réécrire (et réutiliser).
3. ``Prévoyez d'en jeter un, car de toute manière, vous le ferez.'' (Fred Brooks, ``The Mythical Man-Month'', chapitre 11)
4. Si vous avez la bonne attitude, les problèmes intéressants viendront à vous.
5. Quand un programme ne vous intéresse plus, votre dernier devoir à son égard est de le confier à un successeur compétent.
6. Traiter vos utilisateurs en tant que co-développeurs est le chemin le moins semé d'embûches vers une amélioration rapide du code et un débogage efficace.
7. Distribuez tôt. Mettez à jour souvent. Et soyez à l'écoute de vos clients.
8. Étant donné un ensemble de bêta-testeurs et de co-développeurs suffisamment grand, chaque problème sera rapidement isolé, et sa solution semblera évidente à quelqu'un.
9. Il vaut mieux avoir des structures de données intelligentes et un code stupide que le contraire.
10. Si vous traitez vos bêta-testeurs comme ce que vous avez de plus cher au monde, ils réagiront en devenant effectivement ce que vous avez de plus cher au monde.
11. Il est presque aussi important de savoir reconnaître les bonnes idées de vos utilisateurs que d'avoir de bonnes idées vous-même. C'est même préférable, parfois.
12. Bien souvent, les solutions les plus innovantes, les plus frappantes, apparaissent lorsque vous réalisez que votre approche du problème était mauvaise.
13. ``La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever.''
14. Tout outil doit être utile par rapport aux utilisations qu'il a été prévu d'en faire. Mais on reconnaît un outil vraiment excellent au fait qu'il se prête à des usages totalement insoupçonnés.
15. Quand vous écrivez un logiciel jouant le rôle d'une passerelle quelconque, prenez soin de perturber le moins possible le flot de données -- et ne perdez *jamais* d'éléments d'information, à moins que la machine destinataire vous y oblige !
16. Quand votre langage est loin d'être "Turing équivalent", un peu de "sucre syntaxique'' ne peut qu'aider.
17. Un système de sécurité n'est pas plus sûr que le secret (la clé) qui le garde. Gare aux pseudo secrets !
18. Pour résoudre un problème intéressant, commencez par trouver un problème qui vous intéresse.
19. Pour peu que le coordinateur du développement dispose d'un moyen de communication au moins aussi bon que l'Internet, et pour peu qu'il sache comment mener ses troupes sans coercition, il est inévitable qu'il y ait plus de choses dans plusieurs têtes que dans une seule.
Commentaires
Enregistrer un commentaire