Réaction au billet Why is Estimating so Hard?.
Uncle Bob, l'auteur, déclare que, pour un petit problème que l'humain résoud manuellement très facilement, l'estimation de la difficulté à produire un algorithme pour le faire résoudre par la machine est souvent biaisée, justement du fait de la facilité avec laquelle l'humain le résoud.
Uncle Bob explique ce phénomène par le fait que l'humain n'applique pas une procédure pour résoudre le problème, qu'il ne connaît pas la procédure qui pourtant doit être mise en oeuvre par la machine.
Etant donné que l'auteur prône l'aspect artisanal du développement logiciel, je m'étonne qu'il s'arrête à ce constat.
En effet, si l'exemple présenté (découpe d'un texte en lignes avec une longueur maximale, sans couper les mots) peut illustrer son propos pour une partie des développeurs, il n'est en rien convaincant pour d'autres, en tout cas pour moi, puisque cet exercice m'a pris entre 5 et 10 minutes sans me presser.
Pourquoi donc ? Tout simplement car j'ai pu reconnaître dans cet exercice un motif de problème déjà rencontré, déjà traité, pour lequel j'avais déjà une expérience. En effet, ce problème peut être vu comme le cas le plus simple d'un remplissage de sacs à dos, ou de fichiers sur plusieurs CDs, ou d'ordonnancement d'opérations à durées connues sur plusieurs processeurs. C'est le cas le plus simple car l'ordre des mots ne peut être changé, donc pas d'explosion combinatoire nécessitant une méthode comme le recuit-simulé, rien de tout cela. Juste remplir une ligne avec un mot, s'il ne rentre pas le mettre sur la ligne suivante.
Uncle Bob, de son côté, ne semble pas faire le lien pour ce problème. Cela se reconnaît dans l'algorithme suggéré, notamment le point 3.:
3.You look backwards from the 10th character looking for a space and if there is one, you break it there.
Je devine que l'algorithme qu'Uncle Bob a en tête parcourt la chaine et remplit un buffer. Cependant, mes expériences passées m'ont fait adopter intuitivement une autre approche: d'abord découper le texte en une liste de mots, afin de retomber sur le motif de problème déjà rencontré, que les éléments à placer soient des mots n'étant alors qu'un cas particulier.
C'est bien ce qui fait du développement logiciel un artisanat: les expériences passées forgent une intuition, ce que Jean-Claude Beaune appelle un "sens de la matière":
Sans donner dans un archaïsme de rêve, recourir à l'image de l'artisan c'est alors insuffler dans la technologie trois principes critiques qui qualifient ce type idéal: le sens de la matière et de ses contraintes intimes ; le sens des choses belles ; le sens du secret et de l'ésotérisme appliqués à son éducation et à son enseignement futur.
Ajoutons que je me suis d'autant plus facilement tourné vers mon approche que je savais disposer dans ma boîte à outils d'une fonction effectuant cette découpe d'une chaîne de caractères en liste de chaînes, d'après une liste de caractères séparateurs possibles. On pourra voir là l'aspect "économiste" de l'ingénieur, figure également présente chez le développeur. Cette dérive "économiste" de l'ingénieur, récente, le pousse à utiliser des solutions existantes plutôt que tout réinventer. En attendant un billet sur ce sujet, on citera juste encore J.-C. Beaune:
... Qu'est-ce qu'un ingénieur aujourd'hui ? Quelle est sa fonction, son rôle dans la société ? L'ingénieur est-il encore le "technicien" du XIXème siècle, dont la fonction était de prolonger la science pure dans l'ordre de l'application cohérente et efficace ? L'ingénieur n'a plus à résoudre de problèmes techniques précis et spécialisés; on lui demande de produire une recherche destinée à mettre en oeuvre des principes généraux ayant de vastes applications pratiques, non de créer des procédés techniques tels que le moteur, la turbine ou le réacteur; son travail consiste à dégager de nouveaux champs d'applications techniques. L'ingénieur semble donc glisser du côté du savant. Mais la formation hautement mathématique qu'il reçoit ne suffit pas à justifier cette assimilation qui, de la part des pouvoirs, serait une grave faute conduisant souvent à un double emploi. Or les principes économiques enjoignent d'éviter le double emploi.
L'essentiel du changement intervenu réside dans la composante "économique" entrant dans la formation de l'ingénieur.
Enfin, il est fort possible que l'algorithme agissant directement sur la chaîne de caractères soit plus performant, puisque mon approche passe par une phase de découpe du texte en une liste de mots. D'autre part, hormis les éventuelles différences de performances, les deux implémentations auront également une forme différente et donc des potentialités d'évolution différentes.