Se un potenziale datore di lavoro ti ha detto che "ha risolto i bug in outsourcing perché gli sviluppatori odiano risolvere bug", cosa ne penseresti? Quali potrebbero essere le tue preoccupazioni?
La correzione dei nostri bug ci rende effettivamente uno sviluppatore migliore . Ed è un momento molto piacevole per me. Soprattutto quando sono ben segnalati.
Se a loro non piace correggere bug, il problema si trova altrove.
Ho il sospetto che il problema sia come i bug vengono percepiti dalla direzione o, peggio, da cattive decisioni di progettazione e / o no (unit) test, causando dolori nella risoluzione dei bug.
Il bug fixing in outsourcing probabilmente peggiorerà la situazione.
Gli sviluppatori potrebbero essere tentati di ridurre la qualità. Che importa? Alcuni ragazzi dell'offshore sono lì per ripulire il loro casino.
Fino a che i ragazzi dell'offshore non sostituiranno i tipi onshore.
Esci , scappa ... veloce e non guardare mai indietro ...
Ho lavorato per un'azienda del genere, hanno pensato che fossero intelligenti,
hey abbiamo tutti i bug, ma i nostri senior si lamentano che passano troppo tempo a correggere i bug.
apriamo un ufficio offshore e lasciamo che siano gli altri a occuparsi di questo.
per un manager che sembra un ottimo piano e gli sviluppatori sono stati finalmente liberati per affrontare il compito più interessante di creare la prossima cosa migliore !!
ho ... ma aspetta ...
dopo due anni sono passati da un team di 5 sviluppatori nel loro ufficio principale che hanno gestito tutto questo in una squadra di 2 persone che creava nuove cose e un team di 30 che trova e corregge bug.
sai cosa ... la squadra di bug fixing sta lottando, non possono tenere il passo.
questo ha reso gli "anziani" completamente inagibili per i propri errori. Peggio ancora, perché tutto è accaduto così lontano che la direzione non si è resa conto di nessuno e la qualità del codice si è innalzata MOLTO velocemente da un livello di qualità già abissale.
Quando me ne sono andato, hanno già aperto altri due uffici per i bug fixer e ancora non riescono a tenere il passo con gli sviluppatori ora unici che li hanno creati. in realtà pensano che sia perché i nuovi ragazzi non sono abbastanza intelligenti ...
quindi sì, d'ora in poi, se una società afferma di aver esternalizzato il bug fixing ad un ufficio all'estero, fidati di me ... corro ... veloce.
Questa è la Paper Bag metodologia di gestione.
Stai su una ferrovia, aspetta che arrivi un treno, quando lo vedi, metti un sacchetto di carta sopra la testa e ... POOF .. treno andato !! Magia!
Avere l'azienda a pagare qualcun altro per ripulire il mio casino sembra una buona idea, tranne quando mi aspetto che prenda il loro codice 'pulito' e aggiunga nuove funzionalità. E se ottengono così rovinato che non possono risolverlo, eseguirai il debug del debugging.
Non essere adeguatamente compensato perché devono assumere sviluppatori aggiuntivi non è auspicabile.
Dover trascorrere una quantità sproporzionata di tempo a educare gli altri sviluppatori quando potresti averlo risolto da te stesso è controproducente.
Una parte di me sembra che chi crea problemi dovrebbe essere in grado di risolverli o non c'è alcun incentivo a evitare di creare bug in primo luogo.
Gli sviluppatori non sono interessati a imparare dai propri errori? Puoi correggere bug senza conoscenze specifiche sul dominio e il partner di outsourcing ha questa conoscenza? La parte di fissaggio è la più semplice delle volte, è la porzione di analisi che richiede tempo. Dal mio punto di vista è una decisione stupida.
If a prospective employer told you they "outsourced bug fixing because developers hate fixing bugs", What would you think? What might be your concerns?
Io correrei lontano, molto, molto lontano. Uno sviluppatore è sempre, sempre, sempre responsabile di correggere i propri bug. Mangiare il cibo per cani è un principio basilare di buona ingegneria.
Inoltre, la risoluzione dei bug è importante, forse più dello sviluppo. Voglio dire, lo sviluppo è la scrittura del codice, test e debug / fixing.
Quello che ottengo da questa azienda è che stanno trattando i bug fixing come attività di seconda classe. Ciò è di per sé piuttosto inquietante e metterei in discussione la qualità del lavoro (ed ergo, il loro ambiente di lavoro). Più inquietante è che delegano ciò che per loro è lavoro di seconda classe per i lavoratori in mare aperto. Questo è più inquietante. Chiaramente c'è una stratificazione sociale sancita nel loro processo di ingegneria.
Un difetto è sempre causato da una modifica, e in genere il bug ne è responsabile chiunque abbia introdotto il cambiamento. Chi meglio del mittente per capire la natura del bug e la sua risoluzione?
Se è delegato in tutto il mondo, come assicurarsi che l'autore originale sia disponibile per l'ingegnere offshored?
Sarà anche disponibile, lasciando l'ingegnere offshoring che non ha altro che un backlog di bug e scadenze, ma nessun supporto da Metropole ? Quale tipo di correzione del bug potrebbe sperare di eseguire una persona? Chi corregge i suoi bug? E cosa impedisce agli sviluppatori di Metropole di apprendere tramite bug fixing post mortem?
Ci sono stronzi in tutti i campi. Questo è particolarmente vero nel software. Dato che è inevitabile, la tua unica opzione è lavorare con gli stronzi che sanno più di te o stanno facendo le cose per bene. Questa azienda non sembra adattarsi a questa descrizione.
In breve, scappa.
Si aspettano davvero che un gruppo di sviluppatori junior off-shore sia in grado di sistemare un gruppo di codice degli sviluppatori senior? È come avere un'infermiera che controlli tutti i neuroligisti e la ripeti dove ha fatto gli errori. IDEA BAD!
Sarei interessato a quanto bene i loro dipendenti conoscono il codice che stanno sviluppando.
Mi chiedo anche il motivo per cui ci sono abbastanza bug da giustificare i costi aggiuntivi che ciò comporta. Mi preoccuperei anche del futuro a lungo termine dell'azienda, ci sono molti articoli sul web che rivendicano queste aziende, usano lo stesso codice per più progetti anche nello stesso settore.
La correzione del codice rotto fa parte del processo di scrittura del codice che ti consente di comprendere meglio ciò che hai sbagliato 6 mesi fa, quindi non commetti lo stesso errore, se qualche altro sviluppatore risolve i tuoi errori come fare prevedi che il bug si verifichi ancora e ancora?
Questo suona vagamente come il mio precedente datore di lavoro, fatta eccezione per il "potenziale datore di lavoro". Stanno perdendo gli sviluppatori per attrarre e hanno perso troppi per supportare i prodotti esistenti aggiungendo nuove funzionalità richieste dai cambiamenti delle leggi e dei regolamenti (il 60% delle entrate dell'ufficio proviene da un prodotto basato su VB6 e MS ha dichiarato che i runtime VB6 non sarà distribuito in nessun sistema operativo futuro, quindi sarà come quando uscì Vista - una folle corsa per sistemare le cose). I poteri desiderosi di portare presto la società al pubblico, quindi stanno affamando tutti per le risorse per rendere il bilancio un aspetto migliore di quello che è - quindi assumere offshore è l'unico modo per avvicinarsi a rimanere sul mercato.
Sulla base delle mie esperienze, quello che dice la citazione è che il tuo potenziale datore di lavoro è a buon mercato.
Dipende da cosa intendono "correggere i bug". Se questo risolve i bug durante il ciclo di sviluppo / test, è molto strano, questo è il lavoro degli sviluppatori originali. Se, d'altro canto, significano che hanno esternalizzato la manutenzione di un prodotto rilasciato, questo non è insolito e non è qualcosa di cui mi preoccuperei.
La mia esperienza è stata quella di coinvolgere un team esterno dopo che il fatto avrebbe bruciato tutto il tempo necessario per correggere i propri bug - hanno bisogno di essere aggiornati e portati nel processo di sviluppo. E poi mantenuto fino alla velocità continuamente. Il coordinamento è più difficile della scrittura del codice.
Se lavorerò su un codebase, mi piacerebbe avere la certezza che tutti i privilegi di commit siano ragionevolmente competenti. Questo include un bel po 'di persone in India, per esempio, ma non quelle che sono solitamente delegate a.
Inoltre, la maggior parte dei miei bug si trovano in sezioni di codice più complicate, e quelle sono quelle che il programmatore offshore ha meno probabilità di capire prima di applicare una correzione di bug.
Questa politica esiste in modo inconscio in alcune aziende. Lavoro per un outsourcer; io e i miei colleghi siamo più abili programmatori rispetto ai ragazzi sul posto, ci chiedono di insegnare loro come utilizzare gli strumenti, ecc., ma l'altro lato è che individueremo problemi nel loro codice più rapidamente di loro.
Generalmente i programmatori del cliente si trovano fisicamente nello stesso edificio di almeno alcuni degli utenti, quindi hanno maggiori probabilità di ottenere un contesto che non raggiunge gli emisferi. Troviamo che funziona bene, la parte mancante per me è che non stanno rivedendo il nostro codice, quindi quando il contratto termina potrebbero avere alcune sorprese o domande, non dovute necessariamente a pratiche scadenti da parte nostra, ma solo i soliti problemi che si verificano quando prendere in consegna il progetto di qualcun altro.
In ogni caso sono lieto che nel nostro caso non si tratti di una politica ufficiale, in quanto tale penso che possa erodere i programmatori in loco a essere poco più di un BA.