Kategorien
Gelten im Netz andere Gesetze für die Qualität von Software?
Eigentlich sollte der Artikel ja heißen „hinrotzen oder schön machen“. Aber man kann sich ja mal zusammenreißen und es schöner umschreiben. Fangen wir also von vorne an. Ein paar von euch wissen ja, dass ich Qualitätsmanager (und Architekt) bei einem großen Verlagshaus bin. Durch diesen Job hat man natürlich immer ein Auge auf Qualität. Software sollte wartbar, performant und und und sein. Ihr kennt das. Jetzt sollte ich noch dazu sagen, dass wir nur Projekte und kein dediziertes Produkt haben. Also viele Webseiten, aber (noch) keine gemeinsame Basis. So könnte man es auch sagen.
Ok, nehmen wir also mein ein Standard-Projekt. Eine Erweiterung einer Webseite um ein tolles neues Feature, das sich die Konzeption in mühevoller Arbeit ausgedacht hat. Nennen wir es das Super-Feature-0815. Dieses Feature wird natürlich Umsatz bringen und ein voller Erfolg werden. Vielleicht werden wir auch alle selig gesprochen. Wer weiß. Als Architekt will man jetzt natürlich für dieses Feature die beste Architektur bauen, so dass es in zig Jahren noch erweiter- und pflegbar ist. Man steckt jede Menge Gehirnschmalz rein und kommt so einem guten Ergebnis. Zieht man die QM-Brille auf, dann stellt man noch sicher, das getestet wird, unit tests geschrieben werden und der Continuous Integration Server auf hochtouren läuft. Gehen wir mal von aus, dieses Projekt macht also alles richtig und einen Professor der Softwaretechnik würden die Tränen kommen wenn er das System sieht. Freudentränen versteht sich. Na gut, man hätte das Projekt auch hinrotzen können. Dann wäre es ganz bestimmt nicht zig Jahre wartbar gewesen und erweitern hätte es auch niemand mehr können. Viele User? Nee Skalierbarkeit wäre wahrscheinlich auch nicht drinnen.Aber wir wissen ja alle, das man Software so nicht schreibt. Wir sind ja im Jahre 2010.
So jetzt geht das Feature an den Start. Relaunch. Komisch, niemand will das Feature nutzen. Irgendwie war es vielleicht doch nicht so der Heilsbringer. Welch Überraschung, das Projekt war kein Erfolg, so wie gefühlte 90% aller Web-Projekte auch. Tja dumm gelaufen. Jetzt haben wir eine perfekt gebaute Applikation, die keiner will. Skalieren muss das Teil nicht, erweitert wird es auch nicht. Wartung lohnt sich wahrscheinlich auch nicht, denn wenn man klug ist, ist die Lebenszeit dieses Features minimal.
Drehen wir die Zeit also noch mal zurück. Wenn man jetzt die Wahl hätte würde man sich wohl für die unsaubere Technik einlassen. Es tut schließlich nicht so weh nur was halb so teures wegzuwerfen. So jetzt fange ich mal an das zu erzählen, was ich eigentlich sagen wollte. 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. Ich meine wie oft hat wohl Facebook seine Applikation komplett von vorne geschrieben? Aus dieser Ecke habe ich auch mal den Satz gehört, dass wenn sie von Anfang an an dieser Architektur und Infrastruktur gebastelt hätten, dann wäre das Projekt nie zum Erfolg geworden, da es für die erste Zeit viel zu überdimensioniert war. Meine amilio.de und spam-me.org sind übrigens auch Schnellschüsse gewesen und ich bin im Nachhinein nicht traurig drüber.
Ach ja, ich will hier nicht über „Time -to-market“ reden, das ist natürlich auch wichtig, soll aber gar nicht diskutiert werden. So und jetzt bin ich auf eure Meinung gespannt. Seht ihr das genau so? Ist es die grausame Wahrheit oder eher eine dumme Idee vom ansonsten tollen und kompetenten Nils?
Ich stimme dir absolut zu. Auch bei Software gilt die Abhängigkeit von Qualität, Aufwand/Zeit und Preis:
– Muss ein projekt schnell realisiert werden, steigt der Preis und/oder die Qualität sinkt.
– Muss ein Projekt hohe Qualität haben, steigt der Auwand und somit der Preis
– Hat der Kunde nur ein bestimmtes Budget zur Verfügung, sinkt der Zeitaufwand und somit die Qualität.
Bei der Softwareentwicklung hat man den Vorteil, dass man vorhandene Frameworks oder (bei der Webentwicklung) vorhandene CMS verwenden kann, die meisten davon OpenSource und somit ohne weiteren Kostenaufwand. Dadurch kann ich, die dem Projekt am meisten entsprechende Software einsetzen und die Alleinstellungsmerkmale individuell implementieren, ohne jedoch das Rad zig mal neu erfinden zu müssen. In diesem Sinne: Planung ist die halbe Arbeit.
Bei meinen eigenen privaten Projekte, stelle ich erst eine funktionsfähige Version in den Vordergrund, so dass man entweder Investoren oder Besucher überzeugen kann, die Qualität und der Ausbau erfolgen später – wenn das Projekt nicht zu den von dir beschriebenen 90% gehört, die kein Erfolg werden. Alles andere ist Zeit und Ressourcenverschwendung.
Also meiner Meinung nach kann man eine solche These nicht einfach in den Raum stellen. Es spielen einfach viel zu viele Hintergrundinformationen eine Rolle um dazu eine passende Antwort geben können.
Angenommen ein Projekt entsteht nicht aus einer eigenen Idee, sondern man wird von jemanden Beauftrag dieses umzusetzen. Dann spielt es eine sehr große Rolle ob man für das quick & dirty Projekt bezahlt wird, oder ob der Auftraggeber mehr Geld und vorallem Zeit in dieses Projekt investieren will 😉
Sollte ich mir jemals ein eigenes Projekt ausdenken, so könnte die Quick & Dirty Lösung wohl wirklich die beste Variante sein, um zu sehen, ob sich das Projekt überhaupt lohnt 😉
Meiner Meinung nach ist das Problem, dass die Herstellung von qualitativ hochwertiger Software nicht einfach so geschieht. Würden die Menschen, die Features umsetzen „aus dem Bauch heraus“ gute Software bauen können, hätte man 2 Probleme gelöst:
– Die Software würde nur unwesentlich teurer als „hingepfuscht“
– Die Software wäre im Erfolgsfall schnell skalierbar
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.
Gründe dafür sind u.a. dass die umsetzenden nicht gewohnt sind auf hohem Niveau zu arbeiten. Programmieren ist ein Handwerk. Wenn man es nicht mehr ausübt verlernt man es.
Weiterhin habe ich in meiner Laufbahn als Entwickler in und mit vielen Unternehmen gearbeitet in denen Features als „Heilsbringer“ verkauft wurden: „Wenn wir das Umsetzen sind wir saniert.“
Leider hat niemand vorher mal geguckt, wie die Kunden darauf reagieren könnten. Heisst: Nicht alle Anforderungen wurden eingesammelt oder aber es wurde nach dem Wasserfall-Modell entwickelt und erst am Ende hatte der Kunde die Möglichkeit zu sehen, was da kam. Schlecht.
Meiner Meinung nach kann man mit agiler Entwicklungsmethoden und damit einhergehend, die User früh einbinden. Man bekommt schnell Feedback und kann das in die Software einfließen lassen. Dabei kommt dann auch eine gute Architektur dem Projekt zu gute.
Für mich ist eine Mischung aus agiler Entwicklung, guter Architektur und Qualitätsmanagement sowie Verantwortlichkeit, das Fundament für einen Erfolg. Nicht zu vergessen ein cleveres Marketing, dass es schafft die User zum Feature zu locken.
Mit dieser Kombination kann man vielleicht 2 von 10 Projekten zum Erfolg führen. Was aber immerhin eine Steigerung von 100 % bedeutet.
Mike
Ich denke es geht wohl leider doch eher in die Richtung
‚grausame Wahrheit‘.
Ich denke, ein richtig Projekt sollte man nicht „quick and dirty machen“, aber vll. kann man die QM weglassen! 😉
Zum einen bin ich der Meinung, dass man schon vorher den Markt analysieren soll, wenn dann kein Bedarf für das Projekt festgestellt wird, sollte man es gar nicht und nicht „quick and dirty“ machen. Ist die Bedarfs-Frage nicht gefragt finde ich die Idee des Prototypings sehr interessant (und würde sie gerne öfter anwenden 😉 )
@Mike: Agilität könnte dort wirklich was reißen, da muss ich dir Recht geben.
Auch wenn du nichts von Time to market hören willst: Wenn Facebook von Anfang an die perfekte Architektur gehabt hätte, würden wir jetzt vielleicht alle Wallop oder sonst was nutzen (ok, ich nutze kein Facebook, aber egal). Ich denke darum geht es tatsächlich in erster Linie. Facebook hat einen PHP-Compiler gebaut um performant zu werden. Hier sieht man es: Zuerst quick and dirty (wir nehmen PHP weil man damit schnell neue Features umsetzen kann) und dann Performance (-> hiphop). Hätten sie als erstes mal Hiphop entwickelt, bevor sie überhaupt mit Facebook angefangen haben, hätten wir jetzt weder Hiphop noch Facebook (was man davon bedauern würde darf jeder selbst entscheiden).
Und: Webprojekte für Endnutzer leben im Vergleich zu Desktop-Anwendungen und erst Recht Unternehmens-Software ohnehin meist verhältnismäßig kurz. Was nutzt da die Super-Architektur?
Anders sieht es aus wenn ich ein Intranet-Projekt entwickle, von dem ich weiß, dass ein Unternehmen die nächsten 10 Jahre damit arbeiten soll.
Genau das hab ich auch schon vor einiger Zeit überlegt. Warum stecke ich so viel Energie in ordentlich gewartete Features? Warum achte ich darauf, dass im Code kein einziger String steht, sondern alles schön sauber in Sprachdateien abgelegt ist, sodass alles fein übersetzt werden kann, wenn ich weiß, dass die Website eh nie eine zweite Sprache bekommt. Warum schreibe ich den Code so, dass er möglichst wiederverwertbar an anderer Stelle ist, wenn es die andere Stelle nahezu nie gibt?
Eigentlich schwachsinnig und trotzdem gebietet es mir meine „Programmierer-Ehre“ nicht, den Code hinzurotzen. Und für genau das eine mal, wenn der Projektmanager kommt und ein neues Sub-Feature will und ich einfach nur 2 Einstellungen anpasse und es sofort funktioniert, für diesen einen Moment mache ich das. Und was bringt’s? Der Projektmanager weist mir das nächste Ticket zu, ohne zu honorieren, wieviel Zeit ich gerade gespart habe und wie „cool“ das jetzt gerade war… So business as usual und jeden Morgen in den Spiegel schauen können, weil man den sauberen Code (gerade im Web) meist nur für sich schreibt. Denn der Idiot, der den Kram hinterher verstehen muss ist meist der selbe, der ihn geschrieben hat.
Ganz knifflige Frage 😉
Das „quick and dirty“ ist im Lauf der Jahre ein Stück weit als Antithese zum Wasserfall entstanden. Um architektonisch durchdacht und qualitativ hochwertig unter Bereücksichtigung aller möglichen Features zu arbeiten werden die Budgets schnell sehr groß und werden deshalb gerne mit überzogenen Nutzen-Schätzungen versehen.
Konsequente Agilität kann hier wirklich helfen. Eine wichtige User Story an den Start bringen, wenn die vom Anwender angenommen wird, kann man weitermachen. Dann sollte Refactoring vor der 2. Story allerdings nicht vergessen werden.
Seit längerer Zeit mit wenig kontroversen Beiträgen (wie ich finde) mal wieder ein hcoh interessanter Artikel. Meine Argumente sind nicht persönlich gemeint, schreibt sich nur besser…
Zunächst glaube ich, dass Du deine These nicht nur auf Web beschränken musst. Die Unterschiede der einzelnen Dömänen verschwinden doch zusehenst und selbst bei Embedded Software findet die erste Version nur Eingang in Prototypen und könnte dementsprechend auch hingerotzt werden. Oder wo ist der Unterschied von deinem Tool für eure Website und einer App fürs IPad oder sind das auch schon „Netz-Programme“?
Vor dem Hintergrund führt die Diskussion sehr schnell zum allgemeinen Sinn von Qualitätsmanagement und Architektur.
Viele der von dir angeführten Dinge sollen ja die Entwicklung schneller machen und nicht langsamer. Deine Architktur verfügt in aller Regel über Dinge wie ein Cachingkonzept, Anbindung an CMS, Werbung, Datenbanken etc. Das müsstest Du ja alles vom Urschleim aufsetzen.
Die Unittest bringen dir schon bei der Entwicklung Geschwindigkeitsvorteile, von Test-driven mal ganz zu schweigen.
Und was machst Du eigentlich wenn dein Rotz den Rest des Systems runterreißt, Sicherheitslücken schafft oder Arschlangsam macht. Diese Risiken blendest Du mit deinem Ansatz komplett aus. Wer jetzt behauptet eine gute Architektur und Qualität des Gesamtsystems kann das ab und ermöglicht so den Einbau von Crap um einfach mal was auszuprobieren, meint ja auch nur, dass QM und Architektur an vielen Stellen Risiken minimiert und Profitabilität erhöht.
@Mike: du 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.
Klar: ein vorgegebenes Projekt-Budget und ein in vorgegebener Zeit umzusetzendes Feature-Set beeinflussen die Qualität eines Projektes. Doch wenn die drei Punkte Budget, Zeit und Qualität nicht in einem halbwegs vernünftigen Verhältnis zueinander stehen, dann steht das Projekt von Beginn an unter keinem guten Stern.
Meine Überzeugung: eine effiziente Test-Strategie spart mindestens so viel (v.a. Fehlersuche und -behebung während Entwicklung und Betrieb) ein, wie das Schreiben der Unit-Tests kostet. (Meszaros hat dazu unter „Economics of Test Automation“ auf http://xunitpatterns.com/Goals%20of%20Test%20Automation.html eine kleine Grafik.)
Test-Driven-Development und Unit-Tests sind zwar nicht QA – aber ein wesentliches Fundament. Einige Informationen zu effizienten Test-Strategien finden sich in meinem Talk von der PHP-Unconference: http://nunninger.info/projekte-und-veroeffentlichungen/praesentationen
Schöne Grüße
Thomas Nunninger
@Martin: Ich habe meine These auf das Web reduziert, weil ich hier viel einfacher mit Fehlern umgehen kann. Ein Release ist sehr schnell auf alle User ausgerollt. Wenn ich jedoch „herkömmliche“ Applikationen habe, so kann es problematischer sein bei allen Nutzern die Stände zu aktualisieren. Fehler sind daher rufschädigender als bei den WebApps.
Also mal ehrlich. Die Erfolgsaussicht eines Projektes sollte bereits vorher geprueft worden sein. Wenn an ein Projekt nicht geglaubt wird, sollte man es garnicht erst starten. Das faellt aber auch nicht in den Verantwortungsbereich der Entwicklung, der Architektur oder der QM!
Wie waere es nur um die QM bestellt, wenn sie sich in der Verantwortung saehe proaktiv guenstige Abbruchkriterien fuer unausgegohrene Businessplaene zu schaffen? Dafuer sind andere Beteiligte verantwortlich.
Man stelle sich vor die Haustechnik in einem Hotel stellt erstmal nur einen Wassereimer mit Seife und Schwamm hin, wenn der Direktor eine neue Dusche ordert nur weil nicht sicher ist, ob die Gaeste denn ueberhaupt duschen wollen?
Eine Quick n Dirty Loesung feuert auf so vielen Ebenen zurueck, denn nicht nur gefaehrdet sie Performance, Skalierbarkeit, Wartbarkeit und Stabilitaet. Nein sie gefaehrdet sogar die Akzeptanz beim User und damit die Erfolgsaussichten.
Im nachhinein eine Wart- und Erweiterbarkeit zu erlangen schliesst sich doch realistisch betrachtet von vornherein aus.
Zu einen technich, weil zu nachtraeglichen Einbau der Erweiterbarkeit, diese bereits haette gegeben sein muessen.
Vor allem aber aus Projektleitungssicht. Denn das Maintenance Budget wird nie an das initiale (und bereits aufgebrauchte) Umsetzungsbudget heranreichen.
Und sollte doch ein groesseres Budget um die Ecke kommen, werden daran immer Erwartungen neuer Features gekoppelt sein (wieso Refactoring? Laeuft doch! Und ich will ja ein neues Feature.).
Warum sollte die Projektleitung denn diese Kosten akzeptieren ohne sichtbaren Mehrwert wie es eben nur neue Features sein koennen? Sie steht immerhin in direktem Kontakt zum Kunden und spaetestens dem fehlt doch in den meisten Faellen jegliches Verstaendnis fuer Softwarequalitaet. Fuer ihn kann nur klar sein: eine Erweiterung eines Projektes muss weniger Kosten als das Projekt selbst gekostet hat.
Wenn ich jetzt die Winterreifen an meinem Auto wechseln lasse, waere es mir jedenfalls nicht zu erklaeren, dass es teurer ist als das Auto selbst war, nur weil ich damals ne Quick n Dirty Version akzeptiert habe.
Und nochwas: Kann ueberhaupt sichergestellt werden, dass die Projektleitung nach dem Quick n Dirty Projekt ueberhaupt noch dieselbe ist!
Quick n Dirty kann nur in Ausnahmefaellen (Time to Market) akzeptiert werden und das auch nur, wenn die Projektleitung und der Kunde dieses ausdruecklich einfordert unter Kenntnisnahme aller Konsequenzen und idealerweise mit dem Commitment im Erfolgsfall sofort nachzuruesten ohne zum selben Zeitpunkt und unter Verwendung desselben Budgets neue Features zu erwarten. Aber wie realistisch ist das?
Hallo,
ist es nicht so, dass wenn ein Projekt wirklich läuft, man eh keine Zeit hat es neu zu entwicklen? Man muss dann zusätzliche Entwickler dazu nehmen, sodass die Neuentwicklung mehr Geld kostet als eine richtige Entwicklung von Anfang an. Ich denke wenn die Marketingabteilung das vorher richtig evaluiert, ob das Produkt ankommt, kann man einen Mißerfolg sicher mehr ausschließen, als irgendwas einfach mal ins Netz zu stellen.
lg ralf
Dass man vorher prüfen kann, ob ein Projekt ein Erfolg wird, halte ich eher für utopisch. Und die Millionen gefloppten Projekte bestätigen das wohl.
Ich sehe das halt bei einigen unserer Projekte, dass man mit einem Wegwerfsystem viel besser gefahren wäre. Man muss sich dabei natürlich eingestehen, dass etwas keinen Erfolg hat.
Schon ein Stueck weit erschreckend, dass eine gute Architektur und QM oft scheinbar als reine Lehre und wenig pragmatisch verstanden wird.
Eine gute Architektur zeichnet sich doch nicht dadurch aus, alle moeglichen Best Practices umzusetzen sonder Projekt spezifische Kriterien zu beachten. ZB Modulares Entwickeln, was kaum mehr Zeit kostet sondern oft bereits vor Launch Ersparnisse bringt, den Change findet nicht erst nach Launch statt.
Ich würde stärker zwischen „Feature“ und „Projekt“ unterscheiden. Ein Feature das quick & dirty umgesetzt ist (keine Unit-Tests, Klasse mit einer großen Methode), ist ein isolierter Teil innerhalb eines ansonsten stabilen Gesamtsystems und kann dieses zunächst nicht ernsthaft gefährden. Wenn aber bereits das Gesamtsystem (= Projekt) quick & dirty begonnen wird, ist später in der Regel nicht mehr all zu viel zu retten – denn:
„Nichts hält länger als ein Workaround“.
Aus eigener Erfahrung kann ich nur stark davon abraten, diesen Weg auf Grund Drucks irgendeiner Seite (sei es Chefs, PM, „Kunden“, etc.) zu beschreiten. Du betrachtest für deine Theorie den Fall eines Scheiterns des Projekts, in dem weniger verloren geht. Sobald eines der so umgesetzten Projekte ein „Erfolg“ wird, kommt’s erst richtig lustig:
– Wie mein Vorredner bereits beschrieben hat, ist jedes neue Budget/Zeitkontingent an die Erwartung geknüpft, dass dadurch neue Features entstehen – Optimierung oder Refactoring kann wenn nur im Vorbeigehen „eingeschmuggelt“ werden (so lange noch ein gewisser Anspruch an Qualität vorhanden ist und freiwillig auf eigene Kosten von den Entwicklern umgesetzt wird).
– In der Regel soll das Projekt „dupliziert“ werden, um das als funktionierend erkannte Modell auf mehrere Bereiche / Produkte / etc. zu adaptieren. Da das Projekt ja „bereits programmiert“ ist, wird erwartet hier nach „copy & paste“ vorzugehen und auch nicht mehr Zeit / Budget dafür zur Verfügung gestellt. Damit hat sich dein Problemfall auf einmal vervielfacht.
– Da das Projekt nicht ordentlich abgetestet ist und meist von der Architektur Mängel aufweißt, reißt jedes neue Feature an irgendwo neue Bugs auf. Dementsprechend folgt Ärger von oben oder dem Kunden („warum denn jetzt schon wieder“). Jede Live-Stellung einer neuen Version wird zum Lotterie-Spiel.
– Aus der Gesamtsituation erfolgt Frustration bei den Entwicklern, die keinen Spaß mehr an der Arbeit haben, nicht stolz auf „ihre Arbeit“ / „ihr Projekt“ sein können. Wenn das ganze einen Zeitraum von 12 Monaten überdauert, können schon mal erste Abgänge von Entwicklern eingeplant werden.
Das läuft dann so lang, bis irgendwann die Schmerzgrenze erreicht ist, unter der ein Rewrite des Projekts akzeptiert wird. Der sollte dann aber bitte mindestens 50% mehr Features enthalten, die sich dann ja eh viel leichter integrieren lassen und das Ganze darf nur halb so lang dauern wie der erste Versuch, schließlich weiß man ja schon wie’s funktioniert. Unter diesen Bedigungen entsteht dann das nächste Chaos-Projekt.
Ich plädiere nicht dafür, alles von vornherein auf jede Eventualität vorzubereiten – bspw. Caching oder Clusterfähigkeit. Aber zumindest Architektur der Applikation und Qualitätssicherung (= Testing) sollte von Anfang sauber aufgesetzt und berücksichtigt sein, sonst geht’s im Erfolgsfall gegen die Wand.
@Christian: Würde nicht sagen, dass es NUR reine Lehre ist. Beides macht auf jeden Fall Sinn, sonst würde ich meinen Job nicht so gerne haben. Die Frage ist nur, ob es wirklich in jedem Projekt Sinn ergibt.
Wahrscheinlich kommt es auf die Größe des Projektes an. Wenn dich während der Entwicklung noch alles einholt, dann kann es schon sein, dass die saubere Lösung die günstigere gewesen wäre.
Aber nehmen wir einfach mal ein Beispiel aus diesem Blog. Wäre es wirklich sinnvoll gewesen die Ideenschmiede als architektonisches Meisterwerk zu bauen?
Schließe mich hier Mikes Meinung an und denke auch, dass konsequente Agilität wirklich helfen kann.. Es gibt hierzu inzwischen den Begriff „Lean Startup“, was im Grunde genommen eine Adaption agiler Methodiken ist: statt monatelang an einem Projekt zu schrauben und die erdachten Use-Cases bis ins kleinste Detail zu implementieren, lieber mit kleineren Paketen starten und in stetigem und engen Kundenkontakt die Idee reifen lassen.
Im Grunde sind das ja nichts anderes, als die „lean“ Prinzipien: Verschwendung vermeiden.
Konkret auf die These gestützt, wäre eine wirkliche Quick’n’Dirty Lösung aber vermutlich tatsächlich kontraproduktiv. Wenn das Projekt mit Bugs live geht (und das wird es 😉 ), muss es zumindest wartbar sein und schnell angepasst werden. Eine komplett unbrauchbare Architektur würde es auch verhindern, schnell und zeitnah auf den Kunden reagieren zu können.
Meiner Meinung nach sollte die Grundbasis also halbwegs solide sein. Das ist an der Stelle aber das gleiche, wie sich über die Auslegung von KISS sicherlich streiten lässt und von vielen anders interpretiert wird.
„Quick & Dirty“ klingt so hart, erstezen wir es mal mit „Good Enough“.
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.
Denn ob man solche Dinge braucht, zeigt erst die Zeit. Meist sind es dann sowieso „Luxusprobleme“. Und das Projekte auch mit vorhandenen (kleineren) Bugs erfolgreich sein können, wenn die Basis stimmt und die Idee gut ist, wurde auch schon mehrfach bewiesen.
IMHO ist es aber wesentlich entscheidender eine Antwort auf die Frage „Wie gut muss unsere Anwendung sein, damit sie ein Erfolg wird und wir in die Verlegenheit kommen, sie zu perfektionieren?“ zu bekommen.
Das wichtigste Stichwort für weitere Recherchen: Getting Real…
@DonZampano Deine Aussage gefällt mir.
Auch, wenn ich wohl ins Phrasenschwein blechen muss:
Die Wahrheit liegt doch ganz oft irgendwo dazwischen. Time 2 Market, Quick and Dirty, Modularität, Unit Tests… Hat alles seine Daseinsberechtigung.
Ich weiß nicht, ob es alle falsch machen, die ich kenne, aber: Die mir bekannten Unternehmen, die z. B. recht dogmatisch auf Scrum setzen, sind unterm Strich nicht erfolgreicher als Quick-and-Dirty-Klitschen. Die Qualität ist idR besser, aber nun auch nicht riesig unterschiedlich. Dafür aber die Umsetzungsgeschwindigkeit.
Man muss sich m.E. entsprechend der Begebenheiten seiner Methoden bedienen. Immer nur Quick and Dirty führt genauso wenig zu dauerhafter Freude wie zu saubere Entwicklungsmethoden. Beides kann aber durchaus erfolgreich sein. Ich will damit sagen, dass die Wahrheit ganz einfach immer irgendwo dazwischen liegt. Irgendwo zwischen Quick and Dirty und 100% Unit-Test-Abdeckung.
So ist es wichtig, dass der Kunde schnell was zu sehen bekommt, um ein Projekt oder eine Software in die richtige Richtung zu lenken. Und oft genug ergibt sich längerfristig dann auch die Chance, Dinge gerade zu rücken oder sauberer weiter zu machen.
Und auch bei sorgfältig durchgeführten Erstentwicklungen will man ein Produkt irgendwann doch ganz gern nochmal anfangen.
Wie gesagt: Die Wahrheit liegt irgendwo dazwischen. Und ich persönlich tendiere sogar ein wenig von der Mitte weg Richtung schneller Konzepte.
@Nils das ist genau das, was ich meine. Wieso sollte es je ein Meisterwerk werden? SW Architektur sollte immer dem Projekt dienen und nicht dem feuchten Traum des Architekten. Auch „richtige“ Architekten entwerfen Mehrfamilienhäuser, wenn die gefragt sind und nicht das Taj Majal oder den Eifelturm. Es muss funktional und angemessen sein.
@DonZampano: Muss mich da Kim anschließen. Gut formuliert und würde ich so unterschreiben. Danke.
Danke für den interessanten Artikel und vor allem die super Diskussion!
Ich bin auch der Meinung, dass man nicht immer alles perfekt planen muss, vor allem wenn der Erfolg eines Projektes/Produktes unklar ist.
Aber häufig kann man mit einer guten Softwarearchitektur das anfängliche quick&dirty sehr schnell wieder aufholen.
Und eines sollte auch noch gesagt sein. Ich höre immer wieder, dass Qualität viel Zeit braucht und dadurch auch viel kostet. Wenn man aber permanent versucht, qualitativ hochwertig zu entwickeln, wird man mit der Zeit ein besserer Entwickler. Man hat dann einfach mehr Übung gute Software zu entwickeln und dadurch wird man schneller. Beim Kunden kann man immer noch die gleichen Ansätze verlangen und die restliche Zeit in Weiterbildung investieren… dadurch kann man sein Niveau wiederum steigern. Ich empfinde dies als eine schöne Vorstellung.
Die Schnelllebigkeit im Netz ist wirklich ätzend und IMHO nicht zu unterstützen. Es gibt aber auch – hinter Markt-Hype-Gedanken – eine Qualitätsschicht im Netz. Software, die qualitativ hochwertig ist, nur marginal erweitert wird und dadurch jahrelang erfolgreich ist, dass sie verlässlich ist.
Mir fällt als Gegenbeispiel ein, dass ich vor kurzem ein Twitter-Cient-Plugin gesucht habe. Fand eines, das war vielversprechend und hübsch. Aber buggy. Nach 2, 3 Fehlern der Basisfunktionalität (Tweets anzeigen) habe ichs entsorgt. Wem nützt ein Prototyp, den man dann nicht benutzen kann? Der Markterfolg ist auch dahin, wenn die gesamte Community abspringt, weil man auf Dauer nicht mit den Qualitätsmängeln leben kann.
IMHO ist hingerotzt immer eine schlechte Wahl. Die meisten Argumente wurden ja schon genannt:
– Im Zweifel muss ich das Teil noch Jahre pflegen und später wieder anfassen
– Die Mittel aquirieren, um ein erfolgreiches Produkt nochmal „richtig“ umzusetzen (und dann erkläre man den Geldgebern mal, Dinge wie Sicherheitsaspekte, die man nicht sehen oder anfassen kann). Eine Q&D-Version wird dann schnell zu Bumerang, wenn der Aufwand hier plötzlich zu hoch eingestuft wird und eine Neuumsetzung abgelehnt wird
– Im worst case werden neben der Neuentwicklung in der Ur-Version weitere Features implementiert, die ab sofort doppelt gepflegt werden dürfen
– Für eine Software, die von vornherein floppt, wurde schlechte Marktanalyse betrieben oder anders gesagt, hat hier eine andere Abteilung Ergebnisse herausgerotzt, statt den gebotenen Aufwand zu betreiben.
Als Quereinsteiger in Sachen Web-Development macht mich der Artikel aus einem Grunde glücklich: auch etablierte Profis kochen nur mit heißem Wasser.
Bei all den Buzz-Word-Ungeheuern bin ich froh, daß hier wohl jeden die üblichen Gewissensbisse plagen. Es ist schön, mit seinem – mal schlechten, mal gutem – Gewissen nicht alleine zu sein. 😉
Ich denke, mit dem .NET-Framework und C# wäre es nicht so weit gekommen, immer schön locker objektorientiert das Problem kausal lingual lösen…
Mir fällt es auch immer sehr schwer montags mein Gehirn abzuschalten, um halbwegs unbeschadet in der BRD arbeiten zu können. Intellekt ist einfach unerwünscht in dieser tollen BRD. Früher konnte ich als Mensch wenigstens die STASI ärgern, heute ärgert mich die Dummheit der deutschen Bürger. Die Deutschen sollten wie 1989 schon einmal praktiziert, endlich wieder einmal den aufrichten Gang erlernen, ist nicht nur gesund für die Wirbelsäule.
Q&D respektive „good enough“ scheint im Zuge der agilen Softwareentwicklung immer Salonfähiger zu werden. Dies merkt man auch am immer häufigeren Auftreten von buzzwords wie KISS und YAGNI. Meiner Meinung nach eine gute Entwicklung. Doch wie sieht das Ziel dieser Entwicklung aus?