In-house contro Ambiente di sviluppo software [chiuso]

Nella mia esperienza, la distinzione che stai facendo tra "in house" e "prodotto distribuibile" è falsa.

Ci sono aziende che prendono sul serio il loro processo di sviluppo del software e quelli che non lo fanno. Che siano "in casa" o "su misura" o "termoretraibile" tende a non entrare in esso tanto (anche se sono fornitori di "shrink wrap", se non hanno processo, probabilmente non saranno in affari per lungo).

Dovresti cercare un posto che abbia gli standard di sviluppo che stai cercando - durante le interviste devi fare queste domande per assicurarti che il posto sia di tuo gradimento in questo senso (così come in altri).

Puoi leggere questo articolo

link

di Joel Spolsky, che tratta esattamente la tua domanda.

Sono in una posizione in cui ho dovuto lavorare negli ultimi anni - un prodotto software di medie dimensioni venduto e un software interno. Da quell'esperienza, posso dirti che ci sono delle differenze tra queste due piattaforme, ma la situazione non è così grave come Joel l'ha descritta.

Ad esempio, la maggior parte del nostro software interno deve essere eseguito solo in un ambiente molto ristretto. Un sacco di strumenti che funzionano solo con un certo foglio elettronico o versione di database, con un ambiente di rete specifico, con un numero limitato di utenti, nessuna routine di installazione necessaria ecc. Ciò rende molte cose più facili e veloci da sviluppare rispetto alle nuove funzionalità introdotte in il nostro prodotto di spedizione. D'altro canto, ciò non significa che il mio codice per i programmi "in-house" abbia una qualità inferiore o sia scritto in un modo più "casuale".

Molto tempo fa, ho letto un libro su Agile Project Management (vorrei ricordare il titolo), in cui l'autore ha distinto i sistemi in base ai loro livelli di tolleranza per i difetti del sistema. La tolleranza per i difetti potrebbe variare da molto alta - ad esempio, un'utilità usata da altri sviluppatori (dove i bug sono solo un inconveniente), a molto bassa - per esempio, un sistema che sta supportando la vita per gli astronauti (dove un bug potrebbe essere pericolosa per la vita).

Il punto dell'autore era che la metodologia di sviluppo (e la formalità) necessitava di essere mirata alla tolleranza (o alla criticità) del sistema. Penso che questa distinzione sia la più importante, al contrario della distinzione tra sviluppo interno e software per la distribuzione generale.

Immagina un ospedale in cui gli sviluppatori interni costruiscono sistemi di registrazione medica che potrebbero influire sulla qualità dell'assistenza medica. In questo caso, il negozio interno sarebbe probabilmente più rigoroso di una società di consulenza di siti web, che sta costruendo prodotti web per essere utilizzati dal grande pubblico.

Ho lavorato per case software, agenzie di marketing, società di telefonia mobile e banche, una cosa che dirò, è la cultura e l'industria dell'azienda che determina il livello dei processi applicati. L'ambiente più rigoroso, lento, restrittivo e testato che abbia mai sperimentato è stato lo sviluppo interno di una banca. Il più casuale era un'agenzia di marketing.

Consiglierei di imparare da questa esperienza e usarla per decidere la tua futura direzione per il tuo prossimo lavoro. L'industria dello sviluppo del software non è una scienza, la sua arte / scienza, quindi la variazione e le differenze da una società all'altra. È più importante che impari a fare le cose per quanto riguarda il tuo codice. Anche se prendere nota mentalmente dei guasti o della mancanza di processi è utile, così quando il tuo manager puoi implementare processi migliori.