Donner à un développeur une machine de développement plus lente se traduit-il par un code plus rapide / plus efficace?
Supposons que je donne à mes développeurs une machine ultra rapide. VS2010 basé sur WPF se charge très rapidement. Le développeur crée ensuite une application WPF ou WPF/e qui fonctionne bien sur sa box, mais beaucoup plus lentement dans le monde réel.
Cette question comporte deux parties ...
1) Si je donne à un développeur une machine plus lente, cela signifie-t-il que le code résultant peut être plus rapide ou plus efficace?
2) Que puis-je faire pour donner à mes développeurs une expérience rapide IDE, tout en offrant des expériences d'exécution "typiques"?
Mise à jour:
Pour mémoire, je prépare ma réponse impartiale à la direction. Ce n'est pas mon idée et vous m'aidez à corriger les demandes erronées de mon client. Merci de m'avoir donné plus de munitions et des références sur où et quand aborder cela. J'ai attribué +1 à des cas d'utilisation valides tels que:
- optimisations de programmation côté serveur spécifiques
- laboratoires de test
- l'achat éventuel d'un meilleur serveur au lieu de cartes graphiques haut de gamme
Absolument
Il est également vrai que les managers doivent mener toutes les réunions en Pig-Latin. Il améliore globalement leurs compétences en communication pour les désavantager lorsqu'ils prononcent des phrases simples. Ils devront s'appuyer davantage sur les expressions faciales et le langage corporel pour faire passer leur message et nous savons tous que c'est de toute façon au moins 70% de toutes les communications.
Les directeurs financiers ne doivent utiliser qu'un abaque et de la craie. Sinon, ils finissent par trop s'appuyer sur des "données brutes" et pas assez sur leur "intuition".
Et les vice-présidents et supérieurs devraient être tenus de tenir toutes les réunions d'affaires importantes dans des environnements distrayants comme les terrains de golf alors qu'ils sont en état d'ébriété. Oh snap ...
La réponse est (je serai en gras et je dirai) toujours
NON .
Développez au mieux avec votre budget et testez la gamme d'équipements min-max sur laquelle vous vous déploierez.
Il y a des émulateurs, des machines virtuelles, des machines réelles avec des testeurs qui peuvent tous tester les performances pour voir si c'est un facteur.
1) Très, très peu probable.Non, et vos développeurs peuvent mettre quelque chose de méchant dans votre café pour l'avoir suggéré. Le temps que vos développeurs passent à attendre que le code soit compilé ou que le IDE fasse ce qu'il fait ou peu importe le temps ne pas dépenser pour améliorer le code. Perturbe également leur flux mental. Gardez leur esprit sur le problème et ils seront beaucoup plus efficaces pour résoudre ce problème.
2) Donnez-leur chacun un deuxième PC représentant les spécifications les plus basses que vous souhaitez qu'ils prennent réellement en charge, avec un commutateur KVM) pour passer de celui-ci à leur véritable poste de travail.
J'aime les longs temps de compilation. Cela me donne plus de temps pour travailler sur mon CV.
C'est une terrible idée. Vous voulez que vos développeurs soient aussi productifs que possible, ce qui signifie de leur donner une machine aussi vite que possible, afin qu'ils ne restent pas assis toute la journée à attendre que les choses se compilent. (Légèrement OT, mais cela aide également à ne pas bloquer leur accès à des sites potentiellement utiles avec WebSense et autres.) Si vous êtes contraint d'avoir des utilisateurs qui utilisent toujours la technologie Stone-Age, alors vous aurez besoin d'avoir une machine de test avec des spécifications similaires, et assurez-vous de tester tôt et souvent pour vous assurer que vous ne vous trompez pas en termes de choix technologiques.
Le développement doit se faire dans le meilleur environnement possible. Les tests doivent être effectués dans le pire environnement possible.
Si on me donnait une machine lente, je passerais ma journée à optimiser le processus de développement et non à optimiser mon code livré. Donc non!
Les programmeurs de systèmes embarqués s'y heurtent tout le temps! Et il y a une solution en deux parties:
- Vos besoins doivent spécifier les performances X sur le matériel Y.
- Testez sur le matériel Y, et lorsque vous n'obtenez pas de performances X, corrigez les bogues.
Peu importe le matériel sur lequel vos développeurs travaillent.
Une fois cela fait, disons qu'un équipement plus rapide peut faire économiser à vos programmeurs une demi-heure par jour, ou 125 heures par an. Et disons qu'ils coûtent 100 000 $ par an avec avantages et frais généraux (ridiculement bas pour la Silicon Valley), ou 50 $ par heure. Ces 125 heures * 50 $/heure sont 6250 $. Donc, si vous dépensez moins de 6250 $ par an en matériel de développement rockin 'par programmeur, vous économisez de l'argent.
C'est ce que vous devez dire à votre direction.
Tim Williscroft a dit à peu près la première moitié de cela dans un commentaire, et dans un monde juste, il obtiendrait la moitié des points obtenus par cette réponse.
Ajouté le 24 octobre:
Mon ex-employeur avait cette théorie, et cela les a aidés à faire chier environ 100 millions de dollars.
Il s'agit d'un conglomérat basé au Japon qui avait l'habitude d'embaucher des programmeurs au Japon, en Corée et en Chine. Les gens sont cool d'utiliser du matériel de développement merdique, des journées de travail de 13 heures, de dormir à leur bureau et de ne pas avoir de vie. Ils ont donc pensé qu'en acquérant une société réputée de la Silicon Valley pour faire un système d'exploitation de téléphone portable basé sur Linux, ces Californiens idiots qui voulaient du matériel moderne n'étaient que des prima-donnas pleurnichards et n'avaient en fait pas de bonnes raisons (comme la productivité).
Quatre ans plus tard, le système d'exploitation fonctionnait comme de la merde, tous les horaires étaient explosés et les clients étaient énervés et mettaient fin aux contrats à droite et à gauche. Enfin, le projet OS a été annulé et un pourcentage important de la main-d'œuvre mondiale du conglomérat a été licencié au cours de l'année écoulée. Et franchement, je ne voudrais pas avoir été l'un des cadres qui a dû expliquer aux actionnaires où tout cet argent et cet effort sont allés.
Ce n'est pas seulement les machines à développement lent qui ont causé ce fiasco. Il y avait beaucoup d'autres erreurs stratégiques et tactiques - mais c'était le même genre de chose où les gens travaillant dans les tranchées pouvaient voir l'épave du train venir, et se demandaient pourquoi les décideurs ne pouvaient pas.
Et la vitesse lente était certainement un facteur. Après tout, si vous êtes sous le coup de livrer à temps, est-ce vraiment une chose intelligente de ralentir délibérément le travail?
Dans la programmation, il y a un vieux dicton qui dit que " l'optimisation prématurée est la racine de tout mal ". Je pense que vous avez réussi à créer avec succès une autre "racine" (ou au moins la première branche) de tout le mal. Désormais, nous pouvons dire que "la désoptimisation prématurée des développeurs est la racine de tout mal".
En bref, la réponse est que cela ne fera que ralentir votre temps de développement et rendre la maintenance plus difficile. La compilation prendra plus de temps, la recherche de code sur le disque sera plus lente, la recherche de réponses en ligne prendra plus de temps et, surtout, les développeurs commenceront à utiliser prématurément l'optimisation de leur code afin même de pouvoir tester les fonctionnalités nécessaires.
Ce dernier point est le problème le plus critique et n'est pas évoqué dans de nombreuses autres réponses. Vous pouvez obtenir votre première version ok, mais lorsque vous souhaitez mettre à jour le code à l'avenir, vous constaterez que l'optimisation prématurée des développeurs a éloigné le focus de votre code d'une bonne conception et l'a poussé plus près de "dois le faire à moins travailler pour garder mon travail "style de code. L'ajout de fonctionnalités supplémentaires deviendra plus difficile car les optimisations choisies à l'époque peuvent être inutiles et verrouiller votre code dans un chemin de hacks semi-optimisés par-dessus d'autres hacks semi-optimisés.
À titre d'exemple, imaginez que la configuration système minimale de votre version actuelle est une machine à processeur unique de vitesse quelque peu lente. Vous placez les développeurs sur cette boîte et ils proposent une solution unique à thread unique qui s'appuie sur de nombreux hacks car ils voulaient développer le produit rapidement. Aujourd'hui, 5 ans plus tard, vous disposez d'une nouvelle version du produit qui requiert au minimum une machine à double processeur. Vous aimeriez pouvoir séparer proprement les parties du programme que vous pouvez exécuter en parallèle, mais la décision que vous avez prise il y a 5 ans qui a forcé vos développeurs à créer un logiciel hacky vous empêche maintenant d'utiliser la pleine puissance de votre nouvelle exigence minimale .
Ce que vous devez faire est d'ajouter une phase à la fin de votre cycle de développement où vous effectuez des tests d'acceptation sur les cases de la borne inférieure. Certes, une partie du code sera trop lente en raison de la machine plus rapide du développeur, mais vous pouvez isoler cette partie et l'optimiser là-bas. Le reste de votre code reste propre et maintenable.
Je vois votre question comme disant: "Puis-je forcer mes développeurs à optimiser tôt en leur donnant des machines de développeur pauvres tout en obtenant un bon code?" Et la réponse est non.
Lecture intéressante, toutes ces réponses.
Mais je pense que la plupart des gens qui répondent ici manquent de raison. La question, telle que je la lis, n'est pas (seulement au moins) de vraiment donner aux développeurs un P1 pour faire du code plus rapide.
Le fait est que beaucoup de logiciels aujourd'hui sont tout aussi lents ou même plus lents que les logiciels informatiques que nous utilisions au cours du dernier millénaire, malgré des ordinateurs beaucoup plus puissants. À en juger par les réponses ici, la plupart des développeurs ne comprennent pas cet indice. Ceci est très évident dans les applications Web. Ce site est une très bonne exception, mais de nombreux sites ont une première page en 1 Mo. Qu'est-ce que j'obtiens en attendant le téléchargement? Je ne sais pas. Je pense qu'il semble s'agir d'une ignorance du développeur ne respectant pas le temps que l'utilisateur doit y consacrer, ou pire encore de payer si vous payez par mb. Le fait est que toutes ces pages Web ne contiennent même pas d'images à haute résolution. Souvent, ce n'est qu'un code de merde fourni par un environnement de développement. Eh bien, bien sûr, ce n'est pas du code de merde, je suppose, mais cela ne me donne aucun gain en tant qu'utilisateur.
En général, il ne s'agit pas seulement d'optimiser le code, mais tout autant de choisir de ne pas inclure plus de ralentissement que ce qu'il donne.
Il y a quelques semaines, j'ai démarré un ordinateur portable à partir de 1995. Windows 3.x était opérationnel en un rien de temps. La base de données dont je devrais obtenir certaines données a commencé avant que la touche entrée ne soit complètement relâchée (presque au moins).
Je sais que nous tirons beaucoup plus de nos logiciels aujourd'hui, mais nous avons également des ordinateurs beaucoup plus rapides. Pourquoi l’industrie du développement ne décide-t-elle pas de maintenir la vitesse des logiciels à partir de 1995 et d’inciter les gens à acheter du nouveau matériel parce qu’ils veulent de nouvelles fonctionnalités. Aujourd'hui, c'est plus comme les programmes quotidiens et les sites Web obligent les gens à acheter du nouveau matériel pour faire exactement les mêmes choses qu'avant. Mais bien sûr d'une manière plus sophistiquée.
Je dois dire que je pense que le développement Linux semble mieux gérer cela. Depuis de nombreuses années, les distributions Linux ont été très en avance sur les fenêtres, même dans l'imagination avec de nombreuses choses comme les fenêtres animées. Le truc, c'est qu'ils ont malgré tout travaillé sur les ordinateurs d'aujourd'hui et même d'hier. Pas seulement sur le matériel de pointe.
À l'heure actuelle, je suppose que de nombreux développeurs ont un niveau d'adrénaline malsain. Oui, j'ai trouvé un moyen de rendre la frustration de toute attente devant:
Office SQL Server (démarrage de la console de gestion) ArcGIS (démarrage et utilisation) Acrobat Reader (démarrage) pages Web .net (téléchargement)
etc
Je me sens bien :-)
À votre santé
Nicklas
1) Si je donne à un développeur une machine plus lente, cela signifie-t-il que le code résultant peut être plus rapide ou plus efficace?
Nous construisons des logiciels depuis 6 décennies et nous avons encore des questions comme celles-ci? Cela ressemble plus à une nouvelle tentative de couper les coins ronds. Aucune infraction, mais allez, pensez-vous que la question est même logique? Pensez-y en ces termes (si vous le pouvez): vous voulez construire un véhicule 4x4 qui peut fonctionner dans des conditions difficiles, pluie, boue, peu importe. Allez-vous mettre vos ingénieurs et votre chaîne de montage sous les éléments juste pour vous assurer que le véhicule résultant peut fonctionner sur eux?
Je veux dire, Jésus-Christ! Il y a du développement et des tests. Les tests sont effectués dans un environnement différent et plus difficile, ou le développeur sait comment assembler un banc d'essai dans son propre environnement de développement d'une manière adaptée aux tests de stress. S'il ne le peut pas, remplacez-le par un meilleur développeur.
2) Que puis-je faire pour donner à mes développeurs une expérience rapide IDE, tout en offrant des expériences d'exécution "typiques"?
Vous devriez demander cela à vos développeurs. Et s'ils ne peuvent pas vous donner une réponse objective et valide, vous devez les remplacer par de vrais développeurs.
Mais pour répondre à la question, donnez à vos développeurs (en supposant que vous avez de bons développeurs), de bons outils et un bon matériel, le meilleur que vous pouvez vous permettre. Configurez ensuite un environnement de base commun le plus bas dans lequel votre logiciel doit fonctionner. C'est où les tests devraient avoir lieu. Il est de bien meilleure pratique d'ingénierie d'avoir un environnement de test distinct de l'environnement de développement (de préférence celui qui vous permet de faire aux tests de résistance.)
Si vos développeurs sont bons, ils auraient dû vous le communiquer (en supposant que vous leur ayez posé la question.)
Il en résulte un tas de développeurs bitchin '. Ce truc est déjà assez dur, n'aggravons pas l'expérience.
Je vous encourage cependant à disposer d'un matériel similaire à celui de vos utilisateurs dans un environnement de test ou d'assurance qualité pour éliminer tout problème de performances. C'est une bonne idée.
Je vais contre la norme et dire oui SI ET SEULEMENT s'ils écrivent un logiciel serveur. Riez tout ce que vous voulez, mais l'équipe la plus efficace que j'ai jamais vue était un groupe de gars de Perl avec des terminaux Wyse. C'était à la fin des années 1990, était un magasin hors-campus de l'Université, et ils écrivaient un logiciel de quadrillage spatial (qui ne fait que calculer). Ils parlaient cependant à des RS/6000 tardifs relativement puissants.
Juste pour ajouter de l'intérêt à l'événement, il y avait un programmeur aveugle. J'étais vraiment impressionné.
Ce n'est pas une mauvaise idée - mais vous voulez que vos développeurs aient un environnement de programmation rapide.
Vous pouvez éventuellement implémenter cela en donnant à vos programmeurs deux machines - une boîte de développement rapide et une boîte de produit plus lente (éventuellement virtuelle) pour les tests.
Quelques ajustements du processus de construction de VS pourraient faire du déploiement dans la boîte de test la norme, avec un débogage à distance.
Il existe d'autres façons d'envisager de forcer vos codeurs à développer un code plus efficace - vous pouvez inclure des objectifs de performances et d'utilisation de la mémoire dans vos tests unitaires, par exemple. La définition de budgets pour l'utilisation de la mémoire est également un excellent objectif. Définition également de budgets de poids de page pour le code html.
Le problème n'est pas que le développeur crée du code inefficace sur une machine rapide, le problème est que vous n'avez pas défini de métriques de performance qui doivent être mesurées.
Il convient de définir, dans le cadre des exigences du produit, un objectif spécifique qui peut être mesuré sur tous les ordinateurs en fonction de l'expérience client requise. Il existe de nombreux sites Web (Check SpecInt) qui vous permettent de relier votre ordinateur à d'autres types d'ordinateurs.
C'est bon pour plusieurs raisons. Il vous permet de définir plus facilement le matériel minimum pris en charge afin que vous puissiez limiter le nombre de plaintes des clients - nous savons tous que la plupart des logiciels s'exécutent sur la plupart des ordinateurs, c'est juste une question de performances - si nous définissons nos spécifications afin que les personnes dans la plage des exigences minimales a des performances raisonnablement acceptables, vous limitez les plaintes des clients - puis lorsqu'un client appelle, vous pouvez utiliser les repères pour déterminer s'il y a vraiment un problème ou si le client n'est tout simplement pas satisfait de la façon dont le produit est censé fonctionner.
Je suis convaincu qu'avoir un ordinateur plus lent pour le développement se traduit par un code plus rapide, mais cela a un prix. La raison en est que j'ai vécu cette expérience de première main: ayant un long temps de trajet, j'ai acheté un netbook pour travailler dans le train, un netbook qui est plus lent que n'importe quel ordinateur que j'ai acheté au cours des 5 dernières années. Parce que tout est si lent, je vois très vite quand quelque chose est insupportablement lent sur ce netbook, et je suis conscient des taches lentes beaucoup plus rapidement (pas besoin de comparer tout le temps). Travailler sur un netbook a vraiment changé la façon dont j'ai développé.
Cela étant dit, je ne préconise pas de le faire, surtout dans un environnement professionnel. Premièrement, c'est démoralisant. Le fait même que presque tout le monde ait dit que l'idée n'avait même pas de sens montre que les programmeurs réagissent mal à l'idée.
Deuxièmement, tout ralentir signifie que les choses que vous voudrez peut-être faire sur une machine rapide (cela prend 1 minute par exemple) ne sont plus vraiment réalisables sur une machine lente, à cause de la paresse, etc ... C'est une question d'incitation.
Enfin: le code produit peut être plus rapide, mais il prend presque certainement plus de temps à produire.
Point 1, NON! Studio est conçu pour être exécuté sur des machines décentes et cette exigence n'a fait que devenir plus puissante avec chaque version. Vous pouvez réellement verrouiller certaines versions de studio si vous activez Intellisense et utilisez une boîte non HT à noyau unique.
Au point n ° 2, certaines fonctionnalités des projets de test vous permettent de limiter certaines ressources. Ils ne sont pas parfaits, mais ils sont là. VPC ou faible spécification VM images pour un bon travail de contrainte également. J'ai eu des utilisateurs assis sur de mauvaises machines pour faire des tests de temps en temps afin qu'ils puissent voir les implications des fonctionnalités qu'ils ont demandé.
Non - en fait, cela entraînerait plus de bugs car ils ne feront pas autant de tests et n'utiliseront pas autant d'outils supplémentaires comme les profileurs. Donnez-leur les meilleures machines que vous pouvez vous permettre (y compris le matériel d'accélération graphique si vous êtes un développeur de jeux ou un magasin de graphisme) et faites-les tester à l'intérieur des machines virtuelles. Les spécifications VM peuvent être augmentées ou réduites au besoin.
Je pense que c'est une question intéressante, et je n'irais pas pour un "non" aussi rapidement. Mon opinion est: cela dépend du type d'équipe en développement dont nous parlons. Exemple: si vous dirigez un groupe en lice pour le concours de programmation annuel ICFP, avoir de bons résultats après un peu de temps de développement sur un cluster HPC ne signifie pas nécessairement que la solution que vous avez trouvée est bonne. La même chose peut être dite si vous écrivez un algorithme scientifique ou numérique: sur votre ancien AMD Duron 600 MHz avec 64 Mo de mémoire, vous êtes obligé de faire attention à la façon dont vous faites avancer les choses, et cela peut affecter même une certaine conception les choix.
D'un autre côté, un programmeur intelligent/scientifique/tout ce qui est censé être prudent de toute façon. Mais je me suis retrouvé à écrire certains de mes meilleurs codes quand je n'avais PAS d'ordinateur AT TOUS et j'ai dû prendre des notes sur papier. Cela peut ne pas s'appliquer aux grands projets impliquant des cadres énormes, lorsqu'un IDE est strictement nécessaire.
Une chose est sûre: des machines rapides et de bons résultats immédiats font que les (mauvais) programmeurs sont gâtés et peuvent être l'une des raisons de certaines conneries que nous trouvons sur les ordinateurs.
Je travaille sur un package qui prend environ une heure pour s'appuyer sur ma machine 8G 8 cœurs (version entièrement propre). J'ai également un ordinateur portable relativement bas de gamme sur lequel je teste. L'ordinateur portable bas de gamme ne gère pas deux versions complètes au cours d'une même journée de travail.
Suis-je plus productif sur la machine rapide avec des tests délibérés effectués sur l'ordinateur portable, ou dois-je faire toutes mes versions sur l'ordinateur portable?
Gardez à l'esprit que ces chiffres ne sont pas composés.
C'est une démo truquée dans la mesure où je n'ai normalement pas besoin de faire un build propre tous les jours (je peux faire beaucoup de tests sur des modules simples), mais même les builds partiels montrent à peu près un ordre de grandeur dans les temps de compilation/liaison .
Donc, le vrai problème est sur ma machine plus lente, une construction typique est assez longue pour moi d'aller chercher une tasse de café, tandis que sur ma machine plus rapide, je ne peux que siroter un peu de café.
Du point de vue du travail, je préfère faire du développement sur une machine rapide. Je peux respecter les délais de manière beaucoup plus fiable. D'un autre côté, j'imagine que si la direction me faisait faire du développement sur ma machine lente, je ferais beaucoup plus de navigation sur le Web, ou du moins de lecture de livres.
Fait intéressant, j'ai travaillé dans une startup où nous avons fini par le faire. Je pense que cela a plutôt bien fonctionné, mais uniquement en raison de la situation spécifique dans laquelle nous nous trouvions. C'était une boutique mod_Perl où le rechargement automatique de classe fonctionnait correctement. Tous les développeurs ont utilisé vim comme leur choix IDE (ou ont utilisé un logiciel d'édition à distance). Le résultat final a été que très peu (voire aucun) de temps a été perdu en attendant que le code soit compilé/rechargé/etc.
Fondamentalement, j'aime cette idée IFF, il y a un impact négligeable sur le cycle de développement pour tous les développeurs, et cela n'impacte que le fonctionnement au moment de l'exécution de votre code. Si votre code est de toute façon compilé, prétraité, etc., alors vous ajoutez du temps à la boucle "correction de bogue; test; prochaine" dans laquelle les développeurs travaillent.
Du côté interpersonnel, les gens n'ont jamais été forcés à utiliser les serveurs lents, mais si vous avez utilisé les serveurs lents, vous n'avez pas eu à faire votre propre maintenance ou configuration. De plus, cette configuration a existé dès le début, je ne peux pas imaginer essayer de vendre cela à une équipe de développement établie.
Après avoir relu votre question initiale, il me semble qu'une chose qui me terrifie perpétuellement, ce sont les environnements de développement qui diffèrent des environnements de production. Pourquoi ne pas utiliser un VM pour l'exécution de code que vous pouvez paralyser pour l'exécution sans affecter la station de travail de développement? Dernièrement, j'utilise/aime VirtualBox.
Je vais inverser la tendance ici aussi.
Anecdote: J'ai travaillé pour une entreprise néerlandaise de développement de logiciels qui a mis à niveau 286 ordinateurs vers 486 es (oui, je suis si vieux). En quelques semaines, les performances de toutes nos bibliothèques internes ont chuté de 50% et les bogues ont augmenté ... Une petite recherche a montré que les gens ne réfléchissaient plus au code lui-même pendant le processus de débogage, mais recouraient à du code successif "rapide" -> compiler -> tester -> corriger (code) etc. cycles.
Connexes: lorsque j'ai commencé une filiale pour cette même entreprise aux États-Unis, j'ai fini par embaucher des programmeurs russes parce qu'ils étaient habitués à des PC avec moins de fonctionnalités/moins de puissance et étaient des codeurs beaucoup plus efficaces.
Je me rends compte que les temps étaient différents et que les ressources étaient beaucoup plus rares qu’aujourd’hui, mais cela ne cesse de me surprendre comment, avec tous les progrès réalisés sur le plan matériel, le résultat net semble être que chaque pas en avant est annulé par une programmation plus bâclée nécessitant des spécifications minimales plus élevées ...
Par conséquent ... Je pense que les programmeurs devraient être obligés de tester leurs applications sur des machines qui ne dépassent pas la puissance de calcul et les spécifications matérielles "Moyenne Joe".
Le matériel est moins coûteux que le temps de développement.
La plupart des goulots d'étranglement se trouvent dans la base de données et non sur le PC client, mais cela n'excuse pas les tests sur des machines plus lentes que le développeur. Utilisez des outils de test pour tester l'optimisation.
Absolument pas. Offrez à vos programmeurs le meilleur ordinateur portable que vous puissiez acheter, un clavier de leur choix, plusieurs grands écrans, un bureau privé, pas de téléphone, des boissons non alcoolisées gratuites, tous les livres qu'ils veulent (qui sont pertinents), des voyages annuels pour des conférences techniques clés et vous obtiendrez d'excellents résultats. Testez ensuite sur les combinaisons matériel/logiciel/navigateur/bande passante des limites supérieure et inférieure.
Pour de nombreuses applications, le problème consiste à amener les développeurs à tester avec des ensembles de données du monde réel avant qu'ils ne soient "terminés". Pour les applications interactives, une machine/VM de test de base serait nécessaire.
Je travaille sur une machine Windows95 lente, et cela me permet d'écrire efficacement l'intelligence artificielle MindForth en Forth et en JavaScript.
C'est une pensée intéressante (donner aux développeurs une machine lente peut les amener à optimiser davantage).
Cependant, la solution est mieux conçue: placez le temps de réponse dans les exigences des programmes et disposez d'une machine bas de gamme pour les tests.
De plus, si vous avez un compilateur/langage vraiment génial, il pourrait être en mesure de concevoir différentes façons de générer du code et de choisir le meilleur. Cela ne serait aidé que par un ordinateur plus rapide.
D'autres ont répondu que, généralement, vous souhaitiez que les développeurs disposent de machines rapides. Je suis d'accord. Ne sautez pas sur RAM - vous voulez autant de mémoire que possible - certains processus de construction sont très lourds sur l'utilisation du disque.
Vous voudrez peut-être vous débarrasser de l'antivirus sur les disques de génération! Cela ne fait que ralentir et peut être un facteur de ralentissement extrêmement fort.
Vous voudrez peut-être laisser les développeurs se développer sur Linux si possible. Les outils y sont bien meilleurs pour toutes sortes de tâches supplémentaires (juste grep pour quelque chose dans un fichier, etc.). Cela supprime également l'antivirus.
Demander aux programmeurs si les programmeurs devraient obtenir un bon matériel, c'est comme demander à un gros homme s'il aime la nourriture. Je sais que c'est l'échange subjectif, mais quand même ... la question mérite-t-elle d'être posée? : P
Cela dit, je suis bien sûr d'accord avec la majorité: NON .
Je suis tenté de dire "non" catégoriquement, mais permettez-moi de partager une expérience récente: quelqu'un sur notre projet travaillait sur un code pour importer des données dans la base de données. À l'époque, il avait le PC le plus ancien de notre groupe, peut-être même toute l'organisation. Cela a bien fonctionné avec VS 2008, mais bien sûr, une machine plus rapide aurait amélioré l'expérience. Quoi qu'il en soit, à un moment donné, le processus qu'il écrivait a été bombardé pendant les tests (et c'est avant qu'il ne soit complet). Il a manqué de mémoire. Le processus a également duré plusieurs heures avant de bombarder. Gardez à l'esprit, à notre connaissance, que les utilisateurs auraient dû l'utiliser.
Il a demandé plus de RAM. Ils ont refusé, car il allait obtenir une machine plus récente dans 3-4 semaines et l'ancienne allait être jetée.
Gardez à l'esprit que la philosophie de ce type sur l'optimisation est: "Nous avons des machines rapides avec beaucoup de RAM" (la sienne et quelques machines exclues, de toute façon), alors pourquoi perdre un temps précieux en programmeur à optimiser? Mais la situation l'a forcé à modifier l'algorithme pour qu'il soit plus efficace en mémoire afin qu'il s'exécute sur sa machine 2 Go (exécutant XP.) Un effet secondaire de la réécriture est que le processus s'est également déroulé beaucoup, beaucoup plus rapidement qu'auparavant. . De plus, la version originale aurait fini par bombarder même avec 4 Go lorsque davantage de données étaient importées - c'était un porc de mémoire, simple et simple.
Soooo ... Alors qu'en général je dirais "Non", c'est un cas où le développeur ayant une machine moins puissante a abouti à un module mieux optimisé, et les utilisateurs en bénéficieront (car ce n'est pas un processus qui doit être exécuté très souvent, il n'avait initialement pas l'intention de l'optimiser dans les deux cas, ils auraient donc été bloqués avec la version d'origine si la machine en avait eu assez RAM pour exécuter quelques gros tests .. .) Je peux voir son point, mais personnellement, je n'aime pas l'idée que les utilisateurs doivent attendre 8 heures pour qu'un processus se termine, alors qu'il peut s'exécuter en une fraction de ce temps.
Cela dit, en règle générale, les programmeurs devraient avoir des machines puissantes car la plupart des développements sont assez intensifs. Cependant, il faut faire très attention à ce que les tests soient effectués sur des machines au "plus petit dénominateur commun" pour s'assurer que le processus ne bombarde pas et que les utilisateurs ne regarderont pas Paint sécher toute la journée. Mais cela a déjà été dit. :)
En lisant la question et les réponses, je suis un peu abasourdi par la véhémence du cas NON.
Je travaille dans le développement de logiciels depuis 25 ans maintenant, et je peux dire sans aucune hésitation que les programmeurs ont besoin de beaucoup de choses pour développer un bon code:
Un environnement de développement RAISONNABLE. Pas un dinosaure. Il n'a pas non plus besoin de saigner Edge. Assez bon pour ne pas être frustrant.
Une bonne spécification (combien est fait sans AUCUNE spécification écrite?)
Bonne gestion et soutien.
Un calendrier de développement raisonnable.
Une bonne compréhension des utilisateurs ET DE L'ENVIRONNEMENT que les utilisateurs auront.
De plus, sur ce dernier point, les développeurs doivent être conscients de ce que les utilisateurs vont utiliser. Si les utilisateurs ont des superordinateurs et effectuent des simulations de fractionnement d'atomes ou quelque chose où les performances coûtent beaucoup d'argent, et les calculs durent de nombreuses heures, alors penser aux performances compte.
Si les utilisateurs ont 286 ordinateurs portables alimentés par Steam, le développement et le fait que les développeurs effectuent leur test de développement sur le dernier Core i9000 à 47 GHz entraîneront des problèmes.
Ceux qui disent "donner aux développeurs le meilleur et le tester" ont en partie raison, mais cela a un gros problème MENTAL pour les développeurs. Ils n'ont aucune appréciation de l'expérience utilisateur jusqu'à ce qu'il soit trop tard - lorsque les tests échouent.
Lorsque les tests échouent - les architectures ont été engagées, la direction a fait des promesses, beaucoup d'argent a été dépensé, puis cela devient un désastre.
Les développeurs doivent penser, comprendre et être dans la zone de l'expérience utilisateur dès le premier jour.
Ceux qui crient "oh non ça ne marche pas comme ça" parlent de ce qu'ils veulent. J'ai vu cela arriver plusieurs fois. La réponse habituelle des développeurs est celle de "bien dire aux CLIENTS d'acheter un meilleur ordinateur", ce qui blâme effectivement le client. Pas assez bon.
Cela signifie donc que vous avez plusieurs problèmes:
Gardez les développeurs heureux et pisse de la direction, augmentez les chances d'échec du projet.
Utilisez des machines plus lentes pour le développement, avec le risque de déranger les développeurs, mais en les concentrant sur ce qui compte vraiment.
Mettez 2 machines sur le bureau des développeurs ET FORCEZ-LES À TESTER SUR LE CLUNKER (ce qu'ils ne feront pas parce que c'est sous le mépris ... mais au moins c'est très clair alors s'il y a des problèmes de performances dans le test).
Vous vous souvenez des systèmes batch et des cartes perforées? Les gens ont attendu une heure ou un jour pour un revirement. Les choses ont été faites.
Vous vous souvenez des anciens systèmes Unix avec des processeurs 5 MHz? Les choses se sont faites.
Les techo-geeks adorent chasser le bord qui saigne. Cela encourage le bricolage, pas la réflexion. Quelque chose sur laquelle j'ai eu des discussions avec plus de développeurs juniors au fil des ans ... quand je les exhorte à éloigner les doigts du clavier et à passer plus de temps à lire le code et à réfléchir.
Dans le développement du code, rien ne remplace la réflexion.
Dans ce cas, mon sentiment est - comprendre ce qui importe vraiment. Succès du projet? Est-ce une entreprise qui fait/tue un exercice? Si c'est le cas, vous ne pouvez pas vous permettre d'échouer. Vous ne pouvez pas vous permettre de dépenser de l'argent sur des choses qui échouent au test. Parce que le test est trop tard dans le cycle de développement, les impacts de l'échec sont trouvés trop tard.
[Un bogue trouvé dans le test coûte environ 10 fois plus à réparer qu'un bogue trouvé par un développeur pendant le développement.
Et un bogue trouvé dans le test coûte environ 100 fois plus à réparer que ce bogue en cours de conception pendant la phase de conception architecturale.]
Si ce n'est pas un casse-tête et que vous avez du temps et de l'argent à graver, utilisez l'environnement de développement Edge qui saigne et subissez les échecs des tests. Sinon, trouvez un autre moyen. Inférieur h/w, ou 2 machines sur chaque bureau.
Mon Macbook Pro au travail a quelques années. Entre Linux et Windows (pour tester IE bizarreries) vms ainsi que quelques navigateurs Web et terminaux ouverts, la roue tournante OSX apparaît beaucoup. Devinez ce que je fais quand il tourne, je m'assois Dans ce cas, une machine lente ralentit la productivité.
Je dis que les développeurs ont besoin du meilleur système de développement disponible - mais cela ne signifie pas nécessairement le plus rapide. Cela peut bien signifier un système moderne mais relativement lent avec un refroidissement entièrement passif, pour réduire le bruit au minimum, par exemple.
Une chose - un système de développement devrait être raisonnablement nouveau et devrait absolument avoir plusieurs cœurs.
Un vieil ordinateur peut sembler attrayant du point de vue de la performance, mais un Pentium 4, par exemple, peut en fait être plus rapide (par cœur) que certaines puces actuelles. Cela signifie qu'en limitant un développeur à l'utilisation d'un système P4 (en fait ce que j'utilise actuellement - bien que ce soit mon problème de budget personnel) ...
- Vous encouragez le développement de logiciels non concurrents qui ne bénéficieront pas des systèmes multicœurs traditionnels actuels.
- Même si un logiciel multithread est développé, les bogues peuvent ne pas être détectés (ou du moins pas remarqués tôt) car les problèmes liés à la concurrence peuvent ne pas apparaître lors des tests sur un système monocœur.
- Les logiciels multithreads peuvent entraîner de graves problèmes de performances qui peuvent empirer avec les processeurs multicœurs. L'une d'entre elles entraînerait un écrasement de la tête de disque (ce qui peut entraîner un accès plus lent à des milliers de fois aux données) lorsque des threads individuels effectuent un accès séquentiel, mais chacun vers une partie différente du disque. Cela peut même disparaître sur les PC plus lents plus anciens, par ex. ayant deux anciens disques de 160 Go au lieu d'un disque de 1 To, ces threads peuvent ne plus se battre pour accéder au même disque.
Il y a aussi des problèmes avec les PC qui sont trop limités pour bien prendre en charge les machines virtuelles - par exemple pour les tests sur plusieurs plates-formes.
La réponse se trouve au milieu.
Avoir une boîte rapide pour exécuter l'environnement de développement (par exemple Eclipse)
Et une autre boîte lente pour tester la sortie. Ceci est particulièrement important pour les applications Web.
Écrans côte à côte, un pour chaque boîte.
Si le code est acceptable sur la boîte de sortie, il sera plus que acceptable pour la plupart des utilisateurs.
Les boîtes de développement rapides rendent les programmeurs paresseux. Par exemple, rechercher un élément dans le DOM à chaque fois que cela est nécessaire. Trouvez-le une fois et mettez en cache le résultat.
Vous remarquerez vraiment la différence sur une boîte lente exécutant IE 6 ....
Cette théorie est simple et obsolète. C'était vrai à l'époque.
Je me souviens avoir passé plus de temps à microoptimiser mes trucs Turbo Pascal sur mon ordinateur pré-Pentium. Cela avait juste un sens avant l'an 2000, beaucoup moins depuis. De nos jours, vous n'optimisez pas pour du matériel vieux de 10 ans. Il suffit de tester le logiciel pour trouver les goulots d'étranglement. Mais comme tout le monde ici agressif, cela ne signifie pas que la productivité du développeur (et donc de l'optimisation) est en corrélation avec la fourniture de matériel obsolète pour le développement.
1) Si je donne à un développeur une machine plus lente, cela signifie-t-il que le code résultant peut être plus rapide ou plus efficace?
Non. Les bons développeurs sont gâtés. S'ils voient qu'ils obtiennent de mauvais outils dans votre entreprise, ils iront travailler ailleurs. (Les bons développeurs ont généralement le choix d'aller ailleurs)
La réponse à cette question n'est-elle pas un "NON" retentissant, indépendamment de celui à qui vous demandez?
Demandez à vos graphistes s'ils devraient recevoir une machine plus lente.
Demandez à vos rédacteurs s'ils choisiraient une machine plus lente que rapide.
Demandez à vos assistants administratifs s'ils préfèrent une machine plus lente ou plus rapide.
Tous diront qu'ils seront plus productifs avec une machine plus rapide.
Je ne peux qu'imaginer l'expérience de profil en utilisant une machine lente. Oui.
En bref. Sûrement pas.
Ayez également au moins 4 Go de RAM afin que vous puissiez avoir 2 Go sur votre machine principale, 1 pour un VM et l'autre 1 pour la mémoire supplémentaire du VM besoins et pour que vous ayez une marge de mémoire.
De plus, deux processeurs sont indispensables, donc si une application verrouille/mange le processeur, le développeur n'a pas besoin de crier-alt-del quelque chose.
Allons à contre-courant ici: OUI. Ou du moins, c'est la sagesse générale de l'industrie depuis des décennies (sauf bien sûr parmi les développeurs, qui se fâchent toujours lorsqu'ils ne sont pas traités comme des rois et obtiennent les derniers gadgets et ordinateurs).
Bien sûr, il y a un moment où la réduction de la machine du développeur va nuire à ses performances de travail, car il devient trop lent pour exécuter les applications dont il a besoin pour faire son travail. Mais ce point est loin d'un ordinateur à 10000 $ + avec 6 Go de RAM, 2 cartes vidéo de 4 Go, une carte son haut de gamme, 4 écrans, etc. etc.
Je n'ai jamais eu de machine haut de gamme au travail, et cela ne m'a jamais ralenti considérablement tant qu'elle était décente (et les quelques vraies machines inférieures aux normes ont été rapidement remplacées lorsque j'ai montré comment elles me ralentissaient).
La vitesse d'exécution sur la machine du développeur est tellement hors de propos, sauf si vous voulez venger ou punir votre développeur pour avoir écrit du code lent et pour avoir ignoré l'environnement de déploiement cible.
En tant que gestionnaire, vous devez vous assurer que les développeurs connaissent l'objectif du projet et toujours s'assurer qu'ils sont sur la bonne voie. À propos du problème de la machine cible dont nous discutons, il pourrait être évité en testant tôt et fréquemment sur une machine lente, pas en leur donnant une machine lente à utiliser et à souffrir.
La vitesse d'exécution lente ralentit également le développement, car la plupart des programmeurs utilisent la méthode de code et de test. Si l'exécution est lente, leur tâche sera également lente.