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

130

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

tours7
la source
20
Peut-être qu’ils testent l’application sur un PC virtuel!
Marc
209
Je suis bouche bée que c'est même une question. Comment cela pourrait-il entraîner autre chose qu'un développement plus lent et un moral médiocre?
Fosco
76
Développer sur l'état de l'art. Testez sur la pire machine que vous puissiez trouver.
Adam
14
Est-ce que nettoyer le sol avec une brosse à dents plutôt qu'avec une vadrouille rend le sol plus propre? Bien sûr, finalement. Un opérateur de vadrouille ne peut pas détecter la saleté à une distance de 150 cm aussi bien qu'un opérateur de brosse à dents à une distance de 30 cm. N'essayez pas avec un grand plancher.
dbkk
13
Note personnelle: ne travaillez jamais pour MakerofThings7
matt b

Réponses:

234

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 ...

Jay Beavers
la source
85
J'ai aimé le sarcasme. +1
Terence Ponce
8
Les vice-présidents et leurs supérieurs font souvent du réseautage pur: le but de la réunion est de jouer au golf en état d'ébriété. Lorsque vous atteignez un très haut niveau, vous pouvez vous enivrer et jouer au golf pendant que vous choisissez les pays à envahir et à qui confier de gros contrats de défense.
Dan Rosenstark
1
Je ne vois pas de sarcasme ici. +1
FinnNk
376

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.

peterchen
la source
10
Je ne peux pas voter plus d'une fois, bien que j'aimerais pouvoir. Je travaille sur un ordinateur vieillissant et le temps qu'il faut à VS2010 pour accomplir certaines tâches (ouvrir le projet, par exemple) peut être assez ennuyeux.
rjzii
108
Pouvez-vous s'il vous plaît faire le non très grand et audacieux?
Dr. Hannibal Lecter
4
Les tests d'acceptation que vous effectuez doivent couvrir les exigences de performance. Il devrait y avoir des exigences de performance. Si vous ne testez pas les performances, vos testeurs sont appelés clients (et vous leur facturez de l'argent).
Tim Williscroft
2
Je suis complètement d'accord. Donner à un développeur des machines plus lentes ne produira pas un meilleur code. Le développeur sera frustré par la machine et aura toujours un malaise en tête. Cela rend le code pire, et ils ne peuvent pas se concentrer beaucoup quand tout reste bloqué. Voir, on aura un IDE comme Eclipse, disons 2 livres pdf, 2 navigateurs Web, un pour le débogage (en cas de développement basé sur le Web), un serveur en cours d'exécution et un lecteur de musique;) Donnez-lui une machine lente et il va t'embrasser au revoir.
1
La réponse non est incorrecte. La bonne réponse est Nooooooooo!
Pekka
70

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.

BlairHippo
la source
J'aime l'idée d'utiliser un KVM avec un ancien PC pour les tests. En fonction du projet, les développeurs peuvent avoir du mal à installer les dernières versions sur la machine lente à chaque nouvelle création.
Al Crowley
4
Une autre chose à considérer est de leur donner un compte sur au moins le deuxième PC qui ne dispose pas de privilèges administratifs.
David Thornley
43

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

Wonko le sain d'esprit
la source
1
hehehe, le plus long sera le mieux!
Newtopian
33

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.

o. Nate
la source
qui ... attend une minute. Si les compilations étaient rapides, cela ne serait plus possible: xkcd.com/303
gbjbaanb
32

Le développement devrait se faire dans le meilleur environnement possible. Les tests doivent être effectués dans le pire environnement possible.

Yevgeniy Brikman
la source
27

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!

utilisateur6015
la source
26

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?

Bob Murphy
la source
+1 voire trente minutes peuvent être une estimation très modeste dans certains milieux.
Justin
20

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.

EntropyFails
la source
"Nous devrions oublier les petites économies, disons environ 97% du temps: l'optimisation prématurée est la racine de tout mal". Lorsque vous concevez quelque chose, réfléchissez bien pendant 2 minutes au 3%.
Keyo
15

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

Nicklas Avén
la source
Cette. Cette. CETTE. Tellement ça. Cela a toujours été ma plus grande frustration avec le logiciel. Les gens passent plus de temps à essayer de faire briller l’interface qu’à se préoccuper de la facilité d’utilisation. Un exemple de ceci est Android vs Blackberry. Android a l'air plus joli et peut faire plus, mais Blackberry est BEAUCOUP plus agréable (et rapide) à utiliser qu'Android, du moins à mon avis.
Kcoppock
1
Je suis tout à fait d'accord avec l'argument selon lequel les logiciels sont maintenant aussi rapides qu'il y a 20 ans pour à peu près les mêmes fonctionnalités. Mais faire en sorte que les développeurs travaillent avec du matériel vieux de 20 ans ne contribuera en rien à résoudre le problème. Si la société qui crée le logiciel n'investit pas dans la convivialité ni dans les tests de performance, le développement sur du matériel plus lent ne fera qu'empirer les choses. C'est un débat complètement différent pour lequel la tête d'un programmeur n'est pas le seul destinataire approprié d'une gifle bien méritée derrière la tête.
Newtopian
10

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).

luis.espinal
la source
1
Nous construisons des logiciels depuis 6 décennies et nous avons toujours des questions comme celles-ci? - J'ai voté pour votre réponse, mais je vous encourage à examiner la question initiale sous un angle différent. En fait, de nombreux gestionnaires ignorent les avantages des machines rapides et puissantes pour leurs développeurs. En gardant cela à l’esprit, la question initiale visait peut-être à dissuader ces gestionnaires de la notion ridicule selon laquelle les machines lentes peuvent en quelque sorte pousser les développeurs à produire du code plus rapide et plus efficace.
Jim G.
1
"2) Que puis-je faire pour donner à 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." Je crois que ceci est un site SE de programmeurs, pas un site SE de gestionnaires. Il demandait aux devs.
Stimpy77
1
"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 pourra les utiliser?" <<< l'amour de l'analogie
stimpy77
6

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.

bigtang
la source
8
Les développeurs cette chienne? Pas question ...
Jé Queue
6

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é.

texte alternatif

Jé Queue
la source
3
Programmeur aveugle? Est-ce que c'est possible?
WernerCD
1
@WernerCD, j'essaie encore à ce jour d'imaginer le pouvoir de l'esprit nécessaire pour garder une trace des lignes de code dans ma tête.
Jé Queue
3
Oui, la plupart d'entre nous écrivons un logiciel serveur ... +1
goodguys_activate
@ MakerOfThings7, donnez-moi plus de matériel de serveur chaque jour que ma machine locale, dépensez l'argent là où il devrait être (mais donnez-moi un grand moniteur :)) Je n'ai aucun problème avec mon Dell Latitude CPx, vieux de 10 ans, qui est un écran pour les gros systèmes de le DC.
Jé Queue
4
Peut-être qu'un programmeur aveugle pourrait utiliser un afficheur braille?
Antsan
5

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.

damien
la source
5

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.

Mike Glasspool
la source
5

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.

David Cournapeau
la source
+1 Mais je dois être en désaccord sur certains points. J'ai aussi acheté un netbook, mais j'ai remarqué que la vitesse n'était pas le vrai problème, mais la petite taille de l'écran. 1 GHz est assez rapide pour les petits projets en déplacement, mais 1024x600 est tout simplement trop petit.
Joe D
4

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.

Facture
la source
4

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.

JohnL
la source
+1: en fait, cela engendrerait plus de bugs car ils ne feraient pas autant de tests et utiliseraient moins d'outils supplémentaires tels que les profileurs. - Excellent point. N'oublions pas le coût d'opportunité associé à une machine à développement lent.
Jim G.
4

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.

Lorenzo Stella
la source
5
Dis-moi quoi - achète un très bon ordinateur, et
j'échangerai
4

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.

Rayures
la source
De manière générale, en quoi consiste votre construction pour la faire durer aussi longtemps? Est-ce lié au processeur ou au disque (quel est le goulot d'étranglement) Serait-ce un problème si quelque chose comme TFS a été construit pour vous?
goodguys_activate
1
Cela vous prend une demi-journée de travail pour prendre une tasse de café? Vous devez travailler pour le gouvernement.
finnw
I / O lié sur la machine lente. Toujours des entrées / sorties liées parfois sur la machine rapide, mais davantage de goulot d'étranglement de la CPU. Le système de construction actuel n'aime pas travailler sur plus d'une librairie à la fois. Il reste donc de la CPU et des E / S lorsqu'il reste moins de 8 fichiers à compiler dans un sous-projet donné. En ce qui concerne le café, je pourrais le boire plus rapidement, mais j'essaie de limiter ma consommation, donc si je le buvais plus rapidement, il me faudrait une autre activité de temps mort.
Stripes
3

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.

utilisateur6041
la source
3

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».

John SMythe
la source
7
La clé ici est "test", le système live n'a pas besoin de charger un IDE gonflé, d'exécuter le back-end localement plutôt que sur du matériel dédié, d'exécuter le courrier, le bureau, etc. Vous avez besoin d'une machine haut de gamme juste pour environnement dans la plupart des langues aujourd'hui.
Bill Leeper
3

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.

Brian
la source
3

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.

addictedtoswdev
la source
2

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.

Paul Nathan
la source
2

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.

utilisateur1249
la source
N'oubliez pas les avantages d'un disque dur rapide: codinghorror.com/blog/2009/10/…
Jim G.
2

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é.

Thierry Lam
la source
2

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.

utilisateur6043
la source
2

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

Mentifex
la source
2

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 .

Matthew Read
la source