Kategorien
Quick and dirty auf Bewährung
Wir Softwareentwickler haben doch im Grunde zwei große Probleme, die immer und überall auftreten. Das erste Problem ist Softwarequalität. Es muss schnell gehen und die oberen zehntausend sind sich sicher, dass Qualität teuer und somit das erste ist, was gestrichen werden kann. Unit Tests sind bei vielen Projekten also einfach nur Ballast. Ein weiteres großes Problem ist, dass wir häufig Dinge bauen, die kein Erfolg werden. Wie oft ich schon von Leuten gehört habe, dass ihre Idee mindestens den Weltfrieden bringen wird. Aber so etwas kennt ihr bestimmt alle. Ich würde mal sagen, dass 50% der Features, die ich in meinem Leben umgesetzt habe, besser abgeschaltet werden sollten.
Jetzt kombinieren wir diese beiden Punkte einfach einmal. Wir bauen Zeugs, welches wir eh wegwerfen und ärgern uns über die Qualität der Dinge, die wir bauen. Irgendwie ein Widerspruch. Warum hohe Qualität bei Software die wir eh nicht wirklich benötigen.
Inspiriert hat mich Kris Köhntopp, als er ein wenig über den Alltag bei booking.com erzählt hat. Wie könnte man also vorgehen? Wir müssen unsere Software in zwei Teile gliedern. Der erste Teil beinhaltet alles, was sauber ist, zum Beispiel Core-Komponenten und auch erfolgreiche Features. Diese Gruppe muss sauber vom Aufbau und Testabdeckung sein. Mehr ist hier wirklich auch mehr.
Neue Features kommen erst mal in die Quarantänezone. Das geht bei kleineren und autarken Dingen wunderbar. Nehmen wir zum Beispiel die Top 5 Artikel auf phphatesme, wenn ich mir die Statistiken ansehe, wird mir klar, dass es ein unnötiges Feature ist. Also rausgeworfenes Geld, dass ich es damals sauber implementiert habe. Eigentlich hätte ich es „hinrotzen“ sollen und im quick and dirty Verfahren eine Lösung bauen. Wenn das Feature dann ein Erfolg wird, wunderbar, dann machen wir es einfach neu oder setzen unser Optimierungsteam dran. Wenn es kein Erfolg wird: Abschalten.
Ja ich weiß, wenn es mal da ist, dann wird es auch genutzt und eure Produkt-Menschen werden sicher nicht wegwerfen, was schon da ist. Ich glaube, dass dies aber erstens eine Frage der Kommunikation ist und zweitens werden sie ganz schnell sehen, dass ihr Featuredurchsatz nach oben geht und die Dinge, die sich wirklich als erfolgreich herauskrsitalisiert haben eine bessere Qualität besitzen. Schön war auch das Zitat von Kris „Wir haben jede Menge beschissenen Code da draußen, der uns reich macht“.
Nächstes Problem sind die Performance-Junkies. Das Tool muss irgendwann mal tausende von Usern abkönnen und deswegen brauchen wir Techologie X und es muss bis aufs kleinste optimiert sein. Am besten soll es auf einem Server laufen und und und. Bei mir ist es so, dass wir so viele Server im Betrieb haben, dass es kein Problem ist, wenn man noch mal welche hinzustellt. Was ich also sagen will. Wenn euer Tool/Feature im ersten Anlauf nicht viele User abkann, dann schlagt es mit Hardware tot. So teuer sind zwei Server in der Amazon-Cloud nicht, dass man sich das nicht leisten könnte.
Ich glaube, dass die Qualitätswelt mit einer solchen Vorgehensweise glücklich ist und auch die Entwickler, aber es bedeutet ein Umdenken im Prozess.
PS: Das ganze klappt nur bei Projekten und nicht bei Produkten. Sollte ich vielleicht noch zu dem Ansatz hinzufügen. Bei unseren redaktionellen Portalen wäre es ein Fortschritt.
Bevor du Kris erwähnt hattest, dachte ich so: hmm, erinnert mich an die booking.com Session von Kris.
Ich bin durch die Sache auch ein wenig inspiriert worden aber muss dazu sagen, dass es auch viel Disziplin abverlangt, meiner Ansicht nach, Dinge, die gut funktionieren, dann auch im 2. Schritt zu optimieren und nicht sagen: „ach, läuft doch, optimieren kostet Geld, lassen wir einfach so“. Und ich meine nicht die Performance-Sache, ich meine einfach den Coding-Style. Wenn du das n paar mal machst (oder n paar mal zu oft), verbaust du dir vielleicht die ganze Infrastruktur und dann wirds richtig teuer!
Ansonsten sehe ich das wie du, wäre natürlich ein Fortschritt, auch bei Projekten in einer Firma.
Wen du von Anfang an so dein Design planst, dass du möglichst autonome Komponenten und ein saubere Trennung von Kontext und Responsibility hast und die Dinge nur nach dem tatsächlichen Nutzen der Anwender baust, hast du die Probleme nicht.
Insgesamt eine Essenz von GettingThingsDone, CleanCode, agiler Entwicklung, guter Architektur und Domain Modeling.
Also beschriebst du dein „Problem“ genau so, wie es in der Praxis auch sein sollte…;-)
@Don Zampano: Welches Problem genau meinst du? Das wir unnötige Dinge bauen? Das wir zu viel Qualität haben bei Wegwerfprodukten? Oder das wir nicht immer in der Lage sind dieses Vorgehen anzuwenden?
Beim dritten Punkt gebe ich dir natürlich Recht, wenn man sauber entwickelt ist das meiste entkoppelt und ich kann „unsaubere“ Features dranhängen.
Hm, ich sag mal 😀
https://plus.google.com/u/0/114032130852913068411/posts/F2ArG8w5CYN
Ich meinte das ganze Problem.
Also „gut genug“ und „maximaler Nutzen“.
Da geht es dann weniger um Qualität, die sollte sowieso immer vorhanden sein, auch bei Dingen, bei denen man nur eine kurze Halbwertszeit erwartet oder man ahnt, dass sie wohl performanter sein könnten.
Aber sie müssen funktionieren und genau das tun, was verlangt wurde und einen konkreten Nutzen besitzen (für wen auch immer).
„Zum jetzigen Zeitpunkt gut genug“ ist als Qualitätmaßstab ebenso gut genug.
Denn woher weißt du bei Sachen, die du nicht hinrotzt (oder es zumindest meinst) ob es qualtativ hochwertig ist?
Letztendlich reduziert es sich fast immer auf „Welchen Nutzen bringt es?“ und „Ist es wart- und testbar“, oder?
„Warum hohe Qualität bei Software die wir eh nicht wirklich benötigen.“
Im Idealfall spürt man sowas vorher und entwickelt sie gar nicht erst, sondern sucht nach anderen Lösungen.
Qualität warum:
– erstens, um es zu lernen
– zweitens, der nächste der sich an den Code ranmachen muss, wird es dir danken (manchmal ist es dann doch länger im Einsatz als man dachte)
Hört sich wie folgt an:
– programm prototype
– test prototype lokal
– test prototype in real world for a subset of users
– if it works, refactor!
– test again in real world for a subset os users
– if it works, deploy for all
Ich hab ein privates Projekt, dass ich dahingehend aufbaue. Ich rotze gerade einfach nur die Funktionalität hin, weil ich ein Ergebnis haben will, dass funktioniert. Ich denke, derzeit fehlen mir noch 2-3 Features, die erfolderlich sind sodass ich es veröffentlichen kann 😉 Und dann mal abwarten, wie das Feedback ausfällt.
Moin Moin,
schöner Artikel! Wollte nur hinzufügen, das ein solcher Workflow sich wunderbar mit Git realisieren lässten. Um genau zu sein: Mit Git Flow. 😉
Schönes Wochenende euch. 😉
Malte
Hallöchen!
Schnell und schmutzig Prototypen bleiben jedoch häufig keine Prototypen. Dann soll da doch noch was erweitert werden und es muss ja wieder schnell gehen. Wenn man sich dann wirklich mal entscheidet einen Schnitt zu machen, bekommt man noch einen auf den Deckel, weil es ja jetzt erst einmal so lange dauert. Vor allem, wenn die Vorgesetzten überhaupt keine Ahnung von der Softwareentwicklung haben oder meinen sie hätten welchen, haben sie aber nicht.. Sei’s drum..
Allerdings bin ich auch kein Freund von 1000 Zeilen Code für ein einfaches echo, nur weil es den Standards für Softwarequalität entspricht. Es kommt glaube ich auch etwas von der Funktion selbst ab. Ist sie erweiterbar? Kann da noch was kommen? Wie hoch ist der Aufwand überhaupt?
Grüße,
Jacka
Meine Welterfahrung: Was Kunde funktional bekommt und sieht, ist für ihn fertig. Jegliche Weiterarbeit daran ist dann schwer bis kaum zu kommunizieren („was kostet denn das jetzt noch Geld, ich dachte wir sind fertig?“). Dazu kommt der eigene Anspruch und das Problem, dass Prototypen und Hacks halt extrem wartungsunfreundlich sind (dafür sind es ja eben Prototypen). Sicherheitsgedanken noch oben drauf, dann stellt sich langsam die Frage, ob man das noch mit ruhigem Gewissen veröffentlichen kann.
Fazit: Funktioniert für mich nicht.
Ich sehe das wie @nikosch und @jacka. Der Kunde zahlt nicht zweimal. Sobald er eine Oberfläche sieht und es funktioniert, ist der Fall für ihn erledigt. Solange es einen Festpreis gibt, kannst du dir selbst soviel unbezahlten Zusatzaufwand machen wie du willst (oder dein Chef dir den Hals umdreht).
Soll der Kunde aber das Refactoring selbst bezahlen, dürfte die Überzeugungsarbeit schwer fallen: „Erst liefern sie schlechte Qualität, dann müssen sie ihren Pfusch korrigieren und dafür wollen sie jetzt auch noch Geld von mir?“
Außerdem: „hinrotzen“ geht nur wenn vorher die Schnittstellen sauber entkoppelt wurden. In der Regel fängt Quick’n’Dirty aber ausgerechnet bei den Schnittstellen an. Subsysteme sauber zu initialisieren und zu abstrahieren – darin liegt gerade der Aufwand.
Der häufigste Grund für Quick’n’Dirty ist nämlich nicht Lines of Code zu sparen, sondern die bessere Lösung nicht zu kennen und sich nicht die Zeit zu nehmen, sie nachzuschlagen: wer vorher weiß wie es richtig geht, der kann es oft in der gleichen Zeit auch gleich richtig machen.
Auch wissen wir vielleicht erst 1 Jahr nach Projektabschluss welches Feature Erfolg haben wird und welches nicht. Bei politischen Gründen muss der Erfolg sogar noch nicht einmal entscheidend sein.
Beispiel: wer braucht die hässlichen Fratzen der Vorstandsmitglieder als aufwändige Bildergalerie auf der Startseite einer Bank? Oder das aufwendige „Wir-Sind-Toll“-Video, in dem die Vorstandschefs mit Dauergrinsen zu Musik aus „Odyssee im Weltall“ in Zeitlupe einen Gang entlang schreiten?
Aber verlass dich drauf: du wirst es nie wieder los. Eher kommen alle 4 Wochen sogar noch neue Bilder, Videos oder intelligenzbefreite Erweiterungen hinzu. Denn niemand traut sich dem Vorstand zu sagen, dass seine formvollendeten Doppelkinnträger ein Kundenschreck sind.
Deswegen Dito @nikosch: Das „machen wir später im Refactoring“ funktioniert für mich in der Praxis nicht.
Prototyping ist sicherlich nicht falsch und nichts anderes ist ja nach deinem Ansatz hier das „Quick-And-Dirty“-Arbeiten.
Wir haben aber immer wieder das Problem, sowohl bei privaten als auch bei geschäftlichen Projekten, dass wir vielleicht nicht als einiziger an diesem Projekte sitzen, wir nicht kontunierlich daran sitzen oder womöglich vom Buss angefahren werden, die Hälfte unserer Vergangenheit einbüßen und überhaupt keine Ahnung mehr vom Code haben.
Man kann heutzutage, in einem Zeitalter, wo so viele Menschen ihren Computer bedienen können und ich eigentlich ein bisschen mehr Technikverständis erwarten würde, ja nicht einmal mehr ordentlich kommentierten Quelltext ausliefern, weil alle Kunden denken, das wäre eine Sache, die man „mal eben schnell dazwischen schieben kann“ und eben auch entsprechend zahlen.
Das Problem, was diese Kunden eben nicht zu sehen scheinen und weswegen auch so viele Firmen mittlerweile nach China oder andere fernöstliche Länder gehen, um ihre Programme und Webseiten machen zu lassen, ist eben, dass diese Quick and Dirty-Zeug einen für IMMER! verfolgt. Irgendwann fast man seinen Code immer noch einmal an und wenn man ihn dann nicht mehr versteht oder womöglich komplett umstrukturiert, dann muss der Kunde tief in die Tasche greifen. Blöder Weise, will das keiner.
Klar hast du Recht, dass selbst ich manchmal denke: „Das muss doch auch irgendwie leichter gehen und schneller“, aber letztlich braucht qualitativ hochwertige oder wenigstens nachhaltige Arbeit nun einmal seine Zeit. Deswegen kosten handgefertigte Sachen ja auch so viel Geld.
Das einzige, was man da nur machen kann ist, sich auf Frameworks zu stützen, die einem wenigstens einen kleinen Teil der Arbeit abnehmen.
Gruß
func0der