Das größte Hindernis bei der SoftwareOptimierung ist das eigene Ego: Man glaubt zu wissen, wie man optimale Software schreibt. Aber: niemand ist perfekt, keine Situation gleicht der anderen, Optimierung ist ein "moving target", nach dem man sich ständig neu ausrichten muss.

Deshalb gibt es nur eine sichere Optimierungsstrategie:

AlleAlternativenPrüfen

Kritik

AlleAlternativenPrüfen ist meistens sehr aufwendig, manchmal gar unmöglich. In den allermeisten Fällen brauche ich auch nicht die beste Lösung, sondern nur eine ausreichende. AlleAlternativenPrüfen ist dann sehr unökonomisch.

Nun es ist nicht möglich in einem halbwegs "normalen" Projekt alle Alternativen auszuprobieren. Es ist sicherlich aber auch keine gute Idee alles auf eine Karte zu setzen. Frei nach Weinberg: "Nicht ist gefährlicher als eine Idee, wenn es die einzige ist".

AlleAlternativenPrüfen klingt dramatischer als es meist ist. Oft gibt es nur 2-3, selten mehr als 5-7 Möglichkeiten, ein Problem anzugehen. Die Frage ist auch nicht, ob man optimieren soll oder nicht (die Antwort: man soll nie ohne eine explizite Anforderung); Die Frage ist, wie man zu einer optimalen Lösung kommt, wenn man optimieren muss.

Wenn man optimieren muss, braucht man aber nicht zwangsweise ein optimale Lösung, sondern nur eine bessere (ausreichende).

Alternative

TueDasEinfachsteDasFunktionierenKönnte, überprüfe, ob es funktioniert hat, d.h. ob es sich für die konkrete Situation um eine ausreichende Lösung handelt. Wenn nicht, probiere die nächst-einfache Lösung; wenn Du eine ausreichende Lösung gefunden hast, bist Du fertig.

Diskussion

Beispiel: Ich brauche einen Sortieralgorithmus, der schneller ist als BubbleSort?. Muss ich dann wirklich sowohl MergeSort, als auch QuickSort (und eine handvoll weiterer SortierAlgorithmen?) probieren, bevor ich mich für "den richtigen" entscheide?

IMO ist das Sortierbeispiel nicht gut bzw. nicht typisch, weil die Algorithmen und ihre Eigenschaften sehr gut untersucht sind und man meist auf vorhandene Implementierungen oder fertige Programme zurückgreifen kann.

• Oft hat man ein gewisses Performanceziel, dessen Erreichung genügt
• z. B. die optische Kontrolle einer Produktion mit einer Taktzeit von 1 Sekunde, in der ein Produktbild aufgenommen, ausgewertet und eine Ausschuss-Entscheidung getroffen werden muss - es hat keinen unmittelbaren Vorteil es in 0.3 Sekunden tun zu können.
• z. B. die Darstellung digital archivierter Dokument am einzelnen Arbeitsplatz. Antwortzeiten im Bereich von 1-3 Sekunden sind akzeptabel. Alles unter 0.5 Sekunden wird wird vom Benutzer als "sofort" wahrgenommen und nicht mehr aufgelöst.
• Oft hat man aber auch die Forderung nach maximaler Performance
• z. B. Ein Management-Informationssystem, das auf Laptops unterwegs in Verhandlungen komplette statistische Auswertungen von Millionen Versicherungsfällen in Vertragsverhandlungen zur Verfügung stellen soll (1 Minute ist besser als 3 Minuten, aber 30 Sekunden oder 10 Sekunden wären noch besser).
• z. B. Ein Datenbanksystem, dessen Performance gegen Konkurrenzprodukte die Marktchancen wesentlich beeinflusst.
• z. B. Eine WikiSoftware, dessen Performance die Anzahl der auf einem Server gleichzeitig unterstützbaren Wikis bzw. Benutzer bzw. Interaktionen limitiert.

Das glaube ich nicht. Da das Erhöhen von Performance fast immer andere negative Effekte hat (komplexeres System, damit erhöhte Entwicklungs- und Wartungskosten z.B.), gibt es allermeistens einen Punkt, wo eine weitere Optimierung keinen ökonomischen Sinn mehr macht.

z. B. Ein Management-Informationssystem, das auf Laptops unterwegs in Verhandlungen komplette statistische Auswertungen von Millionen Versicherungsfällen in Vertragsverhandlungen zur Verfügung stellen soll (1 Minute ist besser als 3 Minuten, aber 30 Sekunden oder 10 Sekunden wären noch besser).

Wir können die Zeit auch auf 5 Sekunden drücken, schaffen es dann aber zeitlich nicht mehr, drei der Versicherungsarten zu implementieren. Was ist dem Kunden wichtiger?

Das ist IMHO eine XP-voreingenommene Sicht der Dinge. Das obige (reale) Projekt arbeitet mit vom Host-System quartalsweise extrahierten Daten und war entwicklungsmäßig vom operativen System völlig entkoppelt. Die verschiedenen ca. 6-7 Realisierungsvarianten betrafen vor allem das Wechselspiel zwischen Datenbankstruktur und SQL-Effizienz. Das AlleAlternativenPrüfen war ein Aufwand von ca. 3 Arbeitstagen in der frühen Projektphase und gemessen am Gesamtaufwand (ca. 90 Manntagen) unbedeutend.

z. B. Ein Datenbanksystem, dessen Performance gegen Konkurrenzprodukte die Marktchancen wesentlich beeinflusst.

Dann brauchen wir aber nicht maximale Performance, sondern nur bessere als die Konkurrenz. Und gleichzeitig müssen wir noch darauf achten, nicht zu teuer zu werden - für ein "zu schnelles" Produkt ist eventuell gar nicht genug Markt da...

Das ist ein von mir konstruiertes Beispiel. IMO besteht keine Gefahr, dass Datenbanken zu schenll werden könnten.

z. B. Eine WikiSoftware, dessen Performance die Anzahl der auf einem Server gleichzeitig unterstützbaren Wikis bzw. Benutzer bzw. Interaktionen limitiert.

Wieviele tausend Wikis möchtest Du gleichzeitig betreiben? Jubelst Du, wenn es stattdessen zehntausende sein dürfen?

Das kann man so nicht beantworten. Optimierung ist derzeit keine aktuelle Anforderung (sondern ziemlich weit hinten in der Prioritätenliste), sie kann es aber bei heranreifenden Projekten jederzeit werden.

Zugegebenermaßen gibt es aber wohl Situationen, in denen man keine feste Anforderung hat, sondern eine Kosten-Nutzen-Abwägung treffen muss. Muss man dafür AlleAlternativenPrüfen? Ich bin mir nicht sicher - ich würde mich in den meisten Fällen wohl eher auf die offensichtlichsten (und einfachsten) Alternativen beschränken und nur bei Bedarf stärker in die Breite gehen. -- IljaPreuß

Niemand spricht von müssen. Ich meine nur, dass AlleAlternativenPrüfen die einzig theoretisch sichere Methode zur Optimierung (optimieren = etwas bestmöglich bewerkstelligen) ist.

Diese Seite ist unabsichtlich so etwas wie ein Reibungspunkt zu ExtremeProgramming geworden, wobei ich nicht ganz verstehe, warum das so ist. Es besteht ja Einigkeit, dass Optimierung immer eine separate Anforderung sein muss, die nie freihändig vom Programmierer in Angriff genommen werden darf. Aber teilweise Optimierung, vollständige Optimierung, SpikeSolution oder AlleAlternativenPrüfen könnte jederzeit auch in einem XP-Projekt zu einer Aufgabe werden. Deshalb sehe ich den Konflikt nicht. Der Kunde sagt z. B. "Wir haben ein Leistungsproblem, das gelöst werden muss. Wir möchten vordringlich wissen, welche Leistungsreserven wir zu welchen Kosten erschließen können, ob sich dies lohnt oder ob wir besser die Hardware austauschen.". -- hl