Drücken Sie dies: Vermeidung von zeitraubenden Tech-Schulden bei WordPress-Builds mit Jon Martin

Willkommen bei Press This, dem WordPress-Community-Podcast von WMR. Hier setzt sich Gastgeber David Vogelpohl mit Gästen aus der ganzen Community zusammen, um über die größten Probleme zu sprechen, mit denen WordPress-Entwickler konfrontiert sind. Das Folgende ist eine Transkription der Originalaufnahme.

Unterstützt von RedCircle

David Vogelpohl: Hallo zusammen und willkommen bei Press This, den Podcasts der WordPress-Community auf WMR. Dies ist Ihr Gastgeber, David Vogelpohl, ich unterstütze die WordPress-Community durch meine Rolle bei WP Engine, und ich liebe es, Ihnen das Beste aus der Community näherzubringen. Hören Sie jede Woche auf Presse dies als Erinnerung, Sie finden mich auf Twitter @wpdavidv , oder Sie können dies bei iTunes, iHeartRadio, Spotify abonnieren oder die neuesten Folgen bei wmr.fm herunterladen. In dieser Folge werden wir über eines meiner Lieblingsthemen sprechen, und das ist das Vermeiden von Zeitverschwendung durch Tech-Schulden bei WordPress-Builds. Und zu diesem Gespräch möchte ich Jon Martin willkommen heißen. Jon, willkommen bei Press This.

Jon Martin: Vielen Dank, es ist gut, hier zu sein.

DV: Weißt du, ich übe die Aussprache von Hallum vor der Show, aber natürlich habe ich es gleich am Anfang vermasselt, John, tut mir leid. Großartig, also für diejenigen, die John zuhören, wird er seine Gedanken über die Auswirkungen von Tech-Schulden an WordPress-Entwicklungsteams weitergeben, z. B. was bedeutet es, Tech-Schulden zu haben, und wie wirken sie sich auf Sie aus? Wie Sie Ihre Tech-Schulden bei jedem Projekt reduzieren können. Und warum haben Sie dann die Verantwortung, Überlegungen zu Tech-Schulden mit Ihren Kunden zu teilen?

JM: Wenn Sie in einer freiberuflichen Agentur arbeiten. Ich liebe es also, Tech-Schulden zu töten. Ich liebe es, es zu beseitigen, ist eines meiner Lieblingsthemen.

DV: Wir werden auf Johns Gedanken zu diesem Thema eingehen, aber bevor wir damit beginnen, John, werde ich Ihnen die gleiche Frage stellen, die ich jedem Gast gestellt habe. Erzählen Sie mir kurz von Ihrer WordPress-Ursprungsgeschichte. Wann haben Sie WordPress zum ersten Mal verwendet?

JM: Also ich wäre Anfang der 2010er Jahre gewesen, wäre mir nicht sicher, welcher Ausdruck für diese Zeit richtig ist. Also habe ich eigentlich selbst angefangen und war CEO davon, wie wir 2008 eine Agentur gegründet haben. Und zu der Zeit war WordPress immer noch eine Blogging-Plattform. Wir haben Websites erstellt, die viele reichhaltige Inhalte enthalten. Es ist also ein bisschen ein Schimpfwort, aber wir haben damals Joomla verwendet. Aber dann eher als

DV: Joomla ist ein Schimpfwort. Ich persönlich mag alle Open-Source-CMS.

JM: Ja, wir würden gerne sagen, dass es ein großartiges Projekt ist. Ich denke, das Wichtigste für uns ist, dass Joomla im Laufe der Zeit wirklich sehr stark war, als WordPress benutzerdefinierte Post-Site-Unterstützung herausbrachte. Das war, als sich die Dinge in WordPress für mich wirklich veränderten, was es von einer Blogging-Plattform zu einem vollwertigen CMS machte, auf dem Sie alle Arten von Websites erstellen können, egal ob es wirklich klein ist ein Ein-Personen-Unternehmen oder Freiberufler oder was auch immer, bis hin zu massiven, komplexen Websites der Enterprise-Klasse. Und ich denke, wirklich, wirklich für mich war das eine Killerentscheidung von ihrer Seite, weil es einer der Gründe ist, warum WordPress jetzt so beliebt ist. Also ja, das war also der Zeitpunkt, als sie anfing, hier zu konsumieren. Sasha, die Geschichte davor ist wirklich ich selbst und jetzt CEO, wie wir zusammen in einer Band waren. Und wir haben diese brillante Idee zu denken: Nun, weißt du was, es ist eine großartige Art von gleichberechtigter Zeit unterwegs und es ist wirklich schwer, Zeit von meinen aktuellen Jobs zu bekommen. Also dachten wir, weißt du was, lass uns eine Agentur gründen und Webentwickler werden, denn das wird wirklich helfen, all die Zeit zu bekommen, die damals eine großartige Entscheidung war. Ich bin wirklich sehr zufrieden damit, aber er ist sicherlich auch eine naive Entscheidung, denn zu denken, dass man mehr Zeit hat, wenn man für sich selbst arbeitet, war definitiv ein Fehler, den wir, denke ich, ein bisschen später erkennen werden. Und vor diesem Punkt, weißt du, wusste ich ein bisschen über SQL und ich baue seit langem Computer, eigentlich seit Grafikkarten, die Farben sehr unterstützen. Also für alle anderen, die wissen, was CGA ist, wird Ihnen das helfen, zu wissen, wie alt ich bin. Aber ja, so wirklich, es war, als CPTs herauskamen. Dieses Fett hat alles für uns verändert. Und wir fingen eigentlich über Nacht an, WordPress zu verwenden, das wurde unser gewähltes CMS und wir haben seitdem nicht mehr zurückgeschaut und, wissen Sie,

DV: Von all den Leuten, die ich Ihnen diese Frage gestellt habe, haben nur sehr wenige tatsächlich eine Ahnung davon, wie materiell benutzerdefinierte Post-Typen im Verhältnis zu ihrer WordPress-Ursprungsgeschichte waren. Und es ist lustig. Ich habe eine ähnliche Geschichte. Ich habe 2010 eine Agentur gegründet. Also ein bisschen nach euch allen, aber als die benutzerdefinierten Posts schon irgendwie angekommen sind. Wir haben mit Joomla angefangen und aus ähnlichen Gründen zu WordPress gewechselt, aber es waren diese benutzerdefinierten Post-Typen und benutzerdefinierten Metadaten Felder, denen ich zustimme und die ich tatsächlich auf diese Weise in verschiedenen Formaten präsentiert habe, ist, dass es diese Art von Moment war, in dem WordPress wirklich zu einem echten CMS wurde. Ein Jahr nachdem WooCommerce ins Leben gerufen wurde, entstand WP Engine, viele andere Marken im WordPress-Bereich, es ist eine so transformative Zeit. Es ist interessant, Ihre Art von Referenz zu hören, die die Wurzel Ihrer Ursprungsgeschichte ist. Sie haben mir zwar erzählt, wie ähm, und Sie wissen schon, der Gründungsmoment dort, wenn Sie so wollen, aber könnten Sie mir kurz ein bisschen darüber erzählen, wie ähm, und was Sie tun?

J M: Ja, sicher. Also, also eigentlich, diese Agentur, die wir fanden, war nicht so, wie wir später fahren. Okay okay. Nun, der Hauptgrund dafür ist eigentlich, dass es damals in jenen alten Tagen einen sehr deutlichen Unterschied gab zwischen, wissen Sie, wir bauen Websites und wir machen SEO und all diese Dinge. Und es gab nicht wirklich viele auf der ganzen Welt, die einen integrierten Ansatz verfolgten und tatsächlich über Dinge wie Benutzererfahrung nachdachten und wie das mit SEO und Entwicklung funktioniert, all diese Dinge. Also, das war eigentlich der Grund, warum wir später mit Later fusionierten, mit Allen Milan, der seit etwa 20 Jahren dabei ist und unser Gründer ziemlich genau am Anfang gegründet wurde, als SEO anfing, zu einer Sache zu werden. Also ja, also haben wir die beiden Agenturen zusammengelegt. Vor sechs, sieben Jahren, vielleicht etwas länger. Mein Datengedächtnis ist nicht so toll, muss ich zugeben. Und dann Und dann wirklich, ja, das ist unser Ansatz geworden, ist das dieser vollständig integrierte Ansatz, all diese verschiedenen Disziplinen miteinander zu vermischen, um den Menschen zu helfen, die Grenze zu sehen? Also machen wir jetzt PPC, SEO, digitale PR, natürlich Webdesign und es gibt Markendehnungen, digitale Strategie und all diese Dinge, all diese Disziplinen, die Sie heutzutage wirklich brauchen, um eine gute, starke digitale Präsenz zu haben. Was ist Ihre Rolle dort, das Unternehmen? Also meine, meine Berufsbezeichnung war Technischer Direktor. Um ehrlich zu sein, deckt es nicht wirklich alles ab, was ich tue. Ich leite das Entwicklungsteam über einen langen Zeitraum. Also alles, was WordPress sein wird, war unter meiner Leitung. Ich freue mich, sagen zu können, dass wir weitaus bessere Entwickler im Team haben, als Julio und ich jemals gearbeitet haben, als wir anfingen, und das ist der Grund, warum wir heutzutage viel besser abschneiden. Und wir verstehen die Dinge ein bisschen besser. Daher leite ich das Entwicklungsteam für eine lange Zeit und in letzter Zeit auch ein Cost-of-Data-Team. Das heißt, ich kann mit maschinellem Lernen spielen, Python und Bartek und andere spielen, obwohl ich mir all das Spielen vorstellen muss.

DV: Coole separate Clients zu machen, wird auf dem Weg zu einigen technischen Schulden führen. Und deshalb bin ich neugierig, wie Sie darüber denken, was die üblichen Arten von Tech-Schulden sind und vielleicht spezifisch für WordPress. Das für eine Minute, aber wie denkst du darüber nach, wenn du darüber nachdenkst, weißt du, wie und wie du deine technischen Schulden verwaltest, als hättest du sie in Typen mit WordPress gesperrt?

JM: Ja, das tun wir. Ich meine, nicht. Nicht unbedingt. Wir verwenden eine Art Sprache, in der wir Dinge nicht unbedingt kategorisieren oder einen Distriktprozess zur Kategorisierung durchlaufen, aber sie fallen wirklich in drei verschiedene Bereiche. Eine davon ist, wenn Sie schlechten Code auf bestehenden Codes aufbauen, und das könnte daran liegen, dass Sie in der Vergangenheit vielleicht einige Fehler gemacht haben, die ein Problem von Heritage-Websites und jemand anderem sein könnten, was auch immer der Grund ist, also das war's eine Art erster Eimer. Das zweite sind Bauvorschriften, die nicht erforderlich sind und vielleicht gerade jetzt nicht erforderlich sind. Weißt du, ich bin mir sicher, dass wir alle am Ende von Feature-Anfragen von Kunden und Marken waren, mit denen wir zusammenarbeiten, wo sie wirklich scharf auf eine bestimmte Sache sind, aber tatsächlich vielleicht nicht das Richtige ist, um einen tatsächlichen Wert zu erzielen für die Kunden. Und der dritte, der größte, den wir tatsächlich sehen, ist das Erstellen von Funktionen, die eigentlich auf einer anderen Plattform sein sollten. Wenn Sie also diese Art von architektonischem Stück über Okay verstehen, was sind die verschiedenen Teile, die wir hier einstecken, ist ein CRM, hier ist die Website, bei der es im Grunde wirklich um das Marketing des Unternehmens geht. Hier ist Ihre Auftragserfüllungsplattform, so unterschiedlich.

D V: Lassen Sie mich Sie fragen, lassen Sie mich Ihnen hier eine grundlegende Frage stellen, wie Sie die drei Arten von Geräuschen aufgelistet haben, wie dies die drei Arten von technischen Schulden sind, die Sie loswerden möchten. Schreiben Sie schlechten Code auf schlechten Code Code, das sind keine notwendigen Funktionen, die auf einer anderen Plattform ausgeführt werden können. Gibt es zum Beispiel nicht einen vierten Eimer wie Funktionen, die Sie wollen, die wertvoll sind und daher die Technologie, die in diesem Fall vielleicht gut ist? Ist das fair zu sagen? Das ist ein vierter Eimer.

JM: Ja. 100% Ich meine, nicht alle technischen Schulden sind schlecht. Es gibt einige, die Sie akzeptieren müssen, dass so ziemlich jedes Feature, das Sie bauen werden, irgendeine Art von technischer Schuld ansammeln wird, und Sie müssen einen Anruf darüber tätigen, ob diese technische Schuld gut ist oder nicht. Manches ist gut, manches ist schlecht und hängt wirklich davon ab, dass es sich bei dem Schlüsselwort, das ich zuvor erwähnt habe, um den Wert handelt. Wirst du den Wert bekommen, den du für dieses Ding brauchst? Und was noch wichtiger ist: Ist der Kunde, der Endkunde, nicht Ihr Kunde, sondern sein Kunde? Werden sie den Wert dafür bekommen? Das ist normalerweise ein ziemlich guter Anhaltspunkt dafür, ob man diese technische Schuld akzeptieren sollte.

DV: Ja, ich möchte ein bisschen tief in Sie eintauchen, wie Sie über dieses Zitat denken, es lohnt sich, eine Formel dafür zu finden, wann es in Ordnung ist, es anzunehmen oder nicht, aber es ist gut, darüber nachzudenken, um ein gutes Verständnis dafür zu bekommen, wie Sie darüber denken die verschiedenen Arten von Tech-Schulden und insbesondere diejenigen, die Sie möglicherweise optimieren möchten, um sie zu entfernen. Als nächstes möchte ich jedoch verstehen, ob es da etwas gab, das Sie über den Rand getrieben hat, sich auf diesen Bereich zu konzentrieren, aber wir werden unsere erste Pause einlegen, und das werden wir Ich komme gleich wieder. Zeit für eine Werbepause. Bleiben Sie dran für mehr Dringlichkeit, nur einen Moment. Hallo zusammen. Willkommen zurück, um die WordPress-Community-Podcasts auf W EMR zu veröffentlichen. Dies ist Ihr Gastgeber, David Vogel. Paul. Ich interviewe John Martin darüber, wie man Zeit vergeudet und Techniktote tötet. John, kurz vor der Pause haben Sie erklärt, dass die Art und Weise, wie Sie über die drei Arten von Technologieschulden denken, die Sie möglicherweise beseitigen möchten, darin besteht, schlechten Code auf schlechtem Code zu erstellen und Code zu erstellen, der für den Erfolg der Website, an der Sie arbeiten, nicht erforderlich ist. Und dann vielleicht Code für Funktionen entwickeln, die auf einer anderen Plattform besser bedient werden können. Bevor wir jedoch auf die Formel „Das Angebot lohnt sich“ eingehen. Ich habe mich gefragt, ob es eine bestimmte Zeit gab und Ihre Reise ein besonderes Beispiel für technische Schulden ist, dass diese Art von Oberfläche für Sie ein Hauptaugenmerk darauf ist, wie?

JM: Ja, absolut. Es gibt ein wirklich bahnbrechendes Projekt, das mich vor etwa vier oder fünf Jahren zum Nachdenken gebracht hat. Ich habe viele andere Fälle gesehen. Unternehmen gewinnen ständig Zeit, nicht nur durch WordPress durch alle möglichen Dinge, sondern Unternehmen gewinnen sie auch durch ihre betrieblichen Prozesse. Wenn Sie ein technisches Ding sein müssen, wo Sie dieses Deck erstellen. Eine Geschichte, die mir mehr als alle anderen in den Sinn kommt, ist ein Kunde. Wir arbeiten mit einer relativ kleinen Firma zusammen, für die wir viel bezahlte Medienarbeit geleistet haben. Verkaufen im Wesentlichen Sachen online verkaufen. Es war ein E-Commerce-Geschäft. Und sie hatten eine traditionelle Art des Versandhandels, aber viel von ihrer Arbeit und sie versuchten, mehr Verkehr online zu lenken, damit sie nicht über den Versandhandel gehen mussten, der über die Website verwaltet wird, und sie kamen zu uns, weil sie es getan haben eine für sie erstellte Website ist komplett maßgeschneidert. Und zu diesem Zeitpunkt gibt es sie seit ungefähr 10 Jahren. Es wurde also ziemlich alt und begann ein wenig zu kriechen. Du weißt schon, Standards und weitermachen. Die Technologie hat sich weiterentwickelt, es ist Zeit, ein wenig umzudenken. Also setzte sich der Kunde mit uns zusammen und fing an, all die verschiedenen Dinge, die er auf der Website getan hatte, nachzubesprechen. Und mir wurde sehr schnell klar, dass alle Arten von Geschäftslogik und betriebswirtschaftlichem Zeug in die Website eingebaut waren. Und das war eine Logik, die zu Bestellungen führt und ganz spezifisch für die Art und Weise ist, wie sie mit Lieferanten arbeiten. Ich werde also nicht ins Detail gehen, aber ich habe eine ziemlich komplexe Vereinbarung zwischen den Lieferanten und wie sie Bestellungen ausführen und ob sie in ihren Shop geliefert wurden, bevor sie all diese Sachen versenden. Also alles ziemlich kompliziert. Nun, der Geschäftsinhaber und der Vorgänger darüber, wie sie arbeiten, haben schließlich ein System gebaut, das das Ganze so ziemlich verwaltet, dass es zu dieser Zeit ein wirklich, wirklich gutes System war und dem Unternehmen wirklich geholfen hat, massiv zu wachsen. Woran sie nicht wirklich gedacht haben, ist, dass alle Websites irgendwann eine Haltbarkeit haben, die sie irgendwann zum Leben erwecken, genau wie jede Software und in der Marketingwelt. Diese Haltbarkeit ist wirklich relativ kurz im Vergleich dazu, wissen Sie, wenn Sie zum Beispiel in ein CRM investieren, da ein Unternehmen normalerweise eine ganze Weile damit herumlaufen wird, jetzt sind es ungefähr 10 Jahre, wenn nicht mehr Websites. Im Allgemeinen zwischen zwei und fünf Jahren finden wir, dass die meisten zumindest die großen Marken dazu neigen, alle drei Jahre oder so neu zu bauen. Das Problem war also, dass sie all diese komplizierte Logik in die bestehende Website einbauten und die gesamte Website neu erstellen mussten. Und plötzlich müssen Sie auch diese ganze Geschäftslogik neu erstellen. Jetzt haben wir das Projekt hochgerechnet und am Ende war es ungefähr die Hälfte des Jahresumsatzes auf der Basis, nur um das, was wir bereits hatten, wieder aufzubauen. Und das hat mich wirklich dazu gebracht, über diese Sache nachzudenken, also gut, okay, wenn sie das Problem ursprünglich anders angehen, denken wir zum Beispiel über die verschiedenen Dinge nach, die wir mit einer Website erreichen wollen. Weißt du, das kommt vom Marketing, war das für den Verkauf von Produkten. Das ist für die Auftragserfüllung, das ist am besten für die Verwaltung meiner Geschäftsprozesse mit Lieferungen all diese Dinge, und ich dachte etwas modularer darüber nach, dann wäre es für diese Kundin eine ganz andere Situation gewesen, dass sie dort war . Es war ein echtes Problem für sie, weil sie eine Website hatten, mit der sie im Wesentlichen Geld verdienten. Es knarrte ziemlich viel, weil es ziemlich alt ist. Aber gleichzeitig würde es so viel kosten, diese gesamte Website neu zu erstellen, und das Projekt sehr, sehr kompliziert machen. Wir haben es geschafft, bis zum Ende einige ziemlich clevere, aber auch nicht schöne Arbeiten zu finden, um zu versuchen, das zu verwenden, was sie bereits hatten, und es zu integrieren, aber wir können es nicht zitieren, aber Sie wissen, dass es letztendlich viel schmerzhafter, viel langsamer und viel mehr war teurer als nötig. Wenn diese Architektur ursprünglich gedacht wurde.

DV: Ich habe so viele Projekte, dass ich das vergessen möchte. Waren einfach so, und ich kann es mir vorstellen, jetzt nehme ich mich in die Vergangenheit zurück. Für mich klingt das ziemlich klar, es ist, denke ich, eine sehr wichtige Lektion, über die Art der Kosten für das Unternehmen im Verhältnis zu dem von Ihnen geplanten Refactor nachzudenken. Und für mich klang es so, als wäre die klare Antwort, dass Sie es anders gestalten müssten. Und das ist vielleicht ein klarerer Weg, wenn Sie mögen, was Sie tun sollten. Aber ich denke, wie viele Teams, wenn sie an Tech-Schulden denken, denken sie: Okay, nun, es wäre cool, diese Sache zu machen, aber ist es das wert?

JM: Lohnt es sich, dieses Ding im Laufe der Zeit zu warten? Ich bin also nur neugierig, wie Sie über diese Formel denken

D V: wann, wie, Wann ist es in Ordnung, Tech-Schulden einzuführen? Und wie viel denken Sie über diese Formel?

JM: Ja, Sie haben einen wirklich wichtigen Punkt angesprochen, wissen Sie, Sie denken über die Natur von Entwicklern nach, Entwickler beschäftigen sich damit, weil sie es lieben, coole Sachen zu machen. Und das ist, wissen Sie, ein großer Teil unserer Motivation besteht darin, zu lernen, wie man neue Dinge macht, neue Technologien, Sie wissen schon, neue JavaScript-Frameworks, was auch immer die Sache ist, und das gibt uns natürlich die Motivation, coole Sachen zu bauen, aber wir denken nicht unbedingt langfristig darüber nach, wissen Sie, wir werden es trotzdem beibehalten. Weißt du, meine Frau würde gerne einen Whirlpool in meinem Haus haben, aber ich weiß, dass jemand ihn reinigen wird, und ich bin ehrlich, ich glaube sowieso nicht, dass jemand, der ihn reinigt, so denkt. Es ist also eine wirklich, wirklich, wirklich gute Frage, über die man nachdenken sollte, ob es sich überhaupt lohnt, und wenn wir das ein wenig aufschlüsseln, gibt es ein paar verschiedene Dinge, über die man nachdenken könnte, zunächst einmal, lange nachdenken Wie hoch sind die Gesamtkosten für den Besitz und den Bau dieses Dings, um es zu testen und zu warten, und wägen Sie das dann gegen den Wert ab, den wir erhalten? So kann es zum Beispiel einen wirklich einfachen Weg geben, wie Sie dieses Problem lösen können. die Verwendung von Tabellenkalkulationen oder die Verwendung etwas anderer architektonischer Dinge, bei denen das vielleicht jemand intern im Unternehmen für kurze Zeit verwaltet. Und es wäre billiger und effektiver, das zu tun, als dieses wirklich komplizierte Feature zu bauen. Aber wenn man sich die Gesamtbetriebskosten ansieht, wird es mehr kosten, als wenn jemand ein paar Stunden pro Woche für eine bestimmte Sache aufwendet. Versteh mich nicht falsch. Ich bin ein großer Verfechter der Automatisierung. Technologien sollten so viel wie möglich automatisieren, um diese Art von Verwaltung zu vermeiden, aber

DV: Sie melden sich an und verwenden wie diese manuellen Ansätze, um etwas auszuprobieren, bevor Sie es codieren, um sicherzustellen, dass der Wert vorhanden ist. Ich meine, ich habe die Idee, diesen Faktor zu vereinfachen, wie, können wir das stattdessen manuell machen? Ich bin nur neugierig, ob Sie es jemals aus einer Testperspektive angegangen sind, um zu sehen, ob sich die ultimative Rendite lohnt?

JM: Ja. 100%. Daher bin ich ein großer Anhänger der agilen Methodik. Und im Grunde ist einer der wichtigsten Grundsätze von Agile, dass Sie das Richtige zur richtigen Zeit entwickeln. Und Sie konzentrieren sich darauf, so schnell wie möglich an Wert zu gewinnen. Sie wollen also das Minimum Viable Product bauen. Nun, das bedeutet, dass Sie zu diesem Zeitpunkt nicht unbedingt etwas haben, das voll funktionsreich ist. Aber es gibt Ihnen eine Plattform, auf der Sie dann anfangen können, es zu testen, wissen Sie, bekommen Sie wirklich die Dinge, die Sie wollen? Reagieren Ihre Benutzer darauf? In der Art und Weise, wie Sie es von jedem erwarten, der in UX oder Webentwicklern gearbeitet hat, wird er wissen, dass er ziemlich oft Anfragen von Kunden erhält, weil sie denken, dass es ihre Kunden sind, aber wollen sie das wirklich? Das ist eine weitere wirklich gute Frage, die Sie sich stellen sollten: Wenn Sie einmal über diese langfristige Sichtweise nachgedacht haben, wissen wir, ob die Leute die Website nutzen werden, oder müssen wir testen, ob sie wollen? um es zu benutzen? Und sobald Sie diesen Test durchgeführt haben, können wir herausfinden, was wir nicht hätten verlangen sollen und ob wir uns zurückziehen und unsere Investition tatsächlich woanders anlegen sollten.

DV: Es klingt also nach einer Art Rekapitulation dieser Gedanken, und ich mochte Ihre Idee, die Gesamtbetriebskosten langfristig zu betrachten. Wissen Sie, ich denke, dass Teams oft denken, dass sogar die Leute, die Sie kennen, Dienstleistungen bestellen Teams denken darüber nach, wie viele Stunden oder Wochen oder Spreads oder Punkte oder was auch immer dieses Ding bauen muss. Aber dann, wissen Sie, müssen Sie berücksichtigen, dass Sie wissen, wie viel, wie viele Stunden oder Wochen oder Spreads oder Punkte es dauern wird, um dieses Gleichgewicht aufrechtzuerhalten und dann dieses Gleichgewicht gegen den Wert zu verwenden, den Sie aus der Aufrechterhaltung ziehen diese Aktivität. Sie sind offensichtlich, das ist ein vernünftiger Ratschlag. Aber dann denken Sie auch: Nun, kann ich das irgendwie testen, um zu sehen, ob meine Annahmen richtig sind? Klingt das genau?

JM: Ja. Absolut. Absolut. Und das einzige, was wir nicht angesprochen haben, ist das, worüber wir ein bisschen früher gesprochen haben, nämlich Architektur, gibt es einen besseren Weg, dies zu strukturieren, um es besser zu machen, und diesmal, um Objektprogrammierung und so weiter zu machen auf die ich wahrscheinlich etwas später eingehen werde.

DV: Ja, auch die architektonischen Überlegungen, wie ich aufgeschrieben habe, wie Sie waren, gibt es eine Möglichkeit, die Spezifikationen zu ändern? Ist es so, wie ich in meinen Stakeholder-Schulungen oder Vorträgen oft sage, Sie wissen schon, Spezifikation, um richtig einzureichen? Fragen Sie nach dem, was Sie wirklich brauchen, um zu logieren. Und diese zu fragen, wird lügen und wirklich gebraucht werden, und was ist damit? Fragen wurden von mir als sehr kritisch empfunden. Es hört sich also so an, als ob das ein wichtiger Teil davon ist, wie du darüber nachdenkst.

JM: Ja, weil jede Minute, die diese Seite in der Entwicklung ist, eine Minute ist, in der sie vor den Kunden keinen Wert bekommt. Und das ist die einfache Art, darüber nachzudenken. Sie wollen so schnell wie möglich starten. Und dann testen, überwachen, iterieren, lernen, Sie wissen schon, sehen, wie Sie von dort aus weitermachen, aber nur, weil Sie dies auf der Grundlage tatsächlicher Daten tun und nicht auf der Grundlage dessen, was Sie für richtig halten. Denn oft sind sie nicht gleich.

DV: Ja, ich liebe diesen Punkt. Alle Minuten. Es ist in der Entwicklungsphase, nicht wahr, Sie nutzen es nicht gleich, um herauszufinden, und ich sage, es geht zurück zu einer Art von Verbindung zu einem anderen Mantra, das ich habe, und Projektmanagement und Stakeholder-Management, das sind die beiden besten Wörter und ein Projekt auf unser Gesicht bekommen, um es zu schreiben. Wie kannst du reden, ja, ich liebe das, wenn ich mit Stakeholdern zu tun habe oder wenn ich einen Stakeholder habe, der ein mächtiger, mächtiger Teil ist. Okay, cool. Lassen Sie uns als Nächstes darüber sprechen, was Teams tun können, um Tech-Schulden zu reduzieren. Aber bevor wir das tun, machen wir unsere letzte Pause. Zeit für eine Werbepause. Bleiben Sie dran, um dies in einem Moment weiter zu drücken. Jeder ist willkommen, diesen WordPress-Community-Podcast auf W EMR zu veröffentlichen. Das ist Ihr Gastgeber David Mobile Paul, ich rede gerade mit John Martin über die Vermeidung von Zeitverschwendung durch Tech-Schulden darüber, wie John kurz vor der Pause ein wenig über Ihre Wert-Formel gesprochen hat. Mir gefielen Ihre Vorstellungen zum Abbau sehr gut Spezifikationen. Und denken Sie über TCO nach und verfolgen Sie einen iterativen Testansatz. Aber lassen Sie uns jetzt untersuchen, was Teams tatsächlich tun können, um ihre Tech-Schulden und WordPress-Builds zu reduzieren. Was sind einige Ihrer Lieblingstechniken zum Abbau von Tech-Schulden?

JM: Es gibt also alle Arten von technischen Techniken, die Sie verwenden können, und Sie kennen einige davon, mit denen Sie vertraut sind, so dass Sie es nicht tun werden, aber eigentlich ist der Ausgangspunkt für mich eine viel sanftere Herangehensweise an Gespräche zu Ihren Kunden. Und Sie müssen sich daran erinnern, dass Ihre Kunden letztendlich diese Marken sind, die zu uns kommen, weil wir die Experten sind. Sie brauchen unseren Rat, und es ist ziemlich leicht, in die Falle zu tappen, dass wir nur da sind, um zu tun, was sie wollen, was wir da sind, um zu tun, was sie von uns wollen, aber eigentlich sind wir da zu hinterfragen, was sie tun wollen, und zu versuchen, es zu verbessern. Das erste, was Sie tun können, ist, mit ihnen darüber zu sprechen und zu erklären, okay, wenn wir das tun, wird dies die langfristige Wirkung davon sein. Weißt du, es wird uns einen zusätzlichen Testtag kosten. Jedes Mal, wenn wir eine Veröffentlichung machen, wird es jedes Mal ein oder zwei Stunden dauern, wenn wir die Website warten und alle Plugins oder was auch immer aktualisieren müssen. Aber indem wir dieses Bewusstsein schärfen, führen wir diese Gespräche mit ihnen. Sie können den Kunden dazu bringen, Teil dieser Diskussion zu sein. Und dann werden sie schließlich Teil der Problemlösung mit gut, wir müssen unsere Kunden ständig aufklären, einfach weil sie einige Dinge nicht wissen, die wir tun. Wenn sie es täten, würden sie erst gar nicht zu Werkzeugen. Das ist also eigentlich der Ausgangspunkt. Er denkt, sich daran zu erinnern und die Dinge zu vereinfachen. Auch hier sind die Menschen nicht unbedingt so technisch versiert wie wir. Verwenden Sie also Analogien, um darüber zu sprechen. Ich finde immer, dass Häuser eine große Energie sind. Alle wohnen im Haus. Die meisten Menschen haben einige Erfahrung damit, eine Art Hausverbesserung durchzuführen. Es war also ziemlich einfach, diese Energie zu nutzen, um Dinge zu reparieren. Das ist also der erste Punkt, um einen Kunden zu gewinnen oder diese Gespräche zu führen. Das nächste, was wir zuvor angesprochen haben, war diese langfristige Sichtweise oder die Gesamtbetriebskosten. Und stellen Sie sich diese Fragen und hinterfragen Sie jede Feature-Anfrage. Aber ein bisschen technischer zu sein und wie Sie das bei der Arbeit machen würden. Einfache Dinge, die Sie verwenden WordPress-Standards, die Sie kennen, es gibt Standards, die da sind. Sie existieren aus einem bestimmten Grund. Jetzt helfen sie uns Entwicklern und vielleicht arbeiten Sie an einem Projekt, das Sie für ein oder zwei Jahre auf Eis legen, und dann kommen Sie darauf zurück. Sie müssen Ihr Gedächtnis auffrischen und dorthin zurückkehren, wo Sie waren, als Sie es zum ersten Mal erstellt haben, wobei Standards hilfreich sein werden. Sie werden auch anderen Menschen helfen. Wenn Sie also nicht im Team waren, bedeutet dies, dass Sie diese gemeinsame Sprache haben, von der aus jeder operieren kann, was wirklich, wirklich nützlich in Bezug auf Effizienz und Hilfe bei der Dokumentation und all diesen Dingen ist. Das ist also eine sanftere Art, Ihre technischen Schulden zu reduzieren, indem Sie Standards haben, die jeder anwenden kann. Es hilft Ihnen auch zu wissen, dass die Zeit kommen kann, in der einige andere WordPress-Entwickler an diesem Projekt arbeiten. Und es hilft ihnen, es als eine Möglichkeit zu betrachten, der Community etwas zurückzuzahlen und es Ihren Mitentwicklern einfacher zu machen. Das ist also ein guter Punkt, um Standards zu setzen und es sich und anderen leicht zu machen. Der nächste ist mehr über großartig. Großartiger Industriekodex, liebevoll Onkel Bob genannt, der vor vielen, vielen Jahren ein wundervolles Buch mit dem Titel The clean coder geschrieben hat. Ich würde jedem Entwickler wärmstens empfehlen, dieses Buch zu lesen, weil sie es noch nicht gelesen haben. Tatsächlich habe ich es zur Pflichtlektüre für ein Entwicklungsteam gemacht, für jeden, der dem Team beigetreten ist, vor allem, weil er so eine gute Herangehensweise daran hat, über Unit-Tests zu sprechen, all diese Art von Zeug, aber im Grunde eine Menge davon geht es darum, wie Sie Code so schreiben, dass er flexibel ist, sodass Sie ihn sehr schnell iterieren und ändern und zusätzliche Bits hinzufügen können. Einer der großen Punkte, über die er spricht, ist das häufige Refactoring, und das ist die Hauptsache, die Sie daraus ziehen können, dass Sie ein Stück Code schreiben, das nicht unbedingt bedeutet, dass dieses Stück Code fertig ist. Es gibt Dinge, die Sie tun können, um es zu optimieren, um es portabler zu machen, um es modularer zu machen oder um einen Test besser zu machen, was auch immer Sie tun müssen, um Zeit für das Refactoring von Code aufzuwenden. Es kann wirklich, wirklich schwer sein, wenn man dagegen ankämpft oder weißt du, vielleicht ist es ein Zeitrahmen für ein Budget. Aber letztendlich ist das die Art von Dingen, die Sie davon abhalten, technische Schulden anzuhäufen, und eigentlich ist es normalerweise die Art und Weise, wie ich es sehe, dass es erzwungen wird, aber wenn eine Projektfrist festgelegt ist, müssen Sie diese Frist einhalten. Absolut. Sie müssen es treffen, aber es ist besser, den Spielraum zu erweitern, als schlechten Code zu schreiben, den Sie dann

DV: Ich schätze, kläre diese Kunden auch darüber auf, weil ich noch nie einen Entwickler getroffen habe, der nicht umgestalten wollte. Code. Es ist immer die Zeitleiste. Es ist dagegen. Ähm, okay, hier ist der letzte kleine Teil. Ich bin nur neugierig, ob Sie uns mögen, wenn Sie an Dinge wie Offloading und die Verwendung von handelsüblichen Plugins denken, ist eine weitere Möglichkeit, Technologie zu vermeiden, oder eine andere Möglichkeit, Technologieschulden zu vermeiden. Steht das auch in deiner Liste?

JM: Ja. 100% Das ist also ein guter Weg, aber es ist eigentlich ein guter Weg, beides zu tun, Sie können technische Schulden vermeiden. Aber Sie können auch, und das ist, Sie wissen, WordPress ist eine Form von BMC. Es ist gleichermaßen so aktiv, dass es auch sein schlimmster Feind sein kann. Es gibt ein Plugin, das alles kann. Und es gibt auch viele Plugins, die für einen ganz bestimmten Zweck erstellt wurden, aber nicht unbedingt mit Ihren eigenen Plugins übereinstimmen. Ich habe das also besonders bei einigen Entwicklern gesehen, die gerne Websites mit Plugins und einer Art Point-and-Click-Ansatz an Dinge bauen, anstatt sie von Grund auf neu zu programmieren. Die Leute neigen dazu, Plugins auf Dinge zu werfen. Wir haben mit Websites gearbeitet, die über 100 Plugins hatten und von denen einige nicht mehr gepflegt werden. Es gibt überall Sicherheitsprobleme. Sie versuchen, die Release-Rate zu tun. Sie verbringen buchstäblich vier Tage damit, es zu testen, wenn Sie das in ein paar Stunden hätten erledigen können. So So Plugins können gut oder schlecht sein. Das richtige Einstecken zur richtigen Zeit war eine wunderbare, wunderbare Sache. Die größten Stärken von WordPress, aber das falsche Plugin zur falschen Zeit kann auch großen Schaden anrichten. Und tatsächlich kann das eine dieser größten Kapitalquellen sein

DV: Ich hatte sicher ein solches Projekt. Nun, John, das war unglaublich aufschlussreich. Vielen Dank, dass Sie heute bei uns sind.

JM : Gerne.

DV: Großartig. Wenn Sie mehr darüber erfahren möchten, was Jon ist, besuchen Sie hallam.co.uk. Vielen Dank an alle, die diese WordPress-Community-Podcasts auf WMR angehört haben. Dies war wiederum Ihr Gastgeber David Vogelpohl. Ich unterstütze die WordPress-Community im Rahmen meiner Rolle bei WP Engine und ich liebe es, das Beste aus der Community hier auf Press This zu bringen.