Quanto è comune per una squadra scrivere tutto internamente? [chiuso]

In una recente intervista ho chiesto agli intervistatori "come si fa a valutare nuove tecnologie e librerie (come SignalR) e metterle in pratica?". Hanno detto di no, che invece scrivono tutto da soli, quindi non devono fare affidamento su nessun altro.

L'azienda non lavora per il governo o per gli appaltatori della difesa o su progetti critici per la sicurezza o cose del genere. Erano solo la tua media, media impresa di sviluppo software.

La mia domanda è: quanto è comune per i team scrivere tutto da soli? Dovrei essere preoccupato dai team che lo fanno?

Modifica: quasi tutte le risposte hanno affermato che questo è qualcosa di cui preoccuparsi. Una seconda intervista sarebbe il momento opportuno per chiedere loro di chiarire / ripetere la loro posizione nello scrivere tutto in casa?

L'atteggiamento di non usare mai librerie di terzi è assurdo. Scrivere tutto da soli è un uso orribile del tempo della tua azienda, a meno che non ci sia un rigoroso requisito aziendale che ogni riga nella base di codice sia stata scritta da un dipendente della società - ma questo è uno scenario insolito, specialmente per un'azienda del settore privato come hai descritto.

Una risposta più razionale e completa potrebbe essere stata che avrebbero usato solo librerie di terze parti che:

• Soddisfare le esigenze del codice che altrimenti si scriverebbero
• Erano disponibili con una licenza compatibile con il modello aziendale dell'azienda
• Test inclusi
• Superata una revisione del codice

Se tali criteri fossero soddisfatti (e nella mia esperienza la revisione del codice è molto flessibile, specialmente in presenza di buoni test), non stai più "facendo affidamento su qualcun altro" - stai facendo affidamento su quelli esistenti, disponibili e preferibilmente robusti codice.

Se il codice è open source, nel peggiore dei casi, la libreria di terze parti non viene mantenuta. Ma a chi importa? I test dimostrano che la biblioteca è adatta alle tue esigenze!

Inoltre, l'avversione per le librerie di terze parti consolidate ostacola seriamente la produttività del programmatore. Supponiamo che la società stia scrivendo applicazioni Web e abbia rifiutato di utilizzare (ad esempio) jQuery, quindi ha scritto la propria libreria alternativa tra browser per semplificare la manipolazione del DOM. Con quasi certezza possiamo ipotizzare che la loro implementazione:

• Avrà un'API estranea agli sviluppatori che hanno già familiarità con jQuery
• Non sarà ben documentato come jQuery
• Non si otterranno risultati pertinenti di Google in caso di problemi durante l'utilizzo della libreria
• Non sarà testato sul campo come jQuery

Tutti questi punti sono i principali ostacoli alla produttività del programmatore. Come può un'azienda permettersi di rinunciare a una produttività del genere?

Hai aggiornato la tua domanda per chiederti se è opportuno presentarla in una seconda intervista. Lo è assolutamente.

Forse hai frainteso la risposta del tuo intervistatore nella prima intervista, o forse l'intervistatore ha semplicemente erroneamente spiegato la posizione dell'azienda e un nuovo intervistatore può chiarirla.

Se spieghi che sei preoccupato per la loro posizione sulle biblioteche esterne, ci sono almeno due possibili esiti:

• Sono aperti al cambiamento e la tua preoccupazione per il loro processo ti fa sembrare migliore di alcuni altri candidati.
• Non sono aperti al cambiamento e pensano a te come "il tipo di sviluppatore che non vorremmo assumere". Non importa, non è comunque il tipo di posto in cui vuoi lavorare.

Sembra incredibilmente competitivo. Ho lavorato in negozi che hanno deciso di saltare le librerie open source standard come Hibernate e realizzarne una a causa di alcune funzionalità "critiche" mancanti. Alla fine il software era incredibilmente costoso da costruire e mantenere. Ovviamente le spese della biblioteca interna furono ampiamente sottovalutate. E mentre la biblioteca interna veniva scritta, le librerie standard avanzarono rapidamente, aggiungendo nuove funzionalità che non erano disponibili nella biblioteca interna. Alla fine, il lavoro che avrebbe richiesto un'ora usando una libreria standard invece ha richiesto due giorni. Ed è stato un male per le carriere degli sviluppatori, mentre il mondo le superava. Eviterei un negozio del genere. Mi piace consegnare e non ho la pazienza di riscrivere quando potrei riutilizzarlo.

Il negozio ha una malattia chiamata Not Invented Here . È una buona ragione per interrompere l'intervista sul posto e partire immediatamente. Questo può essere risolto solo con una pulizia dall'alto che è molto improbabile.

Per rispondere alla tua domanda, è purtroppo molto più comune di quanto potresti pensare ed è sicuramente un motivo per preoccuparti.

Sì, sicuramente preoccupati! Che puzza di arroganza e (mi dispiace essere duro) stupidità. Qualsiasi programmatore con mezzo cervello utilizzerà una libreria come signalR invece di scriverlo da solo. Non ha assolutamente senso sprecare il tuo tempo a risolvere un problema che è già stato risolto. Probabilmente proverei prima a scoprire maggiori informazioni - potrebbero averti frainteso (potrebbe essere difficile se le interviste fossero finite!)

Ho un paio di amici che hanno entrambi (brevemente) lavorato in software house con la sindrome non inventata qui . Quindi la mentalità è là fuori.

Un'osservazione che entrambi hanno formulato riguarda la cultura che l'approccio ha favorito nei team di sviluppo. Entrambi hanno finito per lavorare con persone che erano piuttosto insulari in termini di prospettive sullo sviluppo del software e persone che non erano realmente spinte a imparare cose nuove e a spingere per la qualità. Indipendentemente da quale fase ti trovi nella tua carriera, ti piacerebbe sempre lavorare da qualche parte dove hai la possibilità di imparare cose nuove dai tuoi coetanei. Questo tipo di ambiente, tuttavia, sembra generalmente non essere trovato in luoghi che desiderano girare tutto da soli.

Non è comune dove vivo e conosco molte aziende anche se colleghi. Andrei fino a dire che è un immediato "no grazie" da parte mia.

Non rigurgiterò i punti positivi già formulati, ma aggiungerò una cosa.

Hanno appena reso le assunzioni molto più difficili.

• Tutti i nuovi assunti hanno una curva di apprendimento ancora più ripida rispetto alla sola parte principale del software / dominio
• I migliori candidati saranno rimandati perché non vorranno che le loro abilità diventino inutilizzate.
• È probabile che le persone non rimangano a lungo una volta che si rendono conto di quanto non sia male utilizzare i loro strumenti preferiti e il turnover del personale è costoso

Ora ci saranno ovviamente persone a cui piace la sfida, ma penso che sarebbero in minoranza.

E allo stesso modo, ci saranno alcune aziende che operano su "Internet scale", Amazon, Facebook, ecc., Dove hanno esigenze personalizzate folli, ma di nuovo queste sono in minoranza.

Non credo che un'azienda di software possa sopravvivere oggi senza fare affidamento su software di terze parti e / o open source e, per rimanere competitivi, ovviamente devono tenere traccia attiva delle nuove tecnologie. Ci sono spesso buone ragioni, tuttavia, per avere almeno una visione piuttosto difensiva su di esso.

Ad esempio, se vendi software e dichiari di fornire supporto 24 ore su 24, 7 giorni su 7 e sei anche legalmente responsabile del corretto funzionamento del software, devi avere un'idea molto precisa di ciò che accadrà in caso di problemi con il tuo software in, diciamo, una fabbrica in cui 1 ora di inattività della produzione può costare diversi milioni di dollari, e poi si verifica un grave bug nella libreria open source che stavi utilizzando. Credetemi, eseguirete valutazioni molto approfondite del software in questione.

Da quello che hai scritto questo scenario non sembra essere al centro della questione, però.

Se sei una società basata sulla tecnologia di una certa dimensione, di quanto sembrerebbe che svilupperai sempre più la tua tecnologia, ad esempio: google sviluppa molto se non la maggior parte se non tutti i loro software mentre ne open source la maggior parte nel tentativo di renderlo uno standard del settore.

Per le aziende più piccole, sembrerebbe una totale perdita di tempo quando stanno cercando di spedire un prodotto specifico con la propria logica aziendale, e nella mia esperienza non ho visto che le aziende di dimensioni medio-piccole lo fanno.

Diventa più complicato quando parli di una base di codice altamente specializzata, ad esempio: algoritmi di crittografia: alcune persone hanno una comprensione di base su come funzionano, ma le parti complesse dell'implementazione effettiva di una soluzione sembrerebbero spararti al piede a meno che non assumi un crittografo specializzato in tali cose.

Alcune aziende consentono la libertà di creare i tuoi progetti open source, il che sembra più appropriato.

Personalmente non andrei in un posto con tale cultura.

Quello che hai è un'ottima opportunità per andare alla seconda intervista e porre loro alcune domande difficili. Non so cosa faccia l'azienda, quindi è difficile dire perché questa sembra una scelta strana. È possibile utilizzare il commento di @Daniel Pryden in merito all'utilizzo da parte di Google di librerie di terze parti.

Qualsiasi componente software utilizzato, sia internamente che di terze parti, presenta vantaggi e svantaggi. Non usare uno strumento perché non è interno, anche se è lo strumento migliore per il lavoro che mostra una certa mentalità chiusa e che non incoraggerà mai l'innovazione e la creatività.

Forse però, proprio forse, sei tu la persona che introduce questo cambiamento. Buona fortuna per tutto.

Ovviamente dovresti andartene. Non l'ho visto menzionato qui, ma il motivo principale per passare il lavoro è perché non guadagnerai molto in abilità trasferibili.

Immagina alla tua prossima intervista quando ti chiedono con quali tecnologie hai lavorato e puoi menzionare solo ossa nude C ++ .. Sembra un livello di laurea

Le grandi aziende scrivono tutto da sole.

Ci sono diversi vantaggi nello scrivere da soli:

1. Sei sicuro di possedere il software da solo
2. È possibile calcolare correttamente gli importi di lavoro che sono andati a crearlo
3. Ripetere i tuoi passaggi diventa possibile anche se la prossima volta le librerie non sono disponibili
4. Riduce il gonfiamento del tuo fabbisogno
5. Non ripeti ciò che altri hanno già fatto
6. Hai la garanzia di avere abbastanza persone per mantenerlo
7. È possibile modificare ogni parte del software
8. Le dimensioni del software sono limitate dalla quantità di risorse disponibili

Ecco come ogni punto si spezza se usi la libreria di qualcun altro:

1. Qualcun altro possiede la lib
2. Non sai quanti sforzi sono stati fatti per creare la lib
3. La tua prossima versione del prodotto è impossibile da creare su una nuova piattaforma poiché le stesse librerie non sono più disponibili
4. La capacità di implementare i requisiti dipende dal fatto che la lib lo abbia implementato anni fa
5. Qualcun altro usa anche la stessa lib, ottenendo le stesse limitazioni e caratteristiche
6. Dal momento che non hai creato le librerie, non hai abbastanza persone per mantenere tutto il software nel tuo prodotto
7. Le librerie sono binarie, non modificabili. Anche se il sorgente è disponibile, non hai abbastanza persone per modificare quella grande quantità di codice.
8. Mantenere il codice che hai creato + le librerie è uno sforzo maggiore di quanto inizialmente stimato