http://prezi.com/xareuaotwrho/high-performance-architecture/

• Dan Kegel on the C10K problem >20 Seiten, viele interessante Links. ftp.cdrom.com auf 1 Maschine (Kegel) mit > 10K gleichzeitigen Verbindungen (1999)
• Jeff Darcy on High-Performance Architecture ~ 6 Seiten über auf was man so achten muss
• C500k in Action at Urban Airship Blogartikel über (hybrid thread/evented/queue-based, NIO) Java-Server für 500K Verbindungen. Stichwörter: Comet, Push

• Exkurs Memory-Allokator
  • Java/C# vs C - GC vs Malloc
  • Same page merging
  • Cache conscious, Cache oblivious
  • Deterministic Paged Skip List - Cache Conscious

• LLVM Blocks
• Grand Central Dispatch
• Stackless Python
• Low latency X264
• Memcached

Scrum als Prozess, damit man halt einen hat, wenn gleichzeitig ein nicht in den Prozess eingebundener Projektleiter feste Termine vorgibt, ist schwierig. Bei langfristigen Terminschätzungen kann man Dinge wie ein Refactoring eher mal dazwischen schieben.

• Das Team gibt die Geschwindigkeit vor
• Eine wichtige Aufgabe des Scrum Masters ist, den Druck vom Team weg zu nehmen und dafür zu sorgen, dass das Team arbeiten kann.
• „Story Points“ statt „Stunden“ unter anderem, damit unbegabte/störrische Projektleiter einen nicht auf eine grob geschätzte Zeit festnageln – Als Tool um Druck weg zu nehmen.
• Bei sehr engen Iterationen (1-Woche-Sprints z.B.) darf trotzdem Maintenance nicht ausfallen
• Buchempfehlung von Froh: Fergus O'Connell Fast Projects.
  • Tipp zum Umgang mit Zeitdruck von oben:
    • „Es dauert bis Dezember.“ (realistische Zeiteinschätzung)
    • - „Macht's bis Oktober.“ (Vorgabe)
    • „Wir probieren's.“ (d.h. das Commitment bezieht sich auf den Versuch)
    • Jeden Tag Projektplanung mit ETA abschließen: „Wir haben das und das geschafft, d.h. wir werden realistisch im Dezember fertig.“
    • ⇒ Nach einigen Tagen/Wochen sollte das beim PM ankommen.
• Joe: Die „10:1“ Effektivitäts-Schätzung für Entwickler deckt maximal die Tagesform ab, realistisch ist eher mehr
• Frank: Oft wird unter Zeitdruck die optimistische Schätzung genommen und dann noch das Testing gekürzt / auf Unit Tests verzichtet. Man könne ja Überstunden machen zum Ausgleich. Aber selbst, wenn die bezahlt werden – Dass da keine Qualität rauskommen kann, ist klar.
  • Joe: Stimmt. In anderen Ingenieurs-Disziplinen sieht man den Produkten leichter von außen an, wenn sie nicht fertig werden; Das ist in der Informatik ein Problem.