2010-06-18 6 views
12

Viele PCs, die wir im Entwicklungsteam haben, sind veraltet und Visual Studio 2008 wird sehr langsam ausgeführt. Sie sollten sehr bald durch neuere Maschinen ersetzt werden. Aber es gibt eine generelle Zurückhaltung gegenüber Management/Firma, neue Maschinen zu kaufen.Wie misst man den Produktivitätsverlust von langsamen PCs mit Visual Studio?

Wie kommen wir mit Zahlen und Benchmarks, um zu zeigen, dass diese langsamen PCs einen Produktivitätsverlust verursachen?

Offensichtlich können wir sie nicht anrufen, um mit uns zusammen zu arbeiten, während wir Lösungen erstellen und/oder verschiedene Dateien öffnen.

Gibt es einen objektiven Weg, mit einer Art von zuverlässigen Zahlen zu kommen, die nicht-technische Leute verstehen können?

Es wäre schön, dies auf einer ganzen Organisation auf vielen verschiedenen PCs mit Visual Studio messen zu können. Ich suche nach einer Antwort, die besser ist als eine physische Stoppuhr. :)

Antwort

17

Ändern Sie Ihre Lösungen so, dass die Pre-Build- und Post-Build-Ereignisse die aktuelle Uhrzeit in eine zentrale Datenbank schreiben. Geben Sie den Computernamen und den Namen des Projekts ein.

Sie können diese Informationen dann als Grafik anzeigen, die die Zeit für Build vs. Machine zeigt.

Dies sollte eine Korrelation zwischen der Bauzeit und dem Alter der Maschine zeigen und hoffentlich zeigen, dass die älteren Maschinen langsamer sind. Sie könnten sogar die Zeit in einen $ (oder £ oder €) Wert umrechnen, um anzuzeigen, wie viel diese älteren Maschinen kosten. Summieren Sie dies im Laufe der Zeit wird einen Wert für die Amortisation von Investitionen in neue Maschinen geben.

Indem Sie die Lösungen ändern, können Sie diese Protokollierung auf allen Entwicklungsmaschinen bereitstellen, indem Sie einfach alle dazu bringen, einen "neuesten" Quellcode zu erhalten.

+1

+1 Ich mag diese Antwort wirklich. Einige Maschinen sind neuer, viele sind viel älter, aber damit kann ich sie alle erfassen und alt gegen neu vergleichen. – spong

+3

Wenn Ihr Build nicht groß ist, sind die Kosten für eine langsame Maschine bei normalen Aufgaben eher verloren. Jede Blocking-Machine-Task, die über 300ms dauert, ist bemerkbar (und ärgerlich), und über 10s ist störend. Diese totenweisen Kürzungen haben weitaus schlechtere Auswirkungen auf die Produktivität als einige zusätzliche Minuten pro Woche Bauzeit. – dbkk

0

Viele PHB verstehen die Produktivität in Bezug auf Codezeilen (die IMO ist sehr falsch).

Können Sie die Menge an Code, die pro Tag auf den langsamen Maschinen produziert wird, im Vergleich zu nicht so langsamen Maschinen aufzeichnen?

+6

Verwendet jemand noch Codezeilen als Maß für die Produktivität ?! Wenn dies in Ihrer Organisation noch immer vor sich geht, haben Sie wahrscheinlich weitaus größere Probleme als langsame Maschinen. – AndreiM

+0

Ich bin mir sicher, dass es viele Verwaltungstypen gibt, die das tun, insbesondere wenn das Codieren in einer IT-Abteilung eines Nicht-IT-Unternehmens erfolgt. – Pete

+0

wenn nicht LOC, Anzahl der Fehler behoben. Viele Orte verwenden _some_ Metrik, unabhängig von Wert –

0

Langsame Maschinen sind der Fluch der Entwicklung, IMHO, besonders da jede Verzögerung Entwickler aus der Konzentration bringt und zu einem viel kostenintensiveren Wechsel zu Dingen wie Webbrowsern führen kann. Es kann andere seltsame Effekte geben, wie zum Beispiel eine leichte Erhöhung der Latenz für das Javadoc-Popup oder C# -Äquivalent), wenn Sie eine Methode anzeigen und die Wahrscheinlichkeit, dass jemand die Dokumentation konsultieren würde.

Wenn in Ihrem Unternehmen legal (zumindest für den Eigengebrauch), nehmen Sie etwa eine halbe Stunde Arbeit mit einem Bildschirm-Capture-Tool wie Camtasia. Verwenden Sie dann einen schnellen Editor, um die Zeiten zu erkennen, an denen die Maschine aufgehängt wurde (einfach, wenn Sie eine Cursor-Änderung, einen Fortschrittsbalken usw. haben), und zählen Sie die Zeit und die Anzahl der Instanzen. Ich habe das stundenlang gemacht - es dauert nicht lange. Verwenden Sie diese Zahlen, um den Fall zu argumentieren, obwohl Sie auch argumentieren müssen, dass es zu den indirekten Kosten wie ein Kontextwechsel führt.

Nach meiner Erfahrung sind Festplatten oft die Hauptursache für Verlangsamung, nicht für CPU oder RAM, und leider kosten die meisten Unternehmen auf schnellen Festplatten oder SSDs und haben sehr strenge Regeln, sie zu ersetzen.

3

Ich würde versuchen, ihnen zu erklären, dass Programmierer viel mehr als Maschinen kosten. Wenn Sie 30 Minuten pro Tag warten, machen Sie die Mathematik und herauszufinden, wie viel Prozent Ihres Gehalts wegen Laggy Maschinen verschwendet wird.Präsentieren Sie ihnen diese Zahlen und vergleichen Sie sie mit dem Preis eines neuen Computers und erklären Sie, wie sie auf lange Sicht durch Upgrades Geld sparen können.

Wenn sie sich dazu entschließen, weiterhin viel Geld auszugeben, um nur zu wissen, dass Sie sitzen und einen drehenden Cursor beobachten, dann lachen Sie einfach, weil der Witz auf ihnen ist.

+4

Nein, der Witz ist auf Sie, wenn Sie zu spät arbeiten müssen, um es nachzuholen. Wenn Sie bezahlt werden, zahlen sie Ihnen auf die gleiche Weise. –

+0

@Mark Guter Punkt. Ich gehe jeden Tag zur gleichen Zeit, also war es leicht für mich, diesen Vorbehalt zu übersehen! –

0

Vergessen Sie nicht, die Kosten der Zeit in Betracht zu ziehen, herauszufinden, wie viel langsame PCs Sie kosten (dieser Beitrag mit anderen Worten)!

4

Dies beantwortet Ihre Frage nicht wirklich, könnte aber helfen, die gewünschten Ergebnisse zu erzielen. Sagen Sie Ihren Chefs, dass The Programmer's Bill of Rights etwas ernst zu nehmen ist.

+1

+1 Sehr schön, es ist lange her, seit ich Jeff Atwood's Post darüber gelesen habe. Leider würden nicht-technische Leute das nicht verstehen. – spong