Discussion :

[el_slapper]

On a pas attendu les ordinateurs pour inventer le concept de temps masqué.

Temps masqué (Tz) : Temps d’un travail accompli pendant l’exécution d’un autre travail dont la durée est seule prise
en considération.

Exemple :contrôle d’une pièce pendant l’usinage automatique de la pièce suivante.

[Glutinus]

Le "grand public" n'a jamais vu les plannings qu'on se tape à certains endroits et les projets qui doivent être finis pour hier. Je connais une boite comme ça, quand un projet démarre, il est systématiquement déjà en retard, tellement leur planning est chaotique.

Il est plutôt chaotique à cause d'un effet tunnel, les équipes se disent "on a le temps" et prend son temps, et plus ça s'approche de la fin, plus ils se rendent compte de la merde, mais le délai n'est pas fini.
Je me souviens d'une mission que je sentais bien mal partir : l'AMOA devait livrer une spec début juillet, elle part en vacances deux semaines, revient mais l'utilisatrice part en vacances, revient, mais l'AMOA repart en vacances etc.
Malgré mes mails d'alerte durant tout l'été, je me retrouve avec les specs avec deux mois de retard, et bien sûr toujours les mêmes délais. Entre guillemets j'ai eu de la chance parce que j'ai eu droit à avoir des développeurs et j'ai fait plutôt de la gestion de projet opérationnelle pendant les devs plutôt que du dev, une petite corde à mon arc.
Cet exemple parfait pour prouver qu'on peut pas faire les tâches en parallèle !

Ceci dit, je suis d'accord sur le post ! C'est un effet "caisse de supermarché", tu te souviens toujours quand tu attends 50 mns au supermarché à cause de deux petits vieux devant toi, mais jamais quand tu passes en 3 secondes top chrono parce qu'il y a personne.
Et quand t'appelles un DBA pour poser une question et qu'il répond "c'est pas possible, ça réplique" tu te souviens de cette anecdote et tu la racontes au café alors que la veille il a répondu à ta requête en deux-deux.

Et le titre du topic encore une fois est très provocateur et ne montre pas la réalité du post

[TiranusKBX]

Il est plutôt chaotique à cause d'un effet tunnel, les équipes se disent "on a le temps" et prend son temps, et plus ça s'approche de la fin, plus ils se rendent compte de la merde, mais le délai n'est pas fini.
Je me souviens d'une mission que je sentais bien mal partir : l'AMOA devait livrer une spec début juillet, elle part en vacances deux semaines, revient mais l'utilisatrice part en vacances, revient, mais l'AMOA repart en vacances etc.
Malgré mes mails d'alerte durant tout l'été, je me retrouve avec les specs avec deux mois de retard, et bien sûr toujours les mêmes délais. Entre guillemets j'ai eu de la chance parce que j'ai eu droit à avoir des développeurs et j'ai fait plutôt de la gestion de projet opérationnelle pendant les devs plutôt que du dev, une petite corde à mon arc.
Cet exemple parfait pour prouver qu'on peut pas faire les tâches en parallèle !

Ceci dit, je suis d'accord sur le post ! C'est un effet "caisse de supermarché", tu te souviens toujours quand tu attends 50 mns au supermarché à cause de deux petits vieux devant toi, mais jamais quand tu passes en 3 secondes top chrono parce qu'il y a personne.
Et quand t'appelles un DBA pour poser une question et qu'il répond "c'est pas possible, ça réplique" tu te souviens de cette anecdote et tu la racontes au café alors que la veille il a répondu à ta requête en deux-deux.

Et le titre du topic encore une fois est très provocateur et ne montre pas la réalité du post

pour les problèmes de délais en général cela m'arrive soit parce que le client fournis les détails à la bourre ou que ce sont ceux qui me pondent des specs en interne de la boite

[Matthieu Vergne]

De ce que je comprends de cette image, le hacker est le seul qui a du temps libre valorisant sa compétence. Comme quoi, c'est bien d'être un hacker. {^_°}

[vertex.3F]

Le "grand public" n'a jamais vu les plannings qu'on se tape à certains endroits et les projets qui doivent être finis pour hier. Je connais une boite comme ça, quand un projet démarre, il est systématiquement déjà en retard, tellement leur planning est chaotique.

c clair !
si l'on peut trouver quelques fonctions ou situations exceptionnelles pendant lesquelles des informaticiens semblent "attendre",
il en est tout autre des metiers du developpement - que je connais bien - soumis aujourd'hui aux cadences (vous savez bien, vos objectifs annuels de productivité) et délais invraisemblables (comme dit plus haut : vous avez 2 semaines de charge pour me livrer ce bout de logiciel dans ... 5 jours)

le developpeur doit produire (coute que coute) un logiciel qui "fonctionne" alors que les elements qui lui sont fournis arrivent souvent... pas bien dans l'ordre et pas bien complets ! (c'est inherent à l'imprecision et la non exhaustivité de l'écrit, par nature), s'il parvient a relever ce défi, ce n'est pas en contemplant son écran

je ne connais pas un seul expert ou architecte qui glande, au contraire !
lorsqu'il est dans l'entreprise il est sans cesse sollicité (il faut aussi qu'il arrive a se concentrer sur ses tâches, bordel) et il passe nombre de ses soirs et weekends à lire des bouquins et coder des POC pour rester au gout du jour, l'informatique etant l'un des secteurs qui evoluent le plus vite me semble t il

l'auteur de la chronique serait il un informaticien "glandeur" qui croirait que l'on fait tous comme lui, ou bien un petit malin qui trime en réalité et qui espère qu'on réagisse à son article pour contrer l'idée reçue ?

[Zirak]

l'auteur de la chronique serait il un informaticien "glandeur" qui croirait que l'on fait tous comme lui, ou bien un petit malin qui trime en réalité et qui espère qu'on réagisse à son article pour contrer l'idée reçue ?

Vu l'heure du post, la source de la chronique, et les quelques fautes de frappes dans celles-ci, plutôt qu'un informaticien glandeur, je pencherais plus pour un chroniqueur mal réveillé en manque d'inspiration...

[Sodium]

Concernant les autres professions, me suis en effet toujours demandé comment ça se passait dans le monde de la 3D. Qu'est-ce que vous faites quand un rendu est en cours (et Dieu sait que ça peut prendre des plombes) ?

En cours d'introduction à la 3D je jouais à Call of Duty 4 comme les frames étaient nombreuses mais très simples. J'avais juste des ralentissements lorsque l'image était sauvée sur le disque
Mais je suppose que les vrais pros de la 3D ont une machine dédiée à ça ou utilisent un service en cloud.

[goomazio]

Question de mentalité... J'ai un collègue qui se croise souvent les bras quand :
- ça compile
- il y a un problème et il attend l'arrivée d'un développeur plus expérimenté...
- il lance une impression et cours jusqu’à l'imprimante pour y attendre sa feuille

Mais c'est un des seuls à avoir cette mentalité "école" où on se réjouit quand le prof n'est pas là :p

[Zirak]

Question de mentalité... J'ai un collègue qui se croise souvent les bras quand :
- ça compile
- il lance une impression et cours jusqu’à l'imprimante pour y attendre sa feuille

Mais c'est un des seuls à avoir cette mentalité "école" où on se réjouit quand le prof n'est pas là :p

Honnêtement, cela m'arrive aussi.

Quand je viens de passer plusieurs heures à réfléchir sur un problème un peu complexe ou que j'ai passé un certains nombre d'heures devant l'écran, je n'hésite pas à profiter d'une impression, d'une compilation, ou d'une grosse injection de données pour me reposer l'esprit 5mn, me décoller les yeux de l'écran ou aller me dégourdir les jambes en allant chercher mon impression.

Ce n'est pas une question d'en profiter pour ne rien faire, mais simplement prendre soin de ma santé.

[goomazio]

Honnêtement, cela m'arrive aussi.

Quand je viens de passer plusieurs heures à réfléchir sur un problème un peu complexe ou que j'ai passé un certains nombre d'heures devant l'écran, je n'hésite pas à profiter d'une impression, d'une compilation, ou d'une grosse injection de données pour me reposer l'esprit 5mn, me décoller les yeux de l'écran ou aller me dégourdir les jambes en allant chercher mon impression.

Ce n'est pas une question d'en profiter pour ne rien faire, mais simplement prendre soin de ma santé.

Je me suis mal exprimé : il n'en profite pas "souvent" ou "parfois" mais "systématiquement"

Idem quand, dans l'openspace, il se passe quelque chose : il est obligé de systématiquement s'y intéresser. D'un côté, je trouve que c'est bien d'être curieux et sociable. D'un autre côté, ça m'exaspère de le voire bailler aux corneilles à la moindre occasion.

[Glutinus]

De base, je suis sur du multi-tâche, j'ai un projet prioritaire, mais si pour raison technique (upload/download, compilation) ou humaine (projet bloqué et refilé aux autorités compétentes) bien sûr je bifurque sur autre chose.

Evidemment je peux être sur un seul projet, ou sur un projet gelé et je me retrouve avec une unique tâche comme faire du suivi de prod :/ j'avoue le passer à moitié à glander, et l'autre moitié à faire des choses que j'ai pas fait (archivage de mes répertoires ou de mes mails, compléter les specs techniques, oui oui vous savez ce .doc duquel on dit "on verra ça plus tard après la livraison"). Ou alors je vais voir sur developpez ou autres forums. Comment ça je passe trop de temps ici ?



Pour anecdote, dans un contexte tout autre informatique, j'ai fait un stage dans un service back-office de banque, pour un mois. J'ai remplacé une titulaire qui était absente pour congés maladie assez grave depuis 5 mois, il y avait donc 5 mois de retard dans les dossiers, si ce n'est plus. Pour blaguer, le chef de service m'a dit que si je n'avais pas rattrapé le retard à la fin du stage, il ne me validait pas mon stage. Et j'ai quasiment tout rattrapé, il restait juste des dossiers envoyés à d'autres services / banques mais sur mon bureau il n'y avait plus rien à ma responsabilité.

Une des raisons du retard était qu'on utilisait divers moyens pour lire la compta, que ce soit des applis qui ne fonctionnaient qu'avec un seul utilisateur connecté (???) ou des machines pour y glisser les micro-fiches, un peu comme dans les films d'espionnage quand le héros lit des vieilles coupures de journaux.

Je me suis rendu compte que mes collègues traitaient les dossiers un par un, alors que je faisais d'abord l'étape 1 sur tous les dossiers, puis l'étape 2, puis après je les dispatchais selon le medium utilisé. J'arrive à la machine à microfiches et je vois plusieurs collègues qui font la queue, avec une seule feuille à la main ! Et mes collègues attendaient bêtement, discutent, vont chercher un café et reviennent... moi je reviens à mon poste et m'occupe d'autre chose avant d'essayer une heure plus tard, si c'est vide je traite 15 microfiches d'un coup.

Je n'avais pas un rythme plus poussé que mes collègues, d'ailleurs je faisais 9h30-16h30 (c'était dans la convention de stage) en mode tranquillou avec une heure pour déjeuner. Et j'étais honnêtement beaucoup plus efficaces qu'eux, et surtout j'ai coûté à la banque que 327 euros vs 5 mois de salaire ou plus.

Et après on dit que c'est les informaticiens qui ont du temps libre ?

[Luckyluke34]

Cela n’est pas étonnant dans la mesure où effectuer un test unitaire pourrait facilement durer 4 heures si le projet est assez complexe.

Facilement, non. Ca n'arrive quasiment jamais sur du développement classique d'applications line of business. De plus, on peut dans ce cas remettre en question le qualificatif "unitaire", qui a toutes les chances d'être faux.

Une suite de tests automatisés qui prend plus de quelques minutes à s'exécuter devrait être restructurée pour mettre les tests les plus lents dans un job exécuté par exemple la nuit ou à des horaires définis, pas à chaque fois qu'on commite du code. Ce qu'on attend d'une suite de tests unitaires, c'est un feedback immédiat pour savoir si le code qu'on vient de soumettre a cassé quelque chose ou pas.

Si le démarrage d'une tâche B dépend du résultat d'un test A qui dure plusieurs heures, c'est qu'on est dans du hyper spécifique (très gros volumes de données, cryptographie, etc.) ou que quelque chose ne tourne pas rond.

Sur la question d'origine, je préfère l'expression temps mort à celle de temps libre qui suggère fortement que ce sont des périodes hors activité professionnelle où le développeur peut faire ce qu'il veut. Bien sûr il y a des temps morts dans nos professions mais si le flux de travail est bien pensé, ils n'excèdent pas quelques minutes et sont l'occasion de prendre du recul sur ce qu'on vient de faire ou réfléchir à la suite et noter les idées qui nous viennent.

[el_slapper]

@Glutinus : c'est pour ça qu'on ne laisse pas les techos s'exprimer. C'est bien trop dangereux, des gens capables de bouleverser les habitudes. Le management, surtout le management intermédiaire ne cherche pas l'efficacité économique, il cherche le pouvoir. Et la paix, aussi.

@Luckyluke34 : non mais oh, tu crois vraiment que ton petit cas particulier s'adapte à l'univers entier? On peut avoir des tests automatiques qui prennent du temps, pour des milliers de raisons. Un, que j'ai connu, était que je n'avais pas de specs, si ce n'est "refonds-nous ça en propre. Ça a 36 ans, ça tourne nickel, et personne n'y comprend rien". Mon test automatique, c'était de comparer le résultat d'un mois complet de l'ancienne chaine, avec un mois complet de la nouvelle. Je n'avais pas le choix. Et ça prenait à peu près 90 minutes pour tout comparer. Ça m'a trouvé des centaines d'anomalies. Si je ne passais pas le mois complet, je risquais de louper des éléments importants.

Je suis sur qu'il y a des milliards d'autres raisons d'avoir des tests unitaires qui durent des plombes. Mon métier, maintenant, c'est les tests fonctionnels automatiques. On bouffe assez vite beaucoup de temps, en jouant avec les interfaces. On essaye de découper en morceaux, mais les VM ne sont pas en nombre infini, et ça prend quand même beaucoup de temps. Alors non, ce ne sont pas des test unitaires. Mais je me retrouve souvent à surveiller l'exécution(c'est fragile, ces petites bêtes-là, quand tu as un programme VB6 qui invoque du WPF et que tu dois capturer les infobulles). Un oeil sur le script qui tourne, un oeil sur DVP.

Ah, fini sans casse(pfiouh), je vous laisse.

[Matthieu Vergne]

Facilement, non. Ca n'arrive quasiment jamais sur du développement classique d'applications line of business. De plus, on peut dans ce cas remettre en question le qualificatif "unitaire", qui a toutes les chances d'être faux.

@Luckyluke34 : non mais oh, tu crois vraiment que ton petit cas particulier s'adapte à l'univers entier? On peut avoir des tests automatiques qui prennent du temps, pour des milliers de raisons. Un, que j'ai connu, était que je n'avais pas de specs, si ce n'est "refonds-nous ça en propre. Ça a 36 ans, ça tourne nickel, et personne n'y comprend rien". Mon test automatique, c'était de comparer le résultat d'un mois complet de l'ancienne chaine, avec un mois complet de la nouvelle. Je n'avais pas le choix. Et ça prenait à peu près 90 minutes pour tout comparer. Ça m'a trouvé des centaines d'anomalies. Si je ne passais pas le mois complet, je risquais de louper des éléments importants.

Je suis sur qu'il y a des milliards d'autres raisons d'avoir des tests unitaires qui durent des plombes. Mon métier, maintenant, c'est les tests fonctionnels automatiques. On bouffe assez vite beaucoup de temps, en jouant avec les interfaces. On essaye de découper en morceaux, mais les VM ne sont pas en nombre infini, et ça prend quand même beaucoup de temps. Alors non, ce ne sont pas des test unitaires. Mais je me retrouve souvent à surveiller l'exécution(c'est fragile, ces petites bêtes-là, quand tu as un programme VB6 qui invoque du WPF et que tu dois capturer les infobulles). Un oeil sur le script qui tourne, un oeil sur DVP.

Justement, il parle de tests unitaires, non de tests automatiques en général. Un test unitaire est censé se focaliser sur une propriété spécifique, et non sur l'exécution d'un système entier, ce qui est visiblement le cas de ton test auto ici décrit. Là on en est à des tests d'intégration typiquement. Si tu as des tests unitaires, ces gros tests là tu ne les fais que ponctuellement et non à chaque changement.

Si on parle de tests automatiques, y'a pas de contrainte, donc oui on peut avoir du très court comme du très long. Mais si on parle de tests unitaires, on parle d'une catégorie spécifique de tests auto. Aucun de vous deux n'a tort, ici, faut juste bien se mettre d'accord sur les termes : dans ton cas tu n'avais que des tests haut niveau et aucun test unitaire pour te permettre de faire les choses de manière progressive.

[Iradrille]

Développeur web, il est très rare que je ne trouve pas quelque à faire en parallèle lorsque je suis en attente d'un transfert FTP. De toute manière, avec la fibre optique, ça va très vite.
Ca doit cependant déjà être beaucoup plus compliqué pour ceux dont toutes les ressources de la machine ont besoin d'être monopolisées. Je suppose que pendant une compilation, il est toujours possible de bosser sur d'autres codes, par contre lors d'un rendu 3D c'est nettement plus compliqué.

Le problème avec la compilation c'est quand on à plein de petites coupures au lieu d'une grosse : un projet qui met 1 heure à compiler, pas de problème on peut bosser sur autre chose. Un projet qui met 2 ou 3 minutes à compiler mais qu'on recompile 20 fois : c'est super chiant

Pour le rendu 3D, il y a souvent des render farms, dans ce cas on peut bosser sur autre chose sans problème pendant un rendu.

[el_slapper]

Justement, il parle de tests unitaires, non de tests automatiques en général. Un test unitaire est censé se focaliser sur une propriété spécifique, et non sur l'exécution d'un système entier, ce qui est visiblement le cas de ton test auto ici décrit. Là on en est à des tests d'intégration typiquement. Si tu as des tests unitaires, ces gros tests là tu ne les fais que ponctuellement et non à chaque changement.

Si on parle de tests automatiques, y'a pas de contrainte, donc oui on peut avoir du très court comme du très long. Mais si on parle de tests unitaires, on parle d'une catégorie spécifique de tests auto. Aucun de vous deux n'a tort, ici, faut juste bien se mettre d'accord sur les termes : dans ton cas tu n'avais que des tests haut niveau et aucun test unitaire pour te permettre de faire les choses de manière progressive.

Non, non, pour mon premier cas, il s'agit bien de test unitaires : je n'avais AUCUN autre moyen de tester mon truc. C'était juste un composant unitaire, d'ailleurs, que je testais : celui qui transformait les données brutes extraites en masse dans un fichier, en un fichier "net" contenant tout ce dont avait besoin l'impression pour tourner. Je testais le composant seul. Tout le reste, je le faisais tourner une fois par mois(avec les données de prod) pour avoir mon fichier en entrée, et je ne m'amusais pas à perdre une heure de plus à chaque fois.

Alors, oui, c'est un cas aux limites, sans doute rare. Mais c'était bien réel. J'avais d'ailleurs intérêt à ramasser un maximum d'anomalies et à en corriger un maximum pour ne pas prendre trop de retard(de mémoire, en 6 semaines, j'ai ramassé et corrigé plus de 500 anomalies, soit une grosse dizaine par exécution). Mais c'était bien du test unitaire, j'avais un composant unitaire que je testais seul, isolé de tout le reste de la chaine, et le test mettait une heure et demie à tourner. L'intégration complète, c'était une journée complète(entre l'extraction des données avant, la transformation de mon fichier en XML suivie du JAVA qui en faisait un joli courrier présentable pour le client).

Alors tu vas me dire que mon architecture était pourrie(et que j'aurais du découper bien plus)? Ben, sans doute. En même temps, ils ont gagné un peu plus d'un équivalent temps plein en maintenance sur cette chaine, alors bon, du pourri comme ça, j'ai tendance à en être fier quand même.....

[Matthieu Vergne]

Alors tu vas me dire que mon architecture était pourrie(et que j'aurais du découper bien plus)?

J'aurai effectivement tendance à le penser. {'^_^}

En même temps, ils ont gagné un peu plus d'un équivalent temps plein en maintenance sur cette chaine, alors bon, du pourri comme ça, j'ai tendance à en être fier quand même.....

Et j'ai rien à dire contre ça. {^o^}

[Luckyluke34]

@Luckyluke34 : non mais oh, tu crois vraiment que ton petit cas particulier s'adapte à l'univers entier?

Mon petit cas particulier s'appelle par exemple Martin Fowler, un des pères du mouvement autour des pratiques d'ingéniérie agiles et orientées objet, un des premiers à utiliser le terme de "tests unitaires automatisés" qui a aussi popularisé les notions d'injection de dépendance ou refactoring. Mais merci pour le mépris, ça fait certainement avancer le débat.

http://martinfowler.com/bliki/UnitTest.html

Despite the variations, there are some common elements. Firstly there is a notion that unit tests are low-level, focusing on a small part of the software system. Secondly unit tests are usually written these days by the programmers themselves using their regular tools - the only difference being the use of some sort of unit testing framework [1]. Thirdly unit tests are expected to be significantly faster than other kinds of tests.

En l'occurrence, j'ai même été moins catégorique que lui puisque j'ai dit que ce n'était presque jamais le cas que des tests soient aussi lents. Tu remarqueras aussi que 90 minutes, ce n'est pas quatre heures.

Peu importe les querelles de dénomination stériles, mon propos c'est que dire "un test unitaire pourrait facilement durer 4 heures si le projet est assez complexe" est surprenant dans du contenu éditorial que des gens de tous niveaux vont lire. Cela en fait, sinon la norme, au moins quelque chose d'habituel, alors que nombre de pratiques actuelles tendent vers exactement l'inverse. Je ne vais pas mentionner TDD qui est assez controversé ici mais si on prend l'intégration continue (pas vu beaucoup d'annonces pour des postes de dev qui ne la mentionnaient pas ces 5 dernières années), le but est d'avoir des tests très rapides pour une boucle de feedback immédiate. Donc présenter un test qui dure 4 heures comme quelque chose d'habituel contre lequel il ne faut pas tenter de trouver des solutions, ben, non...

[vinmar]

Lorsque vous avez les yeux qui piquent parce que vous venez d'enchainer un moment de travail intense sur le développement, la réflexion ou autre tâche que tout informaticien doit faire, et bah je ne suis pas contre :
- me lever
- m'étirer
- boire un café
- parler de tout et de rien pour vider le cache de mon cerveau
- jouer au ping pong (pour les sportifs)
- regarder des lolocats (pour les plus geeks)
- aller sur developpez.com (pour la veille et les débats)

Vous savez, il existe des techniques qui prennent en compte les poses dans le temps de travail : http://pomodorotechnique.com/ ou https://fr.wikipedia.org/wiki/Technique_Pomodoro.

La culture du travail en entreprise doit évoluer, surtout en France. Savez-vous que dans certaines entreprises dans le monde, ils imposent même des siestes => parce qu'il se sont rendu compte qu'un mec reposé est un mec plus productif...

[geniium]

C'est tellement bateau comme article!