Versende es oder stirb (mit oder ohne Qualität?)

Eine der Ideen, die mich fasziniert, ist die Mentalität „Versenden oder sterben”. Es gibt Variationen davon, wie sie genannt wird, aber die Idee hinter dem Satz ist einfach:

Wenn Sie eine Idee haben, bringen Sie sie so schnell wie möglich vom Konzept zum Produkt.

Sicher, die Idee, ein Produkt vom Konzept zu entwickeln, kann auch als „Concept to Cash” bezeichnet werden, aber es gibt nie eine Garantie, dass Sie Bargeld generieren werden, oder? Es gibt jedoch eine Garantie, dass Sie es in ein greifbares Produkt bringen können.

Und in Softwareentwicklungskreisen gibt es immer viel, was man für oder gegen die Idee argumentieren kann. Spontan fallen mir spontan zwei Vor- und Nachteile ein:

1. Pro. Etwas schnell erledigen, das funktioniert und [potenziell] Einnahmen generiert.
2. Kon. Schwache Architektur, Wartung, Skalierbarkeit, Testbarkeit usw.

Kurz gesagt, es kann einen Kompromiss geben zwischen der Geschwindigkeit, mit der Sie etwas für einen Markt liefern können, und der Architektur hinter dem Projekt. Manchmal gibt es, manchmal nicht. Im Allgemeinen denke ich jedoch, dass es sicher ist, ersteres anzunehmen.

Darüber hinaus mögen einige Ersteres als den einfachen Ausweg sehen, andere mögen Letzteres als eine Übung in YAGNI sehen oder, noch einfacher, dass das Problem angegangen werden kann, wann immer es auftaucht.

Aber was hat das im Moment damit zu tun?

Versenden oder sterben?

Der ganze Grund, warum ich Zeit damit verbringe, darüber zu schreiben, ist, dass es etwas ist, über das ich, und ich vermute, andere in unserem Bereich, zumindest ein wenig nachdenken. All dies ist schön und gut, wenn man es im abstrakten Sinne betrachtet, aber lassen Sie mich versuchen, es mit etwas Realistischerem zu verbinden.

Es war einmal…

Vor ein paar Jahren bestand die Front-End-Entwicklung darin, Inhalte in Inline- oder Block-Level-Elemente zu verpacken und sie mit grundlegendem CSS zu gestalten?

Wir hatten fortschrittliche Tools, um mit unserem Backend-Code zu arbeiten, aber das Frontend war relativ einfach, abgesehen vielleicht von den Codierungsstandards, die von der Firma oder dem Team, mit dem wir zusammengearbeitet haben, durchgesetzt wurden.

Aber dann…

Unsere Geräte haben sich weiterentwickelt (was ich, fürs Protokoll, für eine gute und sogar natürliche Sache in der Technologie halte). Zusammen mit diesen Fortschritten haben wir jetzt Build-Tools speziell für die Front-End-Entwicklung, die in mancher Hinsicht genauso fortschrittlich sind wie diejenigen, die wir für Back-End-Software verwenden.

Sicher, wir haben einige, die „Full-Stack-Entwickler” sind, aber ich gebe gerne zu, dass es mir viel angenehmer ist, auf der Serverseite zu arbeiten als am Front-End. Wenn ich am Front-End arbeite, neige ich dazu, mich an die Tools zu halten, mit denen ich vertraut bin, und versuche, innerhalb der Leitplanken zu bleiben, die durch die Spur definiert sind, auf der ich operiere.

Es hilft, die Entwicklung projektübergreifend fokussiert, schnell und konsistent zu halten.

Okay, also, was ist der Punkt?

An und für sich könnte dieser Abschnitt ein langer Beitrag werden, aber ich bin nicht daran interessiert, so weit zu gehen. Stattdessen nehme ich ein einzelnes Stück davon, wie die Front-End-Entwicklung derzeit funktioniert, und schaue, ob ich es nicht verwenden kann, um meinen Standpunkt klar zu machen.

Frech werden

Nehmen wir zum Beispiel, was aus CSS geworden ist. Wir haben Sprachen über Sprachen (wie Sass, das auf grundlegendem CSS aufsitzt oder es ergänzt).

Und wir haben Prozessoren, die kompilieren, minimieren, linten und uns daran hindern, unsere Arbeit zu sehen, bevor bestimmte Fehler und Warnungen aus Qualitätsgründen behoben sind. (Ich halte das nicht für eine schlechte Sache, aber es zeigt die wachsende Komplexität – oder vielleicht Reife – unserer Front-End-Tools).

Die Front-End-Entwicklung ist viel zu einfach, machen wir sie komplexer, damit wir uns unter unseren Kollegen klüger fühlen, die sich anscheinend mit „kritischeren” Aspekten des Geschäfts befassen. Denken Sie daran, dass dies ein Wettbewerb ist.

Dieser Artikel nimmt das Ganze auf humorvolle Weise auf.

Ein angemessenes Maß an Qualität

Um es klar zu sagen, ich sage nicht, dass dies eine schlechte Sache ist, aber ich sage, dass Dinge, die früher auf die Serverseite oder in kompilierte Sprachen verbannt wurden, sich jetzt durch den gesamten Entwicklungsstapel einer Webanwendung erstrecken.

Um es ganz klar zu sagen: Ich bin für Qualität. Das Versenden von Dingen ohne jeglichen Grad davon kann als Übung in Verantwortungslosigkeit angesehen werden.

Aber ich glaube auch, dass es ein Gleichgewicht zwischen dem Schreiben des optimalsten, funktionalsten und leistungsfähigsten Codes zu finden gilt, der unter den Einschränkungen von Zeit und Budget möglich ist.

Ich glaube nicht, dass wir, so sehr wir uns auch bemühen, es uns aufzuzwingen, in einer Entwickler-Utopie leben, in der wir in jedem einzelnen Projekt makellose Systeme optimieren, entwerfen und implementieren können.

Es scheint jedoch, dass wir unser Bestes gegeben haben, um es zu schaffen, nicht wahr?

Aber lohnt es sich nicht irgendwann zu fragen, ob all die Tools, die wir erstellen, und all die Dinge, die wir unseren Projekten hinzufügen, genau das entfernen, was uns überhaupt erst in die Branche gebracht hat? Zugegeben, für einige von uns ist dies wahrscheinlich anders. Ist es fair zu fragen, dass eine Idee zu haben, Code zu schreiben, um sie zum Leben zu erwecken, und zu sehen, wie sie ein Problem löst, uns dazu gebracht hat?

An diesem Punkt haben wir jedoch so viele Tools eingeführt, dass es eine einschüchternde Aufgabe ist, eine Entwicklungsumgebung für eine Webanwendung zum Laufen zu bringen, die von der Datenbank bis zum Browser läuft.

Es müssen so viele Dinge passieren, bevor wir tatsächlich bereit sind, mit dem Schreiben von Code zu beginnen, dass es mühsam und sogar ein bisschen anstrengend werden kann, nur die ersten Schritte dabei zu tun.

Eine persönliche, abschließende Meinung

Ich tendiere dazu, in vielen der Projekte, an denen ich mit meinem Team arbeite und die ich für andere versende, starke objektorientierte Praktiken und Werkzeuge durchzusetzen, weil ich aus Erfahrung weiß, dass die Zeit, das Geld und die Daten, die durch etwas verloren gehen können, nicht ‘ t von allen Seiten angesprochen.

Das soll nicht heißen, dass der Versand etwas davon schnell zunichte macht. Aber der Prozess und die Organisation des Codes hinter einem Projekt ist etwas, das ich nur sehr schwer so sehr ignorieren kann, dass es sich fast lähmend anfühlt, etwas zu versenden, das nicht im höchstmöglichen Maße getestet und überprüft wurde (und selbst dann gibt es Probleme).

Auf der anderen Seite gibt es jedoch einen Teil von mir, der mit ein oder zwei Ideen hinter der Mentalität „Versenden oder sterben” experimentieren möchte, um zu sehen, wie schnell etwas gebaut, versendet und jede Art von Umsatz generiert werden kann, unabhängig davon, wie makellos es ist die Codebasis ist.

Und vielleicht werde ich das bei einigen anstehenden Projekten ausprobieren.