Ainsi, pour un néophyte en programmation, la gestion du temps est par exemple une chose très simple, puisqu’il y a des secondes, des minutes, des heures, des jours et que tout cela mis bout à bout permet d’obtenir des années, des siècles et même des millénaires.
Et de plus, tout cela est régi par des règles universelles, car tout le monde sait que 60 secondes forment une minute, que 60 minutes forment une heure et que 24 heures constituent une journée.
Le tout est de plus utilisé quotidiennement de manière quasi automatique par le commun des mortels depuis plusieurs millénaires, et si le commun des mortels est capable de le faire, un ordinateur devrait en être tout autant capable.
Sauf qu’en réalité, le temps et sa gestion sont infiniment plus complexes, car pour paraphraser Albert Einstein, il s’agit d’une notion toute relative.
Toutes les années ne font en effet pas 365 jours, comme tout les mois ne font pas forcément 30 ou 31 jours et certaines journées peuvent faire 25 heures, voir même contenir des secondes intercalaires.
De plus, en fonction de la position géographique, une date n’a pas forcément la même signification, puisque le 14 février à 18 h en France peut être le 15 février à 2 h à Tokyo.
La représentation d’une date peut également prendre moult formes, en fonction de la langue, du calendrier, de l’époque ou de la culture utilisée, ce qui peut par exemple mener à des ambiguïtés si le référentiel n’est pas précisé.
Ainsi, 9 h peut tout aussi bien signifier 9 h ou bien 21 h.
De plus, une date pourra avoir une signification différente en fonction de l’ordinateur utilisé, grâce par exemple à la magie de la localisation.
Le développeur doit donc prendre tout cela en compte, et même si les règles sont bien connues, faire les bons choix techniques en fonction du contexte d’utilisation et prendre en compte ces règles pour répondre correctement à un besoin peut devenir une véritable gageure.
Et si d’aventure les règles relatives au métier sont également complexes, la problématique peut devenir rapidement très complexe, et si vous avez le moindre doute à ce sujet, je vous invite pour vous en convaincre définitivement à, par exemple, lire les textes de loi régissant les 35 heures ou bien encore les congés payés.
J’ajoute que pour couronner le tout, valider le bon fonctionnement d’un code utilisant le temps peut être délicat, puisqu’il faut pour cela pouvoir se mettre aussi bien dans des contextes d’utilisation nominaux, mais aussi dans des contextes d’utilisation particuliers, par exemple un passage de l’heure d’hivers à l’heure d’été.
Or, la machine à voyager dans le temps n’a pas encore été inventée et s’il est bien possible d’avancer ou de reculer l’horloge d’un ordinateur à volonté, c’est une démarche plus que fastidieuse à réaliser dans le cadre du test logiciel, sans compter que cette modification peut avoir un impact significatif sur le bon fonctionnement de la machine.
Tester le comportement d’un code utilisant une ou plusieurs données temporelles demande donc des techniques d’ingénierie logicielles spécifiques, par exemple la mise en œuvre de bouchons permettant de simuler de manière logicielle l’écoulement du temps au niveau des tests unitaires.
Le développeur peut alors à sa guise accélérer le temps, le ralentir ou s’y déplacer, ce qui lui permet de valider son code par rapport à toutes les situations qu’il peut imaginer.
Reste que le développeur restera tout de même un Humain, et qu’en conséquence, il est sujet à l’erreur et qu’il est très possible que malgré ses efforts, un cas limite lui échappe et que malgré les tests, un bug restera donc tout de même caché au sein de son code, n’attendant que le moment adéquat pour se manifester.
Or, le néophyte ne voit rien de tout cela, et c’est absolument normal, car outre le fait que l’informatique moderne est conçue de façon à masquer totalement sa complexité à son utilisateur final, ce dernier n’a pas à la connaître car ce n’est pas son domaine d’expertise.
Et ce qui est valable pour le temps s’applique également à la sauvegarde dans un fichier, aux connexions à une base de données, et même parfois à des calculs très basiques.
Durant ma première expérience professionnelle, j’ai ainsi eu besoin de justifier le développement d’un programme en C au lieu d’un code en PHP pour calculer des proratas, car mon interlocuteur n’arrivait pas à comprendre que PHP était un outil particulièrement inefficace pour effectuer des calculs même très simples avec des flottants.
D’ailleurs, je ne parlerais pas de la problématique posée par les arrondis qui parait souvent totalement aberrante au béotien tant il a une perception absolue de l’informatique, à tel point qu’il ne veut pas comprendre que pour un ordinateur 0.33333 + 0.33333 n’est pas égal à 2/3 et qu’en conséquence, faire calculer une TVA ou un total de facture à un ordinateur n’est pas forcément une chose simple.
Tout cela pour dire qu’il peut être pertinent lors d’une discussion à propos d’un chiffrage ou d’une planification de faire preuve de pédagogie en donnant une idée, même minimale ou approximative, de la complexité des problèmes à résoudre au niveau informatique pour obtenir le résultat désiré.
Et pour y parvenir, je n’ai toujours pas trouvé la recette magique, donc si vous avez des suggestions, n’hésitez surtout pas à me la communiquer, car je saurais quoi en faire quasi quotidiennement.
15 réactions
1 De MathRobin - 14/02/2014, 14:16
Et encore, tu n'as pas abordé la question des multiples fuseaux horaires dans un seul pays (exemple la Russie qui possède 9 fuseaux horaires depuis 2010, il y en avait 11 avant). Voir des fuseaux horaires décalés. Par exemple l'Iran, l'Afghanistan ou l'Inde qui ont un décalage respectif de +3:30, +4:30 et +5:30 ou le Népal et ses +5:45. Les heures d'été ou d'hiver qui ne sont pas toujours à la même date de changement (tout le monde ne prend pas le solstice comme point de référence) voire les pays qui n'ont pas ce système. J'ai bossé presque un an et demi dans les solutions télécoms professionnelles, ce genre de choses donnent quelque peu l'envie de se pendre...
2 De Frédéric - 14/02/2014, 14:25
"24 heures constituent une journée", sur quoi je répondrais, en bon informaticien qui a rencontré plusieurs bugs aux changements d'heures : Malheureusement pas toujours. Parfois, il faut 23 heures pour faire une journée, et parfois 25 !
3 De mageekguy - 14/02/2014, 14:33
@Frédéric : C'est précisément ce qui est expliqué dans la suite du billet…
4 De MathRobin - 14/02/2014, 14:51
Au moins le nouveau système de TVA à 6,10 et 20% est facile à faire calculer... Ah mais il ne s'applique qu'en France.
5 De Frédéric - 14/02/2014, 14:58
Ca m'apprendra à commenter avant de lire :/ Désolé ...
En tout cas (après lecture complète), je compatis et n'apporterai pas de solution.
Pour moi, ce n'est jamais évident de prévoir tous les cas. D'ailleurs, est-ce possible ? Pour prévoir un cas, il faut déjà savoir qu'il pourrait exister, et là on touche aux limites de nos connaissances propres.
6 De mageekguy - 14/02/2014, 15:27
@Frédéric : Le problème n'est pas vraiment comment trouver tous les cas (même si s'en est un et que des gens travaillent très activement pour lui trouver une solution), le problème est de parvenir à faire appréhender toute la complexité de notre métier à un interlocuteur pour qui l'informatique se résume à des clics sur le bouton d'une souris et qui n'a aucune idée des lois qui régissent l'univers de l'informatique et des problématiques qu'elles posent.
7 De Adirelle - 14/02/2014, 16:17
Pour la TVA et tout ce qui est de la comptabilité, il faut utiliser des représentations à virgule fixe en base 10. En PHP, tu peux utiliser l'extension BC. Les bases de données fournissent également des types spécifiques (decimal en postgres par exemple). Ils sont lents, ils prennent de la place, mais ils écorchent moins les nombres.
8 De Cyrano - 14/02/2014, 16:23
@Mageekguy, je crois que la recette magique, tu viens de la donner toi-même à travers cette démonstration : c'est relativement court, et concis et ça pose un problème basique que le profane rencontre au quotidien chaque fois qu'il regarde sa montre ou l'horloge au mur de son bureau. Pour lui, c'est simple, « Il est 10h15, mon rendez-vous est dans un quart d'heure » : son agenda doit le prévenir dans ce délai : avec ce que tu viens de décrire, tu montres clairement à ce profane que mettre en place ce système d'alerte qui lui parait si simple cache en réalité des cauchemars pour le programmeur. Il convient seulement juste de lui faire observer qu'on ne parle pas à nos machine pour leur dire quoi faire et qu'elle code ça toute seule, il faut écrire tout ça dans un langage de programmation sans rien oublier. S'il ne comprend toujours pas, alors là, il y a lieu de se poser des questions sur la pertinence du choix de l'interlocuteur...
My 2¢
9 De mageekguy - 14/02/2014, 17:04
@Cyrano : malgré mes efforts, j'ai souvent beaucoup de mal à faire comprendre à une personne le fossé entre sa perception des choses induite à la fois par ses connaissances et l'efficacité de son cerveau et ce que peut faire la machine en pratique en fonction de son fonctionnement et des outils à la disposition des programmeurs.
Pour la plupart des gens, la technique est magique, et le fait que cette croyance colle très bien avec leurs besoins ou leurs envies ne permet guère de faire passer un message contradictoire efficacement.
Un décideur non technicien a en effet beaucoup de mal à entendre que la façon dont fonctionne le temps, la machine et le langage de programmation fait qu'une opération qu'il fait lui intuitivement en quelques secondes ou même quelques minutes peut demander plusieurs jours de développement, notamment si cela ne cadre pas avec son besoin commercial ou marketing.
Alors oui, il est très possible que parfois, la qualité de l'interlocuteur soit effectivement un problème, mais on ne choisi forcément les personnes avec lesquelles nous devons travailler.
Il me semble donc pertinent de trouver une solution permettant de mettre une passerelle pédagogique entre ces deux univers aux lois et besoins parfois très orthogonaux, indépendamment de la qualité intellectuelle de leurs habitants.
10 De Cyrano - 14/02/2014, 19:32
Pour ma part, j'utilise ponctuellement une autre astuce : je démontre à mon interlocuteur non technicien qu'il fait quotidiennement de la programmation. J'utilise toujours le même exemple : supposons que vous vouliez faire des frites : intuitivement, presque sans même y réfléchir consciemment, vous allez vous poser une série de questions. D'abord, est-ce que j'ai des patates ? Pourquoi ? Parce que la réponse est binaire. si c'est non, je vais me tourner vers une alternative, des petits pois ou autre chose, mais si c'est oui, question suivante, est-ce que j'ai de l'huile ? Même motif, même punition : question à réponse binaire, et on passe à la suite. À ce stade de l'explication, c'est généralement largement suffisant : j'explique que pour aboutir à un résultat donné, je dois isoler chacun des choix à effectuer et y apporter la réponse appropriée. J'explique ensuite que construire un logiciel, c'est exactement la même chose. La machine ne comprend que le binaire et pour écrire du code, je dois isoler toutes les alternatives possibles et les traduire en code.
En mettant mon interlocuteur à la place du programmeur, il réalise d'abord que ce raisonnement tient la route, ensuite autre chose qu'il savait déjà à savoir qu'il n'aime pas ce genre de boulot et qu'il est donc trop content de pouvoir le refiler à un développeur qui se délecte de ce genre de choses, mais surtout il comprend que quelque chose en apparence très simple demande beaucoup de complications d'ordre technique. Cependant, l'autre aspect est que ça le gratifie quelque peu en lui montrant la supériorité de l'homme sur la machine puisqu'il peut « naturellement » effectuer des raisonnement à très grande vitesse alors que l'ordinateur ne le peut pas, sauf si on lui dit très exactement quoi faire.
Enfin bon, c'est une méthode avec laquelle je n'ai, jusqu'à présent, obtenu qu'une partie du but recherché, mon boss ne me stresse pas avec un chrono, il sait que ça peut prendre du temps et que lui-même est bien incapable d'en évaluer la durée. Reste tout de même l'autre partie pour laquelle je cherche moi aussi la méthode : lui faire exprimer correctement son besoin, m'expliquer complètement les règles de gestion pour la fonctionnalité demandée, pour exactement les mêmes raisons que celles expliquées plus haut avec mes frites. Je construis son outil, pas le mien, et c'est pour effectuer un processus qu'il fait de toutes façons autrement depuis bien avant que je ne sois même entré dans l'entreprise, l'outil devant simplement servir à lui en simplifier la mise en œuvre. Mais là, c'est toujours l'échec et pour obtenir toutes les informations, il faut arriver à lui faire décrire des choses qui sont devenues pour lui tellement automatiques et évidentes qu'il n'y pense même plus « consciemment », mais en oubliant au passage que je n'ai justement pas son expérience en la matière, c'est la croix et la bannière... et des refontes ponctuelles, partielles ou totales selon le cas dans des proportions tout aussi variables.
11 De Adirelle - 15/02/2014, 00:28
C'est rigolo, je viens de voir passer ce tweet, que je trouve fort à propos : https://twitter.com/fjsteele/status...
12 De Jérémy - 15/02/2014, 11:28
Estimer la complexité technique est extrêmement difficile. Il suffit d'assister à un pocker planning pour se rendre compte que la tâche est ardue pour les developpeurs, alors imaginez pour la MOA/PO/Client.
Ce qui me pose personnellement le plus de problème c'est les choix fonctionnelles qui sont fait a partir d'une mauvaise éstimation par le client : "Bon, comme la feature A semble trop compliqué, on va faire B" qui au final est plus longue à réaliser que "A". Ou alors "Ouhla c'est si compliqué pour faire la feature A ? alors, on va prendre la base existante, et pour les clients B, on fait C sauf s'ils font parti de D ou E dans quel cas on applique F".
Personnellement, en cas de doute, j'encourage régulièrement le PO à rédiger plusieurs US pour la même fonctionnalités. Le ratio valeur(estimée par le PO)/compléxité (estimée par les dev) permet ainsi au client de faire son choix plus simplement
13 De Ronan - 17/02/2014, 11:23
Tous les efforts des UX designers du 21ème siècle se résument en une phrase : "Don't make me think". Pas étonnant qu'il soit devenu difficile d'expliquer à quelqu'un que l'informatique embrasse plus de complexité qu'il n'imagine.
Perso, la comparaison avec le tricot fonctionne toujours assez bien.
14 De bfolliot - 18/02/2014, 13:18
Petite conférence qui illustre bien cela :
http://vimeo.com/69888991
15 De blogdevphp - 22/02/2014, 17:19
Je pense que le mot "pédagogie" est le seul postulat viable dans ces conditions. Etre concis et clair dans ses propos, ne pas hésiter à expliquer plusieurs fois si entêtement il y a. Si on fait appel à des développeurs, on cherche leur expertise. Pour une situation donnée, ils pourront apporter des réponses!