Entscheide immer so spät wie möglich

Lesetipps

1. So agil wie möglich (Teil 2/2)
2. So agil wie möglich (Teil 1/2)

Die Weisheiten gehen mir irgendwie nie aus. Aktuell arbeite ich mal wieder an mir und einem wichtigen Prinzip. Entscheide immer so spät wie möglich. Es ist wieder eines dieser eigentlich ganz einfachen, aber irgendwie doch problematisch einzuhaltenden Richtlinien.

Was will uns das Prinzip eigentlich sagen? Legt euch jetzt noch nicht auf Lösungen fest, die Problem lösen, die ihr im Moment eh nicht beheben könnt. Lösungsfindung und Fehlerbehebung sollten immer sehr zeitnahe passieren. Das gilt besonders für eingesetzte Technologie.

Stellt euch mal vor, ihr wollt euer ORM Ende des Jahres austauschen und durch etwas modernes wie doctrine ersetzen. Im Moment ist das bestimmt eine der besten Lösungen, die der Markt so hergibt. Ihr habt euch also jetzt für die neue Technik entschieden und fangt an schon mal neue Klassen ein wenig in diese Richtung zu implementieren, damit sie danach einfacher zu migrieren sind. Klingt bis jetzt ja gar nicht so dumm, auch wenn die Entwicklung jetzt ein wenig langsamer passiert, aber wir sind schon mal vorbereitet.

Jetzt springen wir mal in unsere Zeitmaschine und spulen das Leben bis Ende 2010. Wir sind also an dem Zeitpunkt angelangt, an dem wir wirklich mit der Ablöse beginnen. Dummerweise existiert jetzt aber doctrane, ein noch viel besseres ORM, das natürlich auch ganz andere Schnittstellen besitzt. Tja den ganzen Mehraufwand, den wir betrieben haben, ist jetzt für die Tonne. Millionen in den Sand gesetzt.

Wo war aber der Fehler? Natürlich ist es gut zu wissen, dass ein Stück Technologie in meinem Projekt veraltet und dass es am Ende des Jahres ausgetauscht werden soll. Gegen welche Implementierungen sie aber konkret ersetzt wird, müssen wir zu diesem Zeitpunkt ganz sicher noch nicht bestimmen.

Das YAGNI (You ain’t gonna need it) Prinzip ist fast identisch dazu oder zumindest ein naher Verwandter. Ich komme übrigens auf das Thema, weil ich mir bis zur nächsten PHP Konferenz einen neuen Laptop kaufen und eigentlich sofort losrennen wollte, um einen zu kaufen. Habe ich aber nicht gemacht, denn wer weiß, was für Laptops es gibt, wenn ich im Mai wirklich einen neuen brauche. Bis dahin komme ich noch gut mit dem alten zurecht. Also endlich mal eine Regel, die man auch im Leben anwenden kann.

7 Kommentare »

• 
  

  Ralf Eggert

  am 18. Februar 2010 um 09:41 Uhr

  Dagegen spricht aber das tolle Sprichwort “Was du heute kannst besorgen, das verschiebe nicht auf morgen!”

  Aber im Ernst. Der Ansatz kann klappen, muss aber nicht. Um bei dem Laptop Beispiel zu bleiben. Ein guter Bekannter ist in Sachen Hardware immer top informiert. Der weiss eigentlich immer ganz genau, welchen Laptop er sich gerade kaufen würde, wenn er einen kaufen müsste. Nur er kauft sich eben nie einen neuen. Denn er hat Angst, dass der Laptop, den er sich heute kauft, schon in 1 Monat nicht mehr uptodate ist. Und so schiebt er die Entscheidung immer wieder auf und sagt: “Der Laptop taucht doch noch was. Ich warte lieber noch zwei Monate, dann gibt es bestimmt bessere für einen günstigeren Preis!” Und wenn er nicht gestorben ist, so wartet er noch heute…

  Bezogen auf die Webentwicklung kann dies bedeuten, dass jedes Projekt in Sachen ORM immer mit einem anderen Tool umgesetzt werden würde. Weil ja immer die neueste heiße Scheisse verwendet werden soll. Und so müssen sich die Entwickler nicht nur in Doctrine und Doctrane, sondern auch in Doctrene, Doctrune und Doctrone auskennen. Ein Wechsel aller Projekte auf das neueste Doctrone wird es aber nicht geben, da das niemand bezahlen wird.

  Das Prinzip kann funktionieren, kann aber auch im Chaos enden.

• 
  

  Thilo Habenreich

  am 18. Februar 2010 um 10:36 Uhr

  Ein ähnliches Phänomen ist mir im Zusammenhang mit dem ZendFramework aufgefallen.

  Nehmen wir mal an jemand möchte sich neu in dieses Framework einarbeiten. Dieser jemand entscheidet sich höchstwahrscheinlich dafür sich mit der aktuellen Version vom ZF zu befassen.

  Leider sind die Entwicklungszyklen beim ZF relativ schnell, so dass ein einzelner schnell ins schleudern gerät wenn er nah an der aktuellen Version bleiben möchte.

  Was will ich eigentlich sagen? Oftmals ist es einfach sinnvoll bei einem Projekt ganz klar die Versionsnummern der eingesetzten Komponenten fix zu halten und nicht einfach auf Teufel komm raus zu updaten. Sicherlich ist sind sicherheitsrelevante Fixes eine Ausnahme, aber bei neuen Features sollte man das ganz klar abwägen. Außerdem spielt meiner Meinung nach auch noch ein Große Rolle wie hoch der Einarbeitungsaufwand ist den eine neue Komponente mit sich bringt.

• 
  

  MaikL

  am 18. Februar 2010 um 11:15 Uhr

  Zum Thema doctrine und doctrane möchte ich anmerken, dass es Mitte bis Ende des Jahres doctrine 2.0 geben soll. http://www.slideshare.net/jwage/doctrine-2-not-the-same-old-php-orm
  Dieses wird nicht abwährtskompatibel zu doctrine 1.X sein. Also ist Nils sein Beispiel gar nicht so weit hergeholt. Wenn ich jetzt auf 1.X umsteige, habe ich Ende des Jahres das Problem, dass ich nicht auf 2.X umsteigen kann. Mir geht es genau so mit symfony 1.0 auf symfony 1.1 bzw. jetzt 1.4. Es wurde innerhalb einer Hauptversion so dermaßen viel an der API geändert, dass ein Upgrade von einem großen Intranet-Projekt bei uns in der Firma fehlschlug. Jetzt machen wir mit der 1.0 weiter und grämen uns ein wenig, wenn wir lesen, wie gut Propel 1.3 oder die neuen sfForms Funktionen sind.

• 
  

  Christian

  am 18. Februar 2010 um 16:05 Uhr

  In manchen Fällen ist vielleicht sogar schon ein Brechen der Rückwärtskompatibilität abzusehen aber man braucht jetzt eine Lösung. In diesem Fall macht es Sinn, sich die konyeptionellen Änderungen näher anzusehen, wenn möglich, um seine eigenen Entwicklungen bestmöglich dahingehend vorzubereiten.
  Das trifft einen zB mit der nächsten Symfony Inkarnation.

• 
  

  Nils Langner

  am 18. Februar 2010 um 16:06 Uhr

  @Christian: Du hast aber auch geahnt, dass das nicht immer klappen wird

• 
  

  Nils Langner

  am 18. Februar 2010 um 16:39 Uhr

  @Ralf: Vielleicht hast du mich falsch verstanden. Ich suche mir ein ORM aus und zwar das beste, das es zu diesem Zeitpunkt gibt. Ich schwenke dann nicht mehr um. Wenn du Entscheidung steht, dann steht sie. Dann lebe ich damit, bis es wirtschaftlich ist, auf ein neues zu migrieren.

• 
  

  Ralf Eggert

  am 18. Februar 2010 um 21:34 Uhr

  @Nils: d.h. du setzt dann auch immer alle neuen Projekte mit dem ORM um und schaust bei einem neuen Projekt nicht, was sich mittlerweile in der ORM Welt getan hat?

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar