Wie kann ich es vermeiden, für ein Projekt gezüchtigt zu werden, das ich geerbt habe und das bereits fehlerhaft war, aber mir wurde gesagt, ich solle Funktionen hinzufügen, anstatt es zu reparieren?

Prodnegel

Wie kann ich es vermeiden, für ein Projekt gezüchtigt zu werden, das ich geerbt habe und das bereits fehlerhaft war, aber mir wurde gesagt, ich solle Funktionen hinzufügen, anstatt es zu reparieren?

Vergangenheit: Beginnen Sie einen neuen Job als Software-Ingenieur nach dem College. Zugewiesen an ein unkommentiertes, undokumentiertes Durcheinander eines Projekts ohne Training oder Mentoren. Ich bin die einzige Person, die an diesem Projekt arbeitet, niemand sonst kennt oder hat den Code jemals gesehen .

Ich sage meinem Manager, dass der Code sehr durcheinander ist und Fehler enthält, aber er sagt mir, ich solle an Funktionen arbeiten, anstatt den Code zu reparieren. Jetzt sind Monate vergangen und es ist bald an der Zeit, dem Kunden das Programm zu zeigen, und ich mache mir Sorgen, dass ich bestraft werde, weil ich ein teilweise „kaputtes“ Programm gegeben habe.

Da Refactoring aufgrund von Zeitdruck und Managerwünschen keine Option ist und nie war, was kann ich tun, um meinem drohenden Untergang zu entgehen? Ich habe das Gefühl, dass ich von Anfang an ungewollt zum Scheitern verurteilt war. Ich denke sogar, dass ich die Sache noch verschlimmert habe, indem ich dem fehlerhaften Code Funktionen hinzugefügt habe, da ich einige seltsame Dinge tun musste, um die Fehler zu umgehen.

Wie kann ich es vermeiden, für ein von mir geerbtes Projekt bestraft zu werden, das bereits fehlerhaft war, während mir gesagt wurde, ich solle an mehr Funktionen arbeiten, anstatt Fehler zu beheben?

BEARBEITEN: Ich habe das Gefühl, dass dies anders ist als die mit Duplikat markierte Frage, da ich ein brandneuer Entwickler mit 0 Jahren Erfahrung bin. Ich habe das Gefühl, dass dies ein wichtiger Aspekt meiner Situation ist.


Monika Cellio

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .

Erdbeere

Ah, der vergiftete Kelch. Ich glaube, ich hatte dieses Projekt für eine Weile.

Mitarbeiter-X

@Simba Obligatorischer Hinweis auf Scotty .

Mitarbeiter-X

Wie gut (oder schlecht) dies auch läuft, seien Sie dankbar, dass Sie die Lektion früh in Ihrer Karriere gelernt haben, anstatt später. Dies ist keine ungewöhnliche Situation und ich sehe hier viele gute Ratschläge: Wenn es wieder passiert, sind Sie bereit, von Beginn der Beziehung an taktvoll und professionell damit umzugehen.

Benutzer44108

Sie kennen diese Software jetzt besser als jeder andere.

Konzentrieren Sie sich also bei der Demonstration auf die Teile, die gut funktionieren (oder zumindest so funktionieren, wie sie sollten). Alle anderen Funktionen, die derzeit nicht so gut funktionieren, können als „in Arbeit“ oder „Prototyp“ gekennzeichnet werden. Verwenden Sie diese, um zu besprechen, wie diese Funktionen verbessert werden können (oder, noch besser, lassen Sie sich sagen, dass diese nicht wichtig sind).

Es wäre auch eine gute Idee, Schritte für die Demonstration zu notieren und die zu demonstrierende Version des Programms vorher durchzuspielen, damit Sie alles notieren können, was schief gehen könnte. Sie können dann sagen "das sollte ..." und bevor Sie es in der Demo tun, sagen, was schief gehen könnte und dass es in Ihrer "to-do"-Warteschlange behoben werden muss. Auf diese Weise müssen Sie nicht "ähm ... ähm ... das sollte nicht passieren."

Schauen Sie sich natürlich an, was Sie demonstrieren, und wissen Sie, was funktioniert und was nicht. Sehen Sie sich auch alle Dokumentationen an / sprechen Sie mit Leuten und verstehen Sie, was funktionieren sollte und wie. Das Demonstrieren von Wissen und das Zeigen von Vertrauen in das System wird Vertrauen in Sie und das, was Sie sagen, erzeugen. Dies wird Ihnen helfen, die Dinge wieder auf die Schienen zu bringen.

Es bleibt Ihnen und Ihrem Vorgesetzten überlassen, wie Sie Ihre Rolle darin darstellen – dh wenn Sie ihnen mitteilen, dass der ursprüngliche Entwickler das Projekt verlassen hat und Sie die Zügel übernehmen mussten. Die Leute neigen dazu, Ehrlichkeit mehr zu respektieren als Unehrlichkeit, und Versuche, einen früheren Entwickler zu vertuschen, werden ausnahmslos als Vertuschung angesehen (und die Leute mögen das nicht).

Vorausschauend zu sein, kann Vorteile bringen, da das Projekt neu ausgerichtet werden kann (vorherige Entwickler haben das Projekt möglicherweise ohnehin auf einen unerwünschten Weg geführt).

Prodnegel

Ich denke, Ihre Antwort hilft mir in dieser Situation am besten, aber ich zögere etwas, die Zeile "alter Entwickler hat es verlassen ..." zu verwenden, da es vielleicht so aussieht, als würde ich versuchen, jemand anderem die Schuld zu geben.

Benutzer44108

@Prodnegel - Warum? Es ist ganz natürlich, dass die Mitarbeiter weiterziehen. Sie können dies auch als „vom Projekt genommen“ oder „ich bin jetzt diesem Projekt zugewiesen“ bezeichnen. Schuldzuweisungen sind nicht nötig, es sind schlichtweg Tatsachen.

Nate Diamant

Es geht weniger um die Schuldzuweisung als vielmehr um die Schuldzuweisung. Ich denke, es ist besser zu sagen "Ich wurde damit beauftragt, x neue Funktionen hinzuzufügen, die ich Ihnen hier zeigen werde." Auf der anderen Seite sieht es so aus: "Ich habe dies bekommen, diese gefunden und beschlossen, sie nicht zu reparieren, weil sie nicht mein Problem waren." Das Problem besteht darin, dass der Kunde, wenn er der Entwickler des Projekts ist, in gewissem Maße sein Problem ist (eigentlich das Problem des Managers, aber er ist in diesem Fall der Vertreter).

Andreas Morton

Es wäre auch eine gute Idee, Schritte für die Demonstration zu notieren und die zu demonstrierende Version des Programms vorher durchzuspielen, damit Sie alles notieren können, was schief gehen könnte. Sie können dann sagen "das sollte ..." und bevor Sie es in der Demo tun, sagen, was schief gehen könnte und dass es in Ihrer "to-do"-Warteschlange behoben werden muss. Auf diese Weise müssen Sie nicht "ähm ... ähm ... das sollte nicht passieren."

Luan

@AndrewMorton Das ist zu gut, um es in einem Kommentar zu hinterlassen. Wenn Sie eine Demo erstellen, bereiten Sie die Demo vor . Beflügeln Sie es nicht einfach - planen Sie es, proben Sie es, beheben oder vermeiden Sie alle Fehler, die Sie auf diese Weise entdecken, und führen Sie die Aufführung durch. Denken Sie darüber nach, was der Kunde wahrscheinlich fragen oder sehen möchte, und finden Sie eine gute Antwort. Gehen Sie alles mit Ihrem Vorgesetzten durch, damit Sie beide genau wissen, was Sie liefern und worauf Sie/er achten müssen. Schneiden Sie Dinge, die nicht gut genug funktionieren - ein fehlendes Feature ("WIP") ist oft besser als ein schrecklich kaputtes Feature.

Lilienthal

@Pete Zugeben, dass das in einem internen Projekt in Ordnung ist, aber in Kundenpräsentationen absolut nicht gemacht wird. Andererseits sollten diese Präsentationen in den meisten Fällen sowieso nicht vom Entwickler ausgeführt werden.

Patch und das

@Prodnegel ist, dass die Probleme wirklich offensichtlich und unvermeidlich sein werden, anstatt zu sagen, dass "der alte Entwickler es so gelassen hat", eine Liste mit "bekannten Problemen" zu haben, die Ihnen bekannt sind und behoben werden müssen und die gegeben wurden von Ihrem Vorgesetzten eine geringere Priorität als das Hinzufügen neuer Funktionen.

Andreas Morton

@Luaan Bitte zögern Sie nicht, meinen Kommentar als Material zu verwenden, um diese Antwort zu bearbeiten, wenn Pete dies nicht rechtzeitig tut.

Joe McMahon

Es sollte beachtet werden, dass das Demontieren von etwas Buggy alles andere als ungewöhnlich ist. Das von Steve Jobs vorgeführte iPhone war gerade in der Lage, die Reihe von Demos zu machen, die er während der Präsentation gemacht hat; ein Abweichen vom „goldenen Pfad“ würde zum Absturz führen, AT&T brachte einen tragbaren Mobilfunkmast mit, um sicherzustellen, dass sie Dienst hatten, und es gab mehrere Einheiten auf der Bühne, damit er wechseln konnte, wenn einer starb – nytimes.com/2013/10/ 06/magazin/…

Kilisi

In einer solchen Situation müssen Sie Ihren Rücken bedecken. Lassen Sie sich immer schriftlich sagen, was die Probleme sind und insbesondere die Reaktion der Manager, sie zu ignorieren und Funktionen hinzuzufügen. Es ist so einfach wie das Versenden einer E-Mail.

„Hallo Chef, nach unserem Gespräch können Sie bitte klarstellen, was ich priorisieren soll. Es gibt eine Menge Bugs in X, oder sollte ich einfach mit den neuen Sachen weitermachen. Außerdem musste ich etwas digitales Kung Fu machen, um einen Fehler in W zu umgehen, ist das in Ordnung?'

Wenn Sie den Rücken frei haben, ist das egal, der Manager ist drin, nicht Sie, Sie machen nur Ihren Job.

Prodnegel

Mein Chef besuchte mich immer persönlich, hier kamen die meisten dieser Gespräche ins Spiel. Ich schrieb seine Antworten auf, sodass ich nicht viel Papierspur von ihm hatte, der mir sagte: „Vergiss diesen Fehler, tun Sie stattdessen dies". Ich mache mir Sorgen, dass sie am Ende zu mir kommen und fragen werden, warum es so viele Fehler gibt, und ich glaube nicht, dass es funktionieren würde, zu sagen, dass der Manager es mir gesagt hat?

Kilisi

Warum nicht? Die Arbeiter gehen (hoffentlich) nicht alleine los. Es liegt in der Verantwortung des Managers, Projekte im Hinblick auf sein Team grundsätzlich zu verwalten. Ich würde die Manager eher selbst entlassen, wenn alles in die Brüche geht.

Kilisi

Aber selbst E-Mails, in denen die Probleme aufgeführt sind, auf die NICHT geantwortet wird, sind immer noch ein starker Beweis.

Prodnegel

Ich glaube jedoch nicht, dass ich irgendwelche E-Mails habe, in denen die Fehler erwähnt werden, da sie klein genug sind, um den GRÖSSTEN Teil des Programms nicht zu behindern. Ich würde meinem Chef einfach immer sagen: "Ich glaube nicht, dass das ein sehr stabiler Code ist" und auf kleine Dinge hinweisen, die nicht zu 100 % funktionieren.

Alter_Lampenanzünder

@Prodnegel Durch „schnelle Gespräche“ versuchen viele skrupellose Menschen, Dinge unter dem Radar zu tun. Von nun an in Ihrer Karriere und jedes letzte Mal , wenn dies passiert, senden Sie eine Follow-up-E-Mail, die mit „gemäß unserem Gespräch“ beginnt und detailliert beschreibt, was Sie angewiesen wurden. Nur so können Sie Ihren Hintern schützen, wenn jemand darauf besteht, "offline" mit Ihnen zu sprechen.

Lakonischer Droide

Das Versenden einer Zusammenfassung des Gesprächs per E-Mail ist nicht nur ein guter Weg an CYA, sondern auch eine wertvolle Überprüfung, ob beide Parteien das gleiche Verständnis der Probleme haben.

J...

Ich würde wahrscheinlich auf Formulierungen wie „digitales Kung-Fu“ verzichten , insbesondere bei Managern, die nicht technisch versiert sind. Wenn die implementierte Lösung minderwertig sein musste, um der Zeitbeschränkung gerecht zu werden, sollten Sie sich darüber im Klaren sein, welche Kompromisse eingegangen wurden, sonst haben sie keine Ahnung, worauf sie sich einlassen, und es wird auch nicht erwartet, dass sie verstehen, dass „kung fu" bedeutet, dass es latente Mängel in der Codebasis gibt, die zukünftige Komplikationen verursachen können.

Bradley Thomas

Das ist eine gute Antwort, aber „digitales Kung Fu“ klingt viel glamouröser, als es wirklich ist. Was es wirklich ist, ist Mist auf Mist häufen zu müssen. Wenn ein Fundament wackelt, müssen manchmal alle möglichen unnötigen Engineering-Hacks obendrauf gesetzt werden, um das Ding gerade noch stabil zu machen.

Kilisi

Oh, verdammt, ich dachte, 'digitales Kung-Fu' wäre ein legitimer Tech-Begriff, ich benutze ihn seit einem Jahrzehnt :-)

Ford Präfekt

Wenn Sie ein Ticketing-System verwenden, erstellen Sie frühzeitig Tech-Debt-Tickets mit High-Point-Schätzungen für alles, bei dem Sie ein Problem sehen und wissen, dass die Behebung einige Zeit in Anspruch nehmen wird. Jira und ich denke, dass Trello beide Audit-Trails haben, und auf diese Weise können Sie sowohl Fehler im Auge behalten und was Sie tun müssen, als auch eine digitale Aufzeichnung Ihrer Reservierungen haben

Gedächtnis

Ich werde „digitales Kungfu“ stehlen.

Jeremy Französisch

Diese Art von Situation ist nicht so ungewöhnlich, wie Sie vielleicht denken. Es kann sich sicher wie ein drohender Untergang anfühlen.

Es ist sehr wahrscheinlich, dass sie versuchen, etwas von ihrer Investition in etwas für die geringstmögliche zusätzliche Investition zu retten. Aus diesem Grund haben sie ihm nur einen Junior-Entwickler zugewiesen.

Bis die Software ein Problem für jemanden so löst, dass er bereit ist, dafür zu bezahlen, ist die Software wertlos. Wenn Funktionen benötigt werden, um dieses Stadium zu erreichen, ist dies der beste Ort, um in die Software zu investieren. Zeit damit zu verbringen, etwas zu reparieren, wofür niemand bezahlt, ist keine gute Ressourcenallokation.

Stellen Sie sich vor, Sie hätten nicht getan, was Sie gebeten wurden, und Zeit damit verbracht, Fehler zu beheben, dann wäre bei der Demo ein wichtiges Feature für den Kunden nicht vorhanden. Dies könnte zu einem entgangenen Verkauf führen und wäre ausschließlich Ihre Schuld. Du kennst die Gründe für all diese Entscheidungen nicht, also bleib bei ihnen.

Ich weiß, idealerweise sollten die Dinge von Anfang an gut geschrieben sein, aber Sie haben das Projekt nicht gestartet und können daher nicht für das gesamte System verantwortlich gemacht werden.

Es ist unwahrscheinlich (wenn auch nicht unmöglich), dass Sie zum Scheitern verurteilt sind. Es ist wahrscheinlicher, dass das Unternehmen versucht, etwas aus dem zu machen, was derzeit ein toter Verlust ist.

Tun Sie also, was Sie können, damit die Demo gut läuft. Sie haben sich von Anfang an über den Stand des Codes im Klaren gewesen und Prioritäten vom Management übernommen. Wenn die Demo nicht gut läuft, liegt das nicht daran, dass Sie Ihre Arbeit nicht gut gemacht haben.

Wenn Ihr Unternehmen eine vernünftige Kultur hat, sollte dies in Ordnung sein.

Wenn das Unternehmen eine Schuldzuweisungskultur hat und Sie für die Demo oder den Stand des Codes verantwortlich gemacht werden, können Sie trotz all Ihrer Ratschläge an das Management beim nächsten Mal defensiver sein. Holen Sie sich alles schriftlich, seien Sie sturer bei der Behebung von Fehlern. Wenn Sie darauf angesprochen werden, weisen Sie darauf hin, dass Sie sich in der Vergangenheit die Hitze genommen haben, weil Sie dies nicht getan haben. In einer solchen Kultur zu arbeiten ist nicht schön und Sie müssen auf Ihren Rücken aufpassen (wenn es eine Option ist, einen anderen Job zu bekommen, dann suchen Sie sich einen)

Aber ich würde vorschlagen, Ihrem Unternehmen eine Chance zu geben. Tun Sie, was Sie aufgefordert wurden, so gut Sie können, und akzeptieren Sie, dass das Unternehmen ein gemeinsames Unterfangen ist.

Prodnegel

„Bis die Software ein Problem für jemanden so löst, dass er bereit ist, dafür zu bezahlen, ist die Software wertlos.“ Danke, das musste ich hören und macht sehr viel Sinn

Felsig

Dies ist eine sehr vernünftige Antwort, +1. Machen Sie immer das Beste, was Sie können. Machen Sie Ihr Unternehmen wieder großartig.

gazz0x2z

Von Grund auf neu zu schreiben ist normalerweise eine schlechte Idee. joelonsoftware.com/articles/fog0000000348.html . Davon abgesehen ist es jedes Mal, wenn ein vorhandener Fehler Sie daran hindert, ein neues Feature zu schreiben, an der Zeit, eine lokale Bereinigung vorzunehmen. Nur lokal, um im Fokus zu bleiben.

Jared Smith

@ gazzz0x2z dieser Artikel, auf den Sie verweisen, ist 15 Jahre alt und befasst sich fast ausschließlich mit Schrumpffoliensoftware. Ich sage nicht, dass Sie falsch liegen, aber seien Sie vorsichtig mit Verallgemeinerungen.

Luan

@JaredSmith Es ist alt, aber all diese Argumente sind immer noch vollkommen gültig. Sie sind auch nicht ausschließlich auf Schrumpffolie beschränkt - das Umschreiben ist mit enormen Kosten verbunden und macht alle Ihre Vorteile zunichte. Wenn Sie Ihre Beratungssoftware von Grund auf neu starten müssen, woher nehmen Sie den Vorsprung gegenüber Ihrer Konkurrenz?

gazz0x2z

@JaredSmith: Ich sagte "normalerweise", weil es immer Gegenbeispiele geben könnte. In interner Software habe ich viele Umschreibungen gesehen, die schlecht endeten (schlecht wie in 100 Millionen Euro Aufwand im Papierkorb). Ich sage nicht "niemals neu schreiben", ich sage "mit Vorsicht neu schreiben, in sehr kleinen Schritten".

Jared Smith

@Luaan Wir sprechen im Zusammenhang mit der OP-Frage über Software, die anscheinend niemand für irgendetwas verwendet . Es gibt kein Designdokument, keine Spezifikation, keine Reihe von Tests, die die gewünschte Funktionalität angeben. Es ist in einer Weise fehlerhaft, die für einen Junior-Entwickler offensichtlich ist. Der Versuch, es zu retten, ist möglicherweise nur ein reiner Trugschluss mit versunkenen Kosten. Spolsky sprach davon, funktionierende Software umzuschreiben, die von vielen Leuten verwendet wird. Sie haben absolut recht mit den Argumenten, die er in diesem Fall verwendet.

Luan

@JaredSmith Sicher, das macht die Dinge ein bisschen anders ausbalanciert. Aber Sie haben immer noch keine Ahnung, wie viele Grenzfälle und subtile Probleme der ursprüngliche Autor bereits behoben hat, möglicherweise während der Kommunikation mit dem Kunden. Die Tatsache, dass es keine Spezifikation gibt, ist eine Belastung für den Versuch, sie umzuschreiben und am Leben zu erhalten. Es kann sehr gut sein, dass eine komplette Neufassung billiger ist als der Versuch, dies zu beheben – es könnte auch sein, dass der Manager das Projekt einfach stoppt, wenn er die Wahl hat. Aber letztendlich ist das eine Managemententscheidung – und es ist eine gute Wette, dass Prodnegel wenig Ahnung von der größeren Sicht hat.

Jared Smith

@Luaan sehr wahr. Wenn es sich wirklich um Sunk-Cost-Attachment handelt, dann ist Ihre Vermutung mit ziemlicher Sicherheit richtig, dass das Aufgeben des Projekts das Beste für das Unternehmen ist.

smci

Diese Art von Codebasis existiert überraschend oft, und viele von uns haben an ähnlichen gearbeitet. (Es wurde angemerkt, dass eine Codebasis ein Spiegelbild der Organisationsstruktur ist, die sie hervorbringt – oder tatsächlich eine bewegende Chronik der Organisation). Hier ist ein pragmatischer Ansatz, den ich gelernt habe:

  • Das Management kennt die Codebasis nicht (das ist sowohl eine Stärke als auch eine Schwäche), kümmert sich absolut nicht um Fehler und wird nur dazu angeregt, neue Funktionen hinzuzufügen. Es ist also unendlich einfacher, sie zu verkaufen, wenn Sie an Letzterem arbeiten (Ertragsgenerierung), nicht an Ersterem (Kostensenke); Es ist einfacher für sie, dies sowohl intern als auch an den Kunden zu verkaufen.
  • Wenn also das Projekt beginnt, führen Sie superschnell eine Sichtung der schlimmsten Fehler durch und fügen Sie entweder fehlgeschlagene Testfälle oder Kabelbäume hinzu oder dokumentieren Sie zumindest die Szenarien in einem Fehlerverfolgungssystem ( "Wenn ich X auf Y mache, schlägt es fehl mit Ergebnis/Fehler Z" ). Überprüfen Sie dies gelegentlich, wenn es die Zeit erlaubt oder wenn sich das offensichtliche Vorhandensein oder der Schweregrad von Fehlern in Bezug auf die in der Entwicklung befindlichen Funktionen ausreichend ändert. Es ist eine sehr schwierige Disziplin, Dinge schnell zu sichten, die repariert werden sollten, aber die Zeit nicht zulässt. Aber schreiben Sie die Fehlerberichte und prüfen Sie die Korrekturen mit der Einstellung, dass eine unbekannte Tageszeit und ein unbekanntes Budget auf magische Weise eintreffen können.
  • Wenn Sie dann Funktionen hinzufügen, werden alle damit verbundenen Refactoring- und Fehlerkorrekturen zu einer Abhängigkeit der Funktion, werden in die Arbeit, Zeitschätzungen und Testszenarien einbezogen. Wie Sie diese Arbeit definieren und berichten, ist Ihre Entscheidung. Nur du weißt, wie du es an ihnen vorbei bekommst. Solange in der Zusammenfassung „Feature X implementiert“ steht, ist es ihnen egal.
  • Nähern Sie sich Demos an, indem Sie Wochen vorher interne Proben haben, um ihnen zu zeigen, "Wir haben den Code für X implementiert, aber er hat Fehler A, B, C, die behoben werden müssen". Planen Sie tatsächlich eine interne Demo für Ihr Management ein, unabhängig davon, ob der Kunde danach fragt. Gewöhnen Sie sie allmählich daran, x % der Zeit für Fehlerbehebung und Tests in Ihre Schätzungen einzubeziehen oder umgekehrt die ersten Demowochen durchzuführen, bevor Sie funktionierenden Code erwarten.
  • „Arbeite in ihrer Welt, nicht in deiner“

CodingFeles

Gute Antwort und ich liebe den letzten Punkt. In Kommentaren sagte OP, dass sie nur "kleine Rädchen" seien. Aber das gilt nur, wenn Sie neben dem Programmieren nicht versuchen, das Projekt mehr zu beeinflussen. Arbeiten Sie mit Ihrem Management zusammen, geben Sie ihm Ideen und neue Lösungen, wie Sie Herausforderungen aus Ihrer Sicht angehen können. Sie treffen Entscheidungen, aber Sie haben Einfluss, indem Sie Lösungen anbieten. Bitten Sie sie zuerst, wie diese Antwort nahelegt, um Proben. Versuchen Sie, Zeit dafür auszuhandeln, mindestens eine Woche vor der Demo des Kunden. Versuchen Sie dann, es für alle Demos zur gängigen Praxis zu machen, dann können Sie den Ratschlägen von @TheWanderingDevManager folgen ...

CodingFeles

und versuchen Sie, häufiger Demos mit dem Client zu machen. Usw. Sie werden viele Gründe hören, Ihre Lösung nicht zu implementieren - das ist in Ordnung. Gutes Management hat mehr Informationen über verfügbare Ressourcen und manchmal ist es einfach nicht möglich, großartige Lösungen im Projektablauf zu verwenden. Aber hör nicht auf! Einige Lösungen werden angemessen sein und umgesetzt werden. Und so professionell Einfluss auf Projekt und Unternehmen nehmen, ohne Managerposition. Und so können Sie aufhören, ein kleines Rädchen zu sein, und ein ernsthafter Profi werden.

smci

@CodingFeles Ja, es hängt davon ab, wie hoch die Inkompetenz in der mgmt-Kette geht. Letztendlich liegt es am OP zu entscheiden, wie einschränkend das alles ist, wie viel kulturelle Veränderung sie bewirken können und wie lange sie es versuchen wollen, bevor sie sich für etwas Besseres entscheiden. Wahrscheinlich keine große Menge.

Jörgen Fogh

Dies ist eine brillante Antwort! Anstatt nur zu hoffen, dass das OP nicht beschuldigt wird, beschreiben Sie tatsächlich, wie Sie sicherstellen können, dass dies nicht passiert.

smci

@JørgenFogh: Verdammt nein! Schlechte Managementketten werden dir immer die Schuld geben. Ich habe nur ein paar Tipps gegeben, wie man es verhindern oder minimieren kann. Nichts hindert sie daran, noch mehr Funktionsanfragen zu laden, Demos zu überspringen, sich zu weigern, schwerwiegende Fehler anzuerkennen usw. Ich habe nur vorgeschlagen, wie sie ihre Ahnungslosigkeit ausnutzen können, um zu versuchen, kleine Zeitfenster herauszuarbeiten, um das zu beheben, was dringend behoben werden muss.

Jörgen Fogh

@smci: Ich stimme voll und ganz zu, dass dies kein Allheilmittel ist. Es ist einfach viel besser, als nichts zu tun und auf das Beste zu hoffen.

HLGEM

Und diese Fehler können plötzlich Priorität bekommen, wenn die Übungsdemo für internes Management auf einen oder mehrere von ihnen stößt.

HLGEM

Es kann weniger Zeit in Anspruch nehmen, einen Fehler zu beheben, als beim Hinzufügen einer neuen Funktion eine große Problemumgehung zu erstellen. Betrachten Sie diesen Teil des Hinzufügens der neuen Funktion und es ist ein Vorteil, dass der Fehler auch behoben wird.

Gidds

Dies entspricht meiner Erfahrung: Es ist am besten, Fehler zu beheben, schlechtes Design zu überarbeiten und Verbesserungen vorzunehmen, während Sie fortfahren . Auf diese Weise verstehen Sie diesen Bereich des Codes bereits so gut, wie Sie es werden werden, Sie brauchen nicht viel zusätzliches Testen, Sie vermeiden die Risiken, die mit größeren Änderungen verbunden sind, und Sie müssen nicht begründen, was als solches angesehen werden könnte unproduktive Arbeit. Wissen Sie, wo Sie enden wollen, und machen Sie ständig kleine Schritte in diese Richtung.

Der Wandering Dev Manager

Zugewiesen an ein unkommentiertes, undokumentiertes Durcheinander eines Projekts ohne Training oder Mentoren. Ich bin die einzige Person, die an diesem Projekt arbeitet, niemand sonst kennt oder hat den Code jemals gesehen.

Schritt 1: Für alles, was Sie berühren, schreiben Sie zunächst Unit-Tests, sowohl um zu überprüfen, ob es bereits tut, was es sollte (oder zu zeigen, dass es nicht funktioniert), als auch um zu zeigen, dass Sie es nicht noch schlimmer gemacht haben. Sie berücksichtigen dies in jeder Schätzung. Dies bildet auch eine Dokumentation für den Code, da die Leute ihn aus den Tests verstehen können.

Jetzt sind Monate vergangen und es ist bald Zeit, Programm zu zeigen

Schritt 2: Stellen Sie sicher, dass Sie regelmäßig Demos/Vorschauen mit dem Kunden haben, sowohl um die Erwartungen festzulegen als auch um sicherzustellen, dass Sie das Richtige/Prioritäten tun.

Denn Refactoring ist und war aus Zeitgründen und Wünschen des Managers nie eine Option

Schritt 3: Wenn Sie eine solche Diskussion führen, dokumentieren Sie sie zur Bestätigung in einer E-Mail. Auf diese Weise stellen Sie sicher, dass der schmutzige Stock in die richtige Richtung zeigt, wenn sie anfangen, die Schuld zu verteilen.

da ich einige seltsame Dinge tun musste, um die Fehler zu umgehen

Verbergen Sie niemals Fehler, melden Sie sie, fügen Sie sie einem Fehlertracker hinzu und erhalten Sie einen Urteilsaufruf zur Behebung (siehe oben).

Wie kann ich es vermeiden, für ein von mir geerbtes Projekt bestraft zu werden, das bereits fehlerhaft war, während mir gesagt wurde, ich solle an mehr Funktionen arbeiten, anstatt Fehler zu beheben?

Führen Sie Ihre Due-Diligence-Prüfung durch, wenn Sie das Projekt aufnehmen, nicht wenn jeder herausfinden wird, dass es den Bach runtergegangen ist.

David Schwarz

" Verbergen Sie niemals Fehler, melden Sie sie, fügen Sie sie einem Fehlertracker hinzu und erhalten Sie einen Urteilsspruch zur Behebung (siehe oben). " Das ist Gold wert. Wenn Sie einen Fehler gemeldet haben und nicht angewiesen wurden, ihn zu beheben (oder angewiesen wurden, ihn nicht zu beheben), wird es immer noch einen Fehler geben. (Wenn Sie Widerstand gegen die Verwendung eines Bugtrackers bekommen, weisen Sie darauf hin, dass es keine andere Möglichkeit gibt, Bugs zu verfolgen. Sie wollen sie nicht vergessen.) Es sollte viele E-Mails hin und her geben, wie man Bugfixes priorisiert über Funktionen.

Prodnegel

Ich glaube, dass einige der Ratschläge nicht wirklich auf einen brandneuen Entwickler oder mich in meiner Situation zutreffen. #1) Als ich meinen Manager nach dem Testen/Fehlerbeheben fragte, sagte er mir, ich solle es nicht tun, aber Ihre erste Antwort ist, Unit-Tests zu schreiben. Ich stimme zu, dass dies getan werden sollte, aber ich denke nicht, dass es zulässig ist, gegen die Wünsche meines Vorgesetzten vorzugehen. #2) Ich kann nicht sicherstellen, dass der Kunde regelmäßige Demos bekommt, ich bin ein kleines Rädchen im System, das in dieser Situation null Power hat. Ich glaube nicht, dass es einem neuen Entwickler außerhalb der Schule erlaubt wäre, Demos zu planen

Prodnegel

#5) Es war schon von Anfang an nach Süden gegangen! Ich sagte meinem Manager, dass ich mit Refactoring/Fehlerbehebung beginnen wollte, aber er sagte mir, ich solle es nicht tun. Ich bin mir nicht sicher, was ich in meiner Situation hätte tun können.

smci

Meistens ist dies ein guter Rat, aber "Alles, was Sie berühren, schreiben Sie zuerst Komponententests für" : Das Bestehen auf vollständigem TDD wird im Allgemeinen nicht mit schlechtem Management funktionieren / Unterstützung erhalten. Sie müssen die schlimmsten Fälle selektieren und diese vorrangig behandeln - siehe meine Antwort für mehr. Es ist frustrierend.

alephnull

@Prodnegel "Ich habe meinem Manager gesagt, dass ich mit Refactoring/Bugfixing beginnen möchte, aber er hat mir gesagt, ich soll es nicht tun" - und wenn Sie gerade aus dem College kommen und Ihr Manager einigermaßen kompetent ist, war das genau die richtige Anweisung. Sonst hätte man nach 5 Jahren Arbeit eine schön strukturierte Codebasis, die noch keine der neuen Anforderungen des Anwenders erfüllt – und wenn man anfängt, sie zu implementieren, müsste man wahrscheinlich alles noch einmal komplett umgestalten! Softwareentwicklung in der realen Welt ist nicht wie College-Projekte!

alephnull

@Prodnegel "Ich glaube nicht, dass es jedem neuen Entwickler außerhalb der Schule erlaubt wäre, Demos zu planen" - das gemeinsame Merkmal aller guten Software-Demos ist, "man demonstriert nur das, was funktioniert". Jeder in der realen Welt weiß, dass Software Fehler hat, aber er möchte seine Zeit nicht damit verschwenden, dass ihm Fehler angezeigt werden, die ihn nicht einmal interessieren.

Der Wandering Dev Manager

@smci - wer hat tdd gesagt? Sie schreiben die Tests, die Sie benötigen, um zu zeigen, dass es immer noch funktioniert, nachdem Sie es geändert haben.

smci

@TheWanderingDevManager Das Schreiben vollständiger Unittests, sei es vor, während oder nach dem Codieren, ist laut Zeitplan häufig nicht zulässig. (In der Tat sind vollständige Unittests oft übertrieben, abhängig von den Fähigkeiten des Entwicklers und davon, ob die Funktionen durch Integrationstests oder halbmanuelle Tests ausgeübt werden. Es hängt von vielen Dingen ab.)

Luan

@Prodnegel Ich würde dasselbe sagen wie Ihr Manager. Sie kommen zu einem neuen Projekt, haben keine Ahnung, wie schrecklich es ist, und möchten es neu schreiben ? Herumspielen mit Dingen, die funktionieren, ohne zu verstehen, wie und warum sie funktionieren? Ihre Änderungen würden viel wahrscheinlicher die Qualität des Produkts verringern und sich in eine Reihe von "Oh, ich habe nicht erwartet, dass dieser Teil des Codes davon abhängt ..." verwandeln. Verschwendete Arbeit, kein Wert für den Kunden, und Sie' Ich sehe nur aus wie ein inkompetenter Besserwisser mit Diplom. Fehler melden. Aber sie zu beheben, ist eine Entscheidung für den Manager, nicht für Sie.

Der Wandering Dev Manager

@smci - "Das Schreiben vollständiger Unittests, ob vor, während oder nach dem Codieren, ist nach Zeitplan nicht zulässig", aber es ist üblich, fünfmal so lange mit Nacharbeiten / Fehlerbehebungen zu verbringen. Ich leitete Teams in einer gemeinsamen Codebasis mit vielleicht 150-200 Entwicklern, die gleichzeitig daran arbeiteten, es gibt immer Zeit für Tests, Sie beziehen es in jede Schätzung ein. Die eigene Zeit, die Sie haben (nicht die Brandbekämpfung), ist es mehr als wert, ich würde keinen Entwickler einstellen, der diesbezüglich Kompromisse eingehen würde.

smci

@TheWanderingDevManager: Diese Dinge sind ein Urteilsspruch. 150 Entwickler sind eine ganz andere Geschichte als ein 1-2 Entwicklerteam.

Der Wandering Dev Manager

@smci - Nein, ist es nicht (ich habe das auch in einer Firma gemacht, in der ich Angestellter Nr. 5 war). Wenn ich Ihnen ein bisschen Code gebe, von dem ich sage, dass es X tut, und ich möchte, dass Sie einfach Feature Y hinzufügen, wie überprüfen Sie dann, dass a) es tatsächlich tut, was ich sage, und b) Sie es nicht durch Hinzufügen von Y kaputt gemacht haben? Dazu benötigen Sie Tests (immer noch nicht TDD). Sie werden sowieso Tests als Teil der Codierung schreiben (wie Justin Trudeau über etwas nicht Verbundenes sagte, „weil es 2016 ist“), also sollten Sie ein paar zusätzliche Stunden einplanen, um Ihr Verständnis zu überprüfen, indem Sie einige Tests schreiben, so funktioniert es. Wenn Sie dies nicht tun, kann ich Ihnen einige gute Bücher empfehlen.

JMK

Jeder Entwickler denkt, dass jedes Projekt, das er erbt, ein fehlerhaftes Durcheinander ist, das ist eine natürliche Reaktion, und ich verstehe den Instinkt, alles so umgestalten zu wollen, wie Sie es sich vorstellen.

Wenn der bereits vorhandene Code jedoch funktioniert und seinen Zweck erfüllt und das Unternehmen neue Funktionen hinzufügen muss, sollten Sie sich darauf konzentrieren, die neuen Funktionen hinzuzufügen.

Das bedeutet nicht, dass Sie während des Vorgangs nicht umgestalten können.

Wenn Sie die neuen Funktionen hinzufügen, werden Sie wahrscheinlich mit dem bereits vorhandenen Code arbeiten, und wenn Sie dies tun, ihn aufräumen und Tests hinzufügen und sicherstellen, dass der neue Code auch von Tests abgedeckt wird.

Brownfield-Entwicklung (dh das Arbeiten mit und Verbessern bestehender beschissener Codebasen) ist eine Fähigkeit für sich, und Sie können nicht einfach jede Codebasis in dieser Kategorie, die Ihnen begegnet, neu schreiben.

Sie sind als Entwickler viel wertvoller, wenn Sie sich nicht nur einen neuen Job suchen , sondern sich tatsächlich die Mühe machen, mit der vorhandenen Codebasis zu arbeiten und sie zu verbessern.

Gusdor

"funktionieren und seinen Zweck erfüllen" - es klingt sehr danach, als würde dieses Problemprojekt das nicht tun.

Markus Müller

Auf die Gefahr hin, leichtfertig zu sein, die Welt ist hungrig nach Programmierern. Einige Organisationen sind kaputt, wenn das vielleicht der Fall ist, dann suchen Sie sich einen neuen Job .

Andere Poster haben ganz zu Recht darauf hingewiesen, dass das vererbte Durcheinander bei großen, lang laufenden Projekten üblich, ja sogar unvermeidlich ist. Es ist Sache des Unternehmens, den Aufwand zur Behebung oder Verbesserung zu finanzieren, nicht Sie (es sei denn, Sie haben eine Kapitalbeteiligung). Wenn es Zeit für eine Neufassung ist, dann liegt es an ihnen zu entscheiden (Sie können nur vorschlagen).

Passen Sie in dieser Situation auf sich auf.

Ich programmiere seit über 30 Jahren und nach einer Weile merkt man wirklich, wie wichtig die umgebende Infrastruktur für einen guten Job ist. Und Sie haben das Recht, zu versuchen, es gut zu machen.

Wenn es nicht gut ist, gehen Sie weiter, beginnen Sie nach Möglichkeit mit der Suche, während Sie im aktuellen Job sind. Seien Sie nur vorsichtig, wie Sie das gegenüber potenziellen neuen Arbeitgebern formulieren. Wenn Sie sich darüber beschweren, wie schlimm es in Ihrem letzten Job war, gewinnen Sie nur sehr wenige Pluspunkte.

mcottle

Ich fürchte, Sie sind zu spät, um wirklich viel gegen das bevorstehende Problem zu unternehmen. Sie können Ihrem Vorgänger jetzt keinen Vorwurf machen, da er schon lange weg ist - Sie hätten es (mit einer E-Mail-Spur) im ersten Monat oder so tun können, aber nicht jetzt.

Wenn dies in Zukunft passiert, tun Sie Folgendes:

  • Bewerten Sie schnell, was Sie geerbt haben.
  • Informieren Sie Ihren Vorgesetzten per E-Mail und empfehlen Sie einige Wochen lang geeignete Abhilfemaßnahmen anstelle von Fehlerbehebungen, bevor Sie fortfahren.
  • Legen Sie jede Verweigerung/Beharren auf neuen Funktionen ab (ausdrucken und in einer Datei bei der Arbeit UND zu Hause aufbewahren), um sich später abzusichern.
  • Schieben Sie jede Anfrage nach neuen Funktionen sanft zurück und sagen Sie, Sie hätten Angst, dass Sie eine fragile Codebasis destabilisieren könnten. Legen Sie die endgültige Entscheidung wie oben beschrieben bei Ihrem Vorgesetzten ab.
  • Schreiben Sie Komponententests für alles , was Sie hinzufügen.
  • Füllen Sie jede Schätzung, die Sie abgeben, für eine neue Funktion auf , die über das Hinzufügen von Komponententests hinausgeht (Wie kann jemand Ihrer Schätzung widersprechen, er kennt den Code nicht?).
    Verwenden Sie dann Ihre "zusätzliche" Zeit:
  • Fügen Sie weitere Einheitentests für die fehlerhaftesten Bereiche hinzu (wie andere Leute vorgeschlagen haben).
  • Korrigieren Sie die Breaking-Tests.
  • Refaktorieren Sie den alten Code.

Ihre Situation wird sich dann mit jedem neuen Feature verbessern.

Paul Becotte

Sie befinden sich in einer Situation, in der Sie 0 Berufserfahrung haben und gebeten wurden, an einem fehlerhaften Durcheinander einer Codebasis zu arbeiten, und Ihnen wurde gesagt, dass Sie die Fehler nicht beheben oder umgestalten können.

Allerdings- 1. Sie haben keine Ahnung, ob die Codebasis gut/schlecht/typisch ist. Sie haben keinen Stand der Technik, mit dem Sie es vergleichen könnten. 2. Niemand überprüft Ihre Arbeit, was bedeutet, dass es für Sie unmöglich wäre zu wissen, ob Sie die Codebasis verbessern, selbst wenn Sie Refactoring durchführen würden ... noch einmal, Sie haben keine Erfahrung. 3. Niemand sonst sieht sich die Codebasis an, also könnten Sie tatsächlich so viel Fehler beheben und umgestalten, wie Sie wollten, da Ihr Manager den Unterschied nicht erkennen konnte.

Ich verstehe, dass jeder unterschiedliche Situationen hat, aber ein Umfeld mit ein paar Leuten zu finden, die wissen, was sie tun, und ein gesunder Code-Review-Prozess werden für Ihre Karriere mehr wert sein als das, was Sie in 10 Jahren in diesem Unternehmen verdienen werden. Also- ich würde mir keine Gedanken über die bevorstehende Demo machen (die ohne Ihr Verschulden schlecht laufen wird, sondern Ihr Manager ist hier völlig schuld) ... ich würde mich stattdessen darauf konzentrieren, sich selbst in eine bessere Situation zu bringen, ob das bedeutet einen anderen Job zu finden oder einen Weg zu finden, Unterstützung von erfahreneren Entwicklern bei Ihrem aktuellen zu erhalten.

(Jemand mit solider Erfahrung könnte sich an diese Situationen anpassen, wie die anderen Antworten beschreiben. Gleich nach dem College muss Ihre erste Priorität jedoch darin bestehen, zu lernen, Ihren Job zu machen, was Sie derzeit nicht tun.)

Richter65

Es wurde viel gesagt, dem ich zustimme, aber ich denke, es gibt noch eine Sache, die erwähnt werden sollte: Dies ist eine enorme Chance für Sie.

Denk darüber nach. Sie, ein Junior-Programmierer, frisch aus dem College und ohne jegliche Erfahrung, sind die einzige Person, die damit beauftragt ist, an einer Softwareanwendung zu arbeiten. Das sagt mir, dass die Software auf der Prioritätsskala des Managements sehr niedrig ist. Sie haben es effektiv abgeschrieben; Ihrer Meinung nach ist die Software bereits gescheitert (und aus dem, was Sie gesagt haben, ist es nicht schwer zu erkennen, warum sie zu diesem Schluss gekommen sind).

Das bedeutet, dass Sie nicht scheitern können; du kannst nur Erfolg haben.

Mein Rat ist, Ihrem Management zu vertrauen, die Funktionen hinzuzufügen und sie so zu demonstrieren, wie es Pete in seiner Antwort dargelegt hat. Wenn Ihr Management klug ist, versucht es, dem Kunden die Fähigkeiten zu verkaufen, die die Anwendung bietet, was nicht dasselbe ist, wie die Anwendung selbst zu verkaufen. Ich vermute, dass, wenn der Kunde beißt, er einen Preis aushandelt, der das Korrigieren (oder sogar das Neuschreiben) der fehlerhaften Teile des Codes beinhaltet. In diesem Fall stehen Sie bei diesem Teil der Bemühungen im Mittelpunkt. Wenn dies nicht der Fall ist, hat Ihr Management nichts verloren, außer ein paar Monaten Arbeit eines extrem jungen (dh billigen) Programmierers.

Es gibt ein paar Implikationen für diese Denkweise. Der wichtigste ist, dass Sie zusätzlich zu dem, was Sie bereits tun, darüber nachdenken sollten, wie viel Zeit und Mühe es kosten würde, den Code zu reparieren. Denken Sie über einen Plan und einen Zeitplan nach, damit Sie Ihrem Management einige Optionen anbieten können. Wenn sie keinen Käufer haben, werden sie nicht interessiert sein. Wenn es jedoch potenzielle Käufer gibt, sind diese Informationen für sie von entscheidender Bedeutung, wenn sie mit den Preisverhandlungen beginnen.

Komodosp

Hoffentlich haben Sie es ihm nicht nur gesagt, sondern ihn schriftlich über das Durcheinander informiert. Auf diese Weise kennt er die Situation von Anfang an und kann Sie nicht dafür verantwortlich machen.

Ich habe die Erfahrung gemacht, dass in solchen Situationen der Manager oft genauso glücklich ist wie der Entwickler, demjenigen die Schuld zu geben, der das Unternehmen verlassen hat!

Es wäre wahrscheinlich hilfreich für Sie, jeden Fehler, den Sie entdecken, zu verfolgen und ihn an einem Ort aufzubewahren, an dem Ihr Manager leicht sehen kann (nicht auf passiv-aggressive Weise, wohlgemerkt - sagen Sie ihm einfach, was Sie tun). Auch wenn es sich irgendwo in einer gemeinsam genutzten Tabelle „Bekannte Probleme“ befindet, wenn Ihr Unternehmen keine Software zur Fehlerverfolgung hat. Ermutigen Sie die Benutzer möglicherweise, dasselbe zu tun (im selben Dokument), wenn Politik und Logistik dies zulassen. Möglicherweise können Sie sogar Ihren Manager dazu bringen, den Schweregrad zu bewerten und jedem eine Priorität zuzuweisen (in Bezug auf die neuen Funktionen, die Sie hinzufügen sollen).

Ich vermute, Sie haben keine voll funktionsfähige QA-Abteilung, sonst wäre sie nicht so weit gekommen, aber wenn Sie eine haben, wäre ihr Beitrag hier wirklich von Vorteil.

Dies zeigt nicht nur, dass Sie proaktiv versuchen, das Chaos zu beseitigen, sondern sich auch abzusichern, wenn ein Problem auftritt, bei dem er Sie möglicherweise beschuldigen könnte.

wie Judo

Lassen Sie sich von Ihrem Chef unterstützen. Stellen Sie sicher, dass Ihr Chef davon überzeugt ist, dass es ernsthafte Probleme gibt, damit er Zeit und Zustimmung von der Geschäftsleitung bekommen kann. Holen Sie sich dann den besten Architekten im Unternehmen, der Ihnen hilft, das Projekt neu zu entwerfen, umzugestalten oder neu zu schreiben. Arbeiten Sie mit Ihrem Manager und dem Architekten zusammen, um ein nachweislich besseres Programm zu erstellen. Das ist mir in den letzten 6 Monaten passiert.