Est-il courant pour une équipe de tout écrire en interne? [fermé]

53

Dans une interview récente, j'ai demandé aux enquêteurs "comment allez-vous évaluer les nouvelles technologies et les nouvelles bibliothèques (telles que SignalR) et de les utiliser?". Ils ont dit qu'ils ne le font pas, mais qu'ils écrivent tout eux-mêmes pour ne pas dépendre de quelqu'un d'autre.

La firme ne travaille pas pour le gouvernement, ni pour les entrepreneurs de la défense, ni pour des projets critiques en matière de sécurité, etc. Ils n'étaient que votre moyenne entreprise de développement de logiciels de taille moyenne.

Ma question est la suivante: est-il courant que les équipes écrivent tout elles-mêmes? Devrais-je être concerné par les équipes qui le font?

Modifier - La plupart des réponses ont indiqué qu’il fallait se préoccuper de cela. Une deuxième entrevue serait-elle un moment opportun pour leur demander de préciser / de réitérer leur position en ce qui concerne la rédaction de tout en interne?

Andy Hunt
la source
58
Énorme drapeau rouge. Éloignez-vous calmement et ne faites pas de mouvements brusques.
tdammers
16
Je ne pense pas que cela soit aussi ridicule que les gens le disent ... Récemment, j'ai perdu un temps incroyable à réparer des bibliothèques abandonnées pour de nouvelles versions du framework, de nouvelles versions de bibliothèques avec des modifications importantes qui n'étaient pas documentées et même des lacunes énormes. dans des cadres importants tels que jQuery qui les rendent inutilisables. Les gens ne font pas assez d'efforts pour décider si les composants de la troisième partie vont ajouter un coût important en maintenance et se retrouvent souvent avec un pique de dépendance infernale au spaghetti.
Danny Tuppeny
4
NuGet est génial, mais le rend si facile à faire. J'ai récemment installé une bibliothèque auxiliaire triviale de NuGet, qui intégrait Castle et toutes sortes d'autres foutaises. Sûr; une interdiction totale est étrange, mais ce n’est pas plus stupide que de permettre à chaque développeur et à son chien d’obtenir des informations au hasard sans aucune pensée réelle.
Danny Tuppeny
13
Tout? Est-ce que cela inclut leurs propres navigateurs, systèmes d'exploitation et compilateurs? Sinon, ils se font des illusions.
Muhammad Alkarouri le
4
Bien sûr, c'est aussi ridicule que les gens le disent. Le fait a) qu’il soit possible de choisir la mauvaise bibliothèque pour le travail et b) il existe des situations dans lesquelles aucune bibliothèque tierce disponible ne répondra mieux à vos besoins qu’une bibliothèque interne: ne signifie pas que la politique générale qui consiste à ne jamais utiliser de tiers les bibliothèques sont correctes.
user16764

Réponses:

76

Une attitude consistant à ne jamais utiliser de bibliothèques tierces est absurde. Écrire tout vous-même est une utilisation horrible du temps de votre entreprise, sauf obligation stricte que chaque ligne de la base de code ait été écrite par un employé de l'entreprise - mais il s'agit d'un scénario inhabituel, en particulier pour une entreprise du secteur privé telle que vous avez décrit.

Une réponse plus rationnelle et approfondie aurait peut-être été qu'ils n'utiliseraient que des bibliothèques tierces qui:

  • Répondre aux besoins du code qu'ils auraient eux-mêmes écrit
  • Étaient disponibles sous une licence compatible avec le modèle commercial de l'entreprise
  • Tests inclus
  • Passé une revue de code

Si ces critères sont remplis (et selon mon expérience, la révision du code est très flexible, surtout en présence de bons tests), vous ne "comptez plus sur personne", vous vous fiez à des serveurs existants, disponibles et de préférence robustes. code.

Si le code est open source, dans le pire des cas, la bibliothèque tierce n'est plus maintenue. Mais qui s'en soucie? Les tests prouvent que la bibliothèque est adaptée à vos besoins!

De plus, une aversion pour les bibliothèques tierces établies entrave sérieusement la productivité des programmeurs. Supposons que la société écrivait des applications Web et refusait d'utiliser (par exemple) jQuery. Elle a donc écrit sa propre bibliothèque alternative multi-navigateurs pour simplifier la manipulation DOM. Avec une quasi-certitude, nous pouvons supposer que leur mise en œuvre:

  • Aura une API étrangère aux développeurs déjà familiers avec jQuery
  • Ne sera pas aussi bien documenté que jQuery
  • Ne générera pas de résultats Google pertinents en cas de problèmes d'utilisation de la bibliothèque.
  • Ne sera pas aussi testé sur le terrain que jQuery

Tous ces points constituent des obstacles majeurs à la productivité des programmeurs. Comment une entreprise peut-elle se permettre d'abandonner une telle productivité?


Vous avez mis à jour votre question pour lui demander s'il est approprié de le faire lors d'un deuxième entretien. C'est absolument.

Peut-être avez-vous mal interprété la réponse de votre intervieweur lors du premier entretien, ou peut-être que l'intervieweur a mal expliqué la position de la société et qu'un nouvel intervieweur peut clarifier la situation.

Si vous expliquez que leur position vis-à-vis des bibliothèques externes vous inquiète, il y a au moins deux résultats possibles:

  • Ils sont ouverts au changement et votre préoccupation au sujet de leur processus vous fait paraître mieux que certains autres candidats.
  • Ils ne sont pas ouverts au changement et ils vous voient comme "le genre de développeur que nous ne voudrions pas embaucher". Peu importe, ce n'est pas le genre d'endroit où vous voulez travailler.
Mark Rushakoff
la source
1
+1 mais je pense que vous parliez du secteur privé et non du secteur public .
MarkJ
6
"Si le code est open source, alors dans le pire des cas, la bibliothèque tierce n'est plus maintenue. Mais on s'en fiche. Les tests prouvent que la bibliothèque répond à vos besoins!" Vous avez également le code source, ce qui vous permet de disposer de ce que vous utilisez maintenant et de le mettre à jour pour répondre à tous vos besoins futurs. (Oui, il faut du temps pour s'habituer à une base de code "alien", mais rouler soi-même aussi.)
un CVn
34

Cela semble incroyablement non compétitif. J'ai travaillé dans des magasins qui ont décidé d'ignorer les bibliothèques standard open-source telles que Hibernate et de lancer leurs propres en raison de certaines fonctionnalités "critiques" manquantes. Au final, le logiciel était incroyablement coûteux à construire et à maintenir. Bien sûr, les dépenses de la bibliothèque interne ont été largement sous-estimées. Et tandis que la bibliothèque interne était écrite, les bibliothèques standard évoluaient rapidement, ajoutant de nouvelles fonctionnalités qui n'étaient pas disponibles dans la bibliothèque interne. En fin de compte, le travail qui nécessiterait une heure avec une bibliothèque standard prendrait deux jours. Et c'était mauvais pour la carrière du développeur, car le monde les a dépassés. Je voudrais éviter un magasin comme ça. J'aime livrer, et je n'ai pas la patience de réécrire quand je pourrais le réutiliser.

Kevin Cline
la source
2
Comme les développeurs n'avaient plus de compétences pertinentes pour d'autres emplois, la société a économisé de l'argent perdu en prolongeant son temps de développement en évitant de remplacer les membres de l'équipe qui partaient! #stratgey
Michael Paulukonis
@Michael: Les seules personnes qu'ils ont pu retenir étaient les personnes présentes lors de la décision initiale de créer des cadres internes. Les nouveaux employés ont tendance à partir après environ un an.
Kevin Cline
</ itwasaweakjoke>
Michael Paulukonis
+1 Si la fonctionnalité manquante est vraiment, vraiment cruciale: modifiez la bibliothèque open source et ajoutez la fonctionnalité à la source principale. Offre une grande valeur commerciale, fait du bien à tout le monde et excellent pour les CV de tous, car ils ont maintenant apporté une contribution open source.
MarkJ
@MarkJ: mais si le changement est rejeté, quelqu'un aura un ego meurtri.
Kevin Cline
20

Le magasin a une maladie appelée non inventé ici . C'est une bonne raison de mettre fin à l'entretien sur-le-champ et de partir immédiatement. Cela ne peut être corrigé que par un nettoyage ménager de haut en bas qui est très peu probable.

Pour répondre à votre question, elle est malheureusement beaucoup plus courante que vous ne le pensez et c’est une raison de s’inquiéter.

Dan Pichelman
la source
15

Oui, définitivement être concerné! Cela pue l'arrogance et (désolé d'être dur) la bêtise. Tout programmeur avec une moitié de cerveau utilisera une bibliothèque comme signalR au lieu de l'écrire vous-même. Il ne sert à rien de perdre votre temps à résoudre un problème qui a déjà été résolu. J'essaierais peut-être d'abord de trouver plus d'informations - ils vous ont peut-être mal compris (peut-être difficile si les interviews sont terminées!)

Rocklan
la source
11

J'ai quelques amis qui ont tous deux (brièvement) travaillé dans des maisons d'édition de logiciels sans syndrome inventé ici . Donc, la mentalité est là-bas.

Une observation qu'ils ont tous deux faite concerne la culture favorisée par l'approche développée par les équipes de développement. Ils ont tous deux fini par travailler avec des personnes plutôt insulaires en termes de développement de logiciels et des personnes peu motivées à apprendre de nouvelles choses et à rechercher la qualité. Quel que soit le stade de votre carrière, vous aimeriez toujours travailler dans un lieu où vous avez la possibilité d’apprendre de nouvelles choses de vos pairs. Ce type d’environnement ne semble cependant généralement pas être trouvé dans des endroits qui souhaitent tout rouler eux-mêmes.

avik
la source
+1 une des principales raisons pour lesquelles j'ai quitté mon employeur précédent!
Antony Scott
5

Ce n’est pas courant chez moi, et je connais beaucoup d’entreprises à travers des collègues. J'irais jusqu'à dire que c'est un "non merci" immédiat de ma part.

Je ne vais pas régurgiter les points positifs déjà soulevés, mais je vais ajouter une chose.

Ils ont juste rendu l'embauche beaucoup plus difficile.

  • Toutes les nouvelles recrues ont une courbe d'apprentissage encore plus abrupte que la partie principale du logiciel / domaine
  • Les meilleurs candidats seront rebutés car ils ne voudront pas que leurs compétences deviennent inutilisées.
  • Les gens ne resteront probablement pas longtemps après avoir compris à quel point il est difficile d'utiliser leurs outils préférés et le roulement de personnel est coûteux

Maintenant, il y aura bien sûr des gens qui aiment le défi, mais je pense qu'ils seraient dans la minorité.

De même, il y aura des entreprises qui opèrent à "l'échelle Internet", Amazon, Facebook, etc., où elles ont des besoins personnalisés insensés, mais là encore, elles sont minoritaires.

ozz
la source
4

Je ne pense pas qu'une société de logiciels puisse survivre aujourd'hui sans s'appuyer sur des logiciels tiers et / ou des logiciels à code source ouvert. Pour rester compétitive, elle doit bien entendu suivre de près les nouvelles technologies. Cependant, il y a souvent de bonnes raisons d’adopter au moins une vision plutôt défensive.

Par exemple, si vous vendez un logiciel et déclarez fournir une assistance 24 heures sur 24, 7 jours sur 7 et que vous êtes légalement responsable du bon fonctionnement de votre logiciel, vous devez avoir une idée très précise de ce qui va se passer en cas de problème. Un logiciel dans une usine, par exemple, où une heure d'indisponibilité de la production peut coûter plusieurs millions de dollars, puis un sérieux problème survient dans la bibliothèque open source que vous utilisiez. Croyez-moi, vous allez effectuer des évaluations très approfondies du logiciel en question.

D'après ce que vous avez écrit, ce scénario ne semble toutefois pas être au cœur du problème.

Thomas
la source
4

Si vous êtes une entreprise technologique d'une certaine taille, il semblerait que vous développerez de plus en plus votre propre technologie, par exemple: google développe beaucoup sinon la plupart sinon la totalité de leurs logiciels en open source. dans le but d'en faire une norme de l'industrie.

Pour les petites entreprises, cela semblerait être une perte de temps totale lorsqu'elles essaient d'expédier un produit spécifique avec sa propre logique métier, et d'après mon expérience, je n'ai jamais vu de petites entreprises de taille comparable.

Cela devient plus complexe lorsque vous parlez de bases de code très spécialisées, par exemple: les algorithmes de chiffrement - certaines personnes ont une compréhension de base de leur fonctionnement, mais les éléments complexes de la mise en œuvre d’une solution sembleraient vous tirer dans le pied. sauf si vous embauchez un cryptographe spécialisé dans ce genre de choses.

Certaines entreprises autorisent la liberté de créer leurs propres projets open source, ce qui semble plus approprié.

Personnellement, je n'irais pas dans un endroit avec une telle culture.

Itai Sagi
la source
1

Ce que vous avez est une très bonne occasion d'entrer dans la deuxième interview et de leur poser des questions difficiles. Je ne sais pas ce que l'entreprise fait, alors il est difficile de dire pourquoi cela semble un choix étrange. Vous pouvez utiliser le commentaire de @Daniel Pryden en ce qui concerne l'utilisation par Google de bibliothèques tierces.

Tout logiciel que vous utilisez, qu’il soit interne ou fourni par un tiers, présente des avantages et des inconvénients. Ne pas utiliser un outil, car il n’est pas interne, même s’il s’agit du meilleur outil car le travail fait preuve d’une certaine fermeté et n’encouragera jamais l’innovation et la créativité.

Peut-être que, peut-être, vous êtes peut-être l'auteur de ce changement. Bonne chance pour tout.

Daniel Hollinrake
la source
-3

Bien sûr, vous devriez vous en aller. Je ne l'ai pas vu mentionné ici, mais la principale raison de passer à autre chose, c'est que vous ne gagnerez pas beaucoup en compétences transférables.

Imaginez, lors de votre prochaine entrevue, quand ils vous demanderont avec quelles technologies vous avez travaillé et que vous ne pouvez mentionner que le cœur, le C ++. Cela ressemble à un diplôme de deuxième cycle.

Martin Konecny
la source
"Je ne l'ai pas vu mentionné ici" - avez-vous examiné d'autres réponses, par exemple celle-ci ?
moucher
3
Vous ne gagnerez pas beaucoup en compétences? C'est ridicule. Ce n'est vrai que si vous considérez la programmation comme jouant avec des blocs Lego, empilant des composants ensemble. Si vous devez «réinventer» une bibliothèque, vous en apprendrez beaucoup sur un sujet particulier.
GrandmasterB
@GrandmasterB Vous avez raison, permettez-moi de préciser. - Beaucoup d'endroits demandent avec quels outils vous avez travaillé. Vos chances d'être négligé sont bien plus grandes si d'autres candidats peuvent se mettre au travail sans avoir à apprendre à partir de rien.
Martin Konecny
-9

Les grandes entreprises écrivent tout elles-mêmes.

L'écrire vous-même présente plusieurs avantages:

  1. Vous êtes assuré de posséder le logiciel vous-même
  2. Vous pouvez calculer correctement les montants de travail nécessaires à sa création.
  3. Répéter vos étapes devient possible même si les bibliothèques ne sont pas disponibles la prochaine fois
  4. Il réduit votre exigence
  5. Vous ne répétez pas ce que d'autres ont déjà fait
  6. Vous êtes assuré d'avoir suffisamment de personnes pour le maintenir
  7. Vous pouvez modifier chaque partie du logiciel
  8. La taille du logiciel est limitée par la quantité de ressources dont vous disposez

Voici comment chacun des points se brise si vous utilisez la bibliothèque de quelqu'un d'autre:

  1. Quelqu'un d'autre possède la lib
  2. Vous ne savez pas combien d'efforts ont été consacrés à la création de la bibliothèque
  3. Il est impossible de créer votre prochaine version du produit sur une nouvelle plate-forme, car les mêmes bibliothèques ne sont plus disponibles.
  4. La capacité d'implémenter une exigence dépend de si la bibliothèque l'a implémentée il y a des années
  5. Quelqu'un d'autre utilise également la même bibliothèque, obtenant les mêmes limitations et fonctionnalités
  6. Puisque vous n'avez pas créé les bibliothèques, vous n'avez pas assez de personnes pour gérer tous les logiciels de votre produit.
  7. Les bibliothèques sont des binaires non modifiables. Même si la source est disponible, vous n'avez pas assez de personnes pour modifier cette grande quantité de code.
  8. Maintenir le code que vous avez créé + les bibliothèques représente un effort plus important que celui initialement estimé
tp1
la source
7
L'extension logique de ces arguments ne serait-elle pas d'écrire également votre propre compilateur (probablement pour votre propre langue), d'exécuter ce logiciel sur votre propre système d'exploitation, et probablement de construire votre propre matériel?
timday
4
1: Oui, et je peux payer des frais pour l’utiliser (sans dépenser d’argent pour le construire à la différence des coûts). 2: Si je ne le construis pas, je m'en fiche. 3: Dans les entreprises, les plates-formes sont lentes à changer. Rester à la pointe de la technologie est rarement une exigence. Mais bon logiciel déplacé facilement. 4: pas vrai. Vous venez de transférer le volume de externe à interne. 5: n'a pas de sens. 6: Pas vrai. 7: C'est vrai, mais cela signifie que vous devez détourner vos précieux programmeurs (la partie la plus coûteuse d'un projet) du travail réel vers la correction de bogues sur quelque chose qui pourrait être maintenu ailleurs. 8: C'est une mauvaise chose.
Martin York
5
De nombreuses grandes entreprises utilisent largement le code source ouvert sous différentes formes (y compris les bibliothèques), améliorant souvent les projets concernés et y contribuant. Les points sont pour la plupart non pertinents ou incorrects.
Matt
7
@ tp1: Je travaille pour Google et je peux vous assurer que Google utilise beaucoup les bibliothèques tierces lorsqu'elles répondent à nos besoins. Il arrive souvent que Google ait des besoins uniques ou d'une ampleur différente de ceux de nombreux autres éditeurs de logiciels. Ainsi, pour une raison ou une autre, Google va souvent développer ses propres logiciels. Mais Google utilise également un grand nombre de bibliothèques à code source ouvert et / ou un grand nombre de bibliothèques à code source ouvert, de sorte que tout n’est pas interne. La plupart de vos points ne s'appliquent plus aux logiciels à code source ouvert, car en disposant du code source, vous vous assurez que vous pouvez toujours le déboguer et le corriger si nécessaire.
Daniel Pryden
5
"Non, la valeur provient de la mise en œuvre précise des exigences. Si elle a été construite avant que les exigences ne soient connues, elle ne peut pas mettre en œuvre ces exigences avec précision." Indice: Si vous pensez que cet argument n’a aucun mérite, vous n’avez pas compris la séparation des préoccupations.
user16764