Ogni scelta comporta un debito tecnico?

Il debito tecnico significa che sei in debito . Se completi il tuo compito (ad esempio Amministratori / Utenti) e funziona, è sicuro e facile da mantenere, quindi non c'è debito tecnico.

Non essere in grado di prevedere potenziali sviluppi futuri, nuove funzionalità o cambiamenti non sono ciò che si intende con debito tecnico. Confronta sempre con la soluzione, necessaria per soddisfare i requisiti attuali.

Per usare la famosa analogia dell'auto, il debito tecnico è quando i tuoi freni perdono e non hai soldi per sistemarlo. Se possiedi una Volkswagen perfettamente valida (non Diesel ...), allora non possedere una Ferrari non è ancora un debito tecnico.

I'm familiar with the concept of technical debt as the cost of effort (through maintenance, support, rework etc.) incurred when choosing an expedient solution over a complete one.

Questo non è ciò che Debito tecnico significa.

Il debito tecnico è una metafora finanziaria (Ward Cunningham ha lavorato su un prodotto finanziario quando ha cercato di spiegare il concetto a un manager, quindi ha scelto una metafora finanziaria che gli sarebbe stata familiare.) Dire, vuoi andare in costruzione . Hai bisogno di macchine per guadagnare soldi, ma hai bisogno di soldi per comprare macchine. È un catch-22. Come si rompe questo? Debito! Prendi in prestito denaro, compri macchine, usi quelle macchine per guadagnare denaro, usa quei soldi per ripagare il tuo debito. Se non lo fai, maturerai interessi e il tuo debito sarà ancora più alto.

Il debito tecnico è legato alla comprensione di un sistema: per progettare bene un sistema, è necessario comprendere appieno il sistema. Ma, il più delle volte, la nostra comprensione di ciò che stiamo per costruire è solo parziale. Per acquisire maggiore comprensione, dovremmo osservare il sistema, giocarci, usarlo, ecc. Ma, naturalmente, per fare questo , dobbiamo prima costruirlo ... ma per costruirlo bene, dobbiamo capirlo prima ... e così via. Quindi, per progettare bene il sistema, è necessario avere esperienza con il sistema, ma per acquisire esperienza con il sistema, il sistema deve esistere, cioè è necessario averlo già progettato. Catch-22!

Quindi, cosa fai? Progetta il sistema nel modo migliore che conosci data la tua comprensione parziale. (Accettate il debito tecnico). Quindi, mentre comprendete meglio il sistema, lo rifattate in modo tale che il progetto sembri averlo compreso fin dall'inizio. (Paghi il debito tecnico.)

È molto importante che il debito tecnico significhi "costruire il sistema il modo migliore che puoi , data la tua comprensione parziale". Tu devi progettare bene il tuo sistema, altrimenti limiterai la tua capacità di refactoring del tuo nuovo acquisito comprensione nel sistema! Significa che non significa "costruire qualcosa di scadente, solo per ottenere qualcosa fuori dalla porta". Se conosci un modo migliore per farlo, non è un debito tecnico. Il debito tecnico significa che non conosce un modo migliore per farlo, perché devi prima costruirlo per capire quale sarebbe stato un modo migliore per costruirlo.

Non chiamerei ciò che descrivi il debito tecnico. Quello che stai descrivendo è semplicemente il principio YAGNI : non costruire qualcosa perché pensi che potresti averne bisogno in seguito. Crea solo qualcosa quando in realtà ti serve adesso . Cosa succede se, dopo aver utilizzato il sistema con un utente / utente regolare diviso per un po ', ti rendi conto che non hai realmente bisogno di un sistema basato sui ruoli ma un sistema basato sulle capacità?

potresti interpretarlo come un debito tecnico se la scoperta della necessità di autorizzazione è stata fatta usando il sistema. Non lo avresti mai saputo, se prima non avessi costruito il sistema con una comprensione limitata.

Ciò che presenti non è affatto ciò che chiamerei debito tecnico; è una decisione architettonica che può essere presa solo considerando i vincoli con cui stai progettando il sistema. Se si prevede di aggiungere un solo ruolo durante la vita di questo sistema, non ha senso cercare la seconda soluzione. Allo stesso modo, se ti aspetti di aggiungere molti ruoli saresti stupido a non optare per il secondo.

Il debito tecnico è l'implementazione intenzionale di una soluzione che, a lungo andare, non si manterrà, ma che al momento è abbastanza buona. Forse quel momento potrebbe essere speso meglio altrove, così potrai mettere insieme qualcosa di breve, ritardando l'inevitabile momento in cui dovrai risolvere il problema del vero problema.

Nel tuo caso sarebbe la prima soluzione quando hai effettivamente bisogno della seconda, ma i vincoli temporali (o qualcos'altro) ti costringono a scegliere la soluzione semplice e immediata che funzionerà dato che ti aspetti solo di creare un unico ruolo aggiuntivo nel prossimo mese. Ora hai contratto un debito tecnico perché hai scelto una soluzione che saprai non manterrà a lungo termine.

Uno degli elementi chiave che associo al debito tecnico è che in realtà hai codificato una soluzione che è subpar, non può essere estesa per fare ciò che potrebbe essere necessario in futuro o che sicuramente non può scalare in alcun significato significato (almeno non nel modo in cui ne hai bisogno). Hai intenzionalmente creato una bomba a orologeria.

Se implementate una soluzione tecnica di cui siete fiduciosi risolverete i problemi che intendeva risolvere, non vi è alcun debito tecnico ad esso associato. Come sempre, i requisiti possono cambiare in un secondo momento, ma questo non è un debito tecnico.

Su quella nota, non abbiate paura di incorrere in un debito tecnico.

Nella mia azienda ho imparato quella lezione nel modo più duro spendendo troppo tempo in termini di funzionalità che il tempo ha dimostrato di essere un codice usa e getta; il tipo di materiale da cui potresti ricavare maggiori guadagni monetari compilando in modo programmatico fogli Excel e pubblicandoli in un team di vendita.