Kategorien
Wenn du es baust, wird er kommen!
Filmzitate sind was tolles. Vielleicht sollte ich ja jeden Tag mit einem anfangen. Mir würde es gefallen, aber damit das klappt, müsste ich noch mehr Fernsehen schauen und eigentlich hab ich da keine Zeit zu. Lassen wir das also. Das Zitat ist übrigens aus Feld der Träume, falls es jemanden interessiert.
Ich will aber in diesem nicht einfach über den Film reden, sondern über Prototyping. Wie immer hole ich dazu ein wenig aus. Ich bin beruflich gerade dabei ein relativ großes und wichtiges Projekt zu begleiten, toller High-Tech-Schnickschnack, mit ganz vielen neuen Technologien. Im Moment sind wir dabei das architektonische Grobkonzept zu verfassen. Wir sind bereits bei Seite 27 und haben immer noch geniale Ideen, wie man jetzt die Schnittstellen zu bauen hat und wer mit wem kommunizieren darf. Ich glaube da sind uns wirklich ein paar gute Dinge eingefallen. Aber auch wenn das das beste Konzept aller Zeiten sein mag (und das ist es sicherlich), so habe ich doch ein mulmiges Gefühl.
Warum? Alles was wir da geschrieben haben klingt auf dem Papier super und sowas wie „auf Abwärtskompatibilität ist zu achten“ ist einfach geschrieben, aber die Hölle, wenn es um die Umsetzung geht. Man sollte also irgendwann mal mit einem Prototypen dessen was man umsetzen will beginnen. Nur so gewinnt man wirklich ein Gefühl für das Konstrukt, welches es zu erstellen gilt. Ich meine viele Dinge kann man ja auch erst zur Laufzeit entscheiden, denn ich habe keine Lust auf de Reißbrett schon zu berechnen wie häufig eine bestimmte Komponente durchlaufen werden muss und wie sie deshalb aufgebaut sein sollte. Mein Vorschlag wäre also: Starte mit einem architektonischem Grobkonzept, beginne mit einem Wegwerfprototypen, schreibe das Feinkonzept und beginne dann mit dem Produkt.
Natürlich lohnt sich das nur bei Projekten, die einen auch wirklich eine Weile begleiten und eine gewisse Größe übersteigen. Aber ich glaube da hat jeder ein Gespür für, das brauch ich wahrscheinlich nicht dazusagen.
Oh man, Du sprichst mir aus der Seele. Habe auch mal ein riesen Projekt bei einem deutschen Versandunternehmen als Archikekt begleitet. Wir haben viele 1000 Seiten Konzept Geschrieben und bei der Umsetzung dann ist das Projekt eingestampft worden. Offiziel hat man einen Grund vorgeschoben, aber jedem war nach spätestens 2 Jahren Konzeption klar, das kann man nicht mehr realisieren. Aber die PL wollte davon nichts hören …. Prototyping hätte uns gerettet und unglaublich viel Asche gespart.
Hallo !
Leider ist es wirklich so. Es werden Projekte begonnen bei denen
am Anfang Ideen und Papier in Massen produziert wird.
Und nach einer gewissen Zeit stellt man fest, daß zwischen dem Plan
und dem tatsächlichen Projekt große Lücken auftreten. Also einen neuen
Plan mit gewaltigen Dimensionen geschmidet und viel Papier beschrieben und
frisch losgelegt.
Alles gut ???
Nach einer gewissen Zeit stellt man dann wieder fest das die Realität vom Plan nicht unerheblich abweicht. Man könnte ja einen neuen genialen Plan schmieden und … .
Oder man könnte eine Unternehmenskultur verwenden die in gewissen Abständen Teile des Planes entwickelt und zur Realisierung freigibt.
Mir fällt sofort Scrum ein.
Leider haben wir (Deutschen) das mentale Problem das wir unbedingt vor der Freigabe von Finanzen und Resourcen
einen Plan benötigen, möglichst im Umfang eines Telefonbuches.
Daher wird ein Plan erstellt. Bitte von oben beginnend weiterlesen. 🙂
Gruß Stephan
Das ist ein Bundy-Zitat! Jawoll!
^^
@Dominik: Die Folge, in der er die Toilette baut?
Nö, eigentlich baut Bud was damit sein alter ego kommt. Dann sitzt Al dort und hört auch die stimme… „Wenn du es baust wird er kommen“ 5 sekunden später: „Oder wenn du willst das man es für dich baut drücke die 0“
oh good old times 🙂
@Ludwigr: Stimmt, jetzt kommen die Bilder gerade wieder hoch. Danke.
Bei uns wurde Scrum vor einem Jahr eingeführt und bei uns liegen die Probleme meist woanders. Neue Software hat eigentlich keine Probleme mit der Architektur oder der Skalierung, da sie immer „auf den Punkt“ entwickelt wird, wie wir es jetzt brauchen und ab einem gewissen Grade der Entwicklung kommt dann weitere Skalierbarkeit hinzu.
Schlimmer ist hier der Legacy Code und damit verbundene Fehlentscheidungen, dam an „das große Ganze“ sofort in der 1. Implementierung zu 100% abdecken wollte. Heute wissen wir, dass das garnicht geht 😉 und man sich immer nur an die „perfekte“ Lösung annähern kann.
Ich habe auch das derzeit das Vergnügen, ein in die Jahre gekommenes und immer schwerer wartbares System auf neue Architekturen umzustellen.
Dabei muss das alte auch noch parallel weiter laufen, bis das Neue schrittweise umgebaut wird. Und natürlich ohne die bestehenden Datenstrukturen neu zu überdenken.
Positiv ist allerdings, dass ich sage, wie es gemacht wird und ob es überhaupt erst mal groß auf Papier geplant werden muss.
Dabei gehen wir auch vornehmlich mit Entwicklung von Prototypen vor, die die bisherige Funktionalität abdecken (mit Wrappern und Proxies) und gleichzeitig einen Switch zum neuen System erlauben.
Solch große Legacy-Systeme bedürfen aber eines sorgfältigen schrittweisen Refactorings und jeder Menge Prototypen.
Vieles von dem schwebt im Kopf als Konzept herum aber es würde einfach nichts bringen, es langwierig zu papier zu bringen. Lieber einzelne Aspekte als Prototypen, Dummys, Parallelsysteme (z.B. zwei ORM’s die beide befüllt werden aber den Umstieg schrittweise ermöglichen – oder zwei parallele Models, wobei das neue das alte wrappt [CRUD->Domain Model mit den alten Modellklassen als Data Objects]).
Aber mein allerwichtigster Rat (ob Legacy oder nicht): fangt mit der Planung und der Einhaltung von SRP ganz oben an:
Gleich von Anfang zwei Modelle einplanen, eines fürs Lesen und das andere fürs Schreiben (Transaktionen).
Praktisch jedes System lässt sich dadurch entweder eleganter neu bauen oder verbessern und durch die Trennung kann man spezielle Probleme dediziert angehen, getrennte Teams können den jeweiligen Part isoliert bauen und optimieren.
Und vor allem braucht es auch wesentlich weniger Planung.