Habe ich eine falsche Vorstellung von Software Engineering? [geschlossen]

Ich habe eine Frage, die von meinem letzten Job (eher Praktikant) aufgeworfen wurde.

Nur um die Dinge in einen Zusammenhang zu bringen: Ich bin 21 Jahre alt und habe mein zweites Studienjahr abgeschlossen, bevor ich ungefähr 2 Jahre Erfahrung in Sys Admin / QA-Jobs gesammelt habe IT-Branchen betrieben. Blicken Sie nach vorne in die Gegenwart und hier lande ich einen Praktikumsplatz bei einer der führenden Forschungseinrichtungen in Großbritannien.

Was ich tun muss, ist, einige interne Tools mit einem Technologiemix zu erstellen - hauptsächlich AWS / Java / Bash - Sie erhalten das Bild. Alles ist in Ordnung, ich mache meine Arbeit, aber ich bin nicht glücklich. Warum ist das so? Ich muss in einer Ad-hoc-Angelegenheit arbeiten. Das heißt, Dinge schnell zu erstellen, ohne Zeit mit dem Entwerfen zu verbringen. Mein Vorgesetzter sagte ausdrücklich, es sei zu erwarten, dass es durch auftretende Probleme "stürzt" und wir im Wesentlichen. In der Folge stellte sich heraus, dass Dinge neu gemacht und neu konstruiert werden mussten und sie immer noch nicht perfekt sind. Was das Testen angeht - halten Sie es auf ein Minimum, solange es funktioniert, ist es in Ordnung.

Bin ich schuld daran, mit dieser Arbeitsweise nicht einverstanden zu sein? Ist es falsch, das System als Ganzes zu überdenken, sich dann auf verschiedene Komponenten zu konzentrieren und zu sehen, wie sie zusammenwirken, um verschiedene "Schlüsselpunkte" herauszufinden, die sich in Zukunft als problematisch herausstellen könnten? Ist es ein Verbrechen, einen guten Job machen zu wollen und keinen "schnellen Job"? Ist es ein Fehler oder eine falsche Einstellung, die für ein Problem geltenden Datenstrukturen untersuchen zu wollen, damit Sie je nach Problemstellung die beste auswählen können? Nach meinem besten Verständnis hat das "Engineering" -Bit in "Software Engineering" genau damit zu tun - recherchieren Sie Ihre Problemdomäne und finden Sie eine fundierte Lösung, verfeinern Sie diese dann nach Bedarf?

Ich war bei einem Interview in einem Büro von Arm's in Großbritannien und sie zeigten mir ihren SCRUM-Raum und es sah so aus, als hätten sie eine ziemlich gute Idee, wie sie ihr Projekt managen sollten - sie hatten einen Rückstand, sie hatten Metriken, wie lange sie waren Das Problem könnte gelöst werden - die üblichen Dinge für SCRUM - völlig anders als die Art und Weise, wie die Dinge "hier" ablaufen.

Habe ich eine falsche Vorstellung von der Softwareindustrie im Allgemeinen? Ich würde gerne Ihre Meinung dazu hören. Ich meine, ich bin in die Softwareentwicklung "eingetreten", nur weil ich Dinge schaffen will - schlicht und einfach, aber ich will Qualitätsdinge schaffen. Ich möchte, dass meine Software in verschiedenen Szenarien verwendet wird. Ich möchte, dass sie kugelsicher ist. Ist das nicht die treibende Kraft für alle Softwareentwickler? Ich denke, jeder kann ein Programmierer / Programmierer sein, indem er nur die Syntax lernt, aber für mich beginnt der wahre Spaß, wenn man tatsächlich ein Design entwickeln muss, das in der realen Welt machbar ist.

Früher habe ich meine Aufgaben an der Universität erledigt, indem ich sie nur angeschaut und direkt mit dem Codieren begonnen habe. Dabei konnte ich leicht Noten über 75% erzielen, und ich habe das Modul "Software Development Lifecycle" nie wirklich geschätzt. Aber jetzt, als ich in der realen Welt sah, wie schlimm es ist, ohne formalen Prozess und mit der Frustration zu arbeiten, die einer Situation innewohnt, in der man nicht weiß, ob sich die Anforderungen morgen ändern werden (oh, habe ich gesagt, dass wir nichts tun) Haben Sie keine klar definierte Anforderungsanalyse?)

Ich mag es wirklich zu glauben, dass ich gerade eine Position erreicht habe, in der einige Leute nur einen Code-Affen brauchten, um ihre Drecksarbeit zu erledigen, und das ist nicht der Fall, wie die Software-Welt im Allgemeinen funktioniert.

Software wiederverwendbar und kugelsicher zu machen, ist nicht die treibende Kraft des Software-Engineerings. Beim Engineering geht es darum, reale Probleme unter realen Bedingungen optimal zu lösen . Die meisten Ingenieure würden es vorziehen, an einem Ferrari zu arbeiten - aber ein Kombi benötigt genau so viel Technik, und der Grund, warum ein Kombi (in gewisser Weise) nicht so gut arbeitet, liegt an schwierigeren Konstruktionsbeschränkungen, nicht an schlechterer Technik .

Wenn Sie sagen, dass Sie einen "guten Job" anstatt eines "schnellen Jobs" machen möchten, tun die meisten Ingenieure dies, aber manchmal ist es ein Teil dessen, was gut definiert, wie schnell es zu Ende geht. Es ist also nicht richtig, "gut" und "schnell" als gegensätzliche Entscheidungen zu betrachten. Oder zu glauben, Sie machen einen schlechten Job oder sind nur ein "Code-Affe", um den bestmöglichen Job in der verfügbaren Zeit zu machen.

Natürlich ist es durchaus möglich, dass der Prozess nicht optimal ist und mit etwas mehr Design im Voraus besser abschneidet. Der Säuretest wäre, ob die derzeitige Vorgehensweise mehr Probleme verursacht, als sie für die Benutzer löst , oder nur die Entwickler nervt, die auf diese Weise arbeiten müssen. Wenn es den Benutzern tatsächlich Probleme bereitet, besteht ein Teil Ihrer Aufgabe darin, zu demonstrieren, dass dies der Fall ist, und die Menschen für einen etwas kontrollierteren Prozess zu gewinnen.

Eigentlich stört mich das. Sie sind in einem Beruf, in dem Sie Tools für Forscher entwickeln, richtig. Sie werden jedoch aufgefordert, diese Programme schnell zu erstellen, damit sie scheinbar nur minimal funktionieren. Überraschung Überraschung. Dies ist einfach die typische Herangehensweise des Forschers an die Programmierung mit dem Dollar, der an einen tatsächlichen Programmierer weitergegeben wird.

Die Hauptsorge dabei ist, dass insbesondere mangelnde Tests ethisch bedenklich sein können, wenn die Tools einen wichtigen Zweck haben. Wenn man sich nicht sicher ist, ob die Software Mängel aufweist, weil man sich auf eine minimale Testzeit beschränkt, bedeutet dies, dass NO ONE für den Betriebszustand der Software verantwortlich ist, und Atlas zuckt mit den Schultern.

Lassen Sie uns jedoch eine Sekunde darüber nachdenken. Welche Tools entwickeln Sie? Wenn Sie Software entwickeln, die Daten modelliert, besteht hier ein großes ethisches Dilemma . In einigen Situationen führt wissenschaftliche Forschung zu Entscheidungen, die viele Menschen in großem Maßstab betreffen.

Nehmen wir für einen Moment das umstrittene Thema des vom Menschen verursachten Klimawandels an. Nehmen wir an, sie haben die gleichen Standards für die Modellierungssoftware festgelegt, mit denen sie zu den Ergebnissen kommen, die sie heute ziehen. Das Thema hat großen Einfluss darauf, wie wir mit der Umwelt und der internationalen Politik richtig umgehen.

Ist es nicht ethisch einwandfrei sicherzustellen, dass die Modellierungssoftware keine größeren Probleme mit ihren Vorhersagen hat?

Das ganze Problem ist nicht, dass Treibhausgase die Erde erwärmen. Das Problem ist, ob das Nettoergebnis der Rückkopplungseffekte ein sich beschleunigender Temperaturanstieg ist, der nach dem Überschreiten einer Schwelle nicht mehr reversibel wäre.

Wenn dieser Gewinn einträfe, wäre der Nachweis eines Nettoergebnisses marginal, wahrscheinlich innerhalb des Fehlerbereichs.

Leichte Fehleinschätzungen, sogar Methoden, die das Speichern und Abrufen von Daten im Backend beinhalten, können dazu führen, dass entweder ein ernstes Umweltproblem an einem Ende des Scheiterns ignoriert wird oder dass internationale Richtlinien, die viele Menschen betreffen (Arbeitsplätze zerstören, Renten zerstören usw.). ) auf dem anderen.

Also ja, du hast recht. Es ist mir egal, wie schnell die Forschung ist ... Wenn sich Forscher auf Software-Tools verlassen möchten, um Daten zu verwalten und Berechnungen für sie durchzuführen, müssen sie lernen, auf Software zu warten, die richtig ausgeführt wurde. Andernfalls wird diese Software zu einer Schwachstelle in ihren Theorien, für die sie nicht verantwortlich gemacht werden, was zu ethischem Fehlverhalten führt.

Sie haben keine falsche Vorstellung davon, was Software-Engineering ist. Es fehlt Ihnen jedoch ein sehr wichtiger Aspekt: ​​Dies ist eine Dienstleistungsbranche. Einige von uns arbeiten jahrelang an einem Produkt und durchlaufen erst das Design und dann viele Iterationen, bevor es in Version 1 ist. Andere müssen in 3 Stunden etwas produzieren. Es kommt darauf an, wen Sie warten und was der Zweck ist.

Wenn Sie eine Anwendung in 3 Stunden (oder Tagen) erstellen können, die genau das tut, was sie soll, warum sollten Sie mehr Zeit für das Design im Voraus aufwenden? Du verschwendest nur Geld. Geldverschwendung ist im Allgemeinen keine gute Idee ™.

Wie andere bereits gesagt haben, handelt es sich bei Software-Engineering zu einem großen Teil um "extrinsische Einschränkungen". z.B. Zeit, Budget, Service, Support, Erfüllung irrationaler idiotischer Anforderungen usw.

Viele von uns (einschließlich mir) haben sich mit der Programmierung befasst und dabei gedacht, dass es nur um die Programmierung selbst geht - schöne und elegante Software-Teile in einem Vakuum (oder zumindest in einem relativen Vakuum) zu programmieren. Das ist selten der Fall. Es mag einige seltene akademische oder F & E-Software-Jobs geben, die dem sehr nahe kommen, aber zum größten Teil ist die überwiegende Mehrheit der Software-Entwicklungsarbeit nicht so. Insbesondere in der Wartungsphase, die in der Regel mehr als 90% der Lebensdauer eines Produkts ausmacht, und im täglichen Brot- und Butterbrotprogramm der meisten permanenten kommerziellen Softwarearbeiten.

Ich hatte lange Zeit einen internen Konflikt darüber, der mich oft über meine Arbeit unglücklich machte (und es ist ein Teil dessen, was letztes Jahr schließlich zu einem Burnout führte). Ich hatte immer das Gefühl, dass ein Job scheiße ist, wenn es nicht nur darum geht, schönen Code zu erstellen und sich die Zeit zu nehmen, dies eigenständig zu tun. Aber das ist die Realität - und manche Menschen leben von einem sehr serviceorientierten Arbeitsablauf. Dadurch fühlen sie sich pragmatisch und nützlich. Auch wenn die eigentlichen "pure software engineering" Aspekte eines Projekts relativ hektisch und schlampig werden.

Wie auch immer, es ist gut, dass Sie dies jetzt in Frage stellen. Dies ist eines der Dinge, die sie in der Schule nie richtig erklären. Und Unternehmen tun gerne so, als würden sie sehr gute Ingenieurspraktiken anwenden, auch wenn dies nicht der Fall ist. Hinweis: die meisten nicht.

Trotzdem sind die Dinge unterschiedlich. Bestimmte Unternehmen (vor allem Unternehmen, für die Software das Kerngeschäft darstellt, und Unternehmen, die mit hochgradig sicherheitskritischen Softwareprodukten wie medizinischen Geräten arbeiten) folgen einem sehr strengen Engineering-Prozess. Aber insgesamt, ja, ich sage Ihnen, dass die meisten kommerziellen Software-Arbeiten relativ schlampig sind. In der Regel gibt es einen formalen Prozess, aber die strikte Einhaltung dieses Prozesses tritt fast immer in den Hintergrund, wenn Sie auf Eingaben von Kunden und anderen geschäftlichen Druck reagieren. Es ist nicht wirklich "Schlamperei" an sich, es ist einfach nur pragmatische Nützlichkeit. Der Trick besteht darin, Ihre Nische zu finden und eine Rolle unter dem Gesichtspunkt zu betrachten, welchen Service sie bietet, anstatt wie cool der "reine Programmieraspekt" davon ist.

EDIT : Ich denke, ich hätte in meiner ersten Einschätzung zu einseitig geklungen. Ich mag , dass oft hinzufügen es gibt auch echte Probleme mit Sachen, die zu schlampig, und den Mangel an gutem Prozess - bis zu dem Punkt , wo es um das Projekt in technische Schulden fährt und ist für das Geschäft tatsächlich schlecht. Aber dies zu sehen, ist mit Erfahrung verbunden. Grundsätzlich bleibt der Ausgangspunkt: Die meisten kommerziellen Software-Arbeiten sind heutzutage nicht so streng ingenieurorientiert, wie es Puristen vielleicht wünschen.

Was für eine ausgezeichnete Frage! Manchmal kann man etwas wertvoll machen, indem man schnell ist . Dies ist in der Regel in einem Forschungslabor der Fall. Je schneller wir lernen können, was wir nicht wissen, desto besser wird es uns gehen. Die von Ihnen erstellte Software dient nur zur Beantwortung von Fragen. Es ist "Code wegwerfen". Dies gilt auch für Startups, die nicht wissen, was die Kunden wirklich wollen. Auch das erste Mal, wenn Sie etwas machen, wird es beschissen sein. Lesen Sie den mythischen Mann-Monat .

Manchmal kann man etwas wertvoll machen, indem man gut ist . Dies ist in der Regel bei eingeschweißter Software wie Adobe Photoshop der Fall. Die Recherche wurde bereits vor Jahren durchgeführt und nun stellt sich die Frage, wie die Liste der Funktionen, die Kunden wünschen, so hinzugefügt werden kann, dass keine Fehler auftreten. Es geht um Architektur, Design und Testen, Testen, Testen. Der Code selbst ist das Wertvolle, nicht das, was Sie daraus lernen.

Wenn Sie mit der Forschung nicht zufrieden sind (das erste von etwas machen, neue Dinge lernen, die niemand zuvor wusste), versuchen Sie es mit eingeschweißter Software. Tatsächlich sollten Sie in Ihrem Alter so viele Dinge wie möglich ausprobieren. Gehen Sie Risiken ein! Sie werden viel lernen und auf lange Sicht besser dran sein.

Ich denke, Sie haben schon sehr früh in Ihrer Karriere bemerkt, dass eine schnelle Ausführung ohne ein geeignetes Design oder geeignete Tests dazu neigt, Sie zu beißen. Das gefällt dir offensichtlich nicht und du hast guten Grund, es nicht zu tun. Es ist lächerlich, wenn man davon ausgeht, dass man Probleme "durchstürzt", vor allem wenn man sie später noch einmal überprüfen muss, wenn die anfänglichen Lösungen falsch oder unvollständig sind. Sie können nur dann Lösungen für Probleme bereitstellen, wenn Sie diese vollständig verstehen. Dies erfordert Zeit und sorgfältige Planung.

Ich empfehle Ihnen, Ihre Vorgesetzten darüber zu informieren, dass Sie dies stört, und ihnen einen besseren Ansatz für Ihre Arbeit vorzuschlagen. Wenn sie nicht einverstanden sind und möchten, dass Sie sich weiter durch Ihre Arbeit "beeilen", würde ich anfangen, nach Arbeit woanders zu suchen. Es macht keinen Sinn, Dinge auf eine Art und Weise zu tun, die nicht Ihren eigenen Standards entspricht, geschweige denn einen Standard der Softwareentwicklungsqualität, den die Branche erwartet.

Hier ist mein Rat basierend auf meinen Erfahrungen. Ich bin 20 Jahre alt und arbeite zurzeit als Praktikant bei einem großen Finanzinstitut in Großbritannien. Ich hatte die gleichen Gefühle wie vor einigen Monaten die Arbeit, die du tust.

Was ich damit meine, hast du gesagt:

„Was ich tun muss, ist, einige interne Tools mit einem Technologiemix zu erstellen - hauptsächlich AWS / Java / Bash.“

Ich musste auch interne Tools erstellen, um bestimmte Prozesse zu verwalten und zu automatisieren. In einer schnelllebigen Umgebung müssen „kleine“ Dinge schnell implementiert werden. Ich hatte nicht den Luxus, den größten Teil der Softwareentwicklung oder der Algorithmen und Datenstrukturprinzipien anzuwenden, die mir in meinem zweiten Jahr beigebracht wurden, weil in ein paar Wochen eine funktionierende Version des Tools erforderlich war. Ich war jedoch sehr frustriert darüber nicht ganz schlecht, da ich gelernt habe, besser lesbaren Code zu schreiben.

Ich musste geduldig sein und bin kürzlich zu einem neuen Team gewechselt, das an einer neuen Iteration des von 10K + Benutzern verwendeten internen Systems arbeitet, und ich kann Ihnen versichern, dass der Aspekt des Software-Engineerings sehr ernst genommen wird. Mir wurde gesagt, dass ich den gesamten Software-Lebenszyklus von der Erfassung / Analyse der Anforderungen bis hin zur Implementierung und zum Testen kennenlernen werde. Ich glaube, ich werde diese Erfahrung sammeln, weil ich nicht an internen Tools arbeite, sondern an einem vollständigen System mit einer großen Anwenderbasis.

Was ich empfehle ist, dass Sie geduldig sind, die Tools fertig erstellen und einen sehr guten Job machen, damit Ihre Vorgesetzten mehr Vertrauen in Sie gewinnen und Ihnen herausforderndere Aufgaben zuweisen, die die Anwendung von Software-Engineering-Prinzipien erfordern. Gewinnen Sie zusätzliches Wissen durch zusätzliches Lesen und wenden Sie dieses Wissen auf das an, was Sie gerade tun. Ich erinnere mich, dass ich die gesamte E-Book-Bibliothek im Unternehmen durchsucht habe, um mein Wissen zu erweitern Ein wirklich gutes Buch, das mir sehr geholfen hat.

Seien Sie einfach geduldig, investieren Sie viel in Ihr eigenes Wissen und wenden Sie dieses Wissen an, wo immer dies möglich ist. Wenn Sie einen sehr guten Job machen, wird es bald jemand bemerken.

Ich stimme zu, dass Ihre derzeitige Arbeitsweise nicht optimal ist, ja. Wenn Sie jedoch sagen möchten, dass es überhaupt nicht funktioniert, würde ich Ihnen nicht zustimmen, da es verschiedene Ergebnisse gibt und die Institution immer noch in der Nähe ist.

Meine Hauptfrage an Sie ist, inwieweit Sie es mit Bränden zu tun haben, bei denen sofortige Lösungen erforderlich sind, ähnlich wie bei der Ersten Hilfe für einen medizinischen Patienten Sie müssen Tests und verschiedene Verfahren einplanen, die nicht sofort, sondern in naher Zukunft durchgeführt werden müssen.

Die Zeit für eine gute Arbeit hängt ein wenig von der Reife der Organisation ab und davon, wie wichtig es ist, dass etwas gut gemacht wird und nicht, dass behauptet wird, dass es gut gemacht wird.

Die Frage bei der Erforschung der Datenstrukturen ist, wie lange dies dauern soll. Wenn Sie sich ein Jahrzehnt Zeit nehmen möchten, um eine Datenstruktur zu recherchieren, die sich von einigen Stunden unterscheidet. Ich kann den Wunsch, die beste Antwort zu erhalten, zu schätzen wissen, aber es gibt etwas zu sagen, um die Rendite zu verringern, nachdem Sie einige Zeit mit einem Problem verbracht haben. Könnten Sie z verschiedene Hardware, um zu optimieren, wie schnell es laufen könnte.

Während es wichtig sein kann zu recherchieren, ist es auch wichtig, etwas zu liefern. Wenn Sie nichts liefern, wie gut sind Sie dann wirklich? Duct Tape Programmer wäre eher ein Beispiel dafür, wie die Dinge hier erledigt werden können.

Scrum ist eine spezielle Methode, die Sie möglicherweise an Ihrem aktuellen Arbeitsplatz anwenden können. Denken Sie nicht, dass Scrum eine Wunderwaffe ist. Unter welchen Umständen können Projekte unter Scrum and Agile scheitern? wäre ein Blog-Beitrag zu diesem Thema, der von Interesse sein könnte.

Ich vermute, dass Sie nicht sehen, wie informell die Prozesse an Ihrem aktuellen Standort sind, und dass das Gras auf der anderen Seite, wo es eine formelle Methodik gibt, immens grüner ist. Während es dort vielleicht besser ist, bevorzugen einige Leute vielleicht das, was Sie jetzt haben, mit der massiven Freiheit, Cowboy zu sein .

Ich denke, Ihre Situation ist immer noch realistisch, da weniger Wert auf die Qualität gelegt wird. Ihre Präferenz ist am anderen Ende der realen Welt. Technische Daten ändern, darüber hinwegkommen. Dinge müssen erledigt werden.

Überlegen Sie, wie Sie diese Arten von Unternehmen identifizieren können, wenn Sie sich für Ihren nächsten Job bewerben. Nur wenige Orte verfügen über ein Geschäftsmodell, in dem es sich leisten kann, dass Entwickler ihre Entwürfe für immer analysieren (auch Professoren müssen unterrichten). Kunden zahlen nur selten, wenn Ihre Arbeit nicht die Trockenlöschkarte verlässt. Ich hasse es zu sehen, dass du so früh in deiner Karriere verrückt wirst.