Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

Pourquoi 24 heures et pas 20 ou 30 heures par jour ?


babyloneVoilà un an que je travaille sur l'architecture et le développement d'un logiciel proprement révolutionnaire. Il est temps de faire le point sur le démarrage d'un projet aussi long.

Comme d'habitude, les spécifications étaient minimalistes et comme d'habitude on a su relever le défit grâce à l'agilité. Alors l'agilité humaine (scrum, xProgramming,...) n'a pas été trop difficile à respecter vue que j'étais presque tout seul pendant un an. Mais le code développé est-il souple et agile ?
Dans nos start up, où tout va vite, on n'a pas le temps de passer un an à faire de la R&D et développer le soft après avoir fait un prototype testé pendant 2 ans ! Non, la copie doit d'être fonctionnelle et évolutive du premier coup. Pourtant il n'est pas rare de devoir prendre des virages, ces options qui sont le fondement même du logiciel et qui rendront le fonctionnement du software limpide car il colle au plus près du besoin. Mais ces options ont le revers de mettre des verrous à votre logiciel qui ne pourra plus faire sans, rendant les futurs développements dépendants.
Si les options sont bien modélisées, ce sera un plus structurant, sinon, soit le logiciel sera une usine à gaz soit il clochera quelque part.

Tiens pour comprendre, voici la réflexion dans le même ordre d'idée sur notre système de décompte du temps. Un jour il a fallu trancher et un mec a eu cette idée saugrenue d'avoir 24 heures et pas 20 ou 100. Alors je vous pose la question pourquoi il y a 24 heures dans un jour et 60 minutes dans une heure et 60 secondes et par contre 100 millième de seconde !
Non mais franchement, quel est l'idiot qui a fait ça. Ce mec devait aimé les choses compliquées. Peut être même il était sadique ! Tout ça a plein de conséquences sur notre quotidien : Tour d'horizon des points de vue.

Le point de vue de mon patron. J'ai changé plusieurs fois depuis les début de ce blog, mais ils sont d'accord. Pour eux, la question serait plutôt pourquoi les jours ne font que 24h. Donc mon patron a été séduit par l'idée d'avoir une centaine d'heure par jours pour deux raisons essentiels :
- d'abord la journée du patron, qui ne compte pas ses heures, est toujours trop petite. "Ah il est 21h ! Non j'ai déjeuné il y a à peine 20 min"
- vue le coût du travail en France, il pourrait être compétitif d'instaurer la journée de travail à 48h ! Je vous laisse imaginer le gain de compétitivité par rapport aux autres pays qui resterait à 24h !

Bon alors, vous avez compris, mon patron a fait une école de commerce et n'a pas intégré la question comme moi !
Je parlais évidemment de conserver la durée absolue de la journée qui est lié à la rotation de la terre autour du soleil. A moins d'un cataclysme, on gagnera pas plus d'un pouième de seconde !

Le point de vue du stagiaire
Il a le même raisonnement que le patron, mais voudrais que les journées de travail ne fasse que deux heure... Bizarre il a fait une école d'ingénieur.

Le point de vue du développeur.
Ce serait quand même plus simple d'avoir une base 10 pour compter quand même. Heureusement les Linuxiens ont inventé le temps UNIX qui égraine des secondes depuis 1970, ça en fait un paquet ! Mais au moins c'est de la base 100.
En effet, cette histoire farfelue de devoir compter en base 60, ça nous oblige à avoir des objets dédiés, ça gaspille du temps, de l'énergie et de l'argent...
En génie logiciel, des conventions (ou options) comme celles-ci il y en a plein. Vous comprenez donc aisément par ce petit exemple qu'une convention peut vous faciliter la vie ou vous enquiquiner durant tout la vie du logiciel. Moi j'aime les choses simple. Il y a assez de tordus qui définissent les règles et les normes auxquels nos logiciels ne peuvent échapper sans pour autant ajouter nos propres contraintes tordue d'informaciens.

Enfin le point de vue des babyloniens.
Pour les 24 heures, les babyloniens comptaient à l'origine 6 divisions du temps le matin et 6 le soir. Pour avoir plus de précision, ils ont divisés par deux chaque temps faisant ainsi 12h le matin et 12h l'après-midi. Pour avoir plus de précisions encore, eux qui ne comptaient pas en base 10 mais en base 60 pour une raison très simple : il n'avait pas de calculette électronique. Or 60 est un chiffre qui se divise par énormément de diviseurs sans faire de virgule !

Conclusion : les contraintes d'hier évoluent. Les conventions prises pour se simplifier la vie il y a très très longtemps ont des répercutions encore aujourd'hui. Dans le développement d'un logiciel, certaines fonctionnalités nécessitent de prendre des "options" logicielles dont il  importe d'étudier les répercutions à long terme. S'il peuvent être salvateur aujourd'hui, cela peut devenir un boulet indépassable demain. Alors si certaines conventions ont encore cours aujourd'hui et sont dépassable, imaginez une mauvaise décision d'architecture logicielle prise à la vas vite. Décidément mon patron a raison : " il ne doit pas y avoir d'empressement à faire des erreurs."

Les commentaires sont fermés.