Come posso vendere un programma legacy riscrivibile all'azienda? [duplicare]

Credo che ci siano due fattori che dovresti considerare di non aver coperto nella tua Q. Lasciatemi definire questi mentre li uso, poi inizierò a rispondere alla tua Q.

1. rischio
2. Costo opportunità

Il rischio è probabilmente ovvio: la possibilità che ammucchino una montagna di denaro in qualcosa che non va da nessuna parte. Il rischio è aggravato da quello che Brooks chiama "Second System Effect" e il resto di noi chiama "Gold Plating". Ogni ricostruzione che ho visto comporta il rischio di persone che aggiungono tutte le funzionalità che non hanno aggiunto la prima volta.

Il costo opportunità in questo contesto è il costo associato alla funzionalità di riscrittura che dal punto di vista aziendale funzionava correttamente. È il costo opportunità perché significa che non hai l'opportunità di aggiungere funzionalità.

La vendita di qualcosa che è puramente un refactoring è difficile perché il Risk e il Costo Opportunità hanno entrambi denaro ad essi collegato da una prospettiva decisionale. Quello che generalmente consiglio è che invece di vendere una riscrittura del sistema, si vende un "migliora man mano che si va" a livello di componente. Costa di più perché devi costruire adattatori / facciate / proxy, ma è meno rischioso e più facile da vendere. Sono stato lì su "abbiamo bisogno di ricostruire tutto" e non va bene.

Ed ecco il problema: nel corso del tempo, tutti i sistemi si trasformano in rifiuti a meno che non si sia abbastanza disciplinati da impedirgli di farlo.

Che mi lascia questa domanda per te: se non puoi vendere loro, o anche la tua squadra, facendo la cosa giusta giorno per giorno, cosa ti fa pensare che puoi davvero vedere una riscrittura?

Ci vuole davvero qualche seria introspezione per rispondere onestamente a questa domanda. A volte ti è stato consegnato un sistema da qualcuno che non aveva idea. A volte ti è stato consegnato un sistema da qualcuno che ha iniziato con le migliori intenzioni e con il piede giusto ma è stato compromesso da una scarsa cultura aziendale lungo la strada. Se non riesci a capire quale sia, devi scoprirlo presto!

Ecco alcune idee, tutte cose che ho fatto più di una volta.

1. Niente ha successo come successo: presentalo un giorno . Uno dei motivi principali per cui le cose vengono rifiutate è che i decisori si sentono come se non sarebbe davvero molto meglio in seguito, o che non si è in grado di farlo davvero. Se riesci a mettere insieme una prova convincente del concetto e mostrarlo a loro, è più facile venderli su di esso.

Alcune delle migliori cose che abbia mai scritto sono iniziate come progetti invisibili. Le cose che le persone dicevano non erano possibili. Un altro che sento molto è: "la gente è più intelligente di quanto tu abbia provato e abbia fallito". Quando ti presenti con una prova convincente del concetto, decanta praticamente quegli argomenti.

Non posso dirti quante volte le persone mi hanno negato di lasciarmi lavorare su un progetto, respingendo ogni ragionevole argomento, semplicemente non ascoltando nulla di tutto ciò. Poi mostro loro una demo e improvvisamente pensano che il progetto sia una grande idea. Ma fai attenzione: più aghi qualcuno e più insistono che la risposta è no, devi stare attento: devono avere un modo onorevole di cambiare idea, senza risentirsi per questo o sentirsi male. Quindi, sii diplomatico, cerca idealmente di farli pensare che fosse la loro idea. o avere un buon rapporto con loro, in alternativa.

La chiave per una grande demo sta pianificando. Non iniziare pensando a cosa dovrebbe essere il prodotto. Inizia pensando a come sarebbe la demo più fantastica. Devi fare abbastanza ingegneria che la tua demo non è solo puro vaporware, ma quello che vuoi implementare per primo è qualsiasi cosa serva per fare in modo che la demo cali le calze.

1. Apri nuove possibilità con il nuovo design. C'era un sistema che ho riscritto che si adattava esattamente alla tua situazione. È stato un dolore terribile lavorare sul sistema. Non abbiamo dovuto prenderlo molto spesso, ma quando lo abbiamo fatto, mi ha ferito la mia anima e mi ha fatto venire voglia di piangere. Il sistema è stato scritto in VB.Net, e aveva tutta la logica aziendale inframmezzata su tutto il codice GUI (che era un'app per .NET pesante). La direzione non ha voluto rifarlo. Ho rifatto il back-end usando un webservice, e poi ho mostrato come farlo ci avrebbe permesso di aggiungere più di una UI al prodotto. Questo era un prodotto per la gestione delle chiamate telefoniche nei call center. Ho venduto la gestione sull'idea mostrando loro un mockup che ha funzionato sia su un sito web che su uno smartphone. Iniziarono immediatamente a pensare ad altri tipi di nuovi prodotti che potevano usare avendo più UI su questa cosa.

2. Stabilisci una testa di ponte / Non mangiare l'elefante tutto in una volta: costruisci il tuo sistema perfetto un po 'alla volta . Passa un po 'di tempo a immaginare come sarebbe il tuo sistema ideale. Immagina cosa sia questa architettura. Disegna uno schema a blocchi su un foglio di carta e blocca l'immagine nella tua mente. Poi la prossima volta che devi aggiustare qualcosa, prova a costruire un pezzo di quel sistema ideale. È quindi possibile creare un adattatore che consente di collegarlo al vecchio sistema. L'adattatore isolerà il tuo bellissimo nuovo pezzo dalle brutte bizzarrie del vecchio codice schifoso. Pezzo dopo pezzo, puoi sostituire l'intero sistema in questo modo. Il primo piccolo pezzo è la parte più difficile, è come stabilire una testa di ponte sul territorio nemico. Ma una volta stabilita la tua testa di ponte, andare avanti diventa progressivamente più facile.

Ad esempio, abbiamo avuto questo enorme corpus di codice scritto in PHP in un posto in cui ho lavorato. Il mio team e io volevamo usare Python, ma il management non voleva finanziarci per farlo. Abbiamo iniziato ad aggiungere nuove funzioni usando un webservice Python e usando curl per accedere a quelli da PHP. Non è stata una riscrittura totale, ma una volta che abbiamo costruito le strutture per rendere più semplice l'integrazione delle codebase che avevamo stabilito una testa di ponte, siamo stati in grado di spostare il resto di esso in avanti più facilmente da lì. Ho fatto la stessa cosa con i sistemi doggy legacy in linguaggi come COBOL e RPG / 3, chiamando a Java.

Pensa con estrema attenzione prima di riscriverlo. Leggi il post del blog di Joel Spolsky, Cose che non dovresti mai fare .

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

        It’s harder to read code than to write it.

This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it's easier and more fun than figuring out how the old function works...

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that's kind of gross if it's not made out of all new material?

...It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.

The old mantra build one to throw away is dangerous when applied to large scale commercial applications. If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That's fine. You may want to refactor a class to make it easier to use. That's fine, too. But throwing away the whole program is a dangerous folly...

Ho avuto l'opportunità di eseguire una riscrittura completa due volte (lavori diversi).

Il primo era un'app piuttosto piccola. Si stima che la riscrittura richieda due programmatori per sei mesi. Abbiamo raggiunto la scadenza e il cliente è stato molto contento. Sfortunatamente, nonostante la domanda, il marketing ha abbandonato l'app, quindi lo sforzo è stato sprecato.

Il secondo era l'app principale di una piccola azienda. La riscrittura è stata completamente sottovalutata e ha quasi rovinato la società. Alla fine il progetto è stato un successo.

Il problema con le riscritture è che non aggiunge alcuna funzionalità all'app. Il che significa che è difficile da vendere. Quindi è meglio riscrivere piccoli pezzi ogni volta. Refactoring ++.

Non riscrivere: i rischi e i costi sono troppo alti per la tua azienda. Vedi l'articolo di Joel Spolsky a cui fa riferimento @Grokus per ragioni.

Offro un'opzione alternativa - una combinazione di refactoring del codice che è adatto più l'introduzione di una tecnologia complementare a fianco. Ad esempio, inizia a scrivere nuove pagine in ASP.NET, gradualmente migrando sempre più codice nel mondo .NET. L'abbiamo fatto con successo: le nuove funzionalità sono una grande opportunità per farlo, ma sono anche candidate le parti più semplici del sistema che possono essere migrate rapidamente. Potrebbe essere necessario creare un qualche livello di astrazione o tipo di sistema di bridging (aggiungi un livello API al "vecchio" sistema) per arrivarci.

Solo tu puoi effettuare la chiamata per andare su MVC + AJAX, MVC + SilverLight / Flash o simili, ma non devi parcheggiare una cosa prima di andare avanti.

Sì, ci sarà un po 'di dolore e confusione lungo il percorso, ma avrai un prodotto spedibile per tutto il tempo, piuttosto che un lungo, lungo, lungo "sviluppo" con un prodotto affermato che diventa obsoleto e perdendo quota di mercato ai concorrenti.

Intendi venderlo a il tuo business, come convincere i manager a farlo? Sfortunatamente, non c'è trucco magico per rendere i manager che vedono tutto a breve termine per riconoscere problemi a lungo termine. Soprattutto se non sono tecnici, potrebbero non apprezzare le ragioni tecniche per una cosa del genere. L'unica cosa migliore da fare è quello che hai già fatto: dimostrare che è la cosa giusta dal punto di vista finanziario. Se non lo fanno, non c'è molto che puoi fare se non sederti e guardare le cose implodere.

D'altra parte, se intendi come lo vendi a un cliente che è un business, questo è facile. Riscrivi la cosa e digli che, se vogliono la caratteristica X, devono usare il nuovo sistema. A volte, per aiutare un cliente, hai bisogno di un po 'di amore duro.

Per prima cosa, crea una categoria per le modifiche tipiche in termini di SLOC (e punti funzione se riguardano modifiche agli elementi dell'interfaccia utente.)

Quindi guarda le modifiche al codice precedenti e vedi dove si inseriscono nel modello di categoria descritto sopra.

Fai lo stesso con le nuove funzionalità (ovvero, tratti le modifiche al codice e le nuove funzionalità in modo diverso a meno che una nuova funzionalità non comporti cambiamenti significativi / costi sulla base di codice esistente). Se l'integrazione di una nuova funzione è banale, separala dalle modifiche al codice. Se la sua integrazione con la base di codice esistente è significativamente costosa, si accontenti di modificare il codice.

Quindi, per ogni cambio di codice categorizzato (o nuova funzione), determina 1) quanto tempo è necessario per completare, 2) quanto tempo è stato necessario per complete, 3) quante persone sono state effettivamente coinvolte nel completamento e 4) quante persone erano inizialmente ritenute necessarie per il suo completamento.

Quindi ora dovresti avere una presentazione tabellare delle risorse fornite (modifiche al codice e nuove funzionalità), ciascuna con colonne che indicano le risorse stimate e reali (ore, persone) consumate.

Puoi quindi assumere uno stipendio / ora medio per ingegnere di ballpark (ad esempio $ 40 / ora). Moltiplicare per 2 per indicare il costo totale dell'ingegnere / ora (una stima del salario orario, dell'elettricità, delle amenità dell'ufficio e del noleggio, ecc.) Non deve essere accurato, solo abbastanza realistico.

Per ogni artefatto consegnato A , puoi calcolare quanto segue:

estimated_cost(A) := avg_hr_salary * estimated_hours(A) * estimated_people(A)

approx_cost(A) := avg_hr_salary * (actual_hours(A) + estimated_hours(A))/2 * (actual_people(A) + estimated_people(A)/2

max_cost(A) := avg_hr_salary * actual_hours(A) * actual_people(A)

Con queste relazioni (che devono essere basate su effettive modifiche al codice o nuovi elementi ... altrimenti non hanno senso), puoi calcolare (per dimensione della categoria), qual è la% di un cambio di codice di quella dimensione per deviare dalla dimensione stimata (un% di errore), il costo approssimativo e la% della modifica del codice potrebbero effettivamente raggiungere un valore massimo. costi.

È probabile che la percentuale per la deviazione massima dal costo stimato (minimo) assomigli sempre più a una distribuzione esponenziale, maggiore è il cambiamento di codice.

Con questa data, puoi dire al tuo cliente quanto segue:

You to your customer:

This change you are requesting (A) might take 10K SLOC, on the old code base. Historical data indicates that it might take 2 people at a minimum (estimate_people), possibly escalating up to 3 people (actual_people). The probability of the change to cost (estimate_cost) is A%; B% for approx_cost, and %C for max_cost.

Questa è la chiave. Devi eseguire gli stessi calcoli per nuove richieste (il tipo la cui integrazione con il vecchio codice base comporta cambiamenti non significativi in seguito).

Se ritieni che i costi stimati, approssimativi e massimi per nuove richieste di una determinata dimensione siano (si spera) significativamente inferiori ai costi delle vecchie modifiche alla base di codice della stessa dimensione, < em> THEN hai un argomento per una riscrittura del codice. Hai fornito prove sufficienti del fatto che la vecchia base di codice è costosa da cambiare rispetto alle modifiche della stessa grandezza nel nuovo codice.

Ma se i costi delle nuove richieste di codice non differiscono molto dalle vecchie modifiche al codice della stessa grandezza, sarà difficile giustificare una riscrittura del codice (e potrebbe indicare che i problemi non riguardano solo la base del codice, ma anche nelle tue pratiche di sviluppo.)

Se possibile, fai tutto il possibile per rendere l'applicazione migliore così come è adesso.

Se non sei soddisfatto della documentazione, dopo aver dedicato del tempo a capire cosa significa WRITE THEM DOWN per la prossima sessione di manutenzione. Spesso quando vedi una base di codice per la prima volta, solo una breve lista di "consiglianze" (per rispondere ai perché il codice non può) può aiutare a capire immensamente cosa succede.

Migliora in modo incrementale!

Trova un modo per farlo un po 'alla volta.

Se provi a riscrivere tutto da zero, probabilmente non lo rilascerai mai.

Se i tuoi frammenti di dimensioni del morso sono abbastanza piccoli, potresti non aver nemmeno bisogno di venderlo per il business: potresti essere in grado di andare avanti mentre implementi nuove funzionalità.