"Finché funziona" è la norma? [chiuso]

Vedi la mia domanda più recente: la programmazione è una professione in una corsa verso il basso?

Il mio ultimo negozio non ha avuto un processo. Agile significa essenzialmente che non avevano alcun piano su come sviluppare o gestire i loro progetti. Significava "ehi, ecco un sacco di lavoro. Vai a farlo tra due settimane. Siamo veloci e agili".

Hanno rilasciato cose che sapevano avere problemi. A loro non importava come venivano scritte le cose. Non ci sono state recensioni di codice - nonostante ci siano diversi sviluppatori. Rilasciarono software che sapevano essere difettosi.

Nel mio lavoro precedente, le persone avevano l'atteggiamento fintanto che funziona, va bene. Quando ho chiesto una riscrittura di un codice che avevo scritto mentre stavamo essenzialmente esplorando le specifiche, hanno negato. Volevo riscrivere il codice perché il codice veniva ripetuto in più punti, non c'era incapsulamento e le persone impiegavano molto tempo per modificarlo.

Quindi, in sostanza, la mia impressione è questa: la programmazione si riduce a quanto segue:

1. Leggendo un libro sull'ultimo strumento / tecnologia
2. Combinando il codice in base a questo, evitando di scrivere alcun codice individuale perché la società non vuole "mantenere il codice personalizzato"
3. Mostrandolo e passando alla cosa successiva, "finché funziona".

Mi sono sempre detto che il prossimo lavoro avrò un negozio migliore. Non succede mai Se è così, allora mi sento bloccato. Le tecnologie cambiano sempre; se l'unico sviluppo professionale qui sta leggendo l'ultimo libro sulla tecnologia MS Press, che cosa hai costruito in 10 anni ma una conoscenza superficiale delle varie tecnologie? Sono preoccupato per:

1. Il modo migliore per avere standard professionali
2. Come sviluppare conoscenze ed esperienze significative in questa situazione

Ti sei imbattuto indirettamente su quello che penso sia l'aspetto chiave per essere un buon sviluppatore : trovare l'equilibrio tra " finché funziona " e un codice ben progettato ed elegante.

Proprio come in politica, è molto più facile puntare la tua posizione su un'estremità dello spettro rispetto a prendere una posizione sfumata nel mezzo. La maggior parte degli sviluppatori in cui mi imbatto rientra in una di due categorie: codificare hack da cowboy e astronauti dell'architettura. Cerco di trovare un equilibrio tra i due. Non è così facile come sembra.

Per rispondere più direttamente alla tua domanda, sì, penso che "finché funziona" è spesso la norma. Ma guardalo in un altro modo: sei in una posizione eccellente per educare i tuoi colleghi e provare a introdurre alcune pratiche migliori. Ma non andare all'estremo e ricorda perché lo stiamo facendo tutti: per risolvere i problemi dei nostri clienti.

>> Nel mio lavoro precedente, le persone avevano l'atteggiamento fintanto che funziona, va bene.

Forse sono una minoranza qui, ma ho lo stesso atteggiamento e credo fermamente che per riscrivere qualcosa ci dovrebbero essere prove chiare del perché ne abbiamo bisogno. E non intendo qualcosa del tipo "uf, non mi piace come è stato codificato" - ogni sviluppatore ha le sue preferenze sul codice. Dovrebbero esserci dei problemi con la parte che vogliamo riscrivere:

• Problemi di prestazioni
• Sono stati trovati più bug che in qualsiasi altra parte del sistema
• Gli sviluppatori trascorrono più tempo quando lavorano su questa parte
• eccetera.

Agile non è responsabile per qualsiasi umano che decida di rilasciare software difettoso; gli umani lo sono.

Detto questo, dai molta importanza alla qualità ed è buono. Sono sicuro che sei un perfezionista e sei preoccupato per il tuo valore se non riesci a raggiungere le ultime tecnologie.

Il problema è che il perfezionismo porta alla procrastinazione e la procrastinazione porta alla mediocrità .

Ecco perché le aziende daranno priorità a cose come il time to market e utilizzeranno l' agile per offrire valore rapidamente e ad un ritmo prevedibile.

Dal momento che non hai descritto la strategia aziendale della tua azienda, penso che dovresti iniziare facendo domande al riguardo ai tuoi dirigenti.

Con essere allineati sui loro obiettivi e (che ti ha assunto per aiutarli a raggiungerli), sarete in posizione migliore per capire come si potrebbe contribuire alla loro invece di concentrarsi sui vostri obiettivi propri e personali.

Sono sicuro che provando al understandloro valore, sarai in grado di condividere il tuo, e quello sarà l'inizio di una fruttuosa collaborazione.

E se scopri che non sanno cosa stanno facendo, l'unica opzione sarà quella di smettere .

Tutto dipende da cosa stai costruendo. Se stai costruendo un microsito che sarà online solo per un mese e hai nove giorni per costruirlo: allora sì, finché funzionerà sarà sufficiente.

Se stai scrivendo gli algoritmi fly-by-wire per il sistema FA-18, è meglio che sia costruito nel modo più perfetto possibile.

Come nel caso della maggior parte delle risposte tecnologiche ... dipende.

Dipende dalla compagnia. Tuttavia, molte aziende hanno una forte concorrenza e una forte pressione temporale. Questa è una ragione tipica. Un altro sarebbe un grande carico di lavoro, potenzialmente senza abbastanza personale. (Esistono alcune ottime ragioni per essere a corto di personale, che non sono necessariamente colpa dell'azienda.) Detto questo, alcune organizzazioni non sono riuscite a uscire da un sacchetto di carta bagnato.

Penso che la regola 80/20 si applichi qui. Fondamentalmente, devi sopportare l'80% schifoso e arrivare al 20%. Tuttavia, renditi conto che anche loro dovranno fare dei compromessi. Negli affari, di solito non importa che tu abbia assolutamente ragione. È importante che tu l'abbia in questo momento.

se l'unico sviluppo professionale qui sta leggendo l'ultimo libro sulla tecnologia MS Press, che cosa hai costruito in 10 anni ma una conoscenza superficiale delle varie tecnologie?

Sarebbe piuttosto schifoso ma potrebbero esserci stati alcuni fallimenti spettacolari da notare in quel decennio. Ho visto molti posti in cui posso ricordare cose piuttosto specifiche che mi piacevano lavorare lì o che non mi piacevano e quindi metterei in dubbio di averlo di nuovo nel mio nuovo posto di lavoro. A volte potrebbe esserci la nuova pratica da provare come se un'azienda provasse a implementare Scrum o ad adottare un approccio di Test-Driven Development che potrebbero essere opportunità ma non necessariamente vedere uno sviluppo professionale in quanto non è in un ambiente formale in classe.

Conosco vari luoghi in cui il "finché funziona" è comune insieme a varie strategie di codifica da cowboy. In un paio di start-up ho visto questo tipo di mentalità che può avere senso se la compagnia è così giovane che stanno ancora cercando di stanare l'idea di cosa stanno davvero cercando di fare. In altre società in cui ho lavorato c'è stato più processo e una maturità che può essere abbastanza buona, sebbene non necessariamente facile da trovare, temo. Alcuni posti hanno avuto alcuni processi che ho avuto modo di vedere e fare "Mi piace. Me lo ricorderò per le situazioni lavorative successive" e altri dove andrei "Non mi piace davvero. per cercare di evitarlo in futuro ".

Ho lavorato in un negozio come questo per un po 'proprio nel momento in cui li stava raggiungendo. C'erano applicazioni di due o tre anni con bug noti che non potevano letteralmente risolvere. Pensa a un ciclo lungo 4.000 righe con un calcolo continuo per larghezze e altezze del layout. Riparare un pezzo di codice per riparare un problema in un'istanza comporterebbe venti problemi altrove perché gli sviluppatori precedenti avevano problemi simili aiutati dalla banda regolando arbitrariamente i risultati dei calcoli con numeri magici. Il codice non può essere descritto come nient'altro che tossico.

Alla fine mi è stato consegnato un nuovo progetto che il mio capo mi ha detto che poteva usare questo codice esistente per gestire i layout. In qualche modo l'ho convinto a lasciarmi "alterare" così mi ha dato del tempo extra. Ho usato il tempo invece di scrivere una libreria ben progettata per aiutare con il layout. I bug di questo nuovo progetto mi hanno letteralmente impiegato 10 secondi per risolverlo. Potrei identificare i problemi prima ancora di guardare il codice per vedere cosa è andato storto.

Ho pensato che questo avrebbe comportato una svolta per il mio manager, ma tutto quello che ho avuto è stato una pacca sulla spalla e in sostanza mi ha detto che "Anche il tuo modo di lavorare credo."

Da allora ho iniziato a lavorare per un altro negozio e qui le cose vanno meglio. Il punto è che non puoi cambiare idea. Vai a lavorare altrove.

Ho ancora speranza, che in economia vi sia una sorta di processo evolutivo, che prima o poi mette fuori gioco tali società. Ma forse l'alto ritmo del progresso tecnologico produce troppe nuove nicchie, quindi anche i concorrenti deboli possono ancora trovare abbastanza "cibo".

Se vuoi aumentare le tue possibilità di lavorare in un buon posto, cerca un'azienda che ha un prodotto che vende a molti clienti invece di scrivere qualcosa di nuovo ogni poche settimane. Dovrebbe esserci più interesse ad avere una buona base di codice e ad essere in grado di aggiungere nuove funzionalità senza interrompere il codice esistente in ogni momento.

Mi ricorda il mio compagno di college. Stava frequentando un corso di progettazione VLSI e per i suoi primi compiti è venuto fuori un componente che era nell'ordine dei micrometri di larghezza e un chilometro di lunghezza. Le simulazioni sono passate perfettamente.

La sua risposta ai suoi critici fu: "Tutto quello che so è che la mia merda funziona".

Una norma abbastanza buona è il principio di Pareto

Ho esperienza in un progetto con regola 80-20 e ha funzionato molto bene. Penso che le risposte a questa domanda "Dove traccia la linea per il tuo perfezionismo" possono anche essere utili.

Il termine "principio di Pareto" può anche riferirsi all'efficienza di Pareto. Il principio di Pareto (noto anche come regola 80-20, la legge dei pochi vitali e il principio della scarsità dei fattori) afferma che, per molti eventi, circa l'80% degli effetti proviene dal 20% delle cause. Il pensatore della direzione aziendale Joseph M. Juran suggerì il principio e lo chiamò come l'economista italiano Vilfredo Pareto, il quale osservò nel 1906 che l'80% della terra in Italia era posseduta dal 20% della popolazione; ha sviluppato il principio osservando che il 20% dei baccelli del suo giardino conteneva l'80% dei piselli. È una regola empirica comune negli affari; ad es. "L'80% delle vendite proviene dal 20% dei clienti". Matematicamente, quando qualcosa è condiviso tra un gruppo sufficientemente ampio di partecipanti, ci deve essere un numero k compreso tra 50 e 100 in modo tale che "il k% è preso dal (100 - k)% dei partecipanti". Il numero k può variare da 50 (in caso di distribuzione equa, ovvero il 100% della popolazione ha quote uguali) a quasi 100 (quando un numero esiguo di partecipanti rappresenta quasi tutta la risorsa).Non c'è nulla di speciale sul numero dell'80% matematicamente, ma molti sistemi reali hanno k da qualche parte in questa regione di squilibrio intermedio nella distribuzione. Il principio di Pareto è solo tangenzialmente correlato all'efficienza di Pareto, introdotta anche dallo stesso economista. Pareto ha sviluppato entrambi i concetti nel contesto della distribuzione del reddito e della ricchezza tra la popolazione.

Link alla fonte

Quando ho chiesto una riscrittura di un codice che avevo scritto mentre stavamo essenzialmente esplorando le specifiche, hanno negato. Volevo riscrivere il codice perché il codice veniva ripetuto in più punti, non c'era incapsulamento e le persone impiegavano molto tempo per modificarlo.

Senza offesa, ma come manager ho letto quella dichiarazione da qualche parte sulla falsariga di:

"Quando ho chiesto di essere pagato due volte per riscrivere un codice che avevo già scritto, la mia azienda non voleva pagare. Volevo i soldi extra per ripulire il disordine che ho fatto quando l'ho scritto la prima volta, e il mio i colleghi erano arrabbiati con me per aver reso le loro vite difficili ".

Se è il tuo codice di cui ti lamenti - non hai molto su cui resistere.

AGGIORNARE

Capisco che questo POV è impopolare. Ma non penso sia affatto incongruo con le responsabilità e gli atteggiamenti di uno sviluppatore professionista.

Se scrivi codice pulito per cominciare (e ci sono una moltitudine di ragioni per farlo - indipendentemente dal fatto che pensi che il tuo codice vedrà l'uso della produzione o meno), allora avrai questo problema molto meno regolarmente.

Se includi codice pulito e tempo di refactoring nelle tue stime, avrai anche il programma per mantenere ordinato il codice. Se, a causa della pressione programmata, non si ottiene il tempo necessario, le stime future dovrebbero aumentare a seguito della gestione del debito tecnico sostenuto.

Ad un certo punto, le tue stime future (o le incertezze che circondano le tue stime) ti daranno la possibilità di discutere per una riscrittura (quando il tuo manager ti sta chiedendo di accelerare il processo). In caso contrario, accetta che l'azienda abbia accettato il tuo preventivo e preferisca pagare i costi in corso piuttosto che per una sostituzione. È una decisione puramente aziendale, non tecnica.

Ricorda, il tempo per negoziare i programmi è prima che tu abbia scritto il codice, non dopo. Dopo che il codice è stato scritto (e "funziona"), i clienti, i manager e i dirigenti non vogliono vedere un'altra fattura per "manutenzione" che si avvicina o supera il costo originale. Se ti senti così fortemente come pensi che dovrebbe fare l'azienda, sentiti libero di riscriverlo nel tuo tempo libero - questo è ciò che stai chiedendo all'azienda di fare.

Dal punto di vista del tuo manager, darti il ​​programma di riscrivere mette il suo asino sulla linea. Quando non riesci a consegnare, o aumentare la produttività di quanto dici, allora è lui a rimanere con la borsa. Rispetto al disagio relativamente minore di ascoltarti lamentarti, indovina quale preferirà.

Se questo è il tipo di lavoro che puoi ottenere, concentrati solo sulla scrittura di codice migliore ogni volta, piuttosto che tornare indietro e riscrivere il vecchio codice. Esiste ancora una gamma di qualità che puoi spostare nel regno dell'incollaggio di pacchetti di terze parti.

Se hai tempo e vuoi migliorare il codice di un componente esistente che gestisci, non puoi semplicemente farlo senza chiedere l'autorizzazione, purché ciò che fai funzioni? Fattorizza il tempo nelle tue stime per il prossimo progetto che utilizza il componente.

Per la programmazione di livello inferiore, se non riesci a ottenere la soddisfazione dell'apprendimento dal tuo lavoro, forse è tempo di guardare un progetto open source?

q303, ho trovato la tua domanda interessante e ho sentito che potresti trovare questa domanda dei programmatori degna di nota, su come convincere i manager a lasciare che gli sviluppatori affrontino il debito tecnico.

Penso in generale, sì, è la norma. Comprendi che un software funzionante ma non ottimale è molto meglio di un software non funzionante. C'è anche l'argomento secondo cui la definizione di "lavoro" potrebbe variare in base alla percezione e ai pregiudizi di ciascun individuo. Quando si implementa un nuovo sistema, c'è sempre qualcuno che dirà di ritenere che il vecchio sistema fosse migliore. E quando parli con uno sviluppatore, è probabile che sia riluttante ad ammettere di aver lavorato su un software scadente.