Schnell. Schneller. Am schnellsten?

In Laufe eines Projektes kommt man immer wieder in die Situation zwischen zwei Möglichen Implementierungen unterscheiden zu müssen. Da Technologie-Evaluierung eine gern gesehene Abwechslung zum manchmal eintönigen Programmieralltag, vertieft man sich häufig in diese Aufgabe.

Wird die Untersuchung gewissenhaft durchgeführt, startet man häufig mit einer Matrix, die mit relevanten Qualitätskriterien gefüllt werden. Häufig ist einer der ersten Punkte, die dort auftreten Geschwindigkeit, da es für ein System wichtig ist schnell zu reagieren und dem Benutzer ein angenehmes Nutzungsgefühl zu gewährleisten. Ein großer Fehler, der bei einer solchen Evaluierung häufig gemacht wird ist das Denken in Vergleichen. Technologie 1 ist schneller als Technologie 2. Aus diesem Grund ist Technologie 1 besser als Technologie 2. Richtig. Zumindest wenn es rein um die Performance geht. Nehmen wir mal ein konkretes Beispiel. Wir betrachten zwei Webserver, der eine kann 6.000 statische Anfragen pro Sekunde abarbeiten, der andere bis zu 10.000. Ist die zweite Technologie besser als die erste? Ja, auf die Performance bezogen sicherlich. Betrachtet man das Szenario ein wenig genauer, muss man noch mal einen Schritt zurückrudern.

Genau wie in sehr vielen anderen Problemen der Softwareentwicklung  spielt hier das Anforderungsmanagement eine wichtige Rolle. Der Projektverantwortliche hat die Aufgabe die nicht-funktionalen Anforderungen zu definieren. In den meisten Fällen wird die Forderung an die statischen Anfragen pro Sekunde unter 6.000 liegen. In unserem fiktiven Projekt nehmen wir 1.000 als Richtwert.

Vergleicht man jetzt die beiden Webserver, so wird klar, dass sie mit ihrer Geschwindigkeit beide in Frage kommen. In der aufgestellten Evaluierungsmatrix darf also nicht der Punkte der Geschwindigkeit aufgeführt sein, sondern die Frage „Schnell genug?“ mit ja oder nein muss beantwortet werden. Die tatsächliche Geschwindigkeit darf als Fußnote natürlich notiert sein. Wichtig hierbei ist, dass einem klar wird, dass somit andere Qualitätskriterien wie Wartbarkeit, Erlernbarkeit oder Erweiterbarkeit nun einen höheren Stellenwert gewinnen. Wahrscheinlich sollte man jedem Informatiker nach dem Studium oder der Ausbildung einen Zettel mit „Habt ihr an die Anforderungen gedacht?“ in die Hand drücken, um ihm sein Leben zu erleichtern.

Diese Art zu Vergleichen ist nahe verwandt mit dem „You ain’t gonna need it“-Paradigma, da man Optimierungen, die derzeit nicht notwendig sind auch nicht mit in die Messung einbezieht.

Solche Entscheidungen gilt es aber nicht zu treffen, wenn es um den Einkauf von Software geht, sondern auch wenn man die Eigenimplementierung vorzieht. Einen großen Wert auf Geschwindigkeit zu legen ist sicherlich keine schlechte Eigenschaft eines Softwareentwicklers, doch muss einem klar sein, dass Optimierung oft nicht ohne einen gewissen Preis zu erhalten ist. Wie überall im Leben ist es so, dass wenn man sich sehr stark auf eine Thema konzentriert andere hinten über fallen. In den Performance-Fällen ist es häufig die Wartbarkeit oder Erlernbarkeit, die zuerst in Vergessenheit gerät.

Warum ist dies schlimm? Jeder Programmierer hat sicherlich seine eigene Prioritätenliste, was Anforderungen an den eigenen Code angehen. Bei vielen steht Geschwindigkeit an erster Stelle, diese Entwickler vergessen aber sehr häufig, dass Hardware um einiges günstiger ist, als das Gehalt eines Mitarbeiters. Die Rechnung, die einen nach einer solchen Performanceoptimierung serviert wird ist einfach. Die Anzahl der Server, die eingespart werden muss in Verhältnis stehen zu dem Mehraufwand, den ein Entwickler benötigt um das System zu warten oder weiterzuentwickeln. Meist ist es nämlich doch günstiger einen zusätzlichen Server aufzubauen, um damit Performance zu gewinnen, als das vorhandene System zu beschleunigen.

Diese Regeln gelten solange man in einem eigenen Projekt arbeitet, man also Herr seiner Anforderungen ist und die Skalierung des Systems selber übernehmen kann. Findet man sich im Produktkontext wieder, sieht die Welt anders aus. Hier geht es um Alleinstellungsmerkmale der Software, die man verkaufen will und schneller zu sein als die Konkurrenz ist sicherlich ein wichtiges Kaufkriterium. Ich gehe aber davon aus, dass die meisten Webentwickler in Projekten und nicht an Produkten arbeiten.