Kategorien
Think big, act small!
Heute mache ich mir es sehr einfach. Da ich heute Abend nach London fliege (ein wenig angeben muss sein), hab ich einfach einen Artikel genommen, den ich schon vor einer ganzen Weile geschrieben habe, der es aber nie in den Blog geschafft hat. Also ein wenig Rücksicht …
Heute mal wieder ein Schwank aus meiner Jugend. Naja vielleicht nicht ganz so lange her, trotzdem interessant. Es geht um den Umgang mit neuen Features oder Bugfixes. Man steht meistens vor der gleichen Entscheidung, die es zu treffen gilt. Mache ich es Quick and Dirty oder lasse ich mich auf eine schöne Lösung ein, die ich dann einfach pflegen kann. Der zweite Ansatz ist dann wohl Slow and Clean.
Eigentlich ist es ja ganz klar. Slow and Clean sollte es sein. Aber wenn man mit seinem Chef redet, dann fällt die Wahl doch häufig auf die erste schnelle Alternative. Aber was macht Quick and Dirty so interessant? Ganz klar ist wohl ein Pluspunkt, dass es schnell geht. Und dirty … naja wenn man sich an Christinas Aguileras Dirty Video erinnern, dann kann das ja gar nicht so schlecht sein. Obwohl … das schreibt man mit zwei R. Also doch nur einen Pluspunkt, es ist schnell.
Was natürlich am besten wäre, ist eine Lösung zu finden, die gleichzeitig schnell implementiert ist und trotzdem architektonisch einwandfrei ist. Mein Ansatz, mit dem ich in letzter Zeit immer gut gefahren bin ist „Think big, act small“. Wir suchen uns einfach eine Lösung, die alles abdeckt, was wir zur Zeit an Anforderungen haben, denken aber schon einen Schritt weiter. Was könnte in kurz- bis mittelfristig nötig sein. Was könnte uns das Leben erleichtern. Wir definieren uns also die denkbar beste Lösung, die alles abdeckt, was man braucht.
Jetzt wo ihr das Ziel skizziert habt, baut ihr einfach eine Lösung, die alle derzeitigen Anforderungen löst, aber keine der zukünftigen Anpassen verbaut. Wir bewegen uns also in die richtige Richtung, haben aber eine Lösung, die nicht over-engineered ist und nicht wirklich mehr Zeit benötigt, als die Quick and Dirty Lösung. Wenn man dann mal Zeit hat die große Lösung auszubauen, dann ist alles vorbereitet und das Refaktoring sollte nur minimal ausfallen. Sollte so auch um einiges einfacher sein es seinem Chef zu verkaufen. Think big, act small.
Think big, start small, stay tiny. So in etwa kenn ich das. Auftraggeber hat tolle Ideen für ein Portalsystem, aaaber wir setzen im ersten Schritt nur nen Anfang um, damit Kunden sich registrieren und ihre Daten ändern können. Später dann mehr. Nach der Aufwandschätzung wirds ne Web-Visitenkarte. Super Sache!
Meiner Erfahrung nach ist ein Großteil bis alles was „noch kommen könnte“ reine Theorie und wird nie kommen. Anders ist, wenn etwas langfristig so geplant ist und es mehrere Iterationen eines Projektes gibt.
@Cem: Da muss ich dir recht geben, deswegen hatte ich auch kurz und mittelfristig gesagt. Was langfristig passieren wird, da sollte man sich auf keinen Fall drauf vorbereiten
Hah, gerade jetzt hatte ich eine solche Situation. Ein Voting, welches sehr kurzfristig realisiert werden musste, wo von vornherein klar war, dass dort später weitere Funktionen/Features implementiert werden müssen. Welche Features genau dies werden würden, konnte man nur grob abschätzen, aber den Code so gestalten, dass er Änderungen oder neue Features schnell aufnehmen kann. Wichtig war eben erstmal, dass gevotet werden kann – Statistik, mehrsprachigkeit usw erstmal zweitrangig gewesen. Daher war das Voting innerhalb weniger Stunden online.
Think Big, act small. Gute Arbeitsmethodik, wenn ein Grundziel schnell erreicht werden muss.
Ich glaube das „Think big, act small“ funktioniert aber nur wenn man schon verschiedenen Projekte durchgezogen hat. Man braucht einfach die Erfahrung um ein bißchen in die Zukunft zu schauen, aber eben nicht zu „over-engineeren“.
Grundsätzlich glaube ich auch, dass jeder Chef die „quick & dirty“ – Lösung wählen wird, solange er damit einmal richtig Geld verloren hat. Denn nur so lernt man in der Wirtschaft. 😉
Jep Ulf, das ist eine der Voraussetzungen. Wer keine Erfahrung hat setzt sich bei der Methode schnell in den Dreck. Die andere ist zu wissen, wann welche Methode angebracht ist.