Correzione di bug off-shore

Se un potenziale datore di lavoro ti dicesse che "correzione di bug in outsourcing perché gli sviluppatori odiano correggere i bug", cosa ne pensi? Quali potrebbero essere le tue preoccupazioni?

La correzione dei nostri bug in realtà ci rende uno sviluppatore migliore . Ed è un momento abbastanza piacevole per me. Soprattutto quando sono ben segnalati.

Se non gli piace correggere i bug, il problema sta altrove.

Ho il sospetto che il problema sia come i bug vengono percepiti dalla direzione o peggio, da cattive decisioni di progettazione e / o nessun test (unità), che causa dolorose correzioni di bug.

La correzione di bug di outsourcing probabilmente peggiorerà le cose.

Gli sviluppatori possono essere tentati di ridurre la qualità. Che importa? Alcuni ragazzi in mare aperto sono lì per ripulire il loro pasticcio.

Fino a quando i ragazzi offshore sostituiranno i ragazzi onshore.

Lascia , scappa ... veloce e non guardare mai indietro ...

Ho lavorato per un'azienda del genere, pensavano di essere intelligenti,

• hey abbiamo tutti questi bug ma i nostri anziani si lamentano che passano troppo tempo a sistemare i bug.

• apriamo un ufficio offshore e permettiamo agli altri di occuparsene.

per un manager che sembra davvero un buon 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 una squadra di 5 sviluppatori nel loro ufficio principale che ha gestito tutto con una squadra di 2 che creava nuovi oggetti e una squadra di 30 che ha trovato e risolto i bug.

sai cosa ... il team di correzione dei bug sta lottando, non riescono a tenere il passo.

questo ha reso gli "anziani" completamente non responsabili per i propri errori. Peggio ancora, perché tutto è accaduto così lontano la direzione non se ne è resa conto e la qualità del codice è precipitata 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 non riescono ancora a tenere il passo con gli unici sviluppatori che li creano. in realtà pensano che sia perché i nuovi ragazzi non sono abbastanza intelligenti ...

quindi sì, d'ora in poi, se un'azienda dice di aver esternalizzato il bug fix in un ufficio all'estero, fidati di me ... corro ... veloce.

Questa è la metodologia di gestione del sacco di carta .

Sali su una ferrovia, aspetta che arrivi un treno, quando lo vedi, mettiti un sacco di carta in testa e ... POOF .. il treno è andato !!. Magia !

Fare in modo che la compagnia paghi qualcun altro per ripulire il mio pasticcio sembra una buona idea, tranne quando mi aspetto che prenda il suo codice "pulito" e aggiunga nuove funzionalità. E se lo trovano così incasinato da non riuscire a risolverlo, eseguirai il debug del debug.

Non è opportunamente compensato perché devono assumere altri sviluppatori.

Dover dedicare una quantità sproporzionata di tempo a educare gli altri sviluppatori quando avresti potuto risolverlo da solo è controproducente.

Parte di me ritiene che coloro che creano problemi dovrebbero essere quelli che li risolvono o non vi è alcun incentivo per evitare di creare bug in primo luogo.

Gli sviluppatori non sono interessati a imparare dai loro errori? Riesci a correggere i bug senza una conoscenza specifica del dominio e il partner di outsourcing ha questa conoscenza? La parte di fissaggio è la più semplice la maggior parte delle volte, è la parte di analisi che richiede tempo. Dal mio punto di vista è una decisione stupida.

Se un potenziale datore di lavoro ti dicesse che "correzione di bug in outsourcing perché gli sviluppatori odiano correggere i bug", cosa ne pensi? Quali potrebbero essere le tue preoccupazioni?

Scapperei molto, molto, molto lontano. Uno sviluppatore è sempre, sempre, sempre responsabile di correggere i propri bug. Mangiare il cibo per cani è un principio di base della buona ingegneria.

Inoltre, la correzione dei bug è altrettanto importante, forse più dello sviluppo. Voglio dire, lo sviluppo è la scrittura del codice, il test e il debug / correzione.

Quello che ottengo da questa azienda è che stanno trattando la correzione dei bug come un'attività di seconda classe. Questo di per sé è piuttosto inquietante e metterei fortemente in dubbio la loro qualità del lavoro (ed ergo, il loro ambiente di lavoro). Ancora più inquietante è che delegano ciò che per loro è un lavoro di seconda classe ai lavoratori offshore. Questo è più inquietante. Chiaramente c'è una stratificazione sociale racchiusa nel loro processo di ingegneria.

Un difetto è sempre alla radice di una modifica e in genere il bug è di responsabilità di chiunque abbia introdotto la modifica. Chi meglio dell'originatore può comprendere 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 offshore?

Sarà persino disponibile, lasciando l'ingegnere offshore che non ha nient'altro che un arretrato di bug e scadenze, ma nessun supporto da parte del Metropole ? Che tipo di correzione di bug potrebbe sperare di eseguire una persona? Chi corregge i suoi bug? E cosa impedisce agli sviluppatori di Metropole di apprendere tramite la correzione dei bug post mortem?

Ci sono stronzi in tutti i campi. Questo è particolarmente vero nel software. Dal momento che è inevitabile, l'unica opzione è quella di lavorare con stronzi che sanno più di te o stanno facendo le cose nel modo giusto. Questa società non sembra adattarsi a tale descrizione.

In breve, scappa.

Si aspettano davvero che un gruppo di sviluppatori junior off-shore siano in grado di sistemare un sacco di codice per sviluppatori senior? È come avere un'infermiera che controlla due volte tutti i neuroligisti che lavorano e lo rifà dove ha fatto mistike. CATTIVA IDEA!

Sarei preoccupato di quanto i loro dipendenti conoscano effettivamente il codice che stanno sviluppando.
Vorrei anche chiedermi il motivo per cui ci sono abbastanza bug per giustificare i costi aggiuntivi che ciò comporta. Mi preoccuperei anche per il 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 e ti consente di comprendere meglio cosa hai fatto 6 mesi fa, quindi non commetti lo stesso errore, se qualche altro sviluppatore corregge i tuoi errori come puoi impedirlo bug di ripetersi ancora e ancora?

Questo suona vagamente come il mio precedente datore di lavoro, ad eccezione del bit "potenziale datore di lavoro". Hanno perso gli sviluppatori per logoramento e ne hanno persi troppi per supportare i prodotti esistenti, aggiungendo al contempo nuove funzionalità richieste dalle modifiche alle leggi e ai regolamenti (il 60% delle entrate dell'ufficio proviene da un prodotto basato su VB6 e MS ha dichiarato che l'autonomia di VB6 non sarà distribuito in nessun sistema operativo futuro, quindi sarà come quando Vista uscirà - una corsa folle per sistemare le cose). I poteri che vogliono rendere presto pubblica la società, quindi stanno morendo di fame tutti per le risorse per rendere il bilancio migliore di quello che è - quindi assumere in mare aperto è l'unico modo per avvicinarsi al mercato.

Sulla base delle mie esperienze, ciò che dice la citazione è che il tuo potenziale datore di lavoro è economico.

Dipende da cosa si intende per "correzione dei bug". Se questo sta risolvendo i bug durante il ciclo di sviluppo / test, allora è molto strano, questo è il lavoro per gli sviluppatori originali. Se, d'altra parte, significano che hanno esternalizzato la manutenzione di un prodotto rilasciato, questo non è insolito e non mi preoccuperei.

La mia esperienza è stata quella di coinvolgere un team esterno dopo che il fatto brucerà circa il tempo necessario solo per correggere i propri bug: devono essere aggiornati rapidamente e inseriti nel processo di sviluppo. E poi tenuto il passo per accelerare continuamente. Il coordinamento è più difficile della scrittura del codice.

Se sto andando a lavorare su una base di codice, mi piacerebbe avere la certezza che chiunque abbia i privilegi di commit è ragionevolmente competente. Questo include un bel po 'di persone in India, diciamo, ma non quelle che di solito sono offshore.

Inoltre, la maggior parte dei miei bug si trova in sezioni di codice più complicate, e quelle sono quelle che il programmatore offshore ha meno probabilità di comprendere prima di applicare una correzione di bug.

Questa politica esiste effettivamente inconsciamente in alcune aziende. Lavoro per un outsourcer; io e i miei colleghi siamo programmatori più competenti dei ragazzi in loco, ci chiedono di insegnare loro come usare strumenti ecc., ma l'altro lato è che individueremo i problemi nel loro codice più rapidamente di loro.

Generalmente i programmatori del client si trovano fisicamente nello stesso edificio di almeno alcuni utenti, quindi hanno maggiori probabilità di ottenere un contesto che non raggiunge gli emisferi. Troviamo che funzioni bene, la parte mancante per me è che non stanno rivedendo il nostro codice, quindi al termine del contratto potrebbero avere delle sorprese o domande, non necessariamente a causa di pratiche scadenti da parte nostra, ma solo dei soliti problemi che hai quando subentrare nel progetto di qualcun altro.

In ogni caso, sono contento che nel nostro caso non si tratti di una politica ufficiale, in quanto tale penso che eroderebbe i programmatori in loco per essere poco più che BA.