PSG Performance Driven Development für den SQL Server
In den letzten Monaten wurde ich häufig danach gefragt, was denn dieses Performance Driven Development (PSG PDD) eigentlich sei? Und welche Technologien wir damit meinen?
In erster Linie verstehen wir unter der Performance Driven Development Methode weniger einen Technologie Ansatz, als vielmehr einen Rahmen an Maßnahmen, damit das Thema Performance im Laufe einer Software Entwicklung den Stellenwert er- und behält, welcher bei Projektstart als notwendig erachtet wurde.
Entstanden ist die Idee zu der Methode u.a. aus dem Feedback unserer Schulungskunden.
Es wurde uns zwar attestiert, dass die Teilnehmer unserer Workshops und Schulungen einen deutlichen Knowhow Fortschritt machen würden, dennoch wäre es für den einzelnen Entwickler immer wieder schwierig sei neues Wissen auch so einzusetzen, dass die Projekte bzw. Produkte davon wirklich partizipieren. Der Alltag von Entwicklern sei ja stark getrieben durch ein agiles geprägtes Umfeld und Stakeholder, für die diese grundlegenden technischen Storys erstmal nicht im Fokus stehen. Performance Themen während einer Entwicklung kann man weder sehen noch erleben. Das ist häufig etwas für „Später“. Und oft ist der generelle Tenor in Projekten, dass das eine Grundschuld sei, welche natürlich ein Entwickler immer im Blick haben muss.
In der Vergangenheit haben Endkunden durch regelmäßige Wiederholungen ihrer Schulungsmaßnahmen versucht diesen Effekten entgegenzuwirken. Ich möchte mich ja nicht über Umsatz beklagen, aber es ist nur bedingt eine Freude, wenn die Teilnehmer dann wiederholt anmerken, dass sie für das Thema dann im Projekt eigentlich keine Zeit hätten, weil es einfach keinem wichtig sei. Und wenn es später in den ersten Tagen in der Produktion zu Problemen kommt, dann ist es meist auch schon zu spät und man erhofft sich Wunder durch ein nachträgliches Tuning.
Ein weiterer Aspekt, welcher uns durch das Feedback der Schulungskunden und Teilnehmer erreichte, war, dass mit jeder neuen SQL Server Version (und damit oft auch Schulung) sich das quasi magische Features erhofft wird, damit der SQL Server endlich mal schnell wird.
Zwar wird der SQL Server mit jeder Version natürlich leistungsfähiger und bringt noch mehr Intelligenz mit, um Performance Herausforderungen zu begegnen, dennoch lassen sich diese immer noch durch viele gängige Methoden in der Entwicklung quasi unbemerkt komplett aushebeln. Des Weiteren steht natürlich die Frage im Raum, wie man denn neue Technologien wie zum Beispiel in-Memory OLTP in Abteilungen bringen soll, wenn für das Thema Performance eigentlich keine Zeit ist. Hier beißt sich die Katze in den Schwanz.
Was heißt das jetzt konkret?
Der Performance Driven Development besteht auf der einen Seite aus einer Reihe von Schulungen, um Entwicklern Hintergründe des SQL Servers so aufzubereiten, dass diese ein notwendiges Verständnis bekommen, wie sie Einfluss auf die zu erwartende Geschwindigkeit ihrer Lösung bekommen.
Diese Schulungen haben wir so ausgestaltet, dass wir unterschiedliche Module in wiederum aufeinander aufbauenden Leveln anbieten.
Ein Ziel war, dass wir die Teilnehmer nicht mit Details überfrachten und sie damit komplett irritiert und bewegungsunfähig zurücklassen.
Auf der anderen Seite gibt es Schulungsmodule, welche sich an unterschiedliche Rollen im Performance Driven Development Konzept wenden. Damit adressieren wir auch Projektleiter, Product Owner usw. Inhalt dieser Module sind weniger technische Details über eine Implementierung, sondern vielmehr Methoden zur Definition von Performance generell und wie diese im Projektverlauf kontinuierlich gemessen werden kann. Eine wesentliche Frage, welche wir im Verlauf dieser Module klären, ist, wie man den Aspekt Performance so beschreibt, dass alle Projektbeteiligten später über dasselbe Erlebnis bzw. Ergebnis sprechen.
Ein Ziel dieser Module ist, dass Projektvereinbarungen so formuliert werden können, dass es keine „Missverständnisse“ bzgl. der erwarteten Performance und der Skalierbarkeit einer Lösung geben wird. Erwartungen hinsichtlich der Möglichkeiten aber auch Grenzen müssen klar in ein System gebracht werden.
Als wichtig hat sich die Balance zwischen der Vermittlung eines konzeptuellen Rahmens als auch konkreter Maßnahmen erwiesen.
Für jedes dieser Module im jeweiligen Niveau bieten wir mittlerweile auf Wunsch auch eine Zertifizierung der erworbenen Kenntnisse an. Damit bieten wir sowohl einen Anreiz für die Teilnehmer als auch Kontrolle für die Stakeholder der Maßnahme an.
Ein weiterer Aspekt bei der Planung der Umsetzung von PSG PDD sind die Teamgrößen in den Unternehmen. Es macht einfach keinen Sinn mit einem generischen Rollenmodell sowohl Teams 5 als auch von 25 Entwicklern zu adressieren.
Ich hoffe, dass ich damit einen kurzen Überblick über den PSG PDD Ansatz geben konnte. In den folgenden Tagen werde ich gern auf die unterschiedlichen Inhalte eingehen, da ich der Meinung bin, dass dieser oder auch vergleichbare Ansätze nötig sind, um den heutigen Anforderungen an Entwicklungsteams zu entsprechen.
