In realtà stai parlando del debito tecnico . Forse una metafora potrebbe aiutare i tuoi manager. Spesso paragono l'effetto del debito tecnico nel software per cucinare in una cucina sporca. Se il lavandino, i banconi e la stufa sono ammucchiati con piatti sporchi e c'è del cestino sul pavimento, ci vuole più tempo per fare un pasto. Tuttavia, il modo più veloce per preparare il prossimo pasto è quello di risolvere il problema. Pulire la cucina e tenerla pulita farà ritardare il prossimo pasto, ma migliorerà la consegna di tutti i pasti successivi. E proprio come la persona che ha fame nella sala da pranzo non può vedere la cucina in disordine, e non si capisce perché si vuole pulire prima di iniziare a cucinare, la gestione non può vedere il caos nel codice. Devi mostrare loro il casino o mostrare i problemi di qualità e i ritardi causati dal caos.

Forse potresti anche parlare di attività urgenti e attività importanti. Quando non vengono eseguite attività importanti, le attività urgenti richiedono più tempo e costano di più.

Sei inciampato in qualcosa che affligge i programmatori ovunque ad un certo punto della loro carriera: questo codice deve essere refactored, ci sono problemi di architettura laggiù, questo modulo sta diventando non mantenibile, ecc. Perché della cultura attuale della tua organizzazione, tuttavia, ti viene spinto a concentrarti sul lavoro che produce solo vantaggi visibili .

È di nuovo il classico Segreto Iceberg . Il segreto ha a che fare con il fatto che proprio come un iceberg è sott'acqua al 90%, quindi è la maggior parte del qualsiasi progetto di sviluppo: il 90% del lavoro sarà completamente invisibile all'utente finale . Quel codice avrà un impatto sull'utente finale, ma la gestione ha difficoltà a capire perché hai speso sei ore a refactoring delle chiamate di mantenimento / rilascio e di riferimento automatico quando non possono vedere alcuna differenza e tutto è Funziona perfettamente.

Ecco alcuni fatti che puoi portare con te su questo problema.

• Gestione, a meno che non siano programmatori stessi , non capiranno il segreto di Iceberg.
• Questo è un problema di ignoranza, non di malizia. L'amministratore delegato vuole un buon prodotto: non capisce tutto ciò che fa un buon prodotto.
• Il CEO (e il tuo capo diretto) non sono stupidi: studia e prepara alcuni fatti e alcuni dati concreti per perché dovresti passare il tempo su questo e altri problemi Iceberg.

Non dimenticare - sei un uomo di compagnia (o donna). Non un codice man. Stai sviluppando questo prodotto per un'azienda che ha interesse nel suo successo o fallimento - i tuoi progetti e le tue proposte di progetto dovrebbero riflettere questo. Mostra la tua passione per l'azienda e il prodotto, mostra le tue conoscenze e dimostra al tuo capo e CEO che dovrebbero fidarti di te quando vieni da loro e dì che qualcosa deve funzionare. Mostra loro come contribuirà alla linea di fondo - sia aggiungendo valore al prodotto (più persone comprano copie) o risparmiando tempo lungo la strada (meno clienti arrabbiati quando il tuo prodotto fallisce).

Non lo fai.

Vedo questa domanda e tutte le domande come se si trattasse di un vicolo cieco. Non puoi "convincere" la gente di nulla. Se non sono già a conoscenza di cose come questa o indagano, è probabile che non diano una capriola. E nessuna quantità di dati li convincerà altrimenti. Il cambiamento deve venire dall'interno. Puoi portare un cavallo all'acqua ma non puoi farlo bere.

Dico cuocere le modifiche desiderate nelle prossime stime tecniche. Sii come, hey, dobbiamo "aggiornare" a questo nuovo framework introdotto da Apple. Non lasciare che non usi ARC sulla tua roadmap. Non ci sono opzioni; la migrazione verso ARC è l'unico modo.

Ho già risposto a una domanda simile prima, quindi questo potrebbe essere considerato un duplicato. Fondamentalmente, non otterrai l'approvazione per fare uno "sforzo di refactoring". Il modo in cui decidi di pulire il codice è seguire la regola del boy scout: lascia sempre il codice più pulito quando esci da quando sei arrivato.

Proprio come pagare un debito reale può sembrare un compito insormontabile (o ripulire una casa disordinata). Il trucco è renderlo migliore pezzo per pezzo fino a quando non inizi a vedere "isole di pulizia". Una volta acquisito uno slancio significativo, altri sviluppatori del team inizieranno a notare e alla fine contribuiranno al compito.

Suggerirei di leggere il Clean Coder di "Uncle" Bob Martin. Scrivere un buon codice fa parte del tuo lavoro. Non chiedi il permesso di fare il tuo lavoro, lo fai e basta.

Come per altre domande di questo tipo, è necessario fornire numeri che la direzione comprenderà. Numeri che mostrano quanto tempo verrà risparmiato implementando questi miglioramenti, quanti meno "crash casuali casuali" si verificheranno, ecc. Convincerli che gli arresti anomali sono visibili all'utente finale e che qualsiasi cosa fatta per prevenirli fa bene al business.

Potresti anche tentare di implementare questi miglioramenti nel tuo tempo libero (ad esempio al di fuori delle ore di lavoro) e poi mostrare i benefici alla gestione in seguito. Lo farei solo quando è chiaro che il management non capisce cosa stai cercando di trasmettere e / o che non vuole dedicare del tempo a te nemmeno per tentarlo.

Buona fortuna!

Presenta un caso aziendale

Ci sono molte ragioni per le quali spesso le raccomandazioni ingegneristiche vengono ignorate. Il modo migliore per affrontare quasi tutti i motivi è il caso aziendale del perché dovrebbe essere fatto. La classica analisi costi / benefici. Questo non solo rende un argomento convincente, ma dà anche ai tuoi capi qualcosa da portare ai loro superiori.

• Qual è il costo iniziale?
• Qual è il costo corrente?
• Quali sono i risparmi di denaro / tempo previsti e da dove vengono?
• Quanto tempo ci vorrà prima di vedere il ROI?

Quando si fa un business case, si dovrebbe sempre eseguire il backup dei propri argomenti con i dati.

• Quanto tempo impiega attualmente lo sviluppo per gestire i problemi che verranno rimossi o attenuati?
• Quanti reclami degli utenti ti vengono associati ai problemi che verranno rimossi o attenuati?
• Quali altri vantaggi avrà?

Allinea i numeri e rendi una equazione approssimativa, ma semplice. Costerà X da fare e andrà a beneficio della compagnia Y.

Nota: non sorprenderti se è proibitivamente costoso implementare un'idea accademicamente buona.

Questo tipo di cambiamento rientra nella categoria del refactoring. L'approccio Agile sarebbe che dovresti incorporare il tempo di refactoring AMPLE in ogni storia che stimi e questo è esattamente il motivo. A parte gli ingegneri, nessuno capirà perché vuoi farlo e va bene, non è il loro lavoro determinare come codificare correttamente, è tuo.

Quindi la prossima volta che hai un po 'di lavoro da fare, assicurati che queste modifiche siano parte di esso. Se stai fornendo stime, assicurati di aggiungere il 30% alla tua stima per il refactoring, se non fornisci stime, quindi esegui il refactoring come parte del tuo lavoro.

Potrebbe renderti più lento - beh no, non è questo il modo di guardarlo, il modo di guardarlo è che la tua velocità attuale è un'illusione, essenzialmente una bugia che stai passando sopra la catena, in realtà dovrebbe essere un po 'più lento a causa di questo lavoro che si sa deve essere fatto.

Probabilmente potresti costruire case più velocemente se non usassi il calcestruzzo come base - e sarebbero perfette per il cliente ma - beh - Anche se il cliente non vede la necessità della fondazione , il costruttore deve. (Questo è in realtà un parallelo interessante perché si scopre che i costruttori non sempre fanno ciò che sanno che dovrebbero fare quindi abbiamo bisogno di approvare le leggi per costringerli a farlo - non ci sono leggi che governano lo sviluppo del software, anche se affrontiamo lo stesso decisioni e spesso sbagliate ...)

Hai detto che sei abbastanza fortunato che il tuo manager e CEO sono entrambi programmatori. Quindi probabilmente fanno capiscono qual è il debito tecnico.

Dovresti gestire la situazione cercando di risolvere la situazione sulla base di fatti, il che significa che c'è una possibilità reale che non finirà per fare i miglioramenti tecnici che vuoi (i fatti possono essere noiosi quel modo).

Il tuo compito è assicurarti che comprenda i costi e i benefici derivanti dal pagamento di qualsiasi debito tecnico in particolare. Il loro compito è decidere se il miglior uso delle risorse è nel ripagarlo o nel fare qualcos'altro.

Proprio come può essere difficile per le persone non coinvolte nel codice vedere i benefici del miglioramento delle cose "nascoste", può essere difficile per i programmatori vedere i benefici delle modifiche visibili del codice quando i benefici si accumulano in aree del attività alquanto "nascoste" dagli sviluppatori.

È bello che la tua direzione possa spiegarti perché le caratteristiche visibili valgono più del tuo tempo rispetto al pagamento del debito tecnico, ma in realtà non è comunque compito tuo decidere. Quindi spiegarlo a te non fa molto per gli affari se non per farti felice. E in un certo senso, insistendo sul fatto che non lo fanno, non si fida di loro per fare il loro lavoro. Se non ti piace quando ti micro-gestisci, allora dovresti capire.

Quindi, se continui a tenerli a conoscenza dello stato di ogni debito tecnico e dei costi e dei benefici di ignorarlo rispetto al pagamento, hai fatto il tuo lavoro. A meno che tu non non faccia la gestione fidata di fare il loro, nel qual caso hai un problema molto più grande che sarebbe tutta un'altra questione da affrontare.

Forse questa non è una risposta, ma una risposta basata su errori che ho fatto. Anche un disaccordo con alcune delle filosofie che ho letto qui.

• Non cadere in conflitto con la convinzione che il programmatore sappia che è meglio.
• Sii onesto. Riduci il fattore mentre procedi, ma non mentire e calcolare le stime per i tuoi scopi.
• Non possiedi il codice. Non intraprendere lavori non approvati dal lead.
• Potresti avere ragione su qualcosa; potresti sbagliare ... ma dovresti fare ciò che sei pagato per fare.

Ma certamente segui l'eccellente consiglio dato sul miglioramento delle cose.

Ovviamente lavori per un capo dai capelli a punta (PHB). Lui non programma più, se mai, e se lo facesse probabilmente non sarebbe stato un granché (anche se gli piacerebbe inserire frasi come "const correctness" e "segmentation fault" in modo che i ragazzi sappiano che ha guadagnato le sue strisce ) - Ecco come è stato individuato per la gestione.

All'amministratore delegato (che praticamente ha un Mohawk) piace il PHB perché il PHB offre funzioni . Ogni sprint mostra con orgoglio un nuovo tick-box (leggermente disallineato, con un'etichetta ambigua), un'icona scintillante (non ancora funzionante in nessun ambiente ma colore a 8 bit su Citrix) e un modulo (che ha arresti anomali casuali a causa delle condizioni della gara nella variante su misura xml basata su C implementato database locale che nessuno del team dev ha il coraggio di toccare perché è stato scritto da una delle vecchie leggende di dev di protezione 10 anni fa e fa TUTTO con macro con 5 nomi di lettere, se hanno bisogno di 5 lettere o non).

I programmatori che in realtà fanno il "work bit" (sai che quel bit che accade, scomodo dopo tutto il lavoro reale come disegnare cerchi su lavagne, gridare e mangiare miniature in miniatura di Battenburg è fatto) sappi che in un sano il lavoro che ha richiesto 10 ragazzi per 10 giorni per faticosamente uscire dalla giungla non più mantenuta, probabilmente equivarrebbe a uno o due giorni uomo, inclusi i test. Ma per ottenere il sistema da dove è sano potrebbero volerci 6 mesi di duro lavoro, con un minimo di evidente ricompensa esterna.

Il PHB sa che in 6 mesi, per errore o per truffa, può ottenere trenta o quaranta nuove funzioni nell'applicazione che i venditori (che devono essere maghi dato quello che stanno effettivamente vendendo) ) può essere utilizzato per tentare nuovi acquisti e aggiornamenti.

Tuttavia, per dare al PHB i suoi debiti: senza quei tick-box e le forme le vendite potrebbero ristagnare o diminuire, un concorrente potrebbe guadagnare quote di mercato, e questo potrebbe essere peggio dell'alternativa.

La conclusione a cui sono giunto è che l'unica via d'uscita dal pantano è lavorare in una nuova start-up, con poche persone che condividono la tua visione su come il software dovrebbe essere fatto e poi ostinatamente fermarsi a quello filosofia (sto ancora lavorando per arrivarci!)

C'è un altro costo nascosto non menzionato in altre risposte. Vale a dire che i bravi ingegneri tendono a lasciare nel tipo di ambiente descritto. Alla fine, chiunque abbia l'ambizione o la capacità di refactoring ha lasciato la compagnia, e quindi le cose andranno molto male, probabilmente non risolvibili. Sfortunatamente non puoi dire al tuo manager ciò senza essere arrogante ("Sono uno dei tuoi migliori programmatori"), e un coglione invadente ("Me ne vado se non fai quello che voglio"). Tuttavia, ricordati di menzionarlo nel tuo colloquio di uscita, per assicurarti di non assumere lo status di re-assunzione.

Hai ragione e hai torto entrambi, ecco perché questi problemi restano in sospeso per molto tempo e creano sentimenti difficili.

I motivi per cui sono chiaramente indicati sopra: la direzione pensa in denaro; o ancora più specificamente: entrate. Per loro qualcosa che ha un costo ma nessuna visibilità direttamente al cliente non aggiunge entrate, quindi è un piano sbagliato.

La tua visione è giusta: andrà bene per i clienti ma a lungo termine. Le tue azioni potrebbero generare entrate ancora maggiori in futuro rispetto ai piani a breve termine.

Non sei il manager, non sei il responsabile diretto delle entrate (presumo ovviamente). Quindi ti stai mescolando (è così che si sente per la gestione) con i loro problemi e non ti stai concentrando sul tuo lavoro: espandendo ulteriormente il software.

Tutte parole dure e chiare ma è così che si presentano la maggior parte dei problemi, fuori dagli errori di comunicazione. Entrambi volete la stessa cosa ma le vostre decisioni a breve termine sono fatte in modo diverso. Tutto perché lo sviluppatore ha una prospettiva diversa rispetto al gestore.

Come risolvi questo problema? Si comunicano e si capiscono abbastanza bene su una serie di problemi. Questo sarà il focus sul coinvolgimento e soddisfazione del cliente molto probabilmente.

Per risolvere questo problema in un metodo di prova stabile e futuro concordare su qualche cosa: misurare il costo della correzione di bug nel vecchio codice. Misura il tempo necessario per lavorare con il vecchio software e come sarebbe con il nuovo codebase.

Per provare questo, ad esempio, potresti fare una cosa molto semplice: diramazione del software nel tuo versioning. Prima fai ciò che la direzione vuole, quindi crea quella caratteristica. Lo fai, ma l'accordo ti dà il tempo di mostrare la via diversa. Poi fai la stessa cosa nella nuova branche, ma prima risolvi i problemi che vuoi eliminare. Quindi sviluppa anche la soluzione.

Ora hai la stessa soluzione ma totalmente sviluppata in modo diverso. Crea un caso da questo, metti le soluzioni una accanto all'altra includendo alcune informazioni di gestione come la stabilità, la quantità di codice necessaria e il codice stesso.

Ora prendi un caffè e inizia a dare un'occhiata, non discutendo su chi ha ragione, ma quale sarebbe l'influenza di entrambe le direzioni per l'azienda. Ciò creerà un incontro che è davvero utile e non una discussione peggiore perché non genererà l'atmosfera di cui entrambi avrete bisogno. Ciò non renderà il tuo prodotto migliore.

Se hai una revisione del codice, crea un ticket tecnico in cui dichiari che il codice dovrebbe essere migliorato utilizzando ARC e assegnarlo al gestore.

Convinci. Spiegagli alcuni piccoli esempi di miglioramenti tecnici simili che hai fatto e i suoi benefici per i progetti.

Devi vendere quei cambiamenti nell'unico modo che la direzione è disposta ad acquistare:

Trova una funzione rivolta all'utente che sia così convincente che la gestione deve solo averla, ma sarebbe impossibile fare a meno di alcuni miglioramenti di basso livello nel codice.

Lascia che ti racconti di un'opportunità da 2 miliardi di dollari che è quasi sfuggita alle nostre mani a causa dell'inerzia della gestione.

Alcuni di noi hanno un punto di ascolto della voce del cliente, il che significa capire quello che vuole. Non è sempre quello che chiede, ma se sei in grado di avere conversazioni con i tuoi clienti, alla fine arrivi ad una comprensione reciproca di ciò che vuole. (Quindi può iniziare esplicitamente a chiederglielo.)

Detto questo, è importante capire chi dovrebbe avere quella conversazione con il cliente. In genere hai le persone di sviluppo del tuo business insieme ad alcuni dei principali designer che lo fanno. Se hai qualche competizione, puoi aspettarti che anche il cliente stia avendo questa conversazione con loro.

Allo stesso tempo, è importante che gli sviluppatori tengano aggiornati nei loro campi, perché ci sarà una competizione che ti batterà se non lo farai.

Nella nostra situazione, avevamo un cliente esistente e un prodotto un po 'efficace basato su vecchie tecnologie e il cliente necessitava di rapidi aggiornamenti. Quello di cui avevano veramente bisogno era un prodotto di sostituzione completo, ma la mentalità della nostra azienda era che questo ci avrebbe immediatamente costretti in una posizione competitiva, mentre la modifica del prodotto esistente consentiva ai nostri clienti di continuare con noi senza che fosse richiesto legalmente di renderlo competitivo. Il nostro management pensava di possedere questo mercato. Il problema era che non potevano tenere il passo con le richieste di aggiornamento, perché la struttura del prodotto esistente non era abbastanza flessibile per l'aggiornamento.

Il cliente è diventato impaziente e ha iniziato a conversare con fonti concorrenti. Abbiamo perso la nostra "proprietà" di quel mercato e un paio di miliardi di dollari di entrate. Tuttavia, una volta che il mercato ci ha costretti ad assumere una posizione competitiva, il management non ha avuto altra scelta che abbandonare la propria attività o competere. (La maggior parte di quelli che sono stati bloccati alla fine sono stati licenziati.) Abbiamo gareggiato e siamo riusciti a recuperare l'attività dal filo più sottile.

Ho detto all'inizio che questa opportunità ci è sfuggita di mano. Abbiamo recuperato l'affare, per le entrate che ho menzionato. Se fossimo stati più pronti ad adattarci alle preoccupazioni del cliente all'inizio, non ci sarebbe stata alcuna vera concorrenza.

Il take-away che sto offrendo è questo: cerca sempre di rimanere all'avanguardia nelle tue capacità personali. Sviluppa sempre un prodotto che sia flessibile e possa essere adattato rapidamente a ciò di cui il tuo cliente ha bisogno. Se lavori troppo a lungo per un'azienda che non la pensa così, ti appassionerai e la tua motivazione personale diminuirà. L'ho visto succedere.

Quando hai un'idea per migliorare il tuo prodotto per qualsiasi motivo, poniti queste domande: - È questo che penso che il cliente desideri? Posso convalidare i miei pensieri sullo sviluppo del prodotto rispetto alla voce del cliente? La mia azienda è in grado di soddisfare le esigenze del cliente? Se é cosi, come? - Dovresti quindi essere in grado di fare un caso convincente riguardo alle tue proposte di sviluppo prodotto.

Il linguaggio comune delle imprese in tutti i settori e settori è il denaro. Il problema che stai descrivendo non è un problema di programmazione: è un problema aziendale. Se si desidera ottenere una risposta appropriata a una proposta commerciale, è necessario inquadrarla nella lingua del business. Ciò significa che devi essere in grado di presentare un piano di progetto alternativo che includa tutti i costi e i benefici.

Hai bisogno di conoscere cose come costi opportunità, ROI (ritorno sull'investimento), e NPV (valore attuale netto). Non è necessario un MBA per farlo, ma è necessario accedere ai dati che potrebbero non essere disponibili, come i costi di manodopera, i costi generali e il potenziale di guadagno. Se puoi fare una chiara argomentazione sul fatto che un percorso fornirà più valore di un altro usando numeri complessi, avrai piena attenzione dalla gestione.

Quando ero un nuovo sviluppatore in una squadra molto piccola, ho fatto un sacco di questo tipo di miglioramento nel mio tempo libero. Mi è piaciuto; Vorrei accedere e provare nuove interessanti tecniche mentre ero seduto in salotto con mia moglie durante la notte. Dato che sono diventato uno sviluppatore più anziano e poi il manager di una squadra più grande, il mio tempo libero è scomparso. Stavamo lavorando ore extra solo per ottenere le funzionalità e le correzioni critiche fatte. È diventato davvero difficile giustificare passare il tempo a nessuno in quel normale lavoro di pulizia, anche se tutti sapevamo quanto fosse importante.

I tuoi capi non hanno bisogno di una spiegazione di quanto sia importante, per mantenere bassi i costi di manutenzione, ridurre i costi di crescita futura, mantenere un team di sviluppo di talento impegnato, ecc. Se lo fanno, hai grossi problemi. Ciò di cui potrebbero aver bisogno, tuttavia, è un piano. Perché in questo momento sto immaginando che abbiano tutti i tipi di piani, orari, tabelle di marcia, promesse e pressioni sul lato "aggiungi funzionalità", che sono in competizione con il semplice pio desiderio e le richieste aperte dal team di sviluppatori.

Una cosa che potresti provare è fare un piano documentato. Verifica se è possibile legarlo alle versioni o uscire dai criteri per nuove funzionalità. Una richiesta di "passare un po 'di tempo a rifare il conteggio dei riferimenti" potrebbe essere difficile da approvare dal tuo capo, ma pianificare un blocco di tempo di 5 giorni da ora potrebbe essere più semplice. Fondamentalmente, tuttavia, si vede che le nuove funzionalità sono pianificate e pianificate, provare a imitarla o iniettare una porzione "sotto il cofano" in essa.

Inizia in piccolo chiedendo il 5% di tempo assegnato a quel tipo di materiale e poi gradualmente costruisci le tue priorità della roadmap tecnologica, e continua a collegare per giustificare il business case, il ROI, i livelli di rischio, ecc. su ciascuno di essi . Presto avrai anche un assaggio delle sfide dei tuoi capi, poiché troverai molte più idee fantastiche di quante ne hai il tempo di fare.

Buona fortuna!

Ecco perché la richiesta di conteggio automatico dei riferimenti è stata rifiutata:

1. Non è un miglioramento . Una volta che hai qualcosa di più grande del mondo ciao, qualsiasi cambiamento sta andando nella direzione sbagliata. Nessuna quantità di refactoring cambierà il fatto che se hai bisogno di fare cambiamenti, la direzione è sempre sbagliata. Il trucco è sapere quando i tuoi cambiamenti sono abbastanza significativi da valere ancora il rischio di causare nuovi problemi. La tua direzione ha chiaramente affermato che se gli utenti finali non riescono a vederlo, non ne vale la pena.
2. Il conteggio dei riferimenti è una funzionalità completamente pazza. Hai visto alcune grandi aziende famose implementare alcune funzionalità e immediatamente hai pensato che fosse necessaria la stessa funzione. Bene, è molto probabile che il tuo codice base sia completamente diverso da quello che Apple sta usando. Probabilmente il conteggio dei riferimenti non funzionerà, o è solo una perdita di tempo. Dovresti trovare un modo diverso che non richieda la diffusione delle primitive di conteggio dei riferimenti ovunque nel tuo codice. Probabilmente il tuo piano di risconto richiede migliaia di modifiche nella base di codice, molte di queste modifiche non sono necessarie. Basta perdere tempo e denaro.
3. Stai risolvendo il problema sbagliato. La gestione di solito sa che tipo di problemi ci sono nel sistema. Qualche problema di perdita di memoria irrilevante che la soluzione di refcounting sta risolvendo non è uno di questi. Concentrati sui problemi reali e non su alcuni problemi immaginari su come i computer gestiscono la memoria.
4. Ci vuole troppo tempo per implementarlo Apple è un'azienda leggermente più grande della tua squadra insignificante con pochi programmatori e alcuni gestori. Possono fare grandi cambiamenti semplicemente pagando il prezzo. Se ci vogliono pochi milioni per implementare qualcosa, sono le noccioline. Se le piccole aziende cercano di fare la stessa cosa, finiranno presto senza soldi. Lo sviluppo del software è già molto costoso; l'aggiunta di costi non necessari non aiuterà un po '. Una caratteristica irrilevante come la gestione della memoria sta per aprire le porte: dopo che l'hanno approvata, metà dei programmatori vuole che il proprio "miglioramento" venga implementato. È una storia infinita e la società potrebbe invece fare qualcosa di utile.

Ecco alcuni passaggi che puoi utilizzare per gestire il problema:

1. Elimina la funzione
2. Scopri qual è il vero problema
3. Inizia a fare qualcosa di utile
4. Pianifica attentamente come usi il tuo tempo
5. Scopri come i tuoi miglioramenti stanno portando soldi
6. Scegli solo le funzionalità che portano più denaro
7. Comprendi che l'aspetto della programmazione dello sviluppo del software è solo una piccola parte dell'intero sistema - i miglioramenti non valgono mai il tempo