Quick'n'Dirty ins nächste Projekt?
Kommentare

Wer möchte zu Beginn eines Softwareprojektes nicht zumindest theoretisch einmal die Wahl haben: Sauber vorbereitet, einfach zu nutzen und wartbare Architektur – oder schlicht Quick and Dirty hingeschmiert,

Wer möchte zu Beginn eines Softwareprojektes nicht zumindest theoretisch einmal die Wahl haben: Sauber vorbereitet, einfach zu nutzen und wartbare Architektur – oder schlicht Quick and Dirty hingeschmiert, bei Erfolg kann man ja schließlich immer noch nachbessern?

Stellt man die Frage vier Softwareentwicklern bekommt man möglicherweise fünf Antworten zurückgeliefert, denn wie so häufig verstecken sich hinter einer einfachen Frage viele komplexe Antworten.

Der Ausgangspunkt: Mit größeren Webanwendungen im Hinterkopf stellt Nils Langner die These in den Raum:

Ich möchte heute mal eine These (die ich nicht unbedingt 100% unterschreiben würde) in den Raum stellen. Es ist besser die erste Version eines Projektes quick und dirty zu entwickeln. Produkte würde ich hier erstmal nicht betrachten. Falls ein Projekt ein Erfolg sein sollte, dann kann man schließlich die Zeit, bis man eine wirklich gute Architektur zustande bekommen hat auch mit Hardware überbrücken. Nils Langner, 2010

Agil? Keep it simple? Und: Gehört saubere Architektur nicht als Grundpfeiler in ale Anwendungen?

Ganz so einfach wollen viele Kommentatoren das so nicht unterschreiben. Im Sinne einer schnellen Time-to-Market, so bestätigen die einen, käme man um einen ersten Quick and Dirty Ansatz kaum herum („Wo wäre Facebook heute, wenn sie erst HipHop und dann die eigentliche Seite für ihre Nutzer entwickelt hätten?“). Aber wie sieht die Sache aus, wenn man im Kundenauftrag unterwegs ist? Wird der Kunde bereit sein, eine Neu- oder Weiterentwicklung zu finanzieren? Oder generell: Welche Kosten entstehen bei nachträglicher Anpassung im Vergleich zu dem Ansatz, bei dem von vornherein Wert auf eine saubere Architektur gelegt wird?

Ich bin davon überzeugt, dass in dem 1 von 10 Fällen die Anpassung der Software zur Skalierbarkeit und Erweiterbarkeit teurer ist als in 9 Fällen eine gute Architektur als Grundlage zu verwenden und sie ggf. wegzuwerfen. Mike, 2010

Andere wiederum empfehlen agile Entwicklungsmodelle als Mittelweg, bei dem das Projekt Schritt für Schritt und unter Einbeziehung des Kunden um einzelne Features erweitert und um einzelne Bugfixes ergänzt wird. Was natürlich auch Mahner auf den Plan ruft, denn:

[…] bindest mit Agilität zunächst die Auftraggeber früher ein, weil schon die nicht wissen was sie wollen. Von den Kunden ganz zu schweigen. Martin, 2010

Aber vielleicht ist es auch einfacher, einen Schritt zurückzutreten. Anstatt sich zunächst an den Details aufzuhängen, empfiehlt einer der Kommentatoren, das Quick and Dirty besser durch ein Good enough zu ersetzen. Und so:

Dann kann man immer noch eine recht saubere Sache bauen, die aber nicht in den Bereichen Erweiter- und Skalierbarkeit zu Ende geplant ist, weil man nicht weiß, ob es denn je gebraucht wird. Das heißt aber ja nicht gleich Pfusch. DonZampano, 2010

Ausreichend beantwortet?

Zumindest überraschend viele Fragen offen. Jeder hat seine Erfahrung mit eigenen Projekten und je nachdem, wie diese ausgefällt scheint es ganz individuelle Rezepte für die Umsetzung von Webanwendungen zu geben. Im Grundtenor fährt man mit hinreichend durchdachter Architektur, Best Practices zur testgetriebenen Entwicklung und einem offenen Ohr für seinen Auftraggeber wohl ganz gut. Aber reicht das so allgemein schon aus? Sicher ist, dass einzelne Best Practices erst dann wirken können, wenn sie miteinander verknüpft werden. Ob es dazu ein Patenrezept gibt, muss diskutiert werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -