Come gestire la gestione dei sistemi legacy?

I am currently on a paid internship, and have been tasked with maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years. Management agrees the "system is on life support", and I receive a fairly regular supply of bug reports from end users currently using the system.

Il sistema non è obsoleto se le persone lo stanno ancora utilizzando e supporta le attività commerciali. Dal momento che è ancora in uso, l'azienda non può semplicemente buttarla via: deve essere supportata finché non è più necessario il sistema. Questo potrebbe essere un cambiamento negli obiettivi di business o un nuovo sistema è stato sviluppato, testato e distribuito con successo agli utenti finali.

In realtà, 5 anni non sono così lunghi. Ho lavorato con il codice che aveva 10 anni prima. Se continua a soddisfare le esigenze dell'utente, perché buttarlo via? Questo sta buttando via un sacco di soldi spesi per svilupparlo. Fino a quando non diventa impossibile mantenere a causa di un aumento dei costi o se i requisiti cambiano drasticamente, non c'è alcun motivo commerciale per buttarlo via.

Management now wants to extend the project for another year, and in the process nearly triple the user base.

Se la direzione dice che questo sistema è "in supporto vitale", perché stanno cercando di implementarlo ulteriormente? È normale che le attività di manutenzione continuino su un sistema legacy fino a quando non viene sostituito, ma se un sistema è in fase di dismissione, in genere non viene distribuito a più persone. Estendere la manutenzione è una cosa, ma aggiungere utenti che si affidano al sistema è una situazione diversa, tutti insieme.

Per me, sembra che non sia effettivamente la fine della vita, ma piuttosto in una fase di manutenzione e continuerà ad esserci fino a quando il sistema non soddisferà più le esigenze degli utenti.

As an intern (or any entry level position) how do I "push back"? I've already written a report stating my concerns, albeit in an open-ended document. Is there protocol or document type for suggesting changes? Am I in a position to make suggestions, or should I simply continue to support the old system?

Devi continuare a supportare il vecchio sistema. Più tardi, hai detto che il software non è l'attività principale della tua azienda. In tale ambiente, il compito dei team di software è supportare l'attività principale dell'azienda. Tuttavia, i team del software devono anche tenere a mente gli obiettivi aziendali.

Nel frattempo, cattura i tuoi suggerimenti in un modo che non sia eccessivo. Indica altre tecnologie o tecniche che potrebbero essere integrate con il sistema o utilizzate se / quando viene creato un nuovo sistema e i loro pro / contro. Il modo in cui lo fai dipende dalla compagnia, ma considerando alcuni punti successivi, forse sarebbe utile creare un wiki o un altro sito collaborativo.

In un business non software, il software è un costo e i team del software (in particolare i project manager / program manager) dovrebbero lavorare per ridurre al minimo i costi di costruzione e manutenzione dei sistemi software il più possibile, supportando nel contempo le esigenze di gli utenti finali. Gettare via software che (per quanto posso dire, dal tuo post, comunque) soddisfa le esigenze degli utenti va contro ciò che è nel migliore interesse del team di software.

*To clarify, software development is not my company's primary business. As such no internal protocols exist. Additionally, the project has no formal documentation at all, no requirements documents. The development is very ad hoc.

Per me, questo è il problema. Non producendo documentazione, non sviluppando una specifica, e una mancanza di coerenza tende ad aumentare il costo di sviluppo del software. Lavorare per risolvere questo problema sarebbe la mia massima priorità, e lo farei lavorando su elementi come uno standard di codifica, controllo della versione, produzione di documenti di codice e progettazione auto-documentabili, tracciamento dei difetti e specifiche dei requisiti.

I've already written a report stating my concerns

Buona. Questo è il limite di ciò che puoi fare come tirocinante. Per riferimento futuro quando scrivo tali rapporti, enfatizzo la presentazione di fatti concreti in modo imparziale e professionale, privo di pregiudizi emotivi. Non sai chi leggerà il rapporto, forse qualcuno che potrebbe o non potrebbe aver causato alcuni dei problemi che stai descrivendo o che hanno preso decisioni che hanno portato a questi problemi. Qualunque cosa diversa dai fatti freddi potrebbe essere presa da tali persone come un affronto o un'offesa e causerà loro di non piacere a te e forse non prenderli sul serio.

Management now wants to extend the project for another year, and in the process nearly triple the user base

Tieni presente che le decisioni aziendali come questa sono prese perché stanno cercando di rendere debito con le risorse che hanno a loro disposizione. Sono sicuro che il management è probabilmente a conoscenza dei problemi con il software legacy e probabilmente conosce i reclami degli utenti, ma ha a disposizione le risorse di sviluppo del software per gestire il refactoring o una riscrittura?

La maggior parte delle volte non lo fanno, soprattutto se il software non è il pane della società e la qualità e la soddisfazione degli utenti con il software non influenzeranno direttamente la bottomline. Fare questo tipo di decisioni è a volte il motivo per cui un manager fa schifo perché spesso ti trovi in una situazione di sconfitta, qualunque cosa tu faccia.

maintaining an obsolete system that has been developed by multiple developers (at different times) over the course of the past 5 years

Gli errori sono stati fatti durante tutto il progetto che l'ha portato a questo punto. La mancanza di solidi input o requisiti utente, la mancanza di una corretta gestione del prodotto e il controllo delle modifiche per gestire i mutevoli requisiti e necessità e la mancanza di risorse tecniche adeguate per implementare hanno causato i problemi che esistono oggi. Non so se obsoleto è la parola giusta però. La tecnologia di base è basata su framework e tecnologie supportati, o non è solo la tecnologia all'avanguardia o ideale?

As an intern (or any entry level position) how do I "push back"?

Sei in una posizione di minor potere e sei temporaneo in questo. Non importa se hai ragione, non mi aspetterei che uno stagista mi "risparmi" mai. Mi aspetto che imparino, discutano i problemi mentre li vedono e seguono gli ordini. Questo è tutto. Una volta che viene dato un ordine, mi aspetto che venga eseguito al meglio delle loro possibilità, perché il tempo per la discussione è finito a quel punto.

Sei uno stagista. Dubito molto che tu sia persino lontanamente al passo con gli imperativi aziendali di tutti i giorni e come altre persone hanno notato, una base di codice di 5 anni non è poi così vecchia.

Le decisioni sulla sostituzione di sistemi legacy non sono sempre guidate da un punto di vista tecnico; sono guidati dal cambiamento dei requisiti aziendali. L'input per quelli può essere difficoltà relative al mantenimento; ma alla fine della giornata, devi riconoscere che la tua posizione non significa necessariamente che hai tutte le conoscenze disponibili e richieste. Direi che in realtà hai pochissime conoscenze necessarie per fare la chiamata su quale sia la mossa migliore al momento.

Il mio consiglio è questo: apprendi dall'esperienza e smetti di assumere che la tua conoscenza superi quella delle persone che devono gestire l'attività giorno per giorno.

Il tuo compito è di mantenere il sistema funzionante, non di suggerire una nuova sostituzione brillante.

Mi sembra che molti giovani programmatori non si rendano conto che la manutenzione dei vecchi sistemi è una parte più importante del lavoro di programmazione rispetto alla progettazione di nuovi sistemi brillanti /

Non respingere. L'unica cosa che dovresti fare è esprimere le tue preoccupazioni in modo chiaro e conciso. Il fatto è che la maggior parte delle aziende in cui lavorerai in futuro avrà sistemi legacy. Questi sistemi legacy devono essere mantenuti perché in molti casi sono troppo costosi da sostituire.

In molti casi potresti persino avere le migliori intenzioni di sostituire il sistema attuale con un sistema migliore, tuttavia potresti solo introdurre nuovi e diversi bug ... quando esci, il sistema si trasformerà rapidamente in un sistema legacy e la compagnia sarà nello stesso punto in cui era prima. Niente è obsoleto fino a quando non serve più ai server o è completamente incompatibile con i sistemi moderni. La mia azienda ha un sistema vecchio di 20 anni che stiamo convertendo ora in ASP.NET. Il sistema funziona ancora, ma il supporto per la vecchia tecnologia sta diminuendo e il suo funzionamento con i moderni browser Web sta diventando sempre più dispendioso in termini di tempo.

Che cosa puoi fare:

Lascia le cose più pulite

Quando mantieni qualcosa lascia più pulito rispetto a quando hai iniziato. fai la tua correzione, ma anche ripulisci le cose in modo che la prossima volta che qualcuno debba apportare una modifica sia più facile da capire.

Crea documentazione

Se la mancanza di documentazione è un problema, crea documentazione. Quando lavori su una particolare parte del sistema, documentalo.

Meno doloroso

Come ho affermato, puoi esprimere le tue preoccupazioni, ma il tuo meglio è solo lavorare diligentemente sul sistema e renderlo migliore su cui lavorare per quelli che ti seguono. Risolvi i bug correttamente. Documento. Odori di codice disperso. Rendilo migliore. E quando fai queste cose, che i tuoi superiori sappiano. Dì loro che stai facendo X, Y e Z per migliorare il processo di sviluppo. Ciò crea credibilità e, a lungo termine, aiuterà più di ogni altra cosa la tua azienda.

NON TU !!! Questa è una GRANDE Opportunità!

Sei uno stage da imparare! Questo progetto è un mondo reale come si arriva.

Sei molto fortunato ad averlo. Il fatto che tu sia non qualificato non è la tua preoccupazione. (Se \ quando la direzione lo ha realizzato, avrai guadagnato molto)

Sarai qualificato una volta terminato questo stage, ed è un'ottima notizia.

PS: fai in modo religioso i backup, assicurati che QUALSIASI cosa tu faccia possa essere ripristinato. Inizia con i problemi che sono "Correzioni facili" Ma grandi punti deboli per gli utenti. Fai piccoli passi.

Suppongo, in un senso molto teorico - non esiste una cosa chiamata Sistema legacy . Ho un telefono molto vecchio (un sistema legacy), e in questi giorni ci sono buoni telefoni Android (piattaforme moderne), ma il mio telefono funziona e fa quello che mi serve. Perché dovrei buttarlo via?

Tutti i sistemi che oggi chiamate "legacy", sono stati un giorno lo stato dell'arte. È solo il tempo che ci serve. Inoltre, quando ci sono lavori di considerevole entità, non è che ri-fare di nuovo tutto nelle piattaforme moderne, significa che sarà automaticamente privo di bug (o senza problemi).

Ecco cosa ti consiglio di fare:

1. Lascia per primo la tua avversione al "sistema legacy". Questo ti renderà molto controproducente.

2. Inizia a documentare ciò che fai e ciò che pensi. Anche se in modo graduale. Non c'è momento migliore per fare documentazione di quello in cui ti rendi conto di averne bisogno.

3. Invece di provare a respingere l'avanzamento del "sistema legacy", prova a definire il percorso per la sua uscita senza intoppi. Prova a vedere che puoi convincere il management che uno sviluppo più nuovo che può essere isolato, può essere fatto passo dopo passo in nuove piattaforme senza compromettere l'interoperabilità con i vecchi sistemi. Lentamente (e questo sarà molto lentamente) mentre le cose si evolvono, la necessità di mantenere il sistema legacy svanirebbe. Questo è l'unico modo per dire addio a qualsiasi vecchio sistema.

Dipan.

La verità è che nessuno dà agli stagisti il lavoro che vogliono fare. Quando sei la persona più giovane, ottieni il lavoro meno emozionante. Quanto bene gestisci personalmente ciò dice molto all'organizzazione se possono fidarti di te per fare di più il lavoro eccitante.

Quindi ecco un'opportunità inestimabile per dimostrare che puoi fornire risolvendo i bug, che puoi refactoring rendendo ogni parte del codice che tocchi un po 'più strong, che puoi creare unit test, iniziando a crearli per questo sistema e che puoi documentare creando la documentazione per la prossima povera anima che è bloccata con questo sistema. Ti dà anche l'opportunità di dimostrare che puoi gestire efficacemente gli utenti (per ottenere maggiori dettagli sui bug segnalati) e soddisfare i loro bisogni. Se il progetto non è ora nel controllo del codice sorgente, mettilo lì e se i bug non sono tracciati in un bug tracker, quindi avvialo uno. Questi tipi di azioni ti mostreranno come lavorare professionalmente. Tutto questo è un'esperienza di gran lunga più preziosa del semplice lavoro in una tecnologia divertente che fa un progetto che verrà lanciato dopo che te ne sei andato (le altre cose che alcuni stagisti vengono assegnati a fare).

Oppure potresti prendere la strada opposta e solo lamentarti di quanto sia pessimo il progetto e quanto sarebbe bello sostituirlo. Nel qual caso, quasi sicuramente non ti verrà offerto un lavoro in quella società dopo il tuo stage.

Probabilmente non hai abbastanza informazioni per determinare se è conveniente andare un altro anno o meno. Sarebbe interessante capire l'azienda e il motivo per cui stanno aggiungendo utenti. Sembra che potrebbe esserci qualche crescita in corso e non possono permettersi di fare un passo indietro finanziariamente o con determinati limiti di tempo per costruire un'altra app. Costruire una nuova app è raramente la scelta migliore comunque. 5 anni non sono così vecchi se prima non li hanno costruiti con la vecchia tecnologia.