Pas de solution miracle : Essence et accidents du génie logiciel

Fred Brooks commente :

Une grande partie de la procédure actuelle d'acquisition de logiciels repose sur l'hypothèse que l'on peut spécifier à l'avance un système satisfaisant, obtenir des offres pour sa construction, le faire construire et l'installer. Je pense que cette hypothèse est fondamentalement erronée et que de nombreux problèmes d'acquisition de logiciels découlent de cette erreur. Ils ne peuvent donc pas être résolus sans une révision fondamentale - une révision qui prévoit le développement itératif et la spécification de prototypes et de produits.

Le développement incrémental : faire croître les logiciels, pas les construire. Je me souviens encore de la secousse que j'ai ressentie en 1958 lorsque j'ai entendu pour la première fois un ami parler de la construction d'un programme, par opposition à l'écriture d'un programme. En un clin d'œil, il a élargi toute ma vision du processus logiciel. Le changement de métaphore était puissant et précis. Aujourd'hui, nous comprenons à quel point la construction de logiciels ressemble à d'autres processus de construction et nous utilisons librement d'autres éléments de la métaphore, tels que les spécifications, l'assemblage de composants et l'échafaudage.

La métaphore de la construction a fait son temps. Il est temps de changer à nouveau. Si, comme je le crois, les structures conceptuelles que nous construisons aujourd'hui sont trop compliquées pour être spécifiées avec précision à l'avance, et trop complexes pour être construites sans faille, alors nous devons adopter une approche radicalement différente.

Tournons-nous vers la nature et étudions la complexité des êtres vivants, plutôt que les œuvres mortes de l'homme. Nous y trouvons des constructions dont la complexité nous fait frémir d'admiration. Le cerveau à lui seul est d'une complexité qui dépasse la cartographie, d'une puissance qui dépasse l'imitation, d'une riche diversité, d'une autoprotection et d'un auto-renouvellement. Le secret, c'est qu'il est cultivé, et non construit.

Il doit en être de même pour nos systèmes logiciels. Il y a quelques années, Harlan Mills a proposé que tout système logiciel soit développé par incrémentation[10]. [C'est-à-dire qu'il faut d'abord faire fonctionner le système, même s'il ne fait rien d'utile à part appeler l'ensemble approprié de sous-programmes fictifs. Ensuite, petit à petit, il doit être étoffé, les sous-programmes étant à leur tour développés - en actions ou en appels à des stubs vides dans le niveau inférieur.

C'est depuis que j'ai commencé à recommander cette technique aux concepteurs de projets de mon cours de laboratoire de génie logiciel que j'ai obtenu les résultats les plus spectaculaires. Rien au cours de la dernière décennie n'a changé aussi radicalement ma propre pratique ou son efficacité. L'approche nécessite une conception descendante, car il s'agit d'une croissance descendante du logiciel. Elle permet de revenir facilement en arrière. Elle se prête aux premiers prototypes. Chaque fonction ajoutée et chaque nouvelle disposition pour des données ou des circonstances plus complexes se développent organiquement à partir de ce qui existe déjà.

Les effets sur le moral sont surprenants. L'enthousiasme monte en flèche lorsqu'un système fonctionne, même s'il est simple. Les efforts redoublent lorsque la première image d'un nouveau logiciel graphique apparaît à l'écran, même s'il ne s'agit que d'un rectangle. À chaque étape du processus, on dispose toujours d'un système opérationnel. Je constate que les équipes peuvent développer des entités beaucoup plus complexes en quatre mois qu'elles ne peuvent en construire.

Brooks, Frederick P., "No Silver Bullet : Essence and Accidents of Software Engineering", Computer, Vol. 20, No. 4 (avril 1987) pp. 10-19.