Führt die langsamere Entwicklung eines Entwicklers zu einem schnelleren / effizienteren Code? [geschlossen]

130

Angenommen, ich gebe meinen Entwicklern eine schreiend schnelle Maschine. WPF-basiertes VS2010 wird sehr schnell geladen. Der Entwickler erstellt dann eine WPF- oder WPF / e-Anwendung, die auf seiner Box einwandfrei läuft, in der realen Welt jedoch viel langsamer.

Diese Frage besteht aus zwei Teilen ...

1) Wenn ich einem Entwickler eine langsamere Maschine zur Verfügung stelle, kann der resultierende Code dann schneller oder effizienter sein?

2) Was kann ich tun, um meinen Entwicklern eine schnelle IDE-Erfahrung zu bieten, während ich "typische" Laufzeiterfahrungen gebe?

Aktualisieren:

Um es festzuhalten, ich bereite meine gerechte Reaktion auf das Management vor. Dies ist nicht meine Idee, und Sie helfen mir, die fehlgeleiteten Anfragen meines Kunden zu korrigieren. Vielen Dank, dass Sie mir mehr Munition gegeben haben, und Hinweise darauf, wo und wann Sie sich dem nähern sollten. Ich habe + 1 gültige Anwendungsfälle wie:
- spezifische serverseitige Programmieroptimierungen
- Testlabors
- den Kauf eines möglicherweise besseren Servers anstelle von erstklassigen Grafikkarten

makerofthings7
quelle
20
Vielleicht lassen sie die Anwendung in einem virtuellen PC testen!
Mark C
209
Ich bin sprachlos, dass dies sogar eine Frage ist. Wie könnte es zu etwas anderem als langsamerer Entwicklung und schlechter Moral kommen?
Fosco
76
Entwickeln Sie sich auf dem neuesten Stand der Technik. Testen Sie die schlechteste Maschine, die Sie finden können.
Adam
14
Führt die Reinigung des Bodens mit einer Zahnbürste anstelle eines Wischmopps zu einem saubereren Boden? Sicher, irgendwann. Ein Mop-Bediener kann den Schmutz aus einer Entfernung von 150 cm nicht so gut erkennen wie ein Zahnbürsten-Bediener aus einer Entfernung von 30 cm. Versuchen Sie es nicht mit einem großen Boden.
dbkk
13
Notiz an mich selbst: Arbeite niemals für MakerofThings7
matt b

Antworten:

234

Absolut

Es ist auch richtig, dass Manager alle Besprechungen in Pig-Latin durchführen sollten. Es verbessert ihre Kommunikationsfähigkeiten insgesamt, wenn sie beim Sprechen einfacher Sätze benachteiligt werden. Sie werden sich mehr auf Mimik und Körpersprache verlassen müssen, um ihren Standpunkt zu verdeutlichen, und wir alle wissen, dass dies sowieso mindestens 70% der gesamten Kommunikation ausmacht.

CFOs sollten nur einen Abakus und Kreide verwenden. Andernfalls verlassen sie sich zu sehr auf "Rohdaten" und nicht genug auf ihr "Bauchgefühl".

Vizepräsidenten und höher sollten verpflichtet werden, alle wichtigen Geschäftstreffen in unangenehmen Umgebungen wie Golfplätzen abzuhalten, während sie halb berauscht sind. Oh Schnappschuss ...

Jay Beavers
quelle
85
Ich mochte den Sarkasmus. +1
Terence Ponce
8
Vizepräsidenten und höhere Unternehmen pflegen oft ein reines Networking: Der Sinn des Treffens besteht darin, betrunken Golf zu spielen. Wenn Sie ein wirklich hohes Niveau erreichen, können Sie sich berauschen und Golf spielen, während Sie die Länder auswählen, in die Sie einmarschieren möchten, und denen Sie Verträge zur Fettabwehr geben können.
Dan Rosenstark
1
Ich sehe hier keinen Sarkasmus. +1
FinnNk
376

Die Antwort ist (ich werde kühn sein und sagen) immer

NO .

Entwickeln Sie das Beste, was Sie mit Ihrem Budget erreichen können, und testen Sie das Min-Max-Spektrum der Geräte, für die Sie die Bereitstellung durchführen.

Es gibt Emulatoren, virtuelle Maschinen und tatsächliche Maschinen mit Testern, die die Leistung testen können, um festzustellen, ob dies ein Faktor ist.

peterchen
quelle
10
Kann nicht mehr als einmal abstimmen, obwohl ich wünschte, ich könnte. Ich habe einen veralteten Computer, an dem ich arbeite, und die Zeit, die VS2010 benötigt, um einige Aufgaben auszuführen (z. B. das Projekt zu öffnen), kann ziemlich lästig sein.
rjzii
108
Kannst du das bitte nicht sehr groß und fett machen?
Dr. Hannibal Lecter
4
Die von Ihnen durchgeführten Abnahmetests sollten die Leistungsanforderungen abdecken. Es sollte Leistungsanforderungen geben. Wenn Sie die Leistung nicht testen, werden Ihre Tester Kunden genannt (und Sie berechnen ihnen Geld).
Tim Williscroft
2
Ich stimme vollkommen zu. Wenn Sie einen Entwickler langsamer machen, wird kein besserer Code erzeugt. Der Entwickler wird mit der Maschine frustriert und hat immer ein wenig Unbehagen im Kopf. Das macht den Code schlechter und sie können sich nicht sehr konzentrieren, wenn alles hängen bleibt. Sehen Sie, einer wird eine IDE wie Eclipse haben, beispielsweise 2 PDF-Bücher, 2 Webbrowser, einen für das Ausführen von Debugging (im Falle einer webbasierten Entwicklung), einen Server und einen Musikplayer;) Geben Sie ihm einen langsamen Rechner und Er wird dich zum Abschied küssen.
1
Die Antwort nein ist falsch. Die richtige Antwort ist Nooooooooo!
Pekka 웃
70

1) Sehr, sehr unwahrscheinlich. Nein, und Ihre Entwickler geben Ihrem Kaffee möglicherweise etwas Böses, wenn Sie es vorschlagen. Zeit Ihre Entwickler verbringen warten auf den Code zu kompilieren oder für die IDE zu tun , was er tut oder was auch immer Zeit ist sie nicht der Code besser machen zu verbringen. Beeinträchtigt auch ihren mentalen Fluss. Behalten Sie das Problem im Hinterkopf, und die Lösung des Problems wird wesentlich effizienter sein.

2) Geben Sie ihnen jeweils einen zweiten PC, der die niedrigsten Spezifikationen darstellt, die sie unterstützen sollen, und einen KVM-Switch, der zwischen dem Computer und der eigentlichen Workstation geschaltet wird.

BlairHippo
quelle
Ich mag die Idee, ein KVM mit einem alten PC zum Testen zu verwenden. Je nach Projekt ist es jedoch möglicherweise umständlich, die neuesten Builds bei jedem neuen Build auf der langsamen Maschine zu installieren.
Al Crowley
4
Sie sollten ihnen auch ein Konto auf mindestens dem zweiten PC zuweisen, der über keine Administratorrechte verfügt.
David Thornley
43

Ich mag lange Kompilierzeiten. Es gibt mir mehr Zeit, um an meinem Lebenslauf zu arbeiten.

Wonko der Vernünftige
quelle
1
hehehe, je länger desto besser!
Newtopian
33

Das ist eine schreckliche Idee. Sie möchten, dass Ihre Entwickler so produktiv wie möglich sind. Dies bedeutet, dass Sie ihnen so schnell wie möglich eine Maschine zur Verfügung stellen, damit sie nicht den ganzen Tag auf die Kompilierung warten. (Etwas ot, aber es hilft auch, den Zugriff auf potenziell hilfreiche Websites mit WebSense und dergleichen nicht zu blockieren.) Wenn Sie von Benutzern eingeschränkt werden, auf denen noch die Steinzeittechnologie ausgeführt wird, benötigen Sie einen Testcomputer Testen Sie mit ähnlichen Spezifikationen frühzeitig und häufig, um sicherzustellen, dass Sie bei der Auswahl der Technologie nicht den falschen Weg einschlagen.

O. nate
quelle
wer ... warte mal. Wenn die Kompilierung schnell gehen würde, wäre dies nicht mehr möglich: xkcd.com/303
gbjbaanb 18.04.11
32

Die Entwicklung sollte in der bestmöglichen Umgebung erfolgen. Die Tests sollten in der schlechtesten Umgebung durchgeführt werden, die machbar ist.

Jewgenij Brikman
quelle
27

Wenn ich eine langsame Maschine bekäme, würde ich meinen Tag damit verbringen, den Entwicklungsprozess zu optimieren und meinen gelieferten Code nicht zu optimieren. Also: NEIN!

user6015
quelle
26

Programmierer für eingebettete Systeme haben die ganze Zeit damit zu tun! Und es gibt eine zweiteilige Lösung:

  1. Ihre Anforderungen müssen die X-Leistung auf der Y-Hardware angeben.
  2. Testen Sie auf Y-Hardware. Wenn Sie keine X-Leistung erhalten, treten Dateifehler auf.

Dann spielt es keine Rolle, an welcher Hardware Ihre Entwickler arbeiten.

Wenn Sie dies getan haben, können Ihre Programmierer beispielsweise durch schnellere Geräte eine halbe Stunde pro Tag oder 125 Stunden pro Jahr sparen. Nehmen wir an, sie kosten 100.000 USD pro Jahr mit Vorteilen und Gemeinkosten (für Silicon Valley lächerlich niedrig) oder 50 USD pro Stunde. Diese 125 Stunden * 50 $ / Stunde sind 6250 $. Wenn Sie also weniger als 6250 US-Dollar pro Jahr für die Entwicklung von Hardware pro Programmierer ausgeben, sparen Sie Geld.

Das sollten Sie Ihrem Management mitteilen.

Tim Williscroft sagte die erste Hälfte davon in einem Kommentar, und in einer gerechten Welt würde er die Hälfte aller Punkte bekommen, die diese Antwort bekommt.


24. Oktober hinzugefügt:

Mein ehemaliger Arbeitgeber hatte diese Theorie und sie half ihnen, ungefähr 100 Millionen Dollar wegzupissen.

Es handelt sich um ein japanisches Konglomerat, das daran gewöhnt war, Programmierer in Japan, Korea und China einzustellen. Die Leute dort sind cool, wenn sie beschissene Entwicklungshardware verwenden, 13 Stunden am Tag arbeiten, an ihren Schreibtischen schlafen und kein Leben haben. Als sie ein bekanntes Unternehmen aus dem Silicon Valley erwarben, um ein Linux-basiertes Handy-Betriebssystem zu entwickeln, waren diese albernen Kalifornier, die sich moderne Ausrüstung wünschten, nur winzige Primadonnen und hatten eigentlich keinen guten Grund dafür (wie Produktivität).

Vier Jahre später funktionierte das Betriebssystem wie Quatsch, alle Zeitpläne waren durchgebrannt und die Kunden waren sauer und kündigten Verträge rechts und links. Schließlich wurde das OS-Projekt eingestellt und ein großer Teil der weltweiten Belegschaft des Konglomerats im letzten Jahr entlassen. Und ehrlich gesagt, ich möchte nicht einer der Führungskräfte gewesen sein, die den Aktionären erklären mussten, wohin all das Geld und die Anstrengungen gingen.

Es waren nicht nur die langsamen Entwicklungsmaschinen, die dieses Fiasko verursachten. Es gab viele andere strategische und taktische Fehler - aber sie waren die gleichen, bei denen die Leute, die in den Schützengräben arbeiteten, das Zugunglück kommen sahen und sich fragten, warum die Entscheidungsträger das nicht konnten.

Und der langsame Gang war sicherlich ein Faktor. Wenn Sie pünktlich liefern wollen, ist es dann wirklich klug, die Arbeit absichtlich zu verlangsamen?

Bob Murphy
quelle
+1 sogar 30 Minuten können in manchen Kreisen eine sehr bescheidene Schätzung sein.
Justin
20

In der Programmierung gibt es ein altes Sprichwort: " Vorzeitige Optimierung ist die Wurzel allen Übels ". Ich denke, Sie haben es geschafft, eine weitere "Wurzel" (oder zumindest den ersten Zweig) des Bösen zu schaffen. Von nun an können wir sagen: "Vorzeitige Entwickler-Deoptimierung ist die Wurzel allen Übels."

Kurz gesagt, die Antwort ist, dass dies nur Ihre Entwicklungszeit verlangsamt und die weitere Wartung erschwert. Die Kompilierungszeiten werden länger dauern, die Suche nach Code auf der Festplatte wird langsamer, das Finden von Antworten online wird länger dauern, und vor allem werden Entwickler damit beginnen, ihren Code vorzeitig zu optimieren, um überhaupt die erforderliche Funktionalität testen zu können.

Dieser letzte Punkt ist das kritischste Thema und wird in vielen anderen Antworten nicht angesprochen. Sie werden vielleicht Ihre erste Version in Ordnung bringen, aber wenn Sie den Code in Zukunft aktualisieren möchten, werden Sie feststellen, dass die vorzeitige Optimierung des Entwicklers den Fokus Ihres Codes vom guten Design weggenommen hat und ihn näher an "Muss dies um machen" gebracht hat am wenigsten arbeiten, um meinen Job zu behalten ". Das Hinzufügen zusätzlicher Funktionen wird schwieriger, da die zu diesem Zeitpunkt ausgewählten Optimierungen möglicherweise nicht mehr erforderlich sind und Ihren Code in einem Pfad von halboptimierten Hacks über anderen halboptimierten Hacks fixieren.

Stellen Sie sich als Beispiel vor, dass die minimale Systemanforderung Ihrer aktuellen Version ein Ein-Prozessor-Rechner mit etwas langsamer Geschwindigkeit ist. Sie setzen Entwickler auf diese Box und sie entwickeln eine komplizierte Single-Thread-Lösung, die sich auf viele Hacks stützt, weil sie das Produkt schnell entwickeln wollten. Jetzt, 5 Jahre später, haben Sie eine neue Version des Produkts, für die mindestens ein Dual-Prozessor-Rechner erforderlich ist. Sie möchten in der Lage sein, Teile des Programms, die Sie parallel ausführen können, sauber voneinander zu trennen. Die Entscheidung, die Sie vor 5 Jahren getroffen haben und die Ihre Entwickler zu einer Hacky-Software gezwungen hat, hindert Sie jetzt daran, die volle Leistung Ihrer neuen Mindestanforderung zu nutzen .

Sie sollten am Ende Ihres Entwicklungszyklus eine Phase hinzufügen, in der Sie Akzeptanztests für die unteren Kästchen durchführen. Sicherlich ist ein Teil des Codes aufgrund der schnelleren Maschine des Entwicklers zu langsam, aber Sie können diesen Teil isolieren und dort optimieren. Der Rest Ihres Codes bleibt sauber und wartbar.

Ich sehe Ihre Frage als: "Kann ich meine Entwickler dazu zwingen, frühzeitig zu optimieren, indem ich ihnen schlechte Entwicklercomputer gebe, aber trotzdem guten Code bekomme?" Und die Antwort ist nein.

EntropyFails
quelle
"Wir sollten kleine Wirkungsgrade vergessen, sagen wir in 97% der Fälle: Vorzeitige Optimierung ist die Wurzel allen Übels." Wenn Sie etwas entwerfen, ist es eine gute Idee, 2 Minuten lang über die 3% nachzudenken.
Keyo
15

Interessante Lektüre, all diese Antworten.

Aber ich denke, die meisten Leute, die hier antworten, verpassen den Punkt. Die Frage, wie ich lese, ist nicht (zumindest), ob man den Entwicklern wirklich einen P1 geben soll, um schnelleren Code zu erstellen.

Der Punkt ist, dass eine Menge Software heutzutage genauso langsam oder sogar langsamer ist als die Software, die wir im letzten Jahrtausend trotz sehr viel leistungsfähigerer Computer verwendet haben. Den Antworten hier nach zu urteilen, verstehen die meisten Entwickler diesen Hinweis nicht. Dies ist in Webanwendungen sehr offensichtlich. Diese Seite ist eine sehr gute Ausnahme, aber viele Seiten haben eine Titelseite in 1 MB. Was bekomme ich dafür, dass ich darauf warte, dass es heruntergeladen wird? Ich weiß es nicht. Ich denke, es scheint sich um eine Ignoranz des Entwicklers zu handeln, die die Zeit, die der Benutzer dafür aufwenden muss, nicht respektiert, oder noch schlimmer, wenn Sie pro MB bezahlen. Die Sache ist, dass all diese Webseiten nicht einmal hochauflösende Bilder enthalten. Oft ist es nur ein Mistcode, der aus einer Entwicklungsumgebung stammt. Natürlich ist es kein Mistcode, denke ich, aber er bringt mir als Benutzer keinen Gewinn.

Im Allgemeinen geht es nicht nur darum, den Code zu optimieren, sondern auch darum, Dinge zu vermeiden, die langsamer werden als es der Fall ist.

Vor ein paar Wochen habe ich einen Laptop von 1995 gestartet. Windows 3.x war in kürzester Zeit einsatzbereit. Die Datenbank, aus der ich einige Daten abrufen sollte, wurde gestartet, bevor die Eingabetaste vollständig freigegeben wurde (zumindest fast).

Ich weiß, dass wir heute viel mehr aus unserer Software herausholen, aber wir haben auch Computer, die um ein Vielfaches schneller sind. Warum entscheidet sich die Entwicklungsbranche nicht, die Geschwindigkeit der Software von 1995 beizubehalten und die Leute dazu zu bringen, neue Hardware zu kaufen, weil sie neue Funktionen wollen? Heutzutage ist es eher so, als ob die alltäglichen Programme und Websites die Leute dazu zwingen, neue Hardware zu kaufen, um genau das zu tun, was sie früher getan haben. Aber natürlich ausgefallener.

Ich muss sagen, dass ich denke, dass die Linux-Entwicklung damit besser zurechtkommt. Linux-Distributionen sind Windows schon seit vielen Jahren weit voraus, selbst wenn es um viele interessante Dinge wie animierte Fenster geht. Die Sache ist, dass sie trotzdem auf den Computern von heute und sogar gestern gearbeitet haben. Nicht nur auf modernster Hardware.

Inzwischen haben viele Entwickler einen ungesunden Adrenalinspiegel. Ja, ich habe einen Weg gefunden, um ein wenig Frust von all dem Warten zurückzugeben:
Office SQL Server (Starten der Management-Konsole) arcgis (Starten und Verwenden) Acrobat Reader (Starten) agresso (Verwenden, zumindest als Webanwendung) windows (starren und benutzen, naja ich habe 7 noch nicht ausprobiert) .net webseiten (herunterladen)

und so weiter

Ich fühle mich gut :-)

Prost
Nicklas

Nicklas Avén
quelle
Diese. Diese. DIESE. SO VIEL DIESES. Das war schon immer meine größte Frustration mit Software. Die Leute verbringen mehr Zeit damit, die Oberfläche zu verschönern, als sich wirklich Gedanken über die Benutzerfreundlichkeit zu machen. Ein Beispiel dafür ist Android vs. Blackberry. Android sieht schöner aus und kann mehr, aber Blackberry ist viel angenehmer (und schneller) zu bedienen als Android, zumindest meiner Meinung nach.
Kcoppock
1
Ich stimme voll und ganz dem Argument zu, dass Software jetzt genauso schnell ist wie vor 20 Jahren, und zwar bei nahezu denselben Funktionen. Aber wenn Entwickler an 20 Jahre alter Hardware arbeiten, kann das Problem nicht behoben werden. Wenn das Unternehmen, das die Software erstellt, nicht in die Benutzerfreundlichkeit und / oder in Leistungstests investiert, die auf langsamerer Hardware entwickelt werden, wird dies alles nur schlimm machen. Dies ist eine völlig andere Debatte, für die der Kopf eines Programmierers nicht der einzige richtige Empfänger einer wohlverdienten Ohrfeige ist.
Newtopian
10

1) Wenn ich einem Entwickler eine langsamere Maschine zur Verfügung stelle, kann der resultierende Code dann schneller oder effizienter sein?

Wir haben in den letzten 6 Jahrzehnten Software entwickelt und haben immer noch Fragen wie diese? Scheint eher wie ein weiterer Versuch, Ecken zu schneiden. Keine Beleidigung, aber komm schon, denkst du, die Frage ist sogar logisch? Denken Sie in diesen Begriffen darüber nach (wenn Sie können): Sie möchten ein 4x4-Fahrzeug bauen, das unter rauen Bedingungen, Regen, Schlamm usw. eingesetzt werden kann. Werden Sie Ihre Ingenieure und Montagelinien unter die Elemente stellen, um sicherzustellen, dass das resultierende Fahrzeug mit ihnen arbeiten kann?

Ich meine, Jesus Christus! Es gibt Entwicklung und es gibt Tests. Die Tests werden in einer anderen, raueren Umgebung durchgeführt, oder der Entwickler weiß, wie er einen Prüfstand in seiner eigenen Entwicklungsumgebung auf eine für Stresstests geeignete Weise zusammenbaut. Wenn er nicht kann, ersetzen Sie ihn durch einen besseren Entwickler.

2) Was kann ich tun, um meinen Entwicklern eine schnelle IDE-Erfahrung zu bieten, während ich "typische" Laufzeiterfahrungen gebe?

Sie sollten dies Ihren Entwicklern mitteilen. Und wenn sie Ihnen keine objektive und gültige Antwort geben können, müssen Sie sie durch tatsächliche Entwickler ersetzen.

Um die Frage zu beantworten, geben Sie Ihren Entwicklern (vorausgesetzt, Sie haben gute Entwickler), guten Tools und guter Hardware das Beste, was Sie sich leisten können. Richten Sie dann eine niedrigste gemeinsame Basisumgebung ein, in der Ihre Software ausgeführt werden muss. Das ist , wo Tests auftreten sollten. Es ist eine weitaus bessere technische Praxis, eine Testumgebung zu haben , die sich von der Entwicklungsumgebung unterscheidet (vorzugsweise eine, mit der Sie Stresstests durchführen können).

Wenn Ihre Entwickler gut sind, sollten sie Ihnen dies mitteilen (vorausgesetzt, Sie haben sie gefragt.)

luis.espinal
quelle
1
Wir haben in den letzten 6 Jahrzehnten Software entwickelt und haben immer noch Fragen wie diese? - Ich habe Ihre Antwort positiv bewertet, aber ich empfehle Ihnen, die ursprüngliche Frage aus einer anderen Perspektive zu untersuchen. Tatsächlich gibt es viele Manager, die die Vorteile schneller, leistungsfähiger Maschinen für ihre Entwickler nicht kennen. In Anbetracht dessen hat die ursprüngliche Frage möglicherweise versucht, solche Manager von der lächerlichen Vorstellung abzuhalten, dass langsame Maschinen Entwickler irgendwie dazu bringen können, schnelleren und effizienteren Code zu produzieren.
Jim G.
1
"2) Was kann ich tun, um meinen Entwicklern eine schnelle IDE-Erfahrung zu bieten, während ich 'typische' Laufzeiterfahrungen gebe? Das sollten Sie Ihren Entwicklern abverlangen." Ich glaube, dies ist eine SE-Site für Programmierer, keine SE-Site für Manager. Er fragte die Entwickler.
stimpy77
1
"Sie möchten ein 4x4-Fahrzeug bauen, das unter rauen Bedingungen, Regen, Schlamm usw. eingesetzt werden kann. Werden Sie Ihre Ingenieure und die Montagelinie unter die Elemente stellen, um sicherzustellen, dass das resultierende Fahrzeug auf ihnen eingesetzt werden kann?" <<< Liebe die Analogie
stimpy77
6

Daraus resultieren eine Menge Entwickler. Dieses Zeug ist schon schwer genug, lasst uns die Erfahrung nicht noch schlimmer machen.

Ich würde Sie ermutigen, ähnliche Hardware wie Ihre Benutzer in einer Test- oder QS-Umgebung zu haben, um Leistungsprobleme zu beseitigen. Das ist eine gute Idee.

bigtang
quelle
8
Entwickler diese Schlampe? Auf keinen Fall ...
Jé Queue
6

Ich werde der Norm widersprechen und JA sagen, WENN UND NUR, wenn sie Serversoftware schreiben. Lachen Sie alles, was Sie wollen, aber das effizienteste Team, das ich je gesehen habe, war eine Gruppe von Perl-Leuten mit Wyse-Terminals. Dies war Ende der neunziger Jahre, war ein Off-Shoot-Shop der Universität und sie schrieben eine räumliche Gittersoftware (die im Grunde nur berechnet). Sie sprachen jedoch mit einigen relativ leistungsstarken RS / 6000-Modellen.

Um die Veranstaltung noch interessanter zu gestalten, gab es dort einen blinden Programmierer. Ich war sehr beeindruckt.

Alt-Text

Jé Queue
quelle
3
Blinder Programmierer? Ist das überhaupt möglich?
WernerCD
1
@WernerCD, ich versuche bis heute, mir die Gedankenkraft vorzustellen, die erforderlich ist, um die Codezeilen in meinem Kopf im Auge zu behalten.
Jé Queue 22.10.10
3
Ja, die meisten von uns schreiben Serversoftware ... +1
goodguys_activate
@ MakerOfThings7, gib mir jeden Tag mehr Serverhardware über meinen lokalen Computer, gib $ aus, wo es sein sollte (aber gib mir einen großen Monitor :)) Ich habe keine Probleme damit, dass mein jahrzehntealter Dell Latitude CPx ein Display für die großen Systeme von ist der DC.
Jé Queue 22.10.10
4
Vielleicht könnte ein blinder Programmierer eine Braillezeile verwenden?
Antsan
5

Das ist keine schlechte Idee - aber Sie möchten, dass Ihre Entwickler eine schnelle Programmierumgebung haben.

Sie können dies möglicherweise implementieren, indem Sie Ihren Programmierern zwei Maschinen zur Verfügung stellen - eine Fast-Dev-Box und eine langsamere Commodity-Box (möglicherweise virtuell) zum Testen.

Durch einige Optimierungen des VS-Erstellungsprozesses könnte die Bereitstellung auf der Testbox zur Norm mit Remote-Debugging werden.

Es gibt andere Möglichkeiten, Ihre Codierer zu zwingen, effizienteren Code zu entwickeln. Sie können beispielsweise Leistungs- und Speichernutzungsziele in Ihre Komponententests einbeziehen. Das Festlegen von Budgets für die Speichernutzung ist ebenfalls ein hervorragendes Ziel. Festlegen von Seitengewichtsbudgets für HTML-Code.

damien
quelle
5

Das Problem ist nicht, dass der Entwickler ineffizienten Code auf einem schnellen Computer erstellt. Das Problem ist, dass Sie keine Leistungsmetriken definiert haben, an denen gemessen werden muss.

Als Teil der Produktanforderungen sollte ein bestimmtes Ziel definiert werden, das auf allen Computern basierend auf der erforderlichen Kundenerfahrung gemessen werden kann. Es gibt viele Websites (Check SpecInt), auf denen Sie Ihren Computer mit anderen Computertypen in Beziehung setzen können.

Das ist aus vielen Gründen gut. Mit dieser Funktion können Sie die unterstützte Mindesthardware einfacher definieren, sodass Sie die Anzahl der Kundenbeschwerden begrenzen können. Wir alle wissen, dass die meisten Softwareprogramme auf den meisten Computern ausgeführt werden. Dies ist nur eine Frage der Leistung Wenn die Leistung akzeptabel ist, können Sie Kundenbeschwerden einschränken. Wenn ein Kunde anruft, können Sie anhand der Benchmarks feststellen, ob tatsächlich ein Problem vorliegt oder ob der Kunde mit der Funktionsweise des Produkts nicht zufrieden ist.

Mike Glasspool
quelle
5

Ich bin überzeugt, dass ein langsamerer Computer für die Entwicklung zu schnellerem Code führt, aber dies hat einen Preis. Das Grundprinzip ist, dass ich diese Erfahrung aus erster Hand gemacht habe: Nachdem ich lange Zeit auf dem Weg zur Arbeit war, kaufte ich ein Netbook, um im Zug zu arbeiten. Dieses Netbook ist langsamer als jeder Computer, den ich in den letzten 5 Jahren gekauft habe. Weil alles so langsam ist, sehe ich sehr schnell, wenn etwas auf diesem Netbook unerträglich langsam ist, und ich bin mir langsamer Flecken viel schneller bewusst (kein ständiges Benchmarking erforderlich). Die Arbeit an einem Netbook hat meine Entwicklung grundlegend verändert.

Davon abgesehen plädiere ich nicht dafür, dies zu tun, insbesondere in einem professionellen Umfeld. Erstens ist es demoralisierend. Die Tatsache, dass fast jeder sagte, die Idee sei nicht einmal sinnvoll, zeigt, dass Programmierer schlecht auf die Idee reagieren.

Zweitens, alles langsamer zu machen, bedeutet, dass Dinge, die Sie auf einer schnellen Maschine tun möchten (etwa 1 Minute), auf einer langsamen Maschine aufgrund von Faulheit usw. nicht mehr möglich sind. Dies ist eine Frage des Anreizes.

Endlich: Der produzierte Code ist zwar schneller, aber die Produktion dauert mit ziemlicher Sicherheit länger.

David Cournapeau
quelle
+1 Aber ich muss in einigen Punkten nicht zustimmen. Ich habe mir auch ein Netbook gekauft, aber ich habe festgestellt, dass Geschwindigkeit nicht das eigentliche Problem ist, sondern die kleine Bildschirmgröße. 1 GHz ist schnell genug für kleine Projekte unterwegs, aber 1024x600 ist einfach zu klein.
Joe D
4

Punkt 1, NEIN! Studio soll auf vernünftigen Computern ausgeführt werden, und diese Anforderung wurde mit jeder Version leistungsfähiger. Sie können tatsächlich einige Versionen von Studio sperren, wenn Sie Intellisense einschalten und eine Single-Core-Box ohne HT verwenden.

Zu Punkt 2 gibt es einige Funktionen in den Testprojekten, mit denen Sie einige Ressourcen drosseln können. Sie sind nicht perfekt, aber sie sind da. Auch VPC- oder VM-Images mit niedrigen Spezifikationen müssen ziemlich genau eingehalten werden. Ich habe Benutzer an schlechten Maschinen sitzen lassen, um gelegentlich Tests durchzuführen, damit sie die Auswirkungen der von ihnen angeforderten Funktionen sehen können.

Rechnung
quelle
4

Nein - in der Tat würde dies zu mehr Fehlern führen, da sie nicht so viel testen und keine zusätzlichen Tools wie Profiler verwenden. Geben Sie ihnen die besten Maschinen, die Sie sich leisten können (einschließlich Grafikbeschleunigungshardware für Spieleentwickler oder Grafiker), und lassen Sie sie in VMs testen. Die VM-Spezifikationen können nach Bedarf vergrößert oder verkleinert werden.

JohnL
quelle
+1: Tatsächlich würde dies zu mehr Fehlern führen, da sie nicht so viel testen und keine zusätzlichen Tools wie Profiler verwenden. - Großartiger Punkt. Vergessen wir nicht die Opportunitätskosten, die mit einer langsamen Entwicklungsmaschine verbunden sind.
Jim G.
4

Ich denke, das ist eine interessante Frage, und ich würde nicht so schnell ein "Nein" sagen. Meine Meinung ist: Es hängt davon ab, über welche Art von Entwicklungsteam wir sprechen. Beispiel: Wenn Sie eine Gruppe leiten, die für den jährlichen ICFP-Programmierwettbewerb kandidiert, bedeutet ein gutes Ergebnis nach einer kurzen Entwicklungszeit auf einem HPC-Cluster nicht unbedingt, dass die gefundene Lösung gut ist. Das Gleiche gilt, wenn Sie einen wissenschaftlichen oder numerischen Algorithmus schreiben: Auf Ihrem alten AMD Duron 600 MHz mit 64 MB Arbeitsspeicher müssen Sie vorsichtig sein, wie Sie die Dinge erledigen, und dies kann sogar das Design beeinträchtigen Entscheidungen.

Auf der anderen Seite sollte ein kluger Programmierer / Wissenschaftler / was auch immer aufpassen. Aber ich habe einige meiner besten Codes aufgeschrieben, als ich KEINEN Computer hatte und Notizen auf Papier machen musste. Dies gilt möglicherweise nicht für große Projekte mit großen Frameworks, wenn eine IDE unbedingt erforderlich ist.

Eines ist sicher: Schnelle Maschinen und gute sofortige Ergebnisse machen (schlechte) Programmierer kaputt und können einer der Gründe für den Mist sein, den wir auf Computern finden.

Lorenzo Stella
quelle
5
Sag dir was - kaufe einen wirklich guten Computer und ich
tausche
4

Ich arbeite an einem Paket, das ungefähr eine Stunde benötigt, um auf meinem 8-Kern-8G-Rechner zu bauen (vollständige Bereinigung). Ich habe auch einen relativ günstigen Laptop, auf dem ich teste. Der Low-End-Laptop verwaltet nicht zwei vollständige Builds an einem Arbeitstag.

Bin ich auf dem schnellen Computer produktiver, wenn ich absichtlich Tests auf dem Laptop durchführe, oder sollte ich alle meine Builds auf dem Laptop ausführen?

Denken Sie daran, dass dies keine erfundenen Zahlen sind.

Es ist eine manipulierte Demo, da ich normalerweise nicht jeden Tag einen sauberen Build durchführen muss (ich kann eine Menge Tests an einzelnen Modulen durchführen), aber selbst die Teil-Builds zeigen ungefähr einen Größenunterschied in den Kompilierungs- / Link-Zeiten .

Das eigentliche Problem bei meiner langsameren Maschine ist, dass ein typischer Build lang genug ist, um eine Tasse Kaffee zu trinken, während ich auf meiner schnelleren Maschine nur ein wenig Kaffee trinken kann.

Im Hinblick auf die Erledigung der Arbeit bevorzuge ich die Entwicklung auf einer schnellen Maschine. Ich kann Termine viel zuverlässiger einhalten. Andererseits stelle ich mir vor, wenn das Management mich dazu bringt, auf meinem langsamen Computer zu entwickeln, würde ich viel mehr im Internet surfen oder zumindest Bücher lesen.

Streifen
quelle
Was ist generell in Ihrem Build, damit es so lange dauert? Ist es CPU-gebunden oder festplattengebunden (was ist der Engpass)? Wäre dies ein Problem, wenn TFS die Builds für Sie erledigen würde?
goodguys_activate
1
Sie brauchen einen halben Arbeitstag, um eine Tasse Kaffee zu trinken? Sie müssen für die Regierung arbeiten.
22.
I / O auf der langsamen Maschine gebunden. Immer noch I / O-Vorgänge auf der schnellen Maschine, aber eher ein CPU-Engpass. Das aktuelle Build-System mag es nicht, mit mehr als einer Bibliothek gleichzeitig zu arbeiten, daher verbleiben einige CPU- und E / A-Ressourcen auf dem Boden, wenn in einem bestimmten Unterprojekt weniger als 8 Dateien zum Kompilieren übrig sind. Was den Kaffee betrifft, könnte ich ihn schneller trinken, aber ich versuche, meine Aufnahme zu begrenzen. Wenn ich ihn also schneller trinke, würde ich eine weitere Aktivität in der Freizeit benötigen.
Stripes
3

Interessanterweise habe ich bei einem Startup gearbeitet, bei dem wir das gemacht haben. Ich denke, es hat tatsächlich ziemlich gut funktioniert, aber nur aufgrund der spezifischen Situation, in der wir uns befanden. Es war ein mod_perl-Shop, in dem das automatische Neuladen von Klassen tatsächlich korrekt funktionierte. Alle Entwickler verwendeten vim als IDE ihrer Wahl (oder verwendeten eine Fernbearbeitungssoftware). Das Endergebnis war, dass sehr wenig (wenn überhaupt) Zeit verloren ging, bis der Code kompiliert / neu geladen / etc.

Grundsätzlich gefällt mir diese Idee, wenn der Entwicklungszyklus für alle Entwickler zu vernachlässigen ist und sich nur auf die Laufzeit Ihres Codes auswirkt. Wenn Ihr Code in irgendeiner Weise kompiliert, vorverarbeitet usw. ist, nehmen Sie sich mehr Zeit, um die Schleife "Fehler beheben, testen, weiter", in der Entwickler arbeiten.

Von der zwischenmenschlichen Seite waren die Leute nie gezwungen , die langsamen Server zu verwenden, aber wenn Sie die langsamen Server verwendeten, mussten Sie keine eigene Wartung oder Einrichtung vornehmen. Auch dieses Setup gab es von Anfang an, ich kann mir nicht vorstellen, es an ein etabliertes Entwicklerteam zu verkaufen.

Nachdem ich Ihre ursprüngliche Frage noch einmal gelesen habe, fällt mir ein, dass eine Sache, die mich immer wieder erschreckt, Entwicklungsumgebungen sind, die sich von Produktionsumgebungen unterscheiden. Warum nicht eine VM für die Codeausführung verwenden, die Sie zur Laufzeit verkrüppeln können, ohne die Dev-Workstation zu beeinträchtigen? In letzter Zeit habe ich VirtualBox benutzt / geliebt.

user6041
quelle
3

Ich werde mich auch hier dem Trend widersetzen.

Anekdote: Ich habe für eine niederländische Softwareentwicklungsfirma gearbeitet, die 286 Computer auf 486-es aufgerüstet hat (ja, ich bin so alt). Innerhalb weniger Wochen verringerte sich die Leistung aller unserer internen Bibliotheken um 50% und die Anzahl der Fehler stieg ... Eine kleine Untersuchung ergab, dass die Leute den Code selbst während des Debugging-Prozesses nicht mehr durchdachten, sondern zu 'schnellem', aufeinanderfolgendem Code griffen -> compile -> test -> fix (code) etc. zyklen.

Verwandte: Als ich eine Tochtergesellschaft für dasselbe Unternehmen in den USA gründete, stellte ich schließlich russische Programmierer ein, weil sie an PCs mit weniger Funktionen und weniger Leistung gewöhnt waren und wesentlich effizientere Codierer waren.

Mir ist klar, dass dies unterschiedliche Zeiten waren und die Ressourcen viel knapper waren als heute, aber es überrascht mich immer wieder, wie bei all den Fortschritten, die auf dem Gebiet der Hardware erzielt wurden, das Nettoergebnis zu sein scheint, dass jeder Schritt nach vorne ist Negiert durch schlampigere Programmierung, die höhere Mindestanforderungen erfordert ...

Ich bin daher der Meinung, dass Programmierer gezwungen sein sollten, ihre Anwendungen auf Computern zu testen, die die durchschnittliche Rechenleistung und die Hardwarespezifikationen von Joe nicht überschreiten.

John SMythe
quelle
7
Der Kernpunkt ist hier "Test". Das Live-System muss keine überlastete IDE laden, das Back-End nicht lokal ausführen, sondern nur auf dedizierter Hardware, E-Mail, Office usw. Sie benötigen einen High-End-Computer, um den Entwickler zu starten Umwelt in den meisten Sprachen heute.
Bill Leeper
3

Hardware ist kostengünstiger als Entwicklungszeit.

Die meisten Engpässe liegen in der Datenbank und nicht auf dem Client-PC. Dies entschuldigt jedoch nicht das Testen auf langsameren Computern als dem Entwickler. Verwenden Sie Testtools, um die Optimierung zu testen.

Brian
quelle
3

Absolut nicht. Geben Sie Ihren Programmierern das bestmögliche Laptop-Geld, eine Tastatur ihrer Wahl, mehrere große Bildschirme, ein privates Büro, kein Telefon, kostenlose Erfrischungsgetränke, alle Bücher, die sie möchten (die relevant sind), jährliche Reisen zu wichtigen technischen Konferenzen und Sie werden großartige Ergebnisse erzielen. Testen Sie anschließend die Hardware- / Software- / Browser- / Bandbreitenkombinationen für die obere und untere Grenze.

addictedtoswdev
quelle
2

Dies ist ein interessanter Gedanke (eine langsame Maschine kann dazu führen, dass Entwickler mehr optimieren).

Die Lösung ist jedoch besser gerahmt: Geben Sie die Antwortzeit in die Anforderungen für Programme ein und stellen Sie eine Low-End-Maschine zum Testen bereit.

Wenn Sie einen wirklich großartigen Compiler / eine wirklich großartige Sprache haben, können Sie möglicherweise verschiedene Methoden entwickeln, um Code zu generieren und die beste auszuwählen. Das würde nur durch einen schnelleren Computer geholfen.

Paul Nathan
quelle
2

Andere haben geantwortet, dass Entwickler im Allgemeinen schnelle Maschinen haben sollen. Genau. Überspringen Sie nicht den Arbeitsspeicher - Sie möchten so viel Arbeitsspeicher wie möglich - einige Erstellungsprozesse beanspruchen die Festplatte sehr stark.

Was Sie vielleicht in Betracht ziehen sollten, ist Antivirus auf Build-Laufwerken! Das verlangsamt nur und kann ein extrem starker Verlangsamungsfaktor sein.

Möglicherweise möchten Sie die Entwicklertools unter Linux entwickeln lassen, wenn dies möglich ist. Die Tools dort sind viel besser für alle Arten von zusätzlichen Aufgaben (einfach nach etwas in einer Datei suchen usw.). Dadurch wird auch das Antivirus entfernt.

user1249
quelle
Vergessen Sie nicht die Vorteile einer schnellen Festplatte: codinghorror.com/blog/2009/10/…
Jim G.
2

Mein Macbook Pro bei der Arbeit ist ein paar Jahre alt. Zwischen Linux und Windows (um IE-Macken zu testen), vms sowie einigen Webbrowsern und Terminals, die geöffnet sind, zeigt sich das OSX-Drehrad viel. Ratet mal, was ich mache, wenn es sich dreht, ich sitze und warte. In diesem Fall verlangsamt eine langsame Maschine die Produktivität.

Thierry Lam
quelle
2

Bei vielen Anwendungen besteht das Problem darin, Entwickler dazu zu bringen, Tests mit realen Datensätzen durchzuführen, bevor sie "fertig" sind. Für interaktive Anwendungen wäre eine Basistestmaschine / VM erforderlich.

user6043
quelle
2

Ich arbeite auf einem langsamen Windows95-Computer und kann damit MindForth Artificial Intelligence effizient in Forth und JavaScript schreiben.

Mentifex
quelle
2

Programmierer zu fragen, ob Programmierer gute Hardware bekommen sollen, ist wie einen fetten Mann zu fragen, ob er Essen mag. Ich weiß, das ist der subjektive Austausch, aber trotzdem ... ist es die Frage wert, uns gefragt zu werden? : P

Das heißt, ich stimme natürlich der Mehrheit zu: NEIN .

Matthew Read
quelle