La programmation n'est pas une science exacte

Préambule
Voici un petit article axé sur la programmation et les mathématiques.
Un chapitre aborde également l'importance de l'implication personnelle dans la bonne conduite de projet d'envergure (raison pour laquelle cet article apparait également dans la section société-psycho)

La programmation n'est pas une science exacte
Beaucoup de néophytes et de développeurs pensent que la programmation se résume à (je paraphrase)  "l'ordinateur fait exactement ce qu'on lui demande".
Par conséquent, si on lui demande d'afficher cela à l'écran, il devrait le faire... s'il ne le fait pas ou pas bien, c'est le développeur qui est en cause.
Je partage cet avis, en écartant les problèmes de complexité (1*) et le cas des developpeurs brouillons (2*)... à la condition de l'appliquer à de petites portions d'un logiciel.
1*) car certains problèmes le sont vraiment... même pour des choses simples en apparences.
2*) car il y en a beaucoup dans notre profession.

A plus grande échelle, où les développements impliquent beaucoup de développeurs, beaucoup de code, beaucoup de fonctionnalités entre-croisées, la "stabilité d'un développement" est tout aussi imprévisible que la stabilité de "grosses infrastructures".

Même si certains responsables prétendent le contraire (et même si "les apparences" leur donnent raison... pour ce qu'ils veulent bien révéler), les grands systèmes informatiques (logiciel et infrastructure) sont instables.
Dans les faits, ces systèmes ne doivent leur stabilité qu'à la vigilance de tous les intervenants qui y sont impliqués. C'est la raison pour laquelle les systèmes informatiques (developpement et infrastructure) sont accompagnés de "service de maintenance".


Pourquoi le développement n'est pas une science exacte (1*)
En écartant les problèmes humains du sujet (mauvaise analyse, mauvais développeur), un système informatique n'est pas un système exacte.

En reprenant les propos de Joseph Sifakis (2*), détenteur du prix Turing, le comportement des systèmes informatiques ne peut pas être décrit avec des équations dites "linéaires" comme on le fait avec des circuits électriques. Les systèmes électriques peuvent être réduits à des systèmes d'équations relativement "élémentaires" (les connaisseurs pardonnerons cette simplification un peu extrême).

Il y a 35 ans, Joseph Sifakis pensait pouvoir modéliser un système informatique comme on le fait pour des systèmes électromécaniques. Pour lui, il est un fait aujourd'hui, que cela n'est pas possible pour les systèmes informatiques (réseaux, microprocesseur) . Après deux ans d'étude, cette modélisation linéaire ne s'applique même pas pour un bit en mémoire.
Du coup, puisque l'informatique ne peut être modélisée à l'aide d'équation "linéaire", elle échappe totalement à la prédictibilité... Au contraire de la physique traditionnelle, où il est possible de prévoir l'état futur à partir de l'état actuel.

Lorsque l'on observe globalement les systèmes informatiques, leurs constructions s'effectuent donc de façon empirique.
L'informatique d'aujourd'hui s'apparente à la construction des cathédrales du moyen âge (empirique elles aussi). Les cathédrales étaient montées pierre après pierre, avec savoir faire, mais sans les connaissances exactes de lois de la physique s'y appliquant... sans réelle prédictibilité.
Lorsque l'on prépare un nouveau processeur ou une nouvelle plateforme (web ou non), il n'est donc jamais possible d'avoir des garanties sur le résultat final.
Jusqu'à 30% des gros projets informatiques actuels échouent complètement avant leur achèvement.

1*: Les propos de Mr Joseph Sifakis proviennent du Science et Vie n° 1102 de Juillet 2009, page 146.
2*: Joseph Sifakis est informaticien, directeur de recherche au CNRS, fondateur du laboratoire Verimag (systèmes embarqués). En 2007, il a reçu le prix Turing, la plus haute récompense internationale scientifique en informatique.

Développement de logiciel d'envergure
Ce qui s'applique aux grands systèmes informatiques s'applique bien évidemment aux grands développements. La conception et modification de grands logiciels.
Le développement s'appuie sur ce procédé d'assemblage de briques (idée communément admise) soit dans le programme lui même par la méthode de programmation (losely coupled application), soit par les briques logicielles utilisées (serveur Web, serveur DB, Application Server, composants pour l'environnement de développement, outils divers créés pour le support au développement, etc).
Le développement, au sens général du terme, est donc empirique et s'appuie principalement sur le savoir faire (généralement épaulé par des techniques).
Nul aujourd'hui n'est capable d'assurer la réussite "à coup sur" d'un développement si l'on utilise tel ou tel technique de développement... il reste encore beaucoup de "chaos" en jeu pour faire aboutir un produit

La coercition est indispensable pour l'aboutissement d'un projet
Comme précisé au paravent (et c'est une conviction personnelle), la stabilité d'un gros développement, sa mise en production et sa maintenance dépend intimement du niveau d'implication de ses différents acteurs (concepteurs, développeurs, product owner, testeurs, services de maintenances et support).

Il est important, et beaucoup le perdent souvent de vue, qu'ils agissent tous en coercition pour faire aboutir la plateforme/produit/logiciel.
Seul le "bien du système" dans son ensemble, et cela incluant aussi le bien des acteurs, est l'objectif défendable à atteindre.

Il est malheureusement courant que les intérêts personnels d'un des acteurs prennent le pas sur les intérêts et la finalité du projet.
Suivant sa position de pouvoir (ou celui qu'il peut acquérir), cet élément perturbateur peut avoir un impact important au point de déstabiliser ou ruiner entièrement un projet.
Hormis les guerres de pouvoir qui usent inutilement l'énergie des intervenants (et n'apporte rien de positif au système), la démotivation, dont les sources sont variées mais souvent dépendantes de l'esprit de coercition, est probablement le pire des dangers pouvant déstabiliser la bonne conduite d'un projet.

La démotivation, bien qu'en apparence idéal à la coercition (puisque plus rien n'est discuté), engendre un manque d'implication, une dangereuse diminution de qualité pour le produit par manque de réactivité (les détections de problèmes potentiels étant passé sous silence par "ras-le-bol" ou crainte des conséquences).

Coercition et implication personnelle
La stabilité d'un système informatique est basé sur l'implication personnelle des intervenant.
l'implication personnelle dans un esprit de coercition est essentiel et seul le "bien du système" est le but valable a atteindre. Agir ensemble pour le bien du système c'est inévitablement agir pour son propre bien.
L'implication personnelle n'est par contre pas synonyme de "répondre au doigt et à l'oeil" mais plutôt d'appliquer un sens critique et préventif pour prévenir les problèmes.
Ne pas accepter ou se jeter tête baissée dans des situations/choix dont on sait pertinemment qu'ils représenterons des problèmes à court et a moyen terme.
Pour résumer: agir pour le bien du système.

Et là encore, l'esprit de coercition est important car hiérarchiquement, la personne levant/identifiant un problème (généralement plus bas dans l'échelle hiérarchique) et la personne à qui elle est reportée (plus haut dans l'échelle de décision) doivent agir de concert, en coercition, pour le bien du système dans son ensemble.