« Le projet de loi des droits du développeur »

[Aquanum]

@Nemek je parle bien d'une machine de dev. Et nous avons tous les mêmes besoins dans l'équipe.
La particularité dans mon cas c'est que tout est cross-compilé. Donc la machine de dev overkill est là pour compiler suffisamment vite pour ne pas à perdre plus de temps.

Même chose pour le serveur d'intégration continue. Il faut savoir mettre les moyens pour avoir du matériel décent pour ne pas perdre du temps. Le prix du matériel est amorti en quelques jours à l'échelle d'une équipe de dev qui perd systématiquement son temps parce que le serveur met une plombe à compiler une release.

Et puis je trouve que forcer une mauvaise config pour "éduquer" les développeurs n'est pas franchement une bonne idée. Un bon développeur sait comment bien coder et optimiser pour des configurations différentes. Le fait d'avoir une machine de dev puissante, permet surtout de gagner du temps de développement.

[ManusDei]

Envoyé par OldTimeCoder

Je vais répondre point par point à ce "porjet de loi"
Chaque programmeur aura deux moniteurs : si une entreprise veut maximiser la productivité des développeurs, elle doit s’assurer que chaque développeur dispose de deux moniteurs. >> Non les développeurs oublieront que parfois il développe sur un écran en 80x24 et il sera alors impossible de coder correctement dans ces conditions. Les développeurs doivent apprendre les conditions difficiles pour comprendre pourquoi il faut se restreindre pour ne pas faire chier les autres développeurs.

Dans l'embarqué, on a souvent pas de bibliothèque, voire on code directement en assembleur. Est-ce que tu penses que pour apprendre les conditions difficiles, tout le monde doit coder en assembleur, même les devs qui bossent sur windows8 ?

Envoyé par OldTimeCoder

Chaque programmeur doit avoir un cadre de travail calme : la programmation exige une concentration mentale. Les programmeurs ne peuvent pas travailler efficacement dans un environnement bruyant. >> tOUT EST QUESTION DE GOUT;

Je suis en open space, je n'arrive pas à me concentrer... 50% du temps à cause du bruit. Donc c'est au moins 50% de productivité en moins. C'est dommage quand même pour l'entreprise (ça change rien au chèque à la fin du mois).

Plus généralement, quel intérêt ont les "conditions difficiles" ? J'ai plus l'impression que c'est du simple masochisme.

[Nemek]

Envoyé par Aquanum

@Nemek je parle bien d'une machine de dev. Et nous avons tous les mêmes besoins dans l'équipe.
La particularité dans mon cas c'est que tout est cross-compilé. Donc la machine de dev overkill est là pour compiler suffisamment vite pour ne pas à perdre plus de temps.

Ca me surprend d'avoir une chaîne de compilation aussi longue mais on a pas toujours le choix. Bref comme tu dis "la particularité de ton cas".

Envoyé par Aquanum

Même chose pour le serveur d'intégration continue. Il faut savoir mettre les moyens pour avoir du matériel décent pour ne pas perdre du temps. Le prix du matériel est amorti en quelques jours à l'échelle d'une équipe de dev qui perd systématiquement son temps parce que le serveur met une plombe à compiler une release.

Là on est plus sur une machine de développeur. Cependant on pourrait rajouter "une loi" pour avoir des serveurs plus ou moins dédiés pour : gestion de configuration, bases de données, serveurs applicatifs, etc.

Envoyé par Aquanum

Et puis je trouve que forcer une mauvaise config pour "éduquer" les développeurs n'est pas franchement une bonne idée. Un bon développeur sait comment bien coder et optimiser pour des configurations différentes. Le fait d'avoir une machine de dev puissante, permet surtout de gagner du temps de développement.

Tu supposes que tous les développeurs sont bons

[Aquanum]

Envoyé par Nemek

Ca me surprend d'avoir une chaîne de compilation aussi longue mais on a pas toujours le choix. Bref comme tu dis "la particularité de ton cas".

Je peux me tromper, mais c'est monnaie courante dès que tu fais de l'embarqué. Ca ne me semble pas si particulier comme cas finalement.
Compiler un kernel ou Android from scratch prend un temps fou. Si tu dois faire ça à longueur de journée, c'est vital d'avoir un bon PC.

Envoyé par Nemek

Tu supposes que tous les développeurs sont bons

Héhé c'est vrai, mais ce n'est pas une raison pour niveler par le bas

[ManusDei]

Les dernières pages de cette discussion m'inspirent une phrase :

Y a qu'en informatique qu'on joue à qui a la plus petite.

[el_slapper]

Envoyé par kedare, optimiste

Les droits d'admin sur sa propre machine, pourquoi pas, mais les droits d'admin sur les serveurs et le réseau, la il peut rêver par contre je pense :]

ça fait des années que je n'ai pas les droits admin sur ma machine.

[Nemek]

Envoyé par Aquanum

Je peux me tromper, mais c'est monnaie courante dès que tu fais de l'embarqué. Ca ne me semble pas si particulier comme cas finalement.
Compiler un kernel ou Android from scratch prend un temps fou. Si tu dois faire ça à longueur de journée, c'est vital d'avoir un bon PC.

L'embarqué est déjà une particularité. Ceci dit est-ce nécessaire de faire "from scratch" ? Je connais pas le kernel Android mais faire des .o/.so et les placer dans un repository, ca ferait pas gagner du temps ?
C'est le fonctionnement qui avait été mis en avant dans les discussions "Java vs C++" dans l'approche modulaire.

Envoyé par Aquanum

Héhé c'est vrai, mais ce n'est pas une raison pour niveler par le bas

Le concept de loi s'applique donc à tout le monde et il faut bien tenir compte de tout le monde !

[Aquanum]

Envoyé par Nemek

L'embarqué est déjà une particularité. Ceci dit est-ce nécessaire de faire "from scratch" ? Je connais pas le kernel Android mais faire des .o/.so et les placer dans un repository, ca ferait pas gagner du temps ?
C'est le fonctionnement qui avait été mis en avant dans les discussions "Java vs C++" dans l'approche modulaire.

Bon c'est assez compliqué, et je vais pas forcément m'étendre là dessus ici sans partir dans le HS. Mais en effet je n'ai pas besoin de compiler depuis zéro à chaque fois, mais ça m'arrive plusieurs fois par jour. Et tu as beau avoir déjà plein de choses pré compilées, ça te prend tout de même du temps. C'était surtout pour illustrer le besoin de ressources dans mon cas.

Bon et puis nous sommes vendredi J'ai le droit de troller L'embarqué n'est pas si à part que ça, hein. Ça représente pas mal de monde !

Envoyé par Nemek

Le concept de loi s'applique donc à tout le monde et il faut bien tenir compte de tout le monde !

Tout à fait. Sauf que ce n'est pas pour autant une raison d'empêcher "les bons" de travailler, par un concept de loi, en les forçant à avoir du mauvais matos.

[Nemek]

Envoyé par Aquanum

Bon c'est assez compliqué, et je vais pas forcément m'étendre là dessus ici sans partir dans le HS. Mais en effet je n'ai pas besoin de compiler depuis zéro à chaque fois, mais ça m'arrive plusieurs fois par jour. Et tu as beau avoir déjà plein de choses pré compilées, ça te prend tout de même du temps. C'était surtout pour illustrer le besoin de ressources dans mon cas.

Désolé pour l'incitation au HS

Envoyé par Aquanum

Bon et puis nous sommes vendredi J'ai le droit de troller L'embarqué n'est pas si à part que ça, hein. Ça représente pas mal de monde !

Comme tu dis : "Vendredi tout est permis !"

Envoyé par Aquanum

Tout à fait. Sauf que ce n'est pas pour autant une raison d'empêcher "les bons" de travailler, par un concept de loi, en les forçant à avoir du mauvais matos.

Un bon, il est bon avec du bon ou du mauvais matos


Pour en revenir un peu plus dans le sujet, plutôt que se pencher sur le matériel et éventuellement le cadre "physique" de travail, c'est surtout du côté de la relation client (la vision de ce dernier sur le programmeur et inversement), la gestion de projet au sens extra large (organisation, rôles, dépendances fonctionnelles, échanges entre les services, etc.) qu'il faudrait améliorer.

[MiaowZedong]

Envoyé par Nemek

Un bon, il est bon avec du bon ou du mauvais matos

Certes. Cependant, ce matin, redémarrer mon PC m'a pris 10 minutes (c'est un cas assez extrème, avec un virtual desktop qui prend beaucoup trop long à se lancer).

En démarrant mon PC tous les jours, je perds donc environ 3.5 heures par mois; sans compter le temps perdu en lançant mes applications, le temps perdu avec les occasionels plantages...

Tout ça fait une perte de productivité réellement chiffrable et qui doit coûter plus de €1k/personne/an (minimum) à l'entreprise, en temps passé par les salariés à attendre une réponse de leurs PC.

Un investissement plus régulier en matériel informatique serait donc rentable, voir très rentable.

[fcharton]

Envoyé par MiaowZedong

En démarrant mon PC tous les jours, je perds donc environ 3.5 heures par mois; sans compter le temps perdu en lançant mes applications, le temps perdu avec les occasionels plantages...

Est-ce vraiment une perte de productivité? C'est peut être juste moi, mais le temps passé à coder représente une toute petite partie de mon travail (de développeur), la majeure partie c'est de la rêverie, des gribouillis sur des cahiers, ou des discussions à bâtons rompus.

J'ai toujours eu l'impression que les explications du genre "ah oui mais on perd un temps fou en recompilation" sont de très mauvaises excuses, comme la mesure de la productivité ou de la complexité d'un logiciel en lignes de code.

Envoyé par MiaowZedong

Un investissement plus régulier en matériel informatique serait donc rentable, voir très rentable.

Bien sur. Il faut des machines fiables, des sauvegardes, les outils nécessaires, un réseau qui marche. Mais je rejoins oldtimecoder sur le fait qu'avoir une machine très différente de celle sur laquelle le programme tournera est assez dangereux.

La réponse usuelle du développeur au compte rendu de bug, c'est "sur ma machine ca marche". De même, sa réponse habituelle au "c'est lent" est "pas chez moi". Et le temps perdu dans ces allers-retours (y'a un bug, mais non, mais si, pas chez moi, ben si...) entraine souvent une perte de productivité bien plus importante que celle liée au démarrage des postes, ou à la recompilation de telle ou telle bibliothèque.

Ce n'est pas une raison pour développer sur des machines pourries, bien sur, mais il me parait utile que le programme tourne chez les développeurs (qui sont les premiers testeurs) à une vitesse comparable à celle des clients.

Et si le problème est le temps de recompilation de l'environnement, il est bien plus efficace d'avoir une machine rapide (hors poste de dev) destinée à cela...

Francois

[sevyc64]

Envoyé par fcharton

Mais je rejoins oldtimecoder sur le fait qu'avoir une machine très différente de celle sur laquelle le programme tournera est assez dangereux.

La réponse usuelle du développeur au compte rendu de bug, c'est "sur ma machine ca marche". De même, sa réponse habituelle au "c'est lent" est "pas chez moi". Et le temps perdu dans ces allers-retours (y'a un bug, mais non, mais si, pas chez moi, ben si...) entraine souvent une perte de productivité bien plus importante que celle liée au démarrage des postes, ou à la recompilation de telle ou telle bibliothèque.

Ce n'est pas une raison pour développer sur des machines pourries, bien sur, mais il me parait utile que le programme tourne chez les développeurs (qui sont les premiers testeurs) à une vitesse comparable à celle des clients.

Et si le problème est le temps de recompilation de l'environnement, il est bien plus efficace d'avoir une machine rapide (hors poste de dev) destinée à cela...

Francois

JE suis entièrement d'accord sur ce point, mais ce que tu dis, au regard de ce qui a déjà été dit, sous entend de ta part, j'imagine qu'il n'ai pas forcément judicieux que le développeur ait des machines surpuissantes alors que les utilisateurs auront des machines moins véloces que lui.

Mais ça marche aussi dans le sens contraire, et j'ai connu le cas. Les machines des utilisateurs, somme toutes classiques et normales se sont révélées plus puissante que les machines des développeurs pas guère moins puissantes mais largement plus surchargées.

Résultat : un bug aléatoire, lié à un problème de synchronisation sur les postes des clients, impossible à reproduire sur les postes des développeurs qui, étant à la peine, avaient le temps de se synchroniser. Le problème n'a réellement été mis en évidence qu'au bout de 6 semaines, lorsque par hasard, un des développeurs en charge du bug a été doté d'une machine toute neuve, un foudre de guerre. Sur cette machine le bug était systématique.

[Aquanum]

Envoyé par fcharton

Et si le problème est le temps de recompilation de l'environnement, il est bien plus efficace d'avoir une machine rapide (hors poste de dev) destinée à cela...

C'est marrant, je suis persuadé de l'inverse. Après je conçois aussi ton point de vue.
Mais si je suis bien les choses, tu préconises de donner des PC moins bien pour que le développeur s'adapte à l'environnement d'exécution. Juste parce que celui-ci peut ne pas envisager certains bugs, ou ne pas bien dimensionner son application pour les machines cibles.

Et pourquoi pas l'inverse alors ? De bons PC de dev et une machine cible pour tester le rendu ?

Comme ça tu te rends comptes des problèmes/erreurs en amont et tu gagnes du temps avec un PC de dev plus puissant.

[el_slapper]

La machine de test doit ressembler le plus possible à la machine de l'utilisateur final. Mais quel test? Le TU, certainement pas : le dev a besoin d'un feedback rapide sur la qualité de ce qu'il vient de pondre. Par contre, en intégration ou en recette, c'est obligatoire. Sinon.....

Quand même, une compilation rapide, c'est très important. Si ça traine, au lieu de bosser, on va sur developpez.net et on écrit des trucs au lieu de bosser. Ah, tiens, ça fait deux minutes que ma compil' vient de finir...

[sevyc64]

Envoyé par el_slapper

Quand même, une compilation rapide, c'est très important. Si ça traine, au lieu de bosser, on va sur developpez.net et on écrit des trucs au lieu de bosser. Ah, tiens, ça fait deux minutes que ma compil' vient de finir...

Nan mais faut être un peu organisé. Les compilations longues, on se débrouille pour les faire au moment du café. Comme ça, si le boss vient te chopper à la machine à café, tu peux lui répondre "Mais non, je bosse là, je compile. Tu veux voir ma machine ?"

[fcharton]

Envoyé par Aquanum

Et pourquoi pas l'inverse alors ? De bons PC de dev et une machine cible pour tester le rendu ?

Parce que ça aboutit à dissocier les tests du développement, et donc à les reporter au moment où on a "une première version qui tourne", soit assez tard. Du coup, le développeur, ayant une mauvaise vision de la réalité utilisateur (par exemple la lenteur de tel ou tel module), a toutes les chances de prendre de mauvaises décisions.

Quand tu développes, tu ne gères pas de la même façon un traitement qui dure quelques dixièmes de secondes, ou quelques secondes, ou une minute. Si, ta machine est rapide, dispose d'une mémoire abondante, et d'accès disques/réseaux très performants, ou si tu développes à partir d'un jeu de données d'essai sans commune mesure avec la réalité, il y a de grandes chances pour que la première version du logiciel soit très décevante pour ceux qui la testeront ou l'utiliseront sur des postes "normaux".

Et si les tests sont séparés du développement, comme tu le suggères, ces problèmes ne seront diagnostiqués et pris en compte que tard dans le développement.

C'est une situation assez courante en pratique, où de nombreux programmes se révèlent atrocement lents lors des tests initiaux. Pour se justifier, les développeurs se cachent souvent derrière "l'optimisation prématurée", mais en fait, ça tient souvent au fait qu'on développe dans un environnement (machine et données) assez irréaliste.

Envoyé par Aquanum

Comme ça tu te rends comptes des problèmes/erreurs en amont et tu gagnes du temps avec un PC de dev plus puissant.

J'avoue ne pas bien voir le gain de temps... Comme tout le monde, j'aime bien avoir un PC puissant, mais le "gain de productivité" qu'il m'apporte est très faible. Ce qui ralentit mon travail, ce n'est pas la vitesse de mon ordinateur, mais celle de mon cerveau...

Francois

[Aquanum]

En effet je comprends. Je réalise que je n'ai jamais été confronté au problème.
Car j'ai toujours travaillé sur des cibles qui ne permettent pas, quoi qu'il en soit, de faire du dev dessus. Donc pour moi de toute façon, le PC de dev sera forcément surdimensionné par rapport à la cible, donc autant avoir un bon PC.

Mais je réalise que ça ne s'applique pas forcément à tous les secteurs et profils.

[el_slapper]

Sur ma mission actuelle, je ne fais que du batch. En gros, si je passe en intégration en 6 heures, ça passe en production en 5 heures. Ca me permet de savoir si je suis consommateur ou pas(sur ce job-là, je le suis), mais franchement, les décalages de performances entre l'intégration et la production n'ont aucun impact pour moi.

[souviron34]

En gros (et ça devient une habitude ) je suis presque 100% d'accord avec fcharton, dans les arguments et la conclusion..

Le dernier gros environnement sur lequel j'ai été, grâce (!!!!!) à C++, Boost, et ses innombrables bibliothèques, le projet au total mettait plus de 4h à builder..

Maintenant, évidemment c'était le build total.. Fait une seule fois par jour, (ou plutôt par nuit)..

Car nous, développeurs, nous nous servions du build précédent.. Et par conséquent cétait purement nos modules qui recompilaient.. Soit plutôt de l'odrre de 2 à 30 secondes..

Franchement, avec la puissance des machines depuis 6 ou 7 ans, peu importe d'avoir la dernière version... Compiler 500 000 lignes de code en 1 minute est quand même on ne peut plus efficace, et ne perd strictement rien en productivité..

Si par contre on n'a pas géré convenablement son projet et qu'on est obligé de tout recompiler à chaque fois, le problème n'est pas la vitesse de la machine mais l'aberration de la structuration du projet..

Comme le dit François, la perte de productivité se passe dans le cerveau : si ce n'était pas le cas, alors les mesures de délais en Points de fonctions seraient exactes, et ça se saurait depuis belle lurette (et n'aménerait pas aux échecs et dépassements répétés)..

Notre travail est créatif, et totalement non linéaire... On peut avoir, sur la même machine, une productivité quasi-nulle pendant des jours, puis une productivité sans doute dix fois plus que la moyenne pendant 4h...

Il serait impensable d'imaginer qu'un compositeur de musique se lève et compose pendant 8h une partition sans interruptions et au même rythme (Mozart mis à part)..

[Nemek]

Envoyé par MiaowZedong

Certes. Cependant, ce matin, redémarrer mon PC m'a pris 10 minutes (c'est un cas assez extrème, avec un virtual desktop qui prend beaucoup trop long à se lancer).

En démarrant mon PC tous les jours, je perds donc environ 3.5 heures par mois; sans compter le temps perdu en lançant mes applications, le temps perdu avec les occasionels plantages...

Tout ça fait une perte de productivité réellement chiffrable et qui doit coûter plus de €1k/personne/an (minimum) à l'entreprise, en temps passé par les salariés à attendre une réponse de leurs PC.

Un investissement plus régulier en matériel informatique serait donc rentable, voir très rentable.

Tu supposes qu'on bosse strictement le nombre d'heure pour lequel on est payé. Je pense qu'en grande majorité, on part quand on a fini. Donc ca ne coute pas plus ou pas moins cher à l'entreprise.
Par contre, un cas où tu peux perdre beaucoup de temps c'est de remonter/récupérer/reconstruire un environnement/espace/données de travail parce que t'as pas assez de place sur ton disque. C'est plus ou moins ce que je vis en ce moment.