Mi spiace dirlo ma,

Non vorrai sentire questo, ma non è completamente sbagliato .

If you are doing work for hire for external companies as a consultant, and they are willing to accept the most slapped together thing you can do and don't complain, and are willing to come back over and over again for you to do more work, your boss is 100% correct when it comes to maximizing profits for your company.

Poi c'è YAGNI : se i progetti sono progetti singoli che non ti costeranno nulla da mantenere o riscrittura e tutto quel tempo in manutenzione e riscrittura è fatturabile, facendolo giusto la prima volta ti sta costando ancora più denaro. Quindi, il tuo capo è corretto al 100% di nuovo.

Se i tuoi clienti sono non che lamentano costi e mancanza di qualità, la qualità è non in questione per rendere felici i tuoi clienti. Sembra che i clienti siano contenti di merda, quindi venderli di più non è una decisione difficile.

Qualsiasi cosa tu faccia al di sopra e al di là di ciò che il cliente è contento è uno spreco di sforzi su tutte le parti: non lo apprezzeranno. Il tuo capo è corretto al 100% di nuovo.

Ricorda che la qualità è negli occhi di chi guarda. Se soddisfa le esigenze dei clienti, non si preoccupano del nastro adesivo e degli attaccapanni che lo fanno funzionare.

Ciò che apprezzi molto ha poco o nessun valore diretto per i tuoi clienti, dal momento che non gli interessa come il software fa quello che fa, solo che fa quello che vuole maggiormente.

Ogni pezzo di software alla fine degenera dall'entropia a un Big Ball of Mud . Applicazioni GUI, in particolare quelle per Windows scritte in alcuni aspetti dell'entropia VB più veloce a causa della cultura del set di strumenti.

Se ti fa sentire meglio, stai iniziando un po 'più vicino alla massima entropia rispetto alle altre persone.

Personalmente non definirei mai un precedente con risultati di qualità così bassa, ma di nuovo non andrei per il livello di corsa verso il basso dei clienti che la tua azienda sta cercando apparentemente di soddisfare.

La tua direzione ha deciso che questi sono i clienti che vogliono avere e non c'è bisogno di provare a up sell il cliente su software più costoso di qualità superiore se stanno bene come stanno le cose.

Non cambierai la gestione, solo i tuoi clienti lo faranno. Puoi ottenere clienti migliori o ottenere un lavoro migliore.

Sembra il mio vecchio lavoro

Questo accadeva sempre al mio vecchio lavoro. Sono d'accordo che le vendite guidano tutto. Il responsabile del negozio (Skill Set: 80% vendite 20% grafica) ha costantemente sottovalutato le caratteristiche richieste dai clienti. Un lavoro di 20 ore sarebbe stato venduto a un prezzo di 10 ore perché il cliente non era disposto a pagare di più o (io tendo a pensare) il direttore delle vendite non ha sottolineato abbastanza Il valore il cliente era ottenendo.

Il direttore delle vendite mostrava spesso le caratteristiche dei potenziali clienti e i widget che abbiamo costruito per clienti diversi. E naturalmente avrebbe sottovalutato questa caratteristica per il nuovo potenziale cliente perché non avevamo davvero bisogno di ricodificare la cosa ... tutto quello che dovevamo fare era copiare e incollare il codice da un altro sito web e plop in questo sito. L'avevamo già creato.

Dopo varie sessioni di "avanti e indietro" di "Perché non puoi farlo più velocemente ... lo hai già fatto per il cliente x". e "Ci sono volute solo 10 ore per il cliente e come mai ci sono volute 16 ore per il cliente z".

Abbiamo chiesto al commesso quale fosse l'obiettivo? Ha detto di vendere il maggior numero possibile di questi widget al prezzo più basso possibile.

Gli abbiamo detto che siamo un negozio di qualità e facciamo un lavoro di qualità. Gli abbiamo detto che abbassando il prezzo stava effettivamente diluendo il valore del nostro lavoro e così facendo, quando il cliente torna da noi per nuove funzionalità che non erano state precedentemente sviluppate (ovvero l'opzione di copiare e incollare dal sito x wasn ci sono) respingerebbero i prezzi e il responsabile delle vendite si piegherebbe sotto la pressione.

Abbiamo deciso di valutare i nostri widget ad un prezzo premium così com'è. Eventuali modifiche sarebbero extra. Abbiamo convinto il management che se avessi avuto il tempo di sviluppare questi widget in modo da poterli estrarre dalla nostra " Code Library " anziché da altri siti web, potremmo costruirli in un modo più generico in modo da poter letteralmente plopare li in un sito esistente in 2 ore e vengono pagati per 10 ore di tempo.

Ha iniziato a venderli "così come sono" con tariffe elevate per le modifiche e siamo stati in grado di crearli e farli lavorare in due ore. Abbiamo anche iniziato ad aggiungere questi widget a " Il nostro sito web " e abbiamo smesso di utilizzare gli altri siti Web dei clienti come strumenti di vendita. Utilizzeremmo solo i siti web di altri clienti per mostrare come personalizzare il widget " con un piccolo compenso " per agire come questo o quello.

Per dimostrare il nostro concetto, noi (gli sviluppatori) siamo rimasti in ritardo dopo il lavoro, alcune notti per costruire un widget generico inserito nella nostra libreria di codici. La vita è migliorata Le discussioni sono cambiate dal perché ci è voluto così tanto tempo per ... " Ehi, puoi rivendere questo cliente del widget x vuole? Se sì, quali caratteristiche vuoi che aggiungiamo al modello di base per aiutarti vendilo. "

Ho visto le aziende farlo. Finiscono con clienti arrabbiati. I clienti hanno l'abitudine di tornare e chiedere nuove funzionalità non appena l'app inizia a fare soldi per loro o è integrata nel flusso aziendale. Presto dovrai dire a quei clienti che non puoi aggiungere nuove funzionalità al casino che hai creato, perché non puoi più gestire il codice base. O ci vorrà molto più tempo.

I clienti (anche in una situazione concorrenziale l'uno con l'altro) tendono a parlare. O direttamente, dai dipendenti che cambiano le aziende o da riunioni casuali in occasione di eventi tipici della loro linea di business (conferenze, mostre). Troverai presto difficile acquisire nuovi clienti se la tua azienda ha una cattiva reputazione.

Inoltre: la codifica di bassa qualità funziona solo (se non lo è) se limiti la tua azienda a progetti molto piccoli. Qualunque cosa più grande o più complessa perderà il tempo (e quello per soldi) istantaneamente, anche all'interno del primo ciclo di vita del progetto, semplicemente spendendo più tempo di debug del previsto.

Insegnagli informazioni sul debito tecnico

Quello che devi fare è fargli comprendere le conseguenze delle scelte che fa. Veloce e sporco può andare bene a volte perché puoi fare le cose più velocemente, ma ha conseguenze a lungo termine.

Se per esempio il progetto non è mai stato concepito per avere una base di codice estesa, veloce e sporco potrebbe essere il modo perfettamente corretto di gestire quel progetto.

Ward Cunningham ha trovato la brillante metafora, "Debito tecnico". Proprio come potresti prendere un prestito in banca per ottenere qualcosa di più veloce (invece di risparmiare), devi pagare di più a lungo termine perché devi pagare gli interessi. Questa può essere una buona cosa, se il valore di ottenere la tua "cosa" più veloce supera il costo di interesse.

Le soluzioni rapide e sporche sono come prestiti in banca. E ancora, se il valore di ottenere una funzionalità prima supera il costo di ripulire in seguito, quindi l'assunzione del prestito potrebbe essere l'approccio corretto.

Ma se prendi sempre più prestiti in banca, alla fine paghi tutto il tuo reddito in interessi. Lo stesso vale per il debito tecnico. Se hai fatto troppe soluzioni rapide e sporche, il tuo debito tecnico sarà così alto che i tuoi progressi si fermeranno.

Ho visto accadere questo. In un progetto su cui ho lavorato, il debito tecnico è stato così severo che non abbiamo seriamente avuto progressi per 3 mesi, solo cercando di correggere bug, che hanno introdotto nuovi bug, ecc.

Se riesci a fargli comprendere a fondo il concetto di debito tecnico, allora dovrebbe essere in grado di prendere le decisioni giuste (buona fortuna, è un duro). Nota che la soluzione corretta occasionalmente significa anche rapida e sporca.

Un'ultima cosa che potresti sottolineare è che gli sviluppatori sono più produttivi se sono altamente motivati;)

Il costo della manutenzione è spesso molto più elevato, e spesso la maggior parte del costo, di un software.

Se si programma veloce e sporco, la manutenzione sarà di un ordine di grandezza più difficile, e anche il costo è troppo.

Se costruisci tutto il tuo software in modo rapido e sporco, sarà schifoso e buggato e i tuoi clienti se ne accorgeranno. A lungo termine, se i tuoi prodotti continuano a essere schifosi e infestati, li perderai. I clienti vorranno pagare un po 'di più il tuo concorrente per un prodotto di buona qualità rispetto ai tuoi bug.

Il tuo capo non lo capisce?

In tutti i casi tranne i più rari, non puoi convincere qualcuno che è incredibilmente miope che più a lungo è quasi sempre meglio nella nostra professione. Ci dispiace, ma questa è la verità; le persone miopi sacrificheranno tutto sulla strada per raccogliere i benefici ora, e quasi sempre soffriranno alla fine.

A volte la soluzione corretta è per cambiare posizione in un luogo in cui le persone sono abbastanza intelligenti da comprendere i benefici della qualità e non sono miopi.

Nota: questa risposta prende una strategia di comunicazione aziendale che cerca di usare la ragione per assicurarsi che tutti ottengano ciò che vogliono. Se il problema è semplicemente che fare ingegneria di bassa qualità sta indebolendo la tua voglia di vivere o che il tuo capo è un autista di schiavi e sembra non esserci una fine in vista, potrebbe essere il momento di cambiare scenario.

Non stai parlando la lingua del tuo capo. Parte del tuo lavoro consiste nel dare le informazioni al tuo capo in modo che possa prendere decisioni, e devi cambiare la tua strategia di dare informazioni. Stai parlando in ingegneria, e ciò di cui ha bisogno è rischio, costo, investimento e rendimento. Devi anche essere un po 'difensivo e assicurarti che ci sia una buona registrazione di cosa lo informi di

Ci sono due parti:

Il primo è la comunicazione della tua stima e dell'idea che non sia un obiettivo o un piano. Potrei scrivere volumi qui, ma fondamentalmente sarebbe una copia di tutto ciò che c'è nella Stima del software: Demistificare l'arte nera ", un libro per il quale dovresti correre, non camminare, nel tuo bookstore. Fai attenzione a distinguere tra stime, obiettivi e impegni, e assicurati di fare una stima reale prima di impegnarti in qualcosa!

Il secondo è la comunicazione dei rischi reali a cui il tuo capo sarebbe interessato. In parole povere, questo significa che devi dire al tuo capo che l'implementazione che potrebbe essere completata in 1,5 giorni soddisferà i requisiti di base ma sarà aumentare significativamente il rischio che i cambiamenti futuri e le funzionalità richiederanno molto più tempo di quanto sembra abbiano bisogno. Se lui chiede perché, usa l'analogia di costruzione della casa: se il tuo software è una casa, ogni cambiamento è un nuovo elemento di arredo, e ogni funzionalità è un nuovo piano. Se non hai una base solida e rimodelli / ristrutturazioni un po 'ogni volta che fai qualcosa, alla fine ti troverai nella situazione in cui sarà necessaria una ristrutturazione importante solo per sostenere il peso e le dimensioni di un nuovo trattamento per finestre, e l'intera casa dovrà essere ricostruita se vogliono supportare quattro nuovi piani e un mazzo.

Questo rimette la palla nel campo del tuo capo: gli hai dato delle informazioni e lui deve decidere. Avrà bisogno di pensare se ci saranno o meno cambiamenti futuri e se vorrà o meno ignorare la possibilità. Da lì, se è deciso che la via da seguire è quella veloce e di bassa qualità, assicurati di ricordare (con tatto) i promemoria di questo simbolo in praticamente ogni pezzo di comunicazione e documentazione che puoi. Invia una email di follow-up che confermi la decisione e i rischi che hai comunicato, inviandola alla scrittura. Prendi nota della strategia di ingegneria e dei rischi nelle tue specifiche.

Quando verrà il giorno in cui il cliente vuole una piscina inserita al 50 ° piano, e vedi che gli ultimi 20 piani sono stati costruiti con bastoni e sabbia, assicurati che la stima del grasso che produci sia tecnicamente giustificabile e preparatevi a distribuire le scartoffie delle fatture a basso costo di acquisto per illustrare il motivo per cui costerà tanto.

Se hai davvero fatto tutti questi argomenti e lui ancora li ha spazzati via, allora è un tuo dovere da professionista sollevare questa preoccupazione per un'istanza superiore. Sì, questo significa andare oltre la sua testa. Il motivo è semplicemente che il tuo capo è un pericolo per l'azienda.

La mia esperienza con questi ragazzi è che alla fine faranno fallire la tua organizzazione o almeno la mediocrità. Il tuo prodotto farà schifo e i tuoi clienti ti lasceranno.

Per la cronaca: presumo che il core business delle organizzazioni sia lo sviluppo del software e che il prodotto sia importante e non una cosa da buttare via.

Sì, possiamo hackerarlo insieme oggi.

Se lo facciamo in questo modo, avrà più bug della media e arretrerà seriamente lo sviluppo futuro. Hacking questo insieme è davvero qualcosa che possiamo fare una o due volte. Pensaci come un raschietto per il cielo, potremmo avere già una bella base e abbiamo 10 piani che sono davvero molto belli, se vuoi, possiamo velocemente sistemare insieme alcune tende e scatole sull'11 ° piano, magari anche costruire un 12 ° piano fuori da tende e scatole, ma sei fregato per andare oltre. Dobbiamo spostare tutti fuori da questi due piani, installarli, rimodellare tutto e ricostruirlo di nuovo solo per ottenere il 13 ° piano.

Se proviamo a costruire un tredicesimo piano di scatole e tende, potremmo crollare tre piani in qualsiasi momento casuale, e ci potrebbero volerci mesi solo per ottenere i blocchi jenga e il duplo super incollato nei punti giusti.

Questo è accettabile per te?

W. Edwards Deming è meglio conosciuto per il suo lavoro nella ricostruzione della produzione giapponese dopo la seconda guerra mondiale. Spesso trascurato è il fatto che il suo lavoro è in realtà più sulla gestione che sulla produzione. In effetti, una parte importante del suo libro Out of the Crisis riguarda il miglioramento della qualità nelle organizzazioni di servizi. I suoi esempi di organizzazioni di servizi includono software, banche, assicurazioni e chiese.

Deming argomenta - con molte prove del mondo reale che sostengono che l'aumento della qualità aumenta il profitto.

È possibile analizzare lo sviluppo del software come un processo aziendale. Come la produzione, produce prodotti intenzionali, non intenzionali, diretti e indiretti.

I prodotti diretti intenzionali di produzione e programmazione includono rubinetti e codice sorgente. I prodotti indiretti intenzionali includono il debito e il reddito.

I prodotti involontari dei processi di produzione includono rubinetti che hanno difetti di fabbricazione, incendi accidentali, ferite, un elevato ricambio del personale e furto dei dipendenti. I prodotti non intenzionali dei processi di programmazione includono bug, difficoltà di manutenzione, difficoltà di scalabilità, problemi di sicurezza, elevato turnover del personale e furto dei dipendenti.

Ognuno di questi "prodotti" è soggetto a variazioni, analisi statistiche e miglioramento dei processi.

Nel tuo caso, probabilmente dovrai enumerare e quantificare i prodotti non intenzionali del tuo sviluppo software e dei processi di gestione del progetto.

Deming è uno dei motivi principali per cui il Giappone è una potenza mondiale nella produzione. Il Premio Deming è intitolato a lui.

Questo può sembrare ovvio, ma penso che tu abbia bisogno di trovare una via di mezzo. Non perdere la padronanza del tuo capo di mano. Il tuo punto di vista su di esso è probabilmente estraneo a lui come a te.

O estremo non è ovviamente un bene per nessuno, quindi prova a negoziare una via di mezzo.

Non penso sia possibile. Diverse aziende hanno culture diverse e se la cultura della tua azienda attuale (rapida e sporca) non ti soddisfa, allora penso che dovresti andare avanti. Alcune altre società hanno una visione opposta e lì lavorerai con persone che la pensano come te.

Non voglio davvero entrare nella discussione su quale tipo di cultura sia migliore (vedi gli altri post se sei interessato), tutto ciò che sto dicendo che sarà utile per la tua salute mentale se lavori in un'azienda con lo stesso approccio.

Sono passato a tutte le domande e ho visto che nessuno è entrato nella prospettiva della sicurezza ...

Sì, altri hanno menzionato il tempo di debug, ma in questo caso il debug è fatto solo al livello di "hey finalmente funziona"

Nei miei progetti (piccoli e / o grandi) tengo un alto livello di attenzione agli exploit e ai possibili buchi di sicurezza.

Considerare questi aspetti e testarli richiede una notevole quantità di tempo, ma almeno in questo modo non mi accuseranno di non fare il meglio che potrei quando succede qualcosa di brutto.

Scommetto che quando stai andando veloce e sporco dimentichi di disinfettare alcune variabili, dimentica di fare alcuni controlli nelle funzioni e quindi rendere il tuo progetto un buon punto di partenza per gli hacker.

Quando il mio capo chiede perché qualcosa mi ha preso così tanto tempo, gli mostro tutti i controlli di sicurezza e funzione che ho creato per prevenire cose come l'iniezione, l'inclusione, i loop infiniti e persino le misure di sicurezza per quando qualcosa viene hackerato fa danni minimi

Fare cose veloci e sporche può rallentare anche prima di pranzo. Molto spesso comincerà a far male anche prima che la tua funzionalità sia abbastanza completa da provare a farla accettare da un cliente.

Forse puoi provare la metafora del debito tecnico, l'onere del pagamento degli interessi sarà più grande del reddito dopo un certo punto.

Guidare verso una riscrittura è anche un'opportunità per i tuoi clienti di provare una società di sviluppo diversa (se vogliamo ripartire da zero potrebbero anche).

Se non hai altri datori di lavoro nella tua zona, potrebbero esserci anche più clienti da consumare. Quindi in pratica il tuo capo può continuare a fare quello che sta facendo, nessuna competizione chi fa di meglio. Forse iniziare la propria attività? ; -)

In alternativa potresti semplicemente dirgli che fai sempre cose 'veloci e sporche' e fai solo le tue cose.

Getta la matematica contro di lui. Sfortunatamente non ho i libri in mano per fornire citazioni (speriamo che qualcuno possa darmi una mano), ma uno o entrambi i Pragmatic Programmer e Code Complete 2 hanno una sezione che fa riferimento a studi che mostrano l'impatto sul costo di fare le cose velocemente 'N' sporco, contro il tempo necessario per risolverlo più tardi. Altri poster hanno fornito numerosi argomenti, ma a seconda del comportamento del tuo capo, egli potrebbe rispondere molto meglio al supporto degli studi esistenti. Potrebbe pensare che tu stia solo blaterando per tamponare il tuo tempo e alleggerire il tuo carico di lavoro. Mostrargli che si tratta di un fatto accettato dal settore, al contrario della tua opinione, potrebbe essere il biglietto.

Sono in qualche modo in una situazione simile a te. Lavoro per un'azienda di servizi, quindi scrivo applicazioni personalizzate per diversi clienti. Le persone incaricate di fornire l'applicazione (come project manager, project executives, ecc.) Non si preoccupano molto della qualità del codice (anche se dicono che lo fanno), tutto ciò che interessa è consegnare materiale in tempo in modo che possano massimizzare profitto. Mi viene chiesto costantemente di scrivere funzioni entro breve tempo.

Una tecnica che ho usato per mantenere la qualità del codice e rispettare la scadenza è il refactoring continuo. Se mi viene chiesto di scrivere la feature A in 1 giorno, che in realtà richiederà da 3 a 5 giorni per scrivere con alta qualità, farò solo il modo veloce e sporco e fornirò. Ma mentre faccio il modo rapido e sporco tengo le note sull'area che possono / dovrebbero essere migliorate. Poi più avanti nel ciclo di sviluppo troverò pezzi di frammenti temporali qua e là per rifattorizzare il mio codice nella caratteristica A.

All'inizio, è stata un'esperienza dolorosa rifattorare il mio codice veloce e sporco; Ricordo alcuni casi in cui riscrivo quasi completamente una funzione durante il refactoring. Ma mentre eseguivo sempre più refactoring, il mio codice veloce e sporco ha iniziato a non essere così sporco. Ho iniziato a sviluppare un migliore senso naturale del design modulare, in modo che i codici che scrivo diventano sempre più modulari anche se sono in modalità rapida e sporca.

Non è sbagliato pensare che la qualità del codice non abbia importanza, perché a molte persone in realtà non importa. Ti piace davvero la qualità del design del circuito all'interno della tua TV SONY a patto che mostri una bella immagine HD e funzioni per 5 ~ 10 anni?

Tuttavia, come sviluppatore, dovresti davvero preoccuparti della qualità del codice perché ne conosci il vantaggio. È improbabile che il tuo capo cambi idea sulla qualità del codice, a meno che non provi delle crisi in cui la qualità del codice salva la sua giornata o quando vede personalmente la correlazione tra profitto e qualità del codice.

Solo a causa della mancanza di conoscenza del proprio capo nella qualità del codice, non significa che si dovrebbe compromettere la qualità del codice (tuttavia, è comunque una buona idea mantenere aperto il canale di comunicazione con il proprio capo sulla qualità del codice). Cerca di trovare il punto di equilibrio tra la qualità del codice e il programma di sviluppo. Non è possibile scrivere un codice di buona qualità per l'orario dato non significa che non si può migliorare la qualità negli orari futuri giusto?

Ho una strong sensazione che non c'è nulla che tu possa dire in questo caso. Ma alcuni punti che vorrei richiamare:

Problemi di risoluzione più lunghi

Quando copi e incolli il codice tutto il posto, quando trovi un bug in quel codice ci vorrà più tempo per sistemare e ci vorrà più tempo per testare. Così sprecherai ore extra nella fase di supporto (come immagino tu non abbia una fase di test integrata con una mentalità 'portalo fuori dalla porta') .

L'aggiunta di una nuova funzione richiede più tempo

L'aggiunta di una nuova funzione nel codice spaghetti richiede molto più tempo. E poiché si tratta di un pasticcio di copia e incolla, devi modificare il codice in molti punti. Questo a sua volta creerà bug o funzionalità inattese in vari luoghi. Quindi, dovrai sprecare ore extra nella fase di supporto.

Scompare gli elementi dell'interfaccia utente e la terminologia per i nuovi client

La società a cui sto lavorando in questo momento il loro client web è nata come copia e incolla di codice spaghetti. Prima di iniziare ci sono volute 2 settimane per dare una skin al client web per un nuovo cliente.

Dopo più di alcune lunghe sere, ora ci vuole un pomeriggio. Sto ancora lavorando e modificandolo in modo che ci vorrà meno tempo.

Se il tuo capo desidera realizzare un prodotto che sia facile da vendere, fa diversi clienti, ha bisogno di investire il tempo per assicurarti di non sprecare tempo a spellare il tuo prodotto quando potresti venderle nuove funzionalità.

Sarà difficile, ma devi far capire al tuo capo che, a meno che tu non spenda a volte per assicurarti che sia fatto bene, perderai molte più ore in futuro con i bug, e in realtà impiegheresti più tempo per preparare il prodotto per un nuovo cliente in futuro.

Tutto quello che gli interessa è la linea di fondo, quindi devi fargli capire che la codifica in questo modo non la aiuterà e lo ostacolerà solo.

La migliore risposta possibile sarebbe dall'approccio Agile:

rilascio anticipato, rilascio frequente

Il Rilascio anticipato è positivo per la tua azienda perché inizi a essere pagato in anticipo. Il primo punto di rilascio è quando il tuo prodotto ha abbastanza funzionalità in modo che possa essere utilizzato almeno in qualche aspetto. Quindi aggiunge valore alla società cliente. Ecco perché è intelligente sviluppare modulo per modulo.

Rilasciare spesso è positivo per il tuo cliente perché otterrà prima ciò di cui ha bisogno . Non ho voluto scrivere intenzionalmente, perché il risultato finale differisce spesso dall'idea all'inizio.

Se non altro, questo soddisferà di più i tuoi clienti dal momento che si sentiranno più coinvolti e seguirai passo dopo passo il tuo prodotto.

Una cosa che ho scoperto è che una base di codice pulita può supportare una pelle di cruft senza troppi problemi. Se hai un CMS di base che personalizzi per persone diverse, qualsiasi problema nel core ti perseguiterà. Ma un plugin specifico per il cliente, scarsamente testato e mal fatto, può cavarsela senza troppi problemi.

Nel tuo caso, sembra che tu non abbia costruito il nucleo pulito, quindi sei piuttosto fottuto. Tuttavia, dovresti preferire il tempo per migliorare il tuo codice base, che dovrebbe avvantaggiare i tuoi clienti esistenti e accelerare lo sviluppo futuro.

Digli che può risparmiare denaro. Roger Pressman ha scritto che spendi il 20% dei tuoi soldi per costruire il software e l'80% per mantenerlo.

Se hai bisogno di costruire rapidamente per non perdere un contratto, fallo, ma in un ramo alternativo. Dopo, fallo di nuovo nel modo giusto.

Voglio tagliarlo brevemente

• Se il codice verrà mantenuto per lungo tempo, la qualità del codice è un problema.
• Per il codice di prototipazione, non è davvero un grosso problema. Di solito le persone buttano via questo codice.
• La qualità del codice scritto da un programmatore viene raggiunta attraverso la pratica. Come il modo in cui otteniamo esperienza, otterremo una buona velocità vs. Rapporto qualità Ho visto programmatori che prima chiedevano: "Dammi 3 giorni per aggiornare con lo standard di codifica". Questa è una merda completa. Perché si stanno prendendo cura mentre scrivono il codice stesso? Una volta che il test è terminato, e andare agli aggiornamenti standard potrebbe portare a problemi.
• Anche noi non progettiamo ufficialmente qualcosa, avremo in mente qualche tipo di design prima di scrivere il codice. In queste situazioni, la qualità si basa sui pensieri degli sviluppatori.
• I manager sono noti per orari, sforzi e budget. Se puoi fare qualcosa in un determinato limite, accettalo. Altrimenti digli cosa puoi fare entro il periodo indicato. O dare suggerimenti sulle persone che potrebbero essere in grado di contribuire bene al particolare problema

Come ottenere il meglio da entrambi i mondi? Utilizzare le fabbriche del software. Spendi la tua energia cerebrale per creare strumenti in grado di fare cose che possono essere ripetute. Ad esempio, guarda Ruby on Rails o se sei un utente .NET, guarda ASP.NET MVC combinato con un pacchetto nuget chiamato MVCScaffolding . Attualmente sto scavando in questo strumento e personalizzandolo per generare ciò di cui ho bisogno per il mio flusso di lavoro. La creazione di un semplice sito Web CRUD supportato da database è un semplice controller di Scaffold. Ora posso passare il mio tempo a personalizzare l'interfaccia utente e perfezionare la logica di business che guida l'app.

Come ho detto, è possibile personalizzare lo strumento (ad esempio, ho modificato il modello di controller predefinito per utilizzare le utilità interne IRepository / IUnitOfWork che mi consentono di passare facilmente tra gli archivi di dati EF e InMemory per il test). Per la maggior parte, la maggior parte del mio sviluppo viene speso affinando il modello a oggetti per supportare gli scenari di utilizzo del business.

Vorrei presentare il tuo capo a LulzSec. Potrebbero chiedere di differire che la qualità del codice nelle app Web non ha importanza ...

LIE : quando il tuo capo chiede quanto velocemente "veloce e sporco", digli "che era la stima rapida e sporca".

Molte delle risposte su questo thread sono basate sul ragionamento. L'ultimo difetto in questo approccio è che stai parlando con un uomo d'affari .

Il problema è che il tuo capo - come con la maggior parte dei leader aziendali negli ambienti delle PMI - non è realmente interessato alla visione a lungo termine. Indipendentemente dal modo di ragionare che porti, se suggerisci anche che c'è un'opzione più veloce, prenderà questa opzione il 99% delle volte. Ai boss piace scegliere figure arbitrarie che supportino il tono di vendita, e poi le squadre di sviluppo assorbire il danno negli straordinari e bassa retribuzione. I clienti hanno aspettative irragionevoli a causa dell'ignoranza e i cattivi capi sono troppo disposti a soddisfarli.

Chi sta facendo il profitto? Che cosa sta facendo questo processo per la tua carriera a lungo termine? Svaluta il lavoro e in definitiva il valore della tua abilità. Anche se sei un appaltatore a breve termine, pensa all'effetto a lungo termine sul settore della riduzione del costo per un lavoro ragionevole.

Con ogni mezzo, taglia il tuo indumento in base al tuo vestito, ma "veloce e sporco" è non un'opzione. Se il client richiede una funzionalità, questa funzione richiede un livello base di tempo per essere completata con uno standard ragionevole . Non fornire tempi per qualcosa di meno di un'implementazione ragionevole.