Sie müssen wählen, welche Software Sie benötigen: Pünktlich oder qualitativ geschrieben

Published on September 27, 2018

Sie müssen wählen, welche Software Sie benötigen: Pünktlich oder qualitativ geschrieben

Ursprünglicher Autor: Joan Gamell
  • Übersetzung


Ich hoffe, dass ich mit einem solch provokanten (und zugegebenermaßen übertriebenen) Titel Ihre Aufmerksamkeit erregen konnte. Gut Lassen Sie mich es nun etwas eleganter und weniger verlockend formulieren :

Software kann prinzipiell entweder rechtzeitig oder gut geschrieben werden, aber nicht beide gleichzeitig *

* bis auf wenige Fälle in den bestehenden Hochleistungsteams.

Seit einigen Monaten denke ich darüber nach warum die Erstellung von qualitativ hochwertiger Software nicht gut mit dem geschätzten Zeitrahmen und der Planung im Allgemeinen übereinstimmt. Während meiner Karriere sah ich Projekte, die auf verschiedenen Modellen aufgebaut waren (kaskadierend, wirklich flexibel, flexibel kaskadierend), und alle hatten eines gemeinsam: Egal an welchem ​​Projekt wir arbeiten, ob es " nach der Wissenschaft" gemacht wurde.(d. h., wir haben uns keine schmutzigen Tricks gegönnt, weshalb wir später Albträume hätten), wir haben immer Fristen gebrochen.

Auf der anderen Seite bedeutete das immer dann, wenn das Projekt „pünktlich“ aufgegeben wurde, dass es zwangsläufig sein Volumen reduzieren musste oder so viele Ecken abschneiden musste, dass sich während der Implementierung Berge technischer Schulden bildeten, was fast garantierte, dass das Projekt kurz danach neu geschrieben werden musste starten Daher begann ich mich zu fragen: Kann man wirklich davon ausgehen, dass das Projekt „pünktlich“ geliefert wurde, wenn wir als Ergebnis eine hässliche, unbequeme Unterstützung haben, die mit Fehlern gefüllt ist und, offen gesagt, eine unattraktivere Version des Codes im Vergleich zu der ursprünglichen Version versucht zu tun?

Übersetzt in Alconost

Ich habe an Projekten ohne enge Fristen gearbeitet. Ja, formal waren die "Fristen" da, aber weit entfernt von Stahlbeton. Jeder wusste, dass die Fristen flexibel waren und dass Qualität wichtiger war als die rechtzeitige Lieferung des Produkts. Bei diesen Projekten haben wir die beste Software erhalten, es gab die zufriedensten Entwickler, und im Allgemeinen gehörten diese Projekte zu den erfolgreichsten unter allen, an denen ich arbeiten musste. Aber wir alle wissen, dass solche Projekte sehr selten sind, sonst hätte ich das alles nicht geschrieben.

Warum ist es so schwierig, einen Job zu planen und gute Software herauszugeben, die eng definierte Fristen hat? Ich denke, das liegt vor allem an Kreativität , Können und Unberechenbarkeit .

Kreative Seite der Programmierung


Ich bin der Meinung, dass Softwareentwicklung definitionsgemäß eine kreative Tätigkeit ist . Natürlich gibt es Entwickler, die monotone triviale Aufgaben ausführen, aber sie haben nur Arbeit, bis jemand herausfinden kann, wie sie ihre Arbeit automatisieren können. Sie beneiden nicht, und das Thema dieses Artikels ist völlig anders.

Für mich ist der Schöpfungsakt etwas Besonderes .etwas Neues und auf der Suche nach originellen Lösungen als Antwort auf Herausforderungen; Deshalb empfinde ich die Berufung, Software zu entwickeln, und ich glaube nicht, dass ich die Einzige bin. Ich glaube, Kreativität ist der Hauptgrund, warum Entwickler ihre Arbeit genießen. Meine Erfahrung legt nahe, dass immer dann, wenn ich unter Bedingungen gearbeitet habe, bei denen ein striktes und unverändertes „Set of Practices“ beobachtet wurde (sei es ein technologischer Stack, Prozesse, Regulierung usw.) - das heißt, der geringere Raum für Kreativität ist Ich war - je weniger mich diese Arbeit faszinierte. „Wenn sie am Ende schon alles für sich entschieden hatten, warum sollte ich das tun?“, Dachte ich. Auf der anderen Seite war ich viel satter, inspiriert von dieser Art von Arbeit (in der ich am produktivsten war), in der es relativ wenige Anweisungen von oben gab, gab es Raum für Kreativität,

Es ist wichtig zu wissen, dass zusätzliche kreative Freiheit dazu führt, dass auf dem Weg zur Entscheidung zwangsläufig mehr Versuch und Irrtum stattfinden werden - und das ist normal. Einige Leute denken , dass man einfach die perfekte Lösung weiß , kann von vornherein (im Voraus), auch ohne eine einzige Zeile Code zu schreiben. Ich bestehe im Gegenteil darauf, dass während des kreativen Prozesses der Weg zur Entdeckung der Lösung des Problems (dies gilt nicht nur für Software) erforderlich ist, zu basteln : Es ist unmöglich, alles im Voraus sicher zu kennen; Im Gegenteil, Sie lernen in der Praxis, indem Sie schrittweise alle neuen Optionen heraussortieren und sich an diejenigen halten, die funktionieren, Ihre Entscheidung verfeinern (und, wenn Sie nach der „flexiblen“ Methodik arbeiten, vielleicht schrittweise an die Kunden übergeben), bis Sie damit zufrieden sind.



Denken Sie nur daran, wie oft ein Bauteil auf Papier mühsam entworfen wurde - nur dann, um das Design komplett neu zu gestalten, mussten Sie nur mit der Implementierung beginnen. In diesem Fall wird es immer unbekannte Unbekannte geben, und Sie können sie nur nachträglich identifizieren (nachträglich), Ihre Lösung programmieren und nicht viel Zeit damit verbringen, zu theoretisieren und nicht so zu tun, als hätten wir im Voraus perfekte Informationen. Eine solche Improvisation passt nicht gut zum geschätzten Zeitrahmen.

Wie bei anderen kreativen Aktivitäten ist es auch beim Programmieren sinnvoll, strategisches Zögern zu üben  - dieser Begriff wurde zuerst von Adam Grant vorgeschlagen, der behauptete, dass die Kreativität oft versagt.Auf Nachfrage dagegen entsteht Kreativität als "Push-Benachrichtigung " aus einem bestimmten Prozess, der im Hintergrund in Ihrem Kopf abläuft:
„Regelmäßig verschleppende Mitarbeiter widmen sich in der Regel mehr Zeit für abweichendes Denken. Kuratoren bewerten sie häufiger als kreativer als ihre Kollegen. Aufschub fördert nicht immer die Kreativität: Wenn ein Mitarbeiter nicht die zuversichtliche Motivation hat, ein schwerwiegendes Problem zu lösen, bleibt er aufgrund eines Ausrutschens einfach zurück. Wenn eine Person jedoch leidenschaftlich genug ist, um Geschäfte zu machen und neue Ideen zu verbreiten, dann kommt die Aufgabe zu einem späteren Zeitpunkt zu kreativeren Lösungen . “
- Grant, Adam. „Originale: Wie Nichtkonformisten die Welt bewegen“

Dies wird auch die Befürworter einer zentralen Planung nicht erfreuen , die jede Minute in Softwareentwicklungsprojekten planen und messen wollen.


Milchstraße , Mars und Meteor

Die Erstellung von Programmen beherrschen


Die besten Entwickler, die ich kenne, sind erfahrene Handwerker. Geschicklichkeit ist ein charakteristisches Merkmal guter Software: Sie schaffen etwas, das funktioniert, und Sie erstellen es auf die bestmögliche Weise. Es ist relativ einfach, etwas zu schaffen, das funktioniert, aber es ist sehr schwierig - es wird nicht nur funktionieren, sondern auch die Zeit überdauern.

Da Sie ein Meister sind, spricht die Qualität Ihrer Arbeit von Ihnen . Qualität ist für Sie wichtiger als Quantität, weil Sie nicht der Autor des govnokod sein möchten, auch wenn Sie den Produktmanager zufriedenstellen könnten, indem Sie Ihrem Programm ein glänzendes Aussehen verleihen und es mit einer Menge böser Überraschungen im Innern packen - ich nenne diesen Ansatz " Kindersurprise Development". Sie wissen, dass es richtig ist, genug Zeit für ein gutes Programm zu verwenden und zu schreiben, also widerstehen Sie dem Druck, es schneller zu machen, denn Sie wissen, je mehr Krücken Sie jetzt haben, desto kurzlebiger wird Ihr Code sein und desto mehr Probleme werden Sie damit haben Dinge zu tun


Augen bluten

Beherrschung ist mit Sorgfalt verbunden : Wir sorgen für hervorragende Arbeit, diejenigen, die unseren Code nach uns aufrechterhalten müssen, unsere Kunden, die leicht mit unserem Programm umgehen sollten, Teamkollegen usw. Sie tun dies, weil Sie kein Arschloch sind und weil Sie wissen, dass Sie dies tun sollten, wenn Sie sich für den Erfolg des Projekts interessieren.

Kurz gesagt, ein guter Ingenieur hat eine schwierige Aufgabe: sich um die Qualität zu kümmern, die sich auf lange Sicht bemerkbar macht, in einer Welt, in der alles schnell erledigt ist.

In der Praxis drückt sich dies in solchen Dingen aus:

  • Finden Sie die richtige Kombination zwischen Einkapselung, Erweiterbarkeit, Skalierbarkeit usw. - Wiederum wird durch Versuch und Irrtum ein iterativer Ansatz erforderlich sein, da niemand beim ersten Versuch die beste Lösung finden kann.
  • Nehmen Sie sich etwas Zeit, um zu überdenken, wenn Sie auf einen schändlich schlechten Code stoßen.
  • Schreiben Sie gute, vollständige Tests - vielleicht sogar TDD
  • Programm gemeinsam mit einem Kollegen

Es ist unnötig zu erwähnen, dass es unmöglich ist, dies alles im Voraus zu planen. Daher hilft Ihnen ein solcher Ansatz immer noch nicht, die Fristen einzuhalten.

Ihre Vorhersagen sind falsch.


„Selbst wenn es klare Anforderungen gibt - und diese treten anscheinend niemals auf -, ist es fast unmöglich zu berechnen, wie lange es dauert, eine bestimmte Aufgabe zu erledigen, da wir diese Aufgabe noch nie gelöst haben. Wenn Sie sich entscheiden - dann geben Sie einfach das Ergebnis. "
- Ron Jeffries, NoEstimates- Bewegung

Software-Projekte sind komplexe Systeme : Sie werden von Menschen erstellt und haben daher den Eindruck von zwischenmenschlichen Beziehungen, Motivation, Kommunikationsproblemen und allgemein der menschlichen Psychologie. All dies ist sehr schwer in der Tabelle zu modellieren und zu quantifizieren, wenn Sie an meiner Meinung interessiert sind. Daher sind Softwareprojekte sehr schwer zu modellieren (und daher vorherzusagen). Nassim Taleb erklärt dies am besten in seinem Buch Anti-Fragility :

„Komplexe Systeme zeichnen sich durch ihre große Interdependenz (die schwer zu erkennen ist) und nichtlineare Reaktionen aus. "Nichtlinear" bedeutet, dass, wenn Sie beispielsweise die Medikamentendosis oder die Anzahl der Arbeiter in der Anlage verdoppeln, die Rendite nicht doppelt so hoch ist, sondern entweder viel mehr oder weniger. Ich kann nicht sagen, dass zwei Wochenenden in Philadelphia zweimal schöner sind als eines - ich kann das aus eigener Erfahrung sagen ... “.
- Nassim Nicholas Taleb, "Anti-Fragilität"

Schlimmer noch, da die Zeit kein negativer Wert sein kann, werden ungeplante "Überraschungen" höchstwahrscheinlich die Fertigstellung des Projekts eher verschieben als näherbringen, da es zu einer Asymmetrie der Ergebnisse kommt:

„Zeit ist kein negativer Wert, was bedeutet, dass ein dreimonatiges Projekt nicht in einem Zeitraum von null oder negativ durchgeführt werden kann. Daher häufen sich auf der Zeitachse, die sich von links nach rechts bewegt, Fehler auf der rechten Seite und nicht auf der linken Seite. Wenn die Unsicherheit linear ist, würden wir feststellen, dass einige Projekte wesentlich früher abgeschlossen werden (da wir manchmal viel früher am Standort ankommen und manchmal viel später). Aber in Wirklichkeit ist nicht alles so. "
- Nassim Nicholas Taleb, "Anti-Fragilität"

Dies ist eine schlechte Nachricht, da Unsicherheit gewährleistet ist und sich selbst kleine Fehler bei der Beurteilung einzelner Aufgaben exponentiell auf Projektebene ansammeln. Darüber hinaus betrachten wir hier den besten Fall, wenn die Entwickler nach sorgfältiger Prüfung der Fristen Fristen setzen. Die Realität ist jedoch viel absurder: In den meisten Fällen setzt „Business“ Fristen nach Belieben, und nur dann übernehmen Ingenieure, die alle Anforderungen für diesen willkürlich festgelegten Zeitraum erfüllen wollen, die Aufgabe. ein Fall, der so eklatant ist, als würde man ein Haus von einem Dach aus beginnen, nicht von einem Fundament aus, oder einen Wagen vor ein Pferd stellen.


Gute Frage:

Hier einige Beispiele, die die Nichtlinearität der Softwareentwicklung und die daraus resultierenden Rückkopplungszyklen demonstrieren:

  • Sobald Sie vorgeschlagen haben, dass die API, mit der Sie Kontakt aufnehmen möchten, akzeptiert wird accountId, akzeptiert sie eigentlich nur memberId. Wir fügen die ungefähre Frist von 4 Tagen hinzu, die für die Umgestaltung des API-Codes erforderlich ist. Danach benötigen wir eine separate Überprüfung, zu der wir weitere 2 Tage hinzufügen werden.
  • Die erwartete Aufgabe, die wir in zwei Tagen lösen sollten, erstreckt sich über eine Woche, da einer der Kollegen Sie (und das zu Recht) dazu zwingt, das ekelhafte Code-Snippet, das seit langem in den Startlöchern ist, zu überarbeiten und zu optimieren.
  • Erinnern Sie sich an diese einmalige Aufgabe, wenn Sie nur eine neue Funktion implementieren mussten. Es stellte sich jedoch heraus, dass Sie die Abhängigkeit, die 4 Tage dauerte, aktualisieren mussten. Diese Operation löste eine Kettenreaktion mit der Aktualisierung anderer Abhängigkeiten und einer ganzen Reihe von Abhängigkeiten während der Montage aus.

Haben wir vermasselt?


Durch Trägheit spielen wir dieses Spiel einfach weiter mit Schätzungen und Planungen, nur um uns zu versichern: Wir haben die Situation unter Kontrolle. Aber in Wirklichkeit kontrollieren wir nichts; Die Erfahrung zeigt, dass Softwareprojekte nicht vorhersagbar sind. Daher denke ich, dass es besser ist, sich auf das Geschäft zu konzentrieren, als auf die Planung -  #NoEstimates , wer ist bei mir? In vielen Organisationen ist dies jedoch keine Selbstverständlichkeit: „Man kann die Ingenieure nicht einfach mit einem Ball tanken lassen, damit niemand sie kontrolliert. Es muss Rechenschaftspflicht geben! " Ich habe verstanden.


Das sagst du nicht?

Was dann zu tun Ich denke, es kommt darauf an, die Kluft zwischen der Welt der Tische und der Welt der IDE so zu verringern, dass den Ingenieuren maximale Kreativität, Flexibilität und die Freiheit geboten werden, Geschicklichkeit zu zeigen, sich jedoch gleichzeitig an die versprochenen Erwartungen halten und die Erwartungen der Projektbeteiligten erfüllen. Der Technical Manager (Engineering Manager) ist der beste Spezialist für den Bau solcher Brücken, die auch die Kluft zwischen den beiden Welten auffangen können. Diese Arbeit ist nicht einfach, aber notwendig. So gut spricht Aaron Longwell in ihrem Artikel über sie:

„Da technische Manager an der Grenze zwischen Unternehmen und Technikfreaks leben, müssen sie die Widersprüche zwischen Erwartungen und Realität ausgleichen. Sie sind wie eine Hebelaufhängung, die in verschiedene Richtungen gezogen wird: Sie kann auf beiden Seiten einrasten. Wenn das Geschäft gewinnt, werden Entwickler zu Tode getrieben. Wenn technische Argumente das Geschäft überwiegen, dann verabschieden Sie sich von Budget und Fristen. In jedem Fall - Versagen. Ein erfolgreicher Software-Projektmanager findet Wege, flexibel zu agieren. nachgeben, ohne zu brechen, und Reibung allmählich auflösen. Eine "Führung als Dienst" kann Ihnen dabei helfen, diese Flexibilität zu finden. "
- Aaron Longwell, Warum Softwareentwicklung Servant Leaders erfordert

Es ist auch sehr wichtig, ein starkes Vertrauensverhältnis zwischen Produktion und Ingenieuren aufzubauen. Wenn es Vertrauen gibt, können Sie ehrlich und gewissenhaft Zeitpläne aushandeln. Wenn Sie zuvor bewiesen haben, dass Ihr Team gute Software leistet, sollten Sie einen recht guten Ruf haben, und die Stakeholder sollten Ihnen vertrauen, wenn Sie wissen: Wenn Sie außerhalb des Zeitplans sind, dann aus guten Gründen und zum Wohl der Allgemeinheit.

Ein weiterer "Trick", den ich persönlich als Manager verwendete, bestand darin, bestimmte Termine nicht zu erwähnen, da diese zwangsläufig zu engen Terminen werden. Es ist besser, vage Begriffe anzugeben, beispielsweise "drei bis fünf Wochen". Wenn Sie sich einer solchen wackeligen Frist nähern, fügen Sie in diesem Fall hinzu: „im April oder Mai“, was leicht als „zwischen dem 15. April und dem 3. Mai“ Anfang April interpretiert werden kann, um den 10. April herum kann es zu „In 20 der April "usw. In diesem Fall sind Sie nicht schlau und kommunizieren nicht mit Kollegen, und das Team bietet die nötige Flexibilität, um die unvermeidlichen unvorhergesehenen Probleme zu lösen.

Denken Sie schließlich daran, dass der Entwickler für die technische Qualität des Produkts verantwortlich ist und nicht für andere interessierte Parteien. Natürlich gibt es Reibungen zwischen Organisationen, die auf den ersten Blick von unterschiedlichen Anreizen geleitet werden. In diesem Fall ist das Wichtigste, dass Sie alle (vermutlich) ein gemeinsames Ziel vereinen: den Kunden so schnell wie möglich mit hochwertiger Software zu versorgen. Anscheinend sind nur gute Entwickler in der Lage, auf diese Weise zu denken und zu verstehen, dass es wichtig ist, den betrügerischen Ansatz „Einmal, zweimal und fertig!“ Zu vermeiden, was auf lange Sicht der langsamste ist.

Abschließend möchte ich sagen, dass dies ein lösbares, wenn auch kompliziertes (und allgemeines) Problem ist. Ich würde sagen, wenn Ihr Manager oder Ihre Organisation Ihrer Meinung nach nicht in der Stimmung ist, gute Software zu schreiben, müssen Sie dies kommentieren und versuchen, sie zu ändern. Wenn dies fehlschlägt, suchen Sie einen anderen Job.

Über den Übersetzer

Der Artikel ist in Alconost übersetzt .

Alconost beschäftigt sich mit der Lokalisierung von Spielen , Anwendungen und Websites in 70 Sprachen. Sprachübersetzer, Sprachtests, Cloud-Plattform mit API, durchgängige Lokalisierung, Projektmanager rund um die Uhr, beliebige String-Ressourcenformate.

Wir machen auch Werbe- und Bildungsvideos.- für Websites, die Image, Werbung, Schulungen, Teaser, Explorer, Trailer für Google Play und den App Store anbieten.

Lesen Sie weiter