Kategorien
Gut genug Prinzip
Mir fällt gerade auf, dass ich euch noch gar nicht offiziell ein gutes neues Jahr gewünscht habe. Das hole ich jetzt hiermit nach. Frohes, neues Jahr! So das war’s. Jetzt wieder harte Fakten. Oder besser weiche Fakten, denn heute geht es um ein Prinzip, das ich auch erst einmal lernen musste: das „Gut genug Prinzip“.
Aber warum geht es in diesem Prinzip eigentlich? Wir sind „alle“ Entwickler und haben alle unsere eigenen Projekte schon mal veröffentlicht. Ihr kennt bestimmt das Gefühl, das man kurz vor Schluss hat. Dieses Gefühl hält einen davon ab das Projekt zu veröffentlichen, denn da gibt es ja noch diese eine tolle Idee, die ich noch unbedingt umsetzen muss. Dann kann es an endlich and den Start gehen. Aber nein, mittlerweile ist mir ja noch was Geniales eingefallen. Also wieder in die Tasten gegriffen und schnell das neue Feature runtergehackt. Das könnte ich jetzt ewig so weiter machen.
Man glaubt sein Projekt ist mit dem neuen Feature um so viel besser, dass man nicht ohne es leben kann. In den meisten Fällen ist das einfach Schwachsinn. Das Projekt ist gut genug im veröffentlicht zu werden. Den Rest könnt ihr nacharbeiten. Und wenn das Projekt mit den Grundfeatures kein Erfolg wird, dann wird auch die kleine Erweiterung nichts daran ändern. Ist zumindest meine Meinung.
Das ganze musste ich für mich aber auch erst mal lernen, denn ich war immer der, der alles perfekt haben wollte und „so“ nicht live gehen konnt. Inzwischen beherrsche ich das eigentlich ganz gut und kann z.B. auch mal mit einer Ideenschmiede leben, die keine IP-Sperre oder ähnliches besitzt. Keine Ahnung ob es den Begriff wirklich gibt, aber ich nenne das ganze „Gut genug Prinzip“ und bin damit glücklich.
Das Prinzip gilt übrigens nicht nur für komplette Projekte. Klassen, Methoden und ähnliches sind da genau so betroffen.
Mein Ausbilder hat das auch hier und dort mal fallen gelassen. Vollends dran gewöhnt habe ich mich aber leider auch seitdem noch nicht. Die eigenen Projekte betrachtet man halt mit anderen Augen.
Ich stelle bei privaten Projekten auch unfertiges ins Netz um schonmal vorab Meinung einzuholen, damit ich noch frühzeitig was verändern kann, denn schließlich „nutzt“ man sein eigenes Stück Software ganz anders als die Besucher 😉
PS: Neuerdings erreicht man http://phphatesme.com nicht mehr – nur noch über http://www.phphatesme.com. Absicht?
Meiner Meinung nach kann ich für mich persönlich ‚gut genug‘ immer nur sehr schwer einschätzen.
Wie kann ich das ändern? Einen Externen mal drüberschauen und beurteilen lassen?
@Dennis: Danke. Warst nicht der Erste, der mir den Bug berichtet hat, aber jetzt hatte ich endlich das Aha Erlebnis, warum es nicht geklappt hat. Müsste wieder klappen.
@Sascha: Ich mach mir mal Gedanken.
Das ist in der Tat ein schwieriges Thema.
Andere drüberschauen lassen bringt deswegen nichts, weil es ja meißt um „neue Funktionen“ geht. Ich hab zumindest das Problem und Nils schreibt ja auch darüber(so hab ich es verstanden).
Hier hat sich bei mir aber zum Glück die Selbstdisziplin durchgesetzt und wenn ich den Code soweit habe, dass die Hauptfunktion(das was die Applikation machen soll) implementiert wurde und „fehlerfrei“ funktioniert => wird es released.
Im Laufe der Zeit kommen sowieso die Rückmeldungen der Benutzer, was sie vermissen, ob es eventuell Bugs gibt, was man besser lösen könnte usw und dann starte ich erst die nächste Stufe und setze die neuen Ideen Stück für Stück um.
Ansonsten endet es ja wirklich mit einem „nie veröffentlichten“ Projekt (hab schon einige kleinere Sachen so in den Sand gesetzt)
Nils! Ich erinnere mich an unsere Unterhaltung über das Gut-Genug-Prinzip bei Guessasong und bin dir sehr dankbar über dein „Los! Veröffentlich es!“.
Ich denke, ja, Feedback von anderen ist wichtig, denn man selber wird mit den Entwicklungsmonaten betriebsblind und kann ggf. nicht mehr ganz unterscheiden ob man sich das Feature nur in den Kopf gesetzt hat oder ob es tatsächlich ein Showstopper-Bug ist. Das gilt nicht nur für die Frage, wann das Projekt veröffentlicht werden sollte, sondern auch die generelle Ausrichtung des Projektes.
Das Wichtigste ist aber in der Tat „Release It!“ denn die User sagen einem wenn es ein Erfolg wird schon, was man ändern sollte. Wenn du zu spät bist, kräht kein Hahn mehr nach dir.
Und wenn dir ein bahnbrechendes Feature jetzt fehlt, dann entwickel es in Version 2.
@Timo: Ja da kann ich mich auch dran erinnern. Habe danach aber auch noch öfters das Problem bei mir selbst gehabt. So langsam klappt es aber ganz gut. Gruß aus HH
Der Artikel erinnert mich an „Version 1 Sucks, But Ship It Anyway“[0] von Jeff Atwood.
[0] http://www.codinghorror.com/blog/archives/001313.html
Im Grunde kennt man das sogar von vielen Online-Startups. Ich sage nur „BETA“… („It sucks, but hey, it’s BETA.“)
Grüße zurück in die Hansestadt
Hm, die meisten engagierten Programmierer dürften früher oder später über das Problem stolpern.
Ich habe damit auch noch meine Probleme. Andere Leute zu involvieren ist da manchmal der leichteste Weg. Das beste Feedback ist jedoch immer ein Kunde, der mit dem Produkt dennoch absolut glücklich ist ;o)
Das Gefühl ist mir auch bestens bekannt. Wahrscheinlich ist man bei den eigenen Projekten einfach überkritisch. Ist aber vermutlich besser als eine zu frühe Veröffentlichung.
Für mich ist ein Projekt „gut genug“ wenn der Kunde das bekommt, was er bestellt hat und für was er zu zahlen bereit ist. Seid ihr mit euren Projekten immer so viel früher fertig, dass ihr noch Zeit habt, euch neue Killer-Features auszudenken und wie verrechnet ihr das dann? Oder bekommt der Kunde zusätzliche Features einfach nur so weil es cool ist? Ich bin manchmal einfach schon froh, wenn ich die stramm gesetzte Deadline schaffe. 😉