Donner à un développeur une machine de développement plus lente donne-t-il un code plus rapide / plus efficace? [fermé]

Supposons que je donne à mes développeurs une machine à crier rapide. Le VS2010 basé sur WPF se charge très rapidement. Le développeur crée ensuite une application WPF ou WPF / e qui fonctionne correctement sur son ordinateur, mais beaucoup plus lentement dans le monde réel.

Cette question a 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 offrir à mes développeurs une expérience IDE rapide, 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 me donner plus de munitions et de références où et quand aborder cela. J'ai utilisé des cas d'utilisation valables, tels que:
- des optimisations de programmation spécifiques côté serveur
- des laboratoires de test
- l'achat éventuel d'un meilleur serveur au lieu d'une carte graphique haut de gamme

Absolument

Il est également vrai que les gestionnaires devraient organiser toutes les réunions en cochon latin. Cela améliore globalement leurs compétences en communication, ce qui les désavantage quand on leur dit des phrases simples. Ils devront compter davantage sur les expressions faciales et le langage corporel pour faire passer leur message et nous savons tous que cela représente au moins 70% de toutes les communications.

Les CFO doivent utiliser uniquement un boulier et une craie. Sinon, ils finissent par trop se fier aux «données brutes» et pas assez à leur «instinct».

Et les vice-présidents et les supérieurs devraient être tenus de tenir toutes les réunions d’affaires importantes dans des lieux distrayants, tels que les terrains de golf, tout en étant légèrement intoxiqués. Oh snap ...

La réponse est (je serai audacieux et dis) toujours

NO .

Développez le meilleur de votre budget et testez-le avec la gamme d'équipements min-max que vous utiliserez.

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 le suggérer. Attendez que vos développeurs attendent que le code soit compilé ou que l'EDI fasse ce qu'il fait ou peu importe le temps qu'il ne consacre pas à l' amélioration du code. Perturbe leur flux mental, aussi. 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 réellement prendre en charge, avec un commutateur KVM allant de celui à leur poste de travail réel.

J'aime les longs temps de compilation. Cela me donne plus de temps pour travailler sur mon CV.

C'est une idée terrible. Vous voulez que vos développeurs soient aussi productifs que possible, ce qui signifie qu'ils doivent disposer d'une machine aussi rapide que possible, afin qu'ils ne restent pas toute la journée à attendre que les tâches soient compilées. (Légèrement OT, mais cela aide également à ne pas bloquer leur accès à des sites potentiellement utiles avec WebSense, etc.). Si vous êtes contraint par le fait que des utilisateurs utilisent encore la technologie Stone-Age, il vous faudra alors 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 de choix en matière de choix technologiques.

Le développement devrait 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 fourni. Donc non!

Les programmeurs de systèmes embarqués sont confrontés à cela tout le temps! Et il y a une solution en deux parties:

1. Vos exigences doivent spécifier les performances X sur le matériel Y.
2. Testez sur le matériel Y et, lorsque vous n'obtenez pas les performances X, des bogues de fichiers.

Dans ce cas, le matériel sur lequel travaillent vos développeurs n'aura pas d'importance.

Une fois que cela est fait, disons qu'un équipement plus rapide peut permettre à vos programmeurs d'économiser une demi-heure par jour, ou 125 heures par an. Et disons qu'ils coûtent 100 000 dollars par an avec des avantages et des frais généraux (ridiculement bas pour la Silicon Valley), ou 50 dollars de l'heure. Que 125 heures * 50 $ / heure soit 6250 $. Ainsi, si vous dépensez moins de 6 250 dollars par an en matériel de développement époustouflant par programmeur, vous réalisez des économies.

C'est ce que vous devriez dire à votre direction.

Tim Williscroft a à peu près dit la première moitié de ceci dans un commentaire, et dans un monde juste, il obtiendrait la moitié des points de cette réponse.

Ajouté le 24 octobre:

Mon ex-employeur avait cette théorie et cela les a aidés à dépenser environ 100 millions de dollars.

Ce conglomérat basé au Japon avait l'habitude d'embaucher des programmeurs au Japon, en Corée et en Chine. Les gens là-bas sont cool avec l'utilisation de matériel de développement de merde, de 13 heures de travail, de dormir à leur bureau et de ne pas avoir de vie. Ils ont donc pensé que lorsqu'ils ont acquis une société renommée de la Silicon Valley pour créer un système d'exploitation de téléphone portable basé sur Linux, ces californiens ridicules qui recherchaient du matériel moderne étaient simplement des prima-donnas sournoises et n'avaient pas de raison valable (comme la productivité).

Quatre ans plus tard, le système d'exploitation fonctionnait comme une merde, tous les horaires ont été supprimés, les clients en ont marre et les contrats ont été résiliés à 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é mis à pied au cours de la dernière année. Et franchement, je ne voudrais pas être l’un des cadres qui a dû expliquer aux actionnaires où tout cet argent et ces efforts ont été investis.

Ce fiasco n'a pas été causé uniquement par les machines à développement lent. Il y avait beaucoup d'autres gaffes stratégiques et tactiques - mais c'était le même genre de chose où les personnes travaillant dans les tranchées pouvaient voir le naufrage du train et se demander pourquoi les décideurs ne le pouvaient pas.

Et la vitesse lente était certainement un facteur. Après tout, si vous êtes prêt à livrer à temps, est-ce vraiment une bonne chose de ralentir délibérément le travail?

En programmation, il existe un vieil adage selon lequel "l' optimisation prématurée est la racine de tout mal ". Je pense que vous avez réussi à créer une autre "racine" (ou au moins une première branche) de tous les maux. Désormais, on peut dire que "la déoptimisation 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 ultérieure plus difficile. Les temps de compilation prendront plus de temps, la recherche de code sur disque sera plus lente, la recherche de réponses en ligne sera plus longue 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 la question la plus critique et n’est pas abordé dans de nombreuses autres réponses. Vous pouvez obtenir votre première version, mais si vous souhaitez mettre à jour le code ultérieurement, vous constaterez que l'optimisation prématurée des développeurs a détourné l'attention de votre code de la bonne conception et l'a poussé plus près de moins de travail pour garder mon travail "style de code. L'ajout de fonctionnalités supplémentaires deviendra plus difficile car les optimisations choisies à l'époque risquent d'être inutiles et de verrouiller votre code dans un chemin de hacks semi-optimisés par-dessus d'autres hacks semi-optimisés.

A titre d'exemple, imaginez que la configuration système minimale requise par votre version actuelle soit une machine à un seul processeur à vitesse plutôt lente. Vous placez les développeurs sur cette boîte et ils proposent une solution complexe à thread unique qui repose sur de nombreuses piratages, car ils souhaitaient développer le produit rapidement. Cinq ans plus tard, vous disposez d’une nouvelle version du produit qui requiert au minimum une machine à deux processeurs. Vous voudriez 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 et qui a forcé vos développeurs à créer un logiciel hacky vous empêche maintenant d'utiliser toute la puissance de votre nouvelle exigence minimale. .

Ce que vous devez faire est d’ajouter une phase à la fin de votre cycle de développement dans laquelle vous effectuez des tests d’acceptation sur les champs inférieurs. Certes, une partie du code sera trop lente à cause de la machine plus rapide du développeur, mais vous pouvez isoler cette partie et l’optimiser. Le reste de votre code reste propre et maintenable.

Je vois dans votre question: "Puis-je forcer mes développeurs à optimiser au plus tôt en leur fournissant des machines de développement médiocres 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 le point. La question, telle que je la lis, n’est pas (au moins) de vraiment donner aux développeurs un P1 pour rendre le code plus rapide.

Le fait est qu’aujourd’hui, beaucoup de logiciels sont tout aussi lents, voire plus lents, que les logiciels autonomes que nous utilisions au dernier millénaire en dépit d’ordinateurs beaucoup plus puissants. À en juger par les réponses fournies 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 page de couverture dans 1 mb. Qu'est-ce que je reçois pour attendre que cela soit téléchargé? Je ne sais pas. Je pense qu'il semble s'agir d'une ignorance de la part du développeur qui ne respecte pas le temps que l'utilisateur doit consacrer à cette tâche, ou même pire, 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, il s’agit simplement d’un code de merde provenant d’un environnement de développement. Bien sûr, ce n'est pas du code merde je suppose, mais cela ne me donne aucun avantage en tant qu'utilisateur.

En général, il ne s’agit pas uniquement d’optimiser le code, mais bien d’avoir choisi 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 sur laquelle je devrais obtenir des données a commencé avant que la touche Entrée ne soit entièrement libérée (presque au moins).

Je sais que nos logiciels nous apportent beaucoup plus, mais nous avons également des ordinateurs beaucoup plus rapidement. Pourquoi l’industrie du développement ne décide-t-elle pas de conserver la vitesse des logiciels à partir de 1995 et d’obliger les utilisateurs à acheter du nouveau matériel, car ils veulent de nouvelles fonctionnalités. Aujourd’hui, c’est plutôt comme si les programmes quotidiens et les sites Web obligeaient les utilisateurs à acheter du nouveau matériel pour faire exactement les mêmes choses qu’auparavant. Mais bien sûr d'une manière plus sophistiquée.

Je dois dire que je pense que le développement de Linux semble mieux gérer cela. Depuis de nombreuses années, les distributions Linux sont très en avance sur Windows, même fantaisistes, avec de nombreuses choses loufoques comme des fenêtres animées. Le fait est qu’ils ont malgré cela travaillé sur les ordinateurs d’aujourd’hui et même d’hier. Pas seulement sur le matériel de pointe.

Maintenant, je suppose que beaucoup de développeurs ont un niveau d'adrénaline malsain. Oui, j’ai trouvé un moyen de dissiper un peu de frustration de la part de tous ceux qui attendaient devant:
serveur SQL Server (démarrage de la console de gestion) arcgis (démarrage et utilisation) acrobat reader (démarrage) agresso (utilisation, au moins comme application Web) windows (regarder et utiliser, eh bien, je n'ai pas encore essayé 7) pages web .net (téléchargement)

etc

Je me sens bien :-)

A bientôt
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 toujours des questions comme celles-ci? Cela ressemble plus à une autre 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 capable de fonctionner dans des conditions difficiles, sous la pluie, dans la boue, peu importe. Allez-vous placer vos ingénieurs et votre chaîne de montage sous les éléments pour vous assurer que le véhicule qui en résulte peut les utiliser?

Je veux dire, Jésus Christ! Il y a du développement et il y a des tests. Les tests sont effectués dans un environnement différent, plus sévère, ou le développeur sait comment assembler un banc d'essai dans son propre environnement de développement de manière appropriée pour les tests de contrainte. S'il ne peut pas, remplacez-le par un meilleur développeur.

2) Que puis-je faire pour offrir à mes développeurs une expérience IDE rapide, 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 valable, vous devez les remplacer par des développeurs réels.

Mais pour répondre à la question, donnez à vos développeurs (en supposant que vous ayez de bons développeurs), de bons outils et du bon matériel, au mieux de vos moyens. Ensuite, configurez un environnement de base commun le plus bas dans lequel votre logiciel doit fonctionner. C'est là que les tests devraient avoir lieu. Il est bien plus pratique en matière d'ingénierie de disposer d'un environnement de test distinct de l'environnement de développement (de préférence un environnement permettant d'effectuer des tests de résistance).

Si vos développeurs sont bons, ils auraient dû vous en informer (en supposant que vous les leur demandiez).

Il en résulte un tas de développeurs Bitchin '. Ce truc est déjà assez dur, ne rendons pas l'expérience pire.

Toutefois, je vous encourage à utiliser un matériel similaire à celui de vos utilisateurs dans un environnement de test ou d’assurance qualité afin de résoudre tous les problèmes de performances. C'est une bonne idée.

Je vais éviter 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 dotés de terminaux Wyse. C'était à la fin des années 1990, c'était un magasin de l'université, et ils étaient en train d'écrire un logiciel de maillage spatial (qui ne fait que calculer). Cependant, ils discutaient avec des RS / 6000 relativement récents et relativement puissants.

Juste pour ajouter de l'intérêt à l'événement, il y avait un programmeur aveugle. J'ai été très impressionné.

Ce n'est pas une mauvaise idée, mais vous souhaitez que vos développeurs disposent d'un environnement de programmation rapide.

Vous pouvez éventuellement implémenter ceci en donnant à vos programmeurs deux machines: une boîte de développement rapide et une boîte de produit plus lente (éventuellement virtuelle) à tester.

Certains ajustements du processus de construction du VS pourraient faire du déploiement dans la zone de test la norme, avec le débogage à distance.

Il existe d'autres moyens 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. L'établissement de budgets pour l'utilisation de la mémoire est également un excellent objectif. Définir également des budgets d’épaisseur de page pour le code HTML.

Le problème n’est pas que le développeur construise du code inefficace sur une machine rapide, c’est que vous n’avez pas défini de métrique de performance à laquelle il faut mesurer.

Dans le cadre des exigences du produit, il convient de définir une cible spécifique pouvant être mesurée sur tous les ordinateurs en fonction de l'expérience client requise. De nombreux sites Web (Check SpecInt) vous permettent d'établir un lien entre votre ordinateur et 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, de sorte que vous puissiez limiter le nombre de plaintes de clients. Nous savons tous que la plupart des logiciels fonctionnent sur la plupart des ordinateurs, c'est simplement une question de performance. Si nous définissons nos spécifications de manière à ce que les utilisateurs disposant de la configuration minimale requise a des performances raisonnablement acceptables, vous limitez les plaintes des clients - et puis, lorsqu'un client appelle, vous pouvez utiliser les tests de performance pour déterminer s'il existe réellement un problème ou si le client n'est tout simplement pas satisfait de la manière dont le produit est censé fonctionner.

Je suis convaincu qu'avoir un ordinateur plus lent pour le développement entraîne un code plus rapide, mais cela a un prix. La raison en est que j'ai vécu cette expérience directe: avec un long temps de trajet, j'ai acheté un netbook pour travailler dans le train, netbook 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 au courant des points lents beaucoup plus rapidement (pas besoin de mesurer tout le temps). Travailler sur un netbook a vraiment changé mon développement.

Cela étant dit, je ne préconise pas cela, surtout dans un environnement professionnel. Premièrement, c'est démoralisant. Le fait même que presque tout le monde a dit que l'idée n'avait pas de sens montre que les programmeurs réagissent mal à cette idée.

Deuxièmement, tout ralentir signifie que les choses que vous voudrez peut-être faire sur une machine rapide (prend environ une minute) 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 est peut-être plus rapide, mais sa production est certainement plus longue.

Point 1, NON! Studio est conçu pour être exécuté sur des machines décentes et cette exigence n’est que plus puissante avec chaque version. Vous pouvez réellement verrouiller certaines versions de studio si vous activez intellisense et utilisez une seule boîte non HT.

Au point 2, certaines fonctionnalités des projets de test vous permettent de limiter certaines ressources. Ils ne sont pas parfaits, mais ils sont là. Les images de VPC ou de machine virtuelle de faible spécification sont également assez contraignantes. Des utilisateurs se sont assis devant de mauvaises machines pour effectuer des tests occasionnels afin de pouvoir voir les implications des fonctionnalités qu'ils avaient demandées.

Non, en fait, cela engendrerait plus de bugs, car ils ne feront pas autant de tests et utiliseront moins d'outils supplémentaires, tels que des profileurs. Donnez-leur les meilleures machines que vous pouvez vous permettre (y compris le matériel d'accélération graphique si vous développez des jeux ou développez des graphismes) et faites-les tester à l'intérieur de machines virtuelles. Les spécifications de la VM peuvent être augmentées ou réduites selon les besoins.

Je pense que cette question est intéressante et que je ne choisirais pas un "non" aussi rapidement. Mon opinion est la suivante: cela dépend du type d’équipe de développement dont nous parlons. Exemple: si vous dirigez un groupe participant au concours annuel de programmation ICFP, obtenir de bons résultats après un temps de développement réduit sur un cluster HPC ne signifierait 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 devez faire attention à la façon dont vous procédez, et cela peut même affecter la conception les choix.

D'autre part, un programmeur / scientifique intelligent / tout ce qui est censé faire attention de toute façon. Mais je me suis retrouvé à écrire certains de mes meilleurs codes alors que je n'avais AUCUN ordinateur et que je devais 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 gâchent les (mauvais) programmeurs et sont peut-être l’une des raisons de la merde que nous trouvons sur les ordinateurs.

Je travaille sur un package qui prend environ une heure pour construire sur ma machine 8G 8 core (construction totalement propre). J'ai aussi un ordinateur portable relativement bas 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 sur l'ordinateur portable, ou devrais-je faire toutes mes constructions sur l'ordinateur portable?

Gardez à l'esprit que ces chiffres ne sont pas inventés.

Il s’agit d’une démo truquée dans la mesure où je n’ai normalement pas besoin de faire une construction propre tous les jours (je peux faire beaucoup de tests sur des modules simples), mais même les versions partielles montrent à peu près une différence d’un ordre de grandeur dans les temps de compilation / liaison. .

Donc, le vrai problème, c'est que sur ma machine plus lente, la composition habituelle est assez longue pour aller me chercher une tasse de café, alors que sur ma machine plus rapide, je ne peux siroter qu'un peu de café.

Du point de vue du travail effectué, je préfère développer sur une machine rapide. Je peux respecter les délais de manière beaucoup plus fiable. D'autre part, j'imagine que si la direction m'avait fait développer sur ma machine lente, la navigation sur le Web serait beaucoup plus importante, ou du moins la 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 un magasin mod_perl dans lequel le rechargement automatique de classes fonctionnait correctement. Tous les développeurs ont utilisé vim comme choix de développement (ou ont utilisé un logiciel d’édition distant). Le résultat final était que très peu de temps (le cas échéant) était perdu à attendre que le code soit compilé / rechargé / etc.

En gros, j'aime bien cette idée IFF: l'impact sur le cycle de développement de tous les développeurs est négligeable, il ne concerne que le fonctionnement de votre code à l'exécution. Si votre code est de toute façon compilé, prétraité, etc., vous ajoutez du temps pour la boucle "correction du bogue; test; prochaine" dans laquelle les développeurs travaillent.

Sur le plan interpersonnel, les personnes n’ont jamais été forcées d’utiliser les serveurs lents, mais si vous utilisiez des serveurs lents, vous n’êtes pas tenu de procéder à votre propre maintenance ou à votre propre installation. En outre, cette configuration existait depuis le début, je ne peux pas imaginer essayer de la vendre à une équipe de développement établie.

Après avoir relu votre question initiale, il m'est apparu que les environnements de développement qui diffèrent des environnements de production me terrifient constamment. Pourquoi ne pas utiliser une machine virtuelle pour l'exécution de code que vous pouvez paralyser pour l'exécution sans affecter le poste de travail dev? Dernièrement, j'utilise / aime VirtualBox.

Je vais renverser la tendance ici aussi.

Anecdote: J'ai travaillé pour une société de développement de logiciels néerlandaise qui a mis à niveau 286 ordinateurs en 486 (oui, je suis aussi vieux que ça). En quelques semaines, les performances de toutes nos bibliothèques internes ont chuté de 50% et le nombre de bogues a augmenté. Un peu de recherche a montré que les utilisateurs ne pensaient plus au code lui-même pendant le processus de débogage, mais avaient recours au code "rapide" successif -> compiler -> tester -> fixer (code) etc. cycles.

À propos: quand j'ai créé une filiale pour cette même société aux États-Unis, j'ai fini par embaucher des programmeurs russes, car ils étaient habitués aux PC dotés de moins de fonctionnalités / moins de puissance et de codeurs beaucoup plus efficaces.

Je me rends compte que les temps étaient différents et que les ressources étaient bien plus rares qu'aujourd'hui, mais cela ne cesse de m'étonner de constater qu'avec tous les progrès réalisés sur le plan matériel, le résultat final semble être que chaque pas en avant est nié par une programmation plus bâclée exigeant des spécifications minimales plus élevées ...

Par conséquent, j'estime que les programmeurs devraient être contraints de tester leurs applications sur des machines ne dépassant pas les spécifications matérielles et de puissance de calcul de «Joe moyen».

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, pas dans le PC client, mais cela n'excuse pas les tests sur des ordinateurs plus lents que le développeur. Utilisez des outils de test pour tester l'optimisation.

Absolument pas. Donnez à vos programmeurs le meilleur prix sur un ordinateur portable, un clavier de leur choix, plusieurs écrans géants, un bureau privé, aucun téléphone, des boissons non alcoolisées gratuites, tous les livres qu’ils désirent (qui sont pertinents), des voyages annuels pour des conférences techniques et des conférences clés. vous obtiendrez d'excellents résultats. Ensuite, testez les combinaisons matérielle / logicielle / navigateur / largeur de bande et limites supérieures et inférieures.

C'est une pensée intéressante (donner aux développeurs une machine lente peut les amener à optimiser davantage).

Cependant, la solution est mieux structurée: insérez le temps de réponse dans les exigences des programmes et disposez d'un ordinateur bas de gamme pour les tests.

En outre, si vous avez un compilateur / langage vraiment génial, il pourra peut-être trouver différentes manières 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 qu'en général, vous souhaitiez que les développeurs disposent de machines rapides. Je suis d'accord. Ne sautez pas sur la RAM - vous voulez avoir autant de mémoire que vous le pouvez - certains processus de construction sont très gourmands en utilisation de disque.

Les choses que vous voudrez peut-être envisager de supprimer sont les antivirus sur les lecteurs de build! 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 disponibles sont bien meilleurs pour toutes sortes de tâches supplémentaires (juste grep pour quelque chose dans un fichier, etc.). Cela permet également de se débarrasser de l'antivirus.

Mon Macbook Pro au travail a quelques années. Entre Linux et Windows (pour tester les bizarreries dans IE), vms, ainsi que quelques navigateurs Web et terminaux ouverts, la roue droite OSX est très présente. Devinez ce que je fais quand ça tourne, je m'assieds et j'attends. Dans ce cas, une machine lente ralentit la productivité.

Pour de nombreuses applications, le problème est de faire tester les développeurs avec des ensembles de données du monde réel avant qu'ils ne soient "terminés". Pour les applications interactives, une machine / machine de test de base serait requise.

Je travaille sur une machine Windows 95 lente, ce qui me permet efficacement d’écrire l’intelligence artificielle MindForth en Forth et en JavaScript.

Demander aux programmeurs si les programmeurs devraient avoir du bon matériel revient à demander à un homme gros s'il aime la nourriture. Je sais que c’est un é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 .