Wie häufig schreibt ein Team alles intern? [geschlossen]

In einem kürzlich durchgeführten Interview fragte ich die Interviewer: "Wie bewerten Sie neue Technologien und Bibliotheken (wie SignalR) und bringen sie zum Einsatz?" Sie sagten, sie taten es nicht, stattdessen schreiben sie alles selbst, damit sie sich nicht auf irgendjemanden verlassen müssen.

Die Firma arbeitet nicht für Regierungs- oder Verteidigungsunternehmen oder für sicherheitskritische Projekte oder ähnliches. Sie waren nur ein durchschnittliches, mittelgroßes Softwareentwicklungsunternehmen.

Meine Frage ist: Wie häufig schreiben Teams alles selbst? Sollte ich mich um Teams kümmern, die dies tun?

Bearbeiten - Fast jede Antwort hat gesagt, dass dies etwas ist, worüber man sich Sorgen machen muss. Wäre ein zweites Interview ein angemessener Zeitpunkt, um sie zu bitten, ihre Position zum Schreiben von allem im Haus zu klären / zu wiederholen?

Die Einstellung, niemals Bibliotheken von Drittanbietern zu verwenden, ist absurd. Alles selbst zu schreiben ist eine schreckliche Zeitverschwendung für Ihr Unternehmen, es sei denn, es besteht eine strenge Geschäftsanforderung, dass jede Zeile in der Codebasis von einem Mitarbeiter des Unternehmens geschrieben wurde - dies ist jedoch ein ungewöhnliches Szenario, insbesondere für ein Unternehmen des privaten Sektors wie du hast beschrieben.

Eine rationalere und gründlichere Antwort könnte gewesen sein, dass sie nur Bibliotheken von Drittanbietern verwenden würden, die:

• Erfüllen Sie die Anforderungen des Codes, den sie sonst selbst schreiben würden
• Waren unter einer Lizenz verfügbar, die mit dem Geschäftsmodell des Unternehmens kompatibel ist
• Eingeschlossene Tests
• Code-Überprüfung bestanden

Wenn diese Kriterien erfüllt sind (und meiner Erfahrung nach ist die Codeüberprüfung vor allem bei guten Tests sehr flexibel), verlassen Sie sich nicht mehr auf andere - Sie verlassen sich auf vorhandene, verfügbare und möglichst robuste Code.

Wenn der Code Open Source ist, wird die Bibliothek des Drittanbieters im schlimmsten Fall nicht mehr verwaltet. Aber wen interessiert es? Die Tests beweisen, dass die Bibliothek für Ihre Bedürfnisse geeignet ist!

Darüber hinaus beeinträchtigt eine Abneigung gegen etablierte Bibliotheken von Drittanbietern die Produktivität von Programmierern erheblich. Angenommen, das Unternehmen schrieb Webanwendungen und lehnte die Verwendung von (z. B.) jQuery ab. Stattdessen wurde eine alternative browserübergreifende Bibliothek zur Vereinfachung der DOM-Manipulation geschrieben. Mit ziemlicher Sicherheit können wir davon ausgehen, dass ihre Umsetzung:

• Wird eine API haben, die Entwicklern fremd ist, die bereits mit jQuery vertraut sind
• Wird nicht so gut dokumentiert sein wie jQuery
• Bei Problemen mit der Bibliothek werden keine relevanten Google-Ergebnisse angezeigt
• Wird nicht so praxiserprobt sein wie jQuery

All diese Punkte sind große Hindernisse für die Produktivität von Programmierern. Wie kann es sich ein Unternehmen leisten, diese Produktivität aufzugeben?

Sie haben Ihre Frage aktualisiert und gefragt, ob dies für ein zweites Interview angemessen ist. Es ist absolut so.

Vielleicht haben Sie die Antwort Ihres Interviewers im ersten Interview falsch interpretiert, oder der Interviewer hat die Position des Unternehmens falsch erklärt, und ein neuer Interviewer kann dies klären.

Wenn Sie erklären, dass Sie sich Sorgen über ihre Haltung zu externen Bibliotheken machen, gibt es mindestens zwei mögliche Ergebnisse:

• Sie sind offen für Veränderungen und Ihre Besorgnis über ihren Prozess lässt Sie besser aussehen als einige andere Kandidaten.
• Sie sind nicht bereit, sich zu ändern, und sie betrachten Sie als "die Art Entwickler, die wir nicht einstellen möchten". Egal, das ist sowieso nicht der Ort, an dem Sie arbeiten möchten.

Das scheint unglaublich wettbewerbsunfähig. Ich habe in Läden gearbeitet, die beschlossen haben, die Standard-Open-Source-Bibliotheken wie Hibernate zu überspringen und ihre eigenen zu rollen, weil eine "kritische" Funktion fehlt. Am Ende war die Software unglaublich teuer in der Erstellung und Wartung. Natürlich wurde der Aufwand für die hauseigene Bibliothek stark unterschätzt. Während die interne Bibliothek geschrieben wurde, entwickelten sich die Standardbibliotheken schnell weiter und fügten neue Funktionen hinzu, die in der internen Bibliothek nicht verfügbar waren. Am Ende dauerte die Arbeit mit einer Standardbibliothek eine Stunde, stattdessen zwei Tage. Und es war schlecht für die Karrieren der Entwickler, als die Welt an ihnen vorbeiging. Ich würde so einen Laden meiden. Ich mag es zu liefern und habe nicht die Geduld, um zu schreiben, wann ich wiederverwenden könnte.

Der Laden hat eine Krankheit namens Not Invented Here . Es ist ein guter Grund, das Interview vor Ort zu beenden und sofort zu gehen. Dies kann nur durch eine Top-Down-Hausreinigung behoben werden, die sehr unwahrscheinlich ist.

Um Ihre Frage zu beantworten, es ist leider viel häufiger als Sie vielleicht denken und es ist definitiv ein Grund, besorgt zu sein.

Ja, auf jeden Fall besorgt sein! Das stinkt nach Arroganz und Dummheit. Jeder Programmierer mit einem halben Gehirn benutzt eine Bibliothek wie signalR, anstatt sie selbst zu schreiben. Es ist absolut sinnlos, Ihre Zeit damit zu verschwenden, ein Problem zu lösen, das bereits gelöst wurde. Ich würde möglicherweise versuchen, zuerst mehr Informationen herauszufinden - sie haben Sie möglicherweise missverstanden (könnte jedoch schwierig sein, wenn die Interviews vorbei sind!)

Ich habe ein paar Freunde, die beide (kurz) bei Softwarehäusern mit hier nicht erfundenem Syndrom gearbeitet haben. Die Mentalität ist also da draußen.

Eine Beobachtung, die sie beide machten, betraf die Kultur, die in den Entwicklungsteams gefördert wurde. Am Ende arbeiteten beide mit Leuten zusammen, die in Bezug auf ihre Ansichten zur Softwareentwicklung ziemlich unbestimmt waren, und mit Leuten, die nicht wirklich motiviert waren, neue Dinge zu lernen und auf Qualität zu drängen. Unabhängig davon, in welchem ​​Stadium Sie sich in Ihrer Karriere befinden, möchten Sie immer an einem Ort arbeiten, an dem Sie die Chance haben, von Kollegen Neues zu lernen. Diese Art von Umgebung scheint jedoch im Allgemeinen nicht an Orten anzutreffen zu sein, die alles selbst rollen möchten.

Es ist nicht üblich, wo ich wohne, und ich kenne viele Unternehmen, obwohl Kollegen. Ich würde so weit gehen zu sagen, es ist ein sofortiges "Nein danke" von mir.

Ich werde die bereits gemachten guten Punkte nicht wieder auffliegen lassen, aber ich werde eine Sache hinzufügen.

Sie haben gerade die Einstellung viel schwieriger gemacht.

• Alle neuen Mitarbeiter haben eine noch steilere Lernkurve als nur der Hauptteil der Software / Domain
• Die besten Kandidaten werden abschrecken, da sie nicht wollen, dass ihre Fähigkeiten ungenutzt bleiben.
• Es ist unwahrscheinlich, dass die Leute lange bleiben, wenn sie feststellen, wie schlecht es ist, ihre Lieblingswerkzeuge nicht zu verwenden, und dass die Fluktuation teuer ist

Jetzt wird es natürlich Leute geben, die die Herausforderung mögen, aber ich denke, sie wären in der Minderheit.

Ebenso wird es einige Unternehmen geben, die auf "Internet-Skala", Amazon, Facebook usw. tätig sind, wo sie verrückte Kundenbedürfnisse haben, aber auch diese sind in der Minderheit.

Ich glaube nicht, dass ein Softwareunternehmen heute überleben kann, wenn es nicht auf Software von Drittanbietern und / oder Open Source-Software angewiesen ist. Um wettbewerbsfähig zu bleiben, müssen sie sich natürlich aktiv mit neuen Technologien auseinandersetzen. Es gibt jedoch oft gute Gründe, zumindest eine eher defensive Haltung einzunehmen.

Wenn Sie beispielsweise Software verkaufen und behaupten, rund um die Uhr Support zu bieten, und auch rechtlich dafür verantwortlich sind, dass Ihre Software ordnungsgemäß funktioniert, müssen Sie eine sehr genaue Vorstellung davon haben, was bei einem Problem mit Ihrer Software passieren wird Software beispielsweise in einer Fabrik, in der eine Stunde Produktionsausfall mehrere Millionen US-Dollar kosten kann, und dann ein schwerwiegender Fehler in der von Ihnen verwendeten Open-Source-Bibliothek vorliegt. Glauben Sie mir, Sie werden die betreffende Software sehr gründlich bewerten.

Nach dem, was Sie geschrieben haben, scheint dieses Szenario jedoch nicht im Zentrum der Sache zu stehen.

Wenn Sie ein technologiebasiertes Unternehmen einer bestimmten Größe sind, werden Sie anscheinend immer mehr eigene Technologien entwickeln. Beispiel: google entwickelt eine Menge, wenn nicht die meisten, wenn nicht die gesamte Software, während das meiste davon Open-Sourcing-Prozesse durchführt in dem Bestreben, es zu einem Industriestandard zu machen.

Für kleinere Unternehmen scheint es eine reine Zeitverschwendung zu sein, wenn sie versuchen, ein bestimmtes Produkt mit eigener Geschäftslogik zu liefern, und meiner Erfahrung nach habe ich nicht gesehen, dass kleine und mittlere Unternehmen dies tun.

Es wird komplizierter, wenn Sie über eine stark spezialisierte Codebasis sprechen, zum Beispiel: Verschlüsselungsalgorithmen - einige Leute haben ein grundlegendes Verständnis für ihre Funktionsweise, aber die komplizierten Teile der tatsächlichen Implementierung einer Lösung scheinen sich selbst in den Fuß zu schießen es sei denn, Sie beauftragen einen Kryptographen, der sich auf solche Dinge spezialisiert hat.

Einige Unternehmen gestatten die Erstellung eigener Open-Source-Projekte, was angemessener erscheint.

Ich würde persönlich nicht an einen Ort mit einer solchen Kultur gehen.

Was Sie haben, ist eine wirklich gute Gelegenheit, in das zweite Interview einzusteigen und ihnen einige schwierige Fragen zu stellen. Ich weiß nicht, was das Unternehmen tut, daher ist es schwierig zu sagen, warum dies eine seltsame Wahl zu sein scheint. Sie können den Kommentar von @Daniel Pryden in Bezug auf die Verwendung von Bibliotheken von Drittanbietern durch Google verwenden.

Jede Software, die Sie verwenden, sei es im eigenen Unternehmen oder von Dritten, hat Vor- und Nachteile. Ein Tool nicht zu verwenden, weil es nicht im eigenen Haus ist, auch wenn es das beste Tool für den Job ist, zeigt eine gewisse geschlossene Denkweise und das wird niemals Innovation und Kreativität fördern.

Vielleicht sind Sie aber auch derjenige, der diese Änderung einführt. Viel Glück mit allem.

Natürlich solltest du weggehen. Ich habe es hier nicht erwähnt gesehen, aber der größte Grund, den Job zu verlassen, ist, dass Sie nicht viel an übertragbaren Fähigkeiten gewinnen.

Stellen Sie sich bei Ihrem nächsten Interview vor, Sie werden gefragt, mit welchen Technologien Sie gearbeitet haben und Sie können nur Bare Bones C ++ erwähnen. Das klingt nach einem Abschluss

Große Unternehmen schreiben alles selbst.

Es gibt mehrere Vorteile, es selbst zu schreiben:

1. Sie besitzen die Software garantiert selbst
2. Sie können die Arbeitsmengen, die bei der Erstellung anfielen, korrekt berechnen
3. Das Wiederholen Ihrer Schritte ist auch dann möglich, wenn die Bibliotheken das nächste Mal nicht verfügbar sind
4. Es reduziert Ihre Anforderungen aufblähen
5. Sie wiederholen nicht, was andere bereits getan haben
6. Sie haben garantiert genug Leute, um es zu warten
7. Sie können jeden Teil der Software ändern
8. Die Softwaregröße ist durch die Anzahl der verfügbaren Ressourcen begrenzt

Hier ist, wie jeder der Punkte zerstört wird, wenn Sie eine andere Bibliothek verwenden:

1. Jemand anderes besitzt die Bibliothek
2. Sie wissen nicht, wie viel Aufwand in die Erstellung der Bibliothek gesteckt hat
3. Ihre nächste Produktversion kann nicht auf einer neuen Plattform erstellt werden, da dieselben Bibliotheken nicht mehr verfügbar sind
4. Die Fähigkeit, Anforderungen zu implementieren, hängt davon ab, ob die Bibliothek sie vor Jahren implementiert hat
5. Jemand anderes verwendet ebenfalls dieselbe Bibliothek und erhält dieselben Einschränkungen und Funktionen
6. Da Sie die Bibliotheken nicht erstellt haben, haben Sie nicht genügend Leute, um die gesamte Software in Ihrem Produkt zu warten
7. Bibliotheken sind Binärdateien, nicht änderbar. Selbst wenn die Quelle verfügbar ist, haben Sie nicht genügend Leute, um diese große Menge an Code zu ändern.
8. Die Pflege des von Ihnen erstellten Codes und der Bibliotheken ist aufwändiger als ursprünglich angenommen