Wie quantifizierst du deine "langsame" Entwicklungsmaschine?

Hier ist eine Metrik, die einige höhere Ups beeindrucken kann: Messen Sie die durchschnittliche Zeit, die für die Erstellung Ihrer Anwendung benötigt wird, und wie oft Sie dies pro Tag tun. Zum Beispiel haben wir am Ende ~ 60 Builds pro Tag gemacht. Messen Sie nun die durchschnittliche Bauzeit auf einer vermutlich schnelleren Maschine (sagen wir 30 Sekunden pro Build).

An dieser Stelle können Sie sehen, wie viel Zeit Sie sparen würden, um die "schnellere" Maschine zu haben. Pro Entwickler, pro Tag. Multiplizieren Sie mit der Anzahl der Entwickler und den Tagen in einem Monat und Sie können sehen, wie dies gegen das Hinzufügen eines anderen Entwicklers zum Team aussieht. Ja, ich weiß, es gibt andere Überlegungen beim Hinzufügen von mehr Personen zu einem Team, aber das wird Ihnen einen groben Vergleich geben, auf den sich 'höhere' beziehen können. Zum Beispiel: Wenn wir alle schnellere Maschinen hätten, würden wir weniger Zeit für die Builds aufwenden, vergleichbar mit einem zusätzlichen Entwickler.

Auf der anderen Seite sollten Sie eine gute Schätzung der Kosten für die Aufrüstung aller Maschinen bereitstellen.

Nun, wenn Sie können, sollten Sie diese Art von Vergleich mit mehreren "schnelleren" Maschinen durchführen, um ihre relative Leistung zu bestimmen und vielleicht herauszufinden, welche Engpässe Sie haben (RAM vs. CPU vs. I / O?).

Schließlich ist meine persönliche Meinung, dass, während diese Art von Prozess und die folgende Diskussion mit den Stakeholdern stattfindet (und es kann eine Weile dauern), Sie alle größeren / mehr Monitore bekommen könnten. Das ist ein relativ günstiges Upgrade (natürlich nicht so billig, wenn man auf 52-Zoll-LCD-Monitore setzt, oder?) Und mehr Monitor-Status verbessert die Produktivität (protip: verbessert auch die Moral der Mitarbeiter, was wiederum die Produktivität erhöht) / p>

HTH

Schließen Sie FireFox, um etwas Speicher zu erhalten. Fügen Sie RAM hinzu. Hat mir sehr geholfen.

Hängt von Ihrer Arbeitsumgebung ab. Z.B. In Visual Studio (C ++, 2005) können Sie zeitgesteuerte Builds ausführen, sodass die IDE die verstrichene Zeit nach der regulären Build-Ausgabe ausgibt.

Quantifizierung ist schwierig, wenn Sie nichts haben, gegen das Sie messen / vergleichen können. Wenn deine dev-Box 12 Minuten braucht, um ein Projekt mit 100.000 Zeilen Code zu kompilieren, ohne dass eine andere Dev-Box gegen dich läuft, hast du keine Ahnung, ob das gut oder schlecht ist. Vielleicht sind 12 Minuten für 100.000 Zeilen wirklich gut?

Das Messen wird Ihnen nicht helfen und es wird Ihren Entscheidungsträgern sicher nicht helfen. Erwägen; "Ja Chef, es dauert durchschnittlich zwölf Minuten, um unser Projekt zusammenzustellen." Der Chef sagt; "Ok, ist das normal?". Du hast keine Ahnung.

Computerhardware ist billig. Schauen Sie sich die dev-Box an und überlegen Sie, ob Sie die Entscheidungsträger bitten sollen, etwas Geld zu verdienen, um die Leistung zu verbessern. Wenn Sie durchschnittlich 5 Mal am Tag kompilieren und es durchschnittlich 12 Minuten dauert, ist das eine verlorene Stunde an jedem einzelnen Tag - was zu 5 verlorenen Stunden pro Woche führt. Es lohnt sich die Kosten für einige RAM oder ein CPU-Upgrade.

Bei mir verlangsamt ein langsamer Rechner die Produktivität nicht so sehr wie eine unerwartete Verlangsamung - wenn das Gerät bei jedem Drücken von F5 die gesamte Lösung in 12 Minuten kompiliert, hat die Lösung ein Problem, nicht das Gerät. Abgesehen davon habe ich in 12 Minuten kein Problem, ich kann aufstehen und eine Pause machen. Es ist wirklich gut, eine Pause zu machen, wenn Sie wissen und kontrollieren können, wie lange die Pause dauert.

Was ich am produktivsten gefunden habe, ist diese Software, die nach ihrem Willen Viren scannt (oder Updates installiert) - sich dort hinsetzen und warten muss, ist ein Arschschmerz.