Quali sono le peggiori false economie nello sviluppo del software? [chiuso]

126

Quali sono le peggiori false economie (ovvero i modi per risparmiare denaro che alla fine costano più di quanto risparmiano) prevalenti nel settore del software e come le combatti?

programming-practices project-management

— Jon Hopkins
fonte

2

:( Ho visto molti di questi troppo spesso.

— Tony,

3

relativi programmers.stackexchange.com/questions/18585/…

— cmcginty

@Casey: è un po 'correlato, ma non del tutto. Il link che hai dato tratta direttamente del denaro, mentre le risposte a questa domanda qui riguardano anche il denaro e le credenze. Esempio, vedi la mia risposta: programmers.stackexchange.com/questions/19573/…

— Gan

Hai appena visitato la mia compagnia ... non importa; P

— pramodc84

1

@Mark - sembra una buona domanda, provaci. Tuttavia, alcuni dettagli potrebbero essere buoni.

— Jon Hopkins,

182

Debito tecnico

vale a dire "Fallo velocemente, rifatteremo più tardi". In primo luogo perché non ho ancora visto qualcuno impegnarsi in questo comportamento in realtà refactoring più tardi. In secondo luogo perché fare le cose nel modo più rapido, invece che nel modo giusto, rende più difficile l'aggiunta di funzionalità future o la risoluzione di bug futuri in modo da perdere tempo a lungo termine.

Purtroppo, molti pensano ancora che salvi i cicli degli sviluppatori per far loro fare qualcosa in fretta. Immagino sia possibile, ma devo ancora vederlo in pratica.

— Inaimathi
fonte

2

Non riesco a contare il numero di volte in cui il management ha interrotto gli sviluppatori (da 2 a 3) per un giorno, quindi uno specialista della distribuzione ha risolto in modo anomalo qualcosa (e lo ha fatto numerose volte nel corso del ciclo di vita del prodotto) invece di spendere 2- 4 giorni per farlo bene. Bella risposta.

— DevSolo,

4

Se il tempo necessario per la correzione è misurabile in dollari, ad esempio la correzione di un bug nel sistema di scambio di azioni, la decisione della direzione si orienterà verso una riduzione dei costi. Ho scoperto che la proposta di "rattopparlo ora per mantenerlo attivo mentre determiniamo la correzione corretta per assicurarci che ciò non accada mai più" soddisfi l'urgenza basata sui costi e ottenga anche il risultato giusto, ma a volte devi lottare per questo .

— JBR Wilkinson,

9

Abbiamo tutto il codice con commenti come "Questo è un trucco, sostituisci dopo la demo" che è stato nella base per andare avanti da 3 a 5 anni. Nessuno ricorda nemmeno che è stato fatto a questo punto, quindi nessuno lo trova fino a quando qualcuno (io) non corregge i bug e lo attraversa. Inutile dire che questa lezione oggettiva mi ha insegnato molto bene a farlo bene la prima volta se sono in grado di farlo.

— CodexArcanum,

22

E onestamente, sono continuamente scioccato dal numero di volte che non risparmia nemmeno il tempo a breve termine!

— PeterAllenWebb,

6

@Jorg - Huh? "Il debito tecnico e il debito progettuale sono sinonimo di metafore neologiche che si riferiscono alle eventuali conseguenze dell'architettura del software slapdash e dello sviluppo affrettato del software." en.wikipedia.org/wiki/Technical_debt Questo è esattamente ciò a cui mi riferisco. Un titolo più specifico sarebbe forse stato "Incorrere in debito tecnico senza intenzione di ripagarlo", ma molte persone in questa situazione si dicono che in realtà intendono ripagare (ma non lo fanno) e volevo un titolo incisivo da inserire testo in grassetto in alto. "Debito tecnico" sembrava essere un riassunto abbastanza buono.

— Inaimathi,

163

Assumere 2 sviluppatori economici invece di 1 davvero fantastici. (per lo stesso prezzo)

— user2567
fonte

9

Questo almeno sembra avere una base nella realtà; tieni presente che le persone non tecniche non possono dire chi sono i grandi sviluppatori (quindi è molto probabile che paghino due volte tanto a un idiota di consulenza casuale che a una vera superstar).

— Inaimathi,

112

O purtroppo, ne

— sto

4

... o assumere un guru in cui due manichini farebbero l'1.5 di quello che fa il guru per 1.0 del salario del guru: /

— bobah

14

Non ottieni il 75% di un guru da un manichino , e qualsiasi programmatore veramente bravo farà ciò che è necessario senza esserne snob.

— Peter Boughton,

8

I programmatori 10x o 100x hanno un rapporto qualità-prezzo incredibilmente incredibile; vengono pagati solo 1,5 forse 2 volte. Come dice Michael Lopp (Rands in Repose), se ne assumi uno solo in tutta la tua carriera, è una vittoria netta.

— Tim Williscroft,

85

Il mio esempio sarebbe l'esatto contrario dell'esempio di NimChimpsky , vale a dire:

Cercando di sviluppare internamente qualcosa che può essere acquistato immediatamente.

Normalmente ciò accade a causa di un fallimento nel controllare effettivamente il mercato per vedere se esiste già qualcosa che risolverà il problema. Ciò può essere aggravato dagli sviluppatori a cui piace "immergersi" nel codice prima di fare qualsiasi ricerca e dai project manager che non riescono a tenere conto di quel tempo = denaro.

Uno degli esempi più comuni che ho visto nel mio campo, lo sviluppo web, sono le aziende che cercano di sviluppare un sistema CMS interno. Questi inevitabilmente iniziano in piccolo, ma presto si gonfiano e sfuggono al controllo man mano che le funzionalità sono fissate, mentre per tutto il tempo ci sono molti prodotti e framework gratuiti là fuori che sarebbero molto più adatti.

— Dan Diplo
fonte

17

Solo perché può essere, non significa che dovrebbe essere. Un CMS di base, beh sì, perché reinventare la ruota. Ma quando inizi a parlare di sistemi su larga scala e di modellare complessi processi aziendali - perché provare a montare una spina rotonda in un foro quadrato? Soprattutto se disponi di sviluppatori e competenze esistenti in casa.

— NimChimpsky,

9

@NimChimpsky - Penso che ci siano esempi validi di entrambi. Ho sicuramente visto persone rompere i loro processi di business e perdere i vantaggi che avevano provando ad adattarli al software standard, ma ho anche visto sviluppatori che soffrono di "non inventato qui" codice cose che avrebbero potuto scaricare perché era più interessante per loro.

— Jon Hopkins,

3

@NimChimpsky Se le specifiche richiedono uno sviluppo su misura, allora va bene - ci tiene in posti di lavoro :) Il problema si presenta quando le persone non controllano prima se c'è qualcosa di già sviluppato che si adatta al conto e si tuffano direttamente nello sviluppo. Una piccola ricerca può fare molto!

— Dan Diplo,

6

Perché reinventare la ruota? Perché sei un ingegnere delle ruote. O perché la tua ruota è migliore della ruota del prossimo. O perché la ruota non si adatta. Vedi: mostlymaths.net/2010/03/…

— Derek,

2

Dove lavoro quasi tutto OTS poteva essere acquistato - e quasi tutto è reinventato in-house, perché secondo i nostri leader Fearless (tm) "il nostro ambiente è così complessa che nulla sul mercato potrebbe eventualmente gestirlo". Pfeh! Ma che hey - paga le bollette. Ci è stato detto ieri che un importante componente del nostro software verrà riscritto il prossimo anno - CON UN'INTERFACCIA GRAFICA! Ooooooh-aaaaaaah! Sono tutto un twitter ... (<pheh!>)

— Bob Jarvis,

73

Nessuna risorsa dedicata per la gestione del progetto

Ho sperimentato diverse volte quando alcuni programmatori erano appaltati e qualcuno che ha già un lavoro diurno impegnativo avrebbe dovuto gestire il progetto, ma in realtà era troppo impegnato con altre attività, quindi il progetto non ha mai acquisito slancio. I programmatori realizzarono "prototipi" e roba del genere, ma senza una guida, gran parte di essa correva in cerchio per sembrare occupata.

Attrezzatura difettosa per i nuovi programmatori

Una volta ho sperimentato un'azienda in cui la politica era "i nuovi programmatori devono lavorare su un PC molto vecchio con un piccolo schermo fino a quando non dimostrano che sono degni". Nessuna sorpresa che una tale politica abbia causato una selezione negativa che ha spinto le persone buone che hanno sempre la scelta di lavorare in un ambiente più sano.

— user281377
fonte

19

+1. Non fornire buone attrezzature per i tuoi dipendenti è "destinato a fallire" scritto dappertutto.

— Terence Ponce,

3

+1. Tuttavia, tenere presente quanto segue: in molte aziende, i budget hardware rientrano nelle infrastrutture e sono separati dai budget di sviluppo. Il gestore dell'infrastruttura non subirà un colpo contro il suo budget per alleviare il budget del gestore dello sviluppo. Ho visto questa brutta politica recitare più volte.

— Fil

3

Che ne dite di apparecchiature difettose per TUTTI i programmatori? Il mio ex datore di lavoro ci ha pagato i salari della Silicon Valley per scrivere codice sui desktop che era stato mediocre cinque anni prima. A causa delle scadenze scadute, un anno fa hanno licenziato metà del personale e la maggior parte degli altri a luglio - ma ragazzo, hanno risparmiato denaro sulle attrezzature!

— Bob Murphy,

1

Kaz: Ogni sviluppatore dovrebbe avere una macchina adeguata. Se acquistare nuovo hardware significa che il PC del nuovo sviluppatore è un po 'migliore rispetto a quello di altri sviluppatori, nel peggiore dei casi si hanno macchine di scambio se si tratta di un tipo di gente che conta le dimensioni del cazzo. Le persone normali semplicemente non si prenderanno cura finché avranno l'equipaggiamento che le consente di lavorare in modo efficiente. Nel posto in cui sto attualmente lavorando, ho un PC più recente (probabilmente più veloce) di quello che mi ha assunto. Le persone che sono venute dopo di me hanno PC ancora più recenti, probabilmente più veloci. Indovina un po? A nessuno importa, perché tutte le nostre macchine sono abbastanza veloci.

— user281377

3

Quando l'hardware è inadeguato, faccio in modo di far sapere alla direzione, di solito facendo un lavoro utile come tagliare le unghie dei piedi o leggere il foglio durante le compilazioni lunghe. Prendo la vecchia macchina lenta? Certo, nessun problema. Oh, hai risolto un bug di fretta e devo fare la build? Certo, signor Manager-bwana-sahib-amico - ci vediamo tra 90 minuti! (Una volta un manager mi ha chiesto cosa ho fatto tutto il giorno - gli ho detto "Ricostruito l'app. Quattro volte". "IN OTTO ORE?!?" Gridò. "No," certo che no ", dissi I." Ci vollero 10 ore ". La nuova macchina apparve non molto tempo dopo ... :-)

— Bob Jarvis,

71

Possiamo risparmiare denaro facendo raddoppiare i programmatori come tester / scrittori tecnici

Se stai pagando gli stipendi del programmatore per il lavoro di tester / scrittore tecnico, allora stai sprecando soldi e probabilmente stai ottenendo un lavoro di qualità inferiore rispetto a qualcuno che ha dedicato la propria carriera a tale compito. Inoltre, quando un programmatore si trova ad affrontare una scadenza serrata, è molto probabile che i test e la documentazione vengano lasciati cadere o facciano mezzo culo per soddisfarlo.

A proposito: gli sviluppatori sono SEMPRE in controtendenza.

— JohnFx
fonte

12

Le persone intelligenti possono fare qualsiasi cosa fallace.

— Jon Hopkins,

3

Ho effettuato l'inserimento dei dati, anche se di certo non avrei abbassato le tariffe per questo. Volevano qualcuno che fosse veloce e accurato per l'inserimento di dati critici e non gli dispiaceva pagare almeno le triple percentuali di inserimento dei dati. La loro scelta.

— David Thornley,

1

Direi che è compito dei programmatori testare il loro codice, ma non sono sicuro che sia quello a cui ti riferivi.

— Ben Lakey,

3

I programmatori dovrebbero testare il proprio codice, non escludendo di avere tester dedicati che sono professionisti nella rottura del software.

— JohnFx,

1

Concordare sulla scrittura tecnica, non essere d'accordo sui test. Il test è una parte naturale della scrittura di un buon software. La scrittura tecnica è semplicemente troppo spostata dalla codifica. Trovo che devo cambiare molti ingranaggi per passare dalla scrittura di codice alla scrittura tecnica e mi sembra un cattivo uso del mio tempo.

— Adam Bruss,

63

Ricercare / leggere / scrivere codice non correlato allo sviluppo del prodotto è uno spreco di risorse.

Alcuni programmatori e persino i manager ci credono. Normalmente, semplicemente programmano in base alle conoscenze in testa e fanno ricerche e cercano risposte quando affrontano problemi. Non migliorano continuamente le loro conoscenze in modo proattivo. Secondo me, dovremmo sempre tenerci aggiornati e le conoscenze che abbiamo raccolto ci sarebbero utili per risolvere i problemi esistenti e futuri. Ovviamente, devi dedicare saggiamente il tuo tempo per farlo.

Questo è anche simile alla risposta di Dan . Alcuni manager vogliono solo che gli sviluppatori si immergano rapidamente e sviluppino il prodotto in base alle esigenze senza effettuare ricerche sui prodotti esistenti sul mercato.

— Gan
fonte

3

Vorrei poter aver votato più di una volta.

— MAK,

1

Consente di scrivere una libreria GUI. Consente di creare un toolkit di messaggistica. Se non VENDI il software, è solo una parte di una cosa più grande, per l'amor del cielo basta usare l'implementazione di qualcun altro. Punti di sicurezza per l'utilizzo di una soluzione open source, puoi sempre risolverlo e supportarlo se necessario. Se hai i soldi per acquistare soluzioni con sorgente inclusa, fallo, ma fai attenzione alla scarsa qualità dei componenti software commerciali. I venditori raramente ti vendono il componente due volte, quindi potresti essere deluso una volta che lo possiedi (so che ho lavorato in posti che sono stati morsi prima)

— Tim Williscroft,

58

In molti casi l'offshoring costa più denaro. Nella mia azienda è molto difficile ottenere nuovi posti per i dipendenti, siamo fortemente spinti ad esternalizzare. È anche difficile ottenere appaltatori in loco; c'è un rapporto di 3: 1 offshore a onshore che dovrebbero mantenere. Di conseguenza, molti team assumono solo una dozzina in mare aperto e li usano a malapena, solo per ottenere 4 appaltatori in loco.

— Jeremy
fonte

18

+1. La mia esperienza con il off-shoring è che inevitabilmente costa molto più denaro di quanto risparmi.

— Adam Crossland,

2

+1, ma offshore può funzionare se usato correttamente

3

+1. Sembriamo avere diversi sviluppatori off-shore su ogni nuovo progetto, il che significa che gli sviluppatori on-shore trascorrono la maggior parte del loro tempo a insegnare ai nuovi sviluppatori off-shore il modello di dominio tecnico e commerciale oltre a fornire supporto tecnico. Fine del progetto e sono andati altrove e ricominciamo da capo con la prossima serie di sviluppatori "economici".

— Chris Knight,

8

molte squadre assumono solo una dozzina in mare aperto e le usano a malapena, solo per ottenere 4 appaltatori in loco. Wow.

— poolie

1

E dimenticare che l'offshoring per sua stessa natura prolungherà la scadenza. Abbiamo un controllo della qualità offshore e possono essere necessari 3-4 giorni per ripristinare qualcosa che due persone nello stesso ufficio potrebbero riprendersi in meno di un'ora a causa delle differenze di tempo.

— HLGEM,

50

Cicli di feedback lunghi!

Succede a tutti: costruisci qualcosa che ritieni fantastico e si scopre che hai sbagliato. Non è questo il problema. Il problema è quanto tempo impieghi a costruire prima di scoprire che dovresti smettere.

Ad alto livello, si riscontra questo problema con lunghi cicli di rilascio. Se costruisci per un anno senza feedback, stai giocando tutto l'anno. Più spesso rilasci, più piccole sono le tue scommesse e migliore diventa il gioco.

Ma succede anche ai livelli più bassi. Come sviluppatore, mi piacciono molto le frequenti revisioni del codice (o, meglio, accoppiare la programmazione) perché limita la quantità di tempo in cui posso continuare a fare qualcosa di stupido prima che qualcuno dica: "Ehi, c'è un modo più semplice!" Per lo stesso motivo, mi piace che i test delle mie unità vengano eseguiti rapidamente e frequentemente, quindi posso catturare e uccidere i bug prima che crescano.

Una volta che inizi a notare l'importanza di brevi cicli di feedback, lo vedrai ovunque. Ad esempio, la nozione militare del ciclo OODA .

— William Pietri
fonte

6

+1. Inoltre: più lungo è il ciclo di feedback, meno ricordi dell'attività. All'estremo, è necessario conoscere nuovamente l'intera base di codice.

— Joseph Tanenbaum,

Come è una falsa economia? Qual è il risparmio previsto?

— Chris Pitman,

L'intento è quello di risparmiare tempo "sprecato" in cose che fai in ogni ciclo. Ad esempio, costruire, testare, rilasciare, prestando attenzione agli utenti. Questa è la scusa, comunque. Penso che sia davvero radicato nell'evitare il disagio.

— William Pietri,

Ecco perché è indispensabile che i revisori e gli amici di coppia abbiano l'umiltà e il rispetto per il programmatore il più possibile. Un recensore problematico che tratta male il programmatore e puoi garantire che il circuito di feedback crescerà molto.

— Jonathan Neufeld,

47

Non il mio aneddoto, ma una volta ho sentito parlare di un negozio che ha smesso di fornire caffè gratis ai suoi sviluppatori, dicendo loro che ogni volta che volevano prendere un caffè, erano liberi di camminare fino alla caffetteria più vicina (qualcosa come un dieci minuti viaggio in entrambe le direzioni) e acquistarne un po '.

Praticamente la definizione di falsa economia.

— EricBoersma
fonte

4

È davvero speciale. Confronta e confronta con alcune delle banche mercantili di Londra che avevano un Starbucks sovvenzionato costruito nell'edificio per eliminare il tempo necessario per uscire e prendere un caffè.

— Jon Hopkins,

48

Non sono d'accordo sul fatto che si tratti automaticamente di una falsa economia: i 10 minuti di aria fresca mentre si cammina fuori per acquistare il caffè ossigeneranno il dipendente e miglioreranno la sua concentrazione e l'interazione sociale (sebbene limitata) ridurrà la depressione, specialmente in inverno. Quei dipendenti che non prenderanno il caffè perché non è gratuito, probabilmente torneranno a casa in orario, dormiranno di più e avranno una salute migliore a causa della riduzione dell'assunzione di caffeina.

— JBR Wilkinson,

6

-1, una camminata di 20 minuti è perfetta per liberare la mente e avere una nuova prospettiva sul problema.

— Malfist,

23

@Malfist: A quanto ho capito, non sono stati solo i 20 minuti a piedi, ma anche i 15 minuti di attesa per ottenere effettivamente il caffè che ha interrotto il lavoro. Una pausa di 45 minuti in qualsiasi momento della giornata distruggerà praticamente la produttività per oltre un'ora e mezza. Tutto per risparmiare 100 dollari al mese sul caffè.

— EricBoersma,

8

20 + 15 = 35 [altri sei personaggi]

— Malfist,

47

Fornire workstation a schermo singolo perché un secondo monitor è troppo costoso . Anche se ti fa risparmiare solo un'ora di lavoro ogni anno, un secondo schermo è comunque un buon investimento. So per certo che il mio mi ha risparmiato molte, molte ore di lavoro.

Una configurazione multi-monitor può rendere quasi tutte le attività più efficienti, non solo le attività di sviluppo. Tre monitor sono addirittura meglio di due, ma l'effetto diventa meno pronunciato con ogni schermo aggiuntivo.

Configurazioni multi-monitor:

riduce l'overhead di commutazione della finestra
ti consente di tenere d'occhio le cose in esecuzione in background (posta, compilation, ecc.).
ti dà una sensazione di libertà. È come essere in un atrio contro l'essere in un armadio per scope.
eccetera...

— Arjen Kruithof
fonte

2

Una volta stava affrontando esattamente quel problema. Ho scritto una mail a uno dei nostri amministratori delegati calcolando esplicitamente che, dato un aumento dell'efficienza del 5%, avrei risparmiato una quantità di denaro degno di essere monitorata in circa mezzo mese rispetto al mio reddito netto. Questo calcolo era praticamente coraggioso ... ma ... immagino tu sappia già la fine della storia :)

— Raffael,

39

Hardware più economico dato a un consulente quando il consulente costa più di 150 $ / ora .

Mettendolo in prospettiva, un hardware migliore può almeno rendere il lavoro di 30 minuti più efficace al giorno. Ciò darebbe 30 minuti * 20 giorni di lavoro al mese = 600 minuti / mese = 10 ore / mese> più di 1 giorno di lavoro = 10 ore * 150 $ / ora = 1500 $

Ora un consulente non sarebbe più efficiente se avesse un computer da 1500 $? Renderebbe il consulente meno irritato?

Ora il problema sembra essere che ci sono due budget, uno per il consulente e uno per l'hardware del PC.

— Amir Rezaei
fonte

8

Come consulente, ci sono stato, l'ho fatto e ho preso la maglietta. (Ho solo $ 80 / ora, però.) Ma hey, questo è uno dei motivi per cui mi piace contrarre ogni ora. A differenza di una posizione stipendiata, se un cliente di consulenza sceglie di perdere il mio tempo e devo lavorare di più per compensare, sono più soldi in tasca.

— Bob Murphy,

2

Senza offesa, ma se pago $ 150 / ora per un consulente, è meglio che abbia il suo computer.

— Steven Evers,

8

@SnOrfus: Di solito non funziona nell'ambiente aziendale, dove esiste un controllo rigoroso dei PC consentiti sul dominio. Devi fornire loro l'hardware.

— HardCode,

1

@HardCode - Sì, suppongo. Ora capisco il punto.

— Steven Evers,

3

@HardCode In un recente progetto, invece di aggiungerci (appaltatori) alla loro rete aziendale interna, ci hanno messo in quarantena sulla nostra linea DSL. Una linea DSL dedicata per 3 sviluppatori a $ 40 al mese è un cambio di chump e ci ha reso facile spingere gli aggiornamenti da remoto senza mandare in panico lo staff IT. Inoltre, se il PC di produzione che esegue il nostro codice viene infettato e si arresta in modo anomalo, è automaticamente colpa nostra poiché siamo responsabili della sicurezza delle nostre comunicazioni e dei laptop personali. Puoi dire win-win-win.

— Evan Plaice,

38

Mesi di lavoro risparmiano giorni di pianificazione

(Non investire abbastanza tempo nella pianificazione)

— serg
fonte

21

Alla scuola elementare si diceva che alcune settimane in laboratorio possono farti risparmiare un'ora di tempo in biblioteca.

— David Thornley,

7

Sì. Quando stavo frequentando un corso di laurea in cui abbiamo identificato sostanze chimiche sconosciute, il prof ci ha detto "un'ora in biblioteca ti farà risparmiare quattro in laboratorio". L'ho preso sul serio, ed è stato divertente entrare in laboratorio per un'ora alla settimana e ottenere cattivi sguardi dai medici che trascorrevano dodici ore alla settimana facendo test sulle ammine su composti che chiaramente non erano ammine. E quando ho insegnato allo stesso laboratorio diversi anni dopo, ho dato agli studenti lo stesso consiglio, e proprio come pochi l'hanno effettivamente preso.

— Bob Murphy,

3

Se non si pianifica, si prevede di fallire

27

La maggior parte sospetto è che i manager semplicemente non forniscano agli sviluppatori gli strumenti di cui hanno bisogno per svolgere il proprio lavoro in modo efficiente.

Fondamentalmente, punto 9 sul test Joel .

— richeym
fonte

2

Ho partecipato a progetti in cui ci avrebbero fatto sprecare una o due settimane invece di acquistare, ad esempio, una libreria per $ 300 con il lavoro già fatto - e meglio (non siamo "sviluppatori di controllo" dove lavoro). O scegli uno strumento software "perché è creato da" questa o quella "compagnia" invece di cercare alternative migliori, quindi rendi la nostra vita un inferno per anni.

— MetalMikester,

L'ho incontrato anch'io. Il ragionamento PM / cliente era che non avevamo una voce di budget per acquistare cose per il cliente (le modifiche ai contatti erano una cagna), quindi avremmo dovuto reinventare la ruota (di nuovo).

— Ken Henderson,

24

"Lancia (abbastanza) corpi al problema" può ancora essere usato in alcuni punti, sfortunatamente. Brook's Law contrasta da The Mythical Man-Month , anche se alcuni richiedono esperienza per imparare questa lezione. Generalmente questo non è qualcosa in mio potere da fermare poiché il management può credere alla falsa dichiarazione sull'aggiunta di persone e sul fatto di non dover pagare un prezzo.

— JB King
fonte

2

+1. Oh Dio sì. Questo sta accadendo su scala epica in un grande progetto in cui lavoro.

— Tavoli Bobby,

3

Lavoro con un gruppo di project leader, manager, ecc., Tutti con la loro meravigliosa certificazione di gestione del progetto (qualunque diavolo si chiami) e NESSUNO DI LORO aveva sentito parlare di The Mythical Man-Month prima che li presentassi ad esso. Sheesh!

— Bob Jarvis,

2

Ho sentito una grande citazione su questo una volta: 9 donne non possono fare un bambino in un mese

— Richard

@Richard L'ho usato in una riunione. mi ha dato un immenso piacere!

— Tjaart,

21

Incontri giornalieri :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...

— zzz
fonte

9

Avere un incontro solo per il gusto di avere un incontro ...

— Gan,

5

Ordine del giorno per oggi: cosa sarà all'ordine del giorno della riunione di domani?

— Segna C il

9

Le riunioni quotidiane vanno bene se sono brevi; Le riunioni di 3 minuti in stile Scrum non perdono molto tempo ma tengono tutti al corrente degli sviluppi di tutti gli altri. Tuttavia, lunghi incontri con numerosi partecipanti disinteressati sono tossici.

— 9000

3

@Mark C - Potrebbe sembrare uno scherzo, ma in realtà sono stato invitato alle riunioni per pianificare quale sarebbe l'agenda del prossimo incontro ...

— Gavin Coates,

@Gavin Coates è una realtà e una situazione ... :)

— Zzz,

20

Acquistare il software standard invece di svilupparlo internamente.

Ho esperienza di sistemi di gestione su scala aziendale, focalizzati sia sui laboratori delle risorse umane che su quelli biologici.

Una soluzione pronta all'uso costava £ 50-100.000 e aveva bisogno di ulteriore sviluppo e personalizzazione per soddisfare i requisiti aziendali.

La soluzione sviluppata internamente ha richiesto (<6) mesi per svilupparsi, con altri progetti su cui si sta lavorando in parallelo e che utilizzava uno sviluppatore già impiegato.

Sono passato dal settore pubblico dove avevamo installato e funzionante un LIMS (sistema di gestione delle informazioni di laboratorio) sviluppato internamente, fino a un grande settore farmaceutico internazionale in cui l'implementazione di una soluzione standard era durata oltre un anno e non era completa.

(6 mesi di uno sviluppatore già assunto che lavora su altri progetti in parallelo. Quindi ~ 10k. E questo non include i costi di supporto associati alla soluzione off shelf). Il punto principale è che il sistema sviluppato internamente veniva effettivamente utilizzato! Quindi hai il vantaggio in termini di costi aggiuntivi associato a quello, che non posso calcolare.

Sono d'accordo per i siti Web di base ecc., Perché preoccuparsi di sviluppare il proprio. Ma per qualsiasi sistema complesso di grandi dimensioni e se hai già competenze interne, lo costruirò da solo .

— NimChimpsky
fonte

26

Scommetto che ci sono anche molti esempi del contrario.

— Jon Hopkins,

13

Acquistare o sviluppare dipende dalle persone giuste che fanno la dovuta diligenza. Semplice come quella. Pensa prima di agire. (+1)

— DevSolo

4

@DevSolo: spot on. La decisione di acquisto o acquisto dovrebbe essere supportata da un'analisi costi-benefici, piuttosto che da un atteggiamento emotivo "non inventato qui" o "amo il software di XXX".

— JBR Wilkinson,

9

Se hai intenzione di fare una dichiarazione generale su build vs buy, dovrebbe essere: preferisci acquistare soluzioni a problemi che non fanno parte della competenza principale della tua azienda. Non è sempre la risposta giusta, ma è una posizione predefinita ragionevole e affidabile quanto un cliché può essere. Dire che acquistare software standard è una falsa economia, tuttavia, non è nemmeno un cliché utile. Sento che il tuo dolore si è strappato alle soluzioni "E" (che dovrebbe significare "Enterprise", ma in realtà significa "Costoso" '). Ma la presenza di cattive opzioni non significa che non ce ne siano di buone là fuori.

— evadeflow,

2

Penso che il problema stia acquistando e che quindi necessitino ancora di ulteriore sviluppo e personalizzazione , il costo di una piccola personalizzazione su un grande sistema portato spesso può essere più che scrivere il proprio piccolo sistema che fa proprio quello che vuoi. Quindi acquista se riesci a lavorare nel modo in cui il sistema che stai acquistando si aspetta che tu funzioni, ma comprare e personalizzare può dare il peggio di entrambe le parti!

— Ian,

15

Acquistare costosi prodotti pronti all'uso quando le alternative open source sono migliori e gratuite.

Quante aziende usano git? Quante aziende usano un pessimo controllo della versione aziendale?

— hasen
fonte

1

Ehm, questo può essere considerato la "peggiore falsa economia"? O probabilmente hai bisogno di elaborare di più ...?

— Gan

3

Non sono sicuro di essere completamente d'accordo con l'esempio del controllo del codice sorgente, almeno. Git è stato appositamente progettato per risolvere problemi open source: molti sviluppatori, scarso controllo centrale, molte filiali, ecc. Il software "enterprise" funziona con una serie di presupposti diversi: la necessità di gestire una varietà di prodotti in un'azienda, sicurezza, flusso di lavoro, ecc.

— Peter Allll Webb

1

@Gan: pensano che l'utilizzo dell'open source sia una falsa economia, ma hanno tutto all'indietro.

— hasen

3

Sono un collaboratore di X11 e GNOME e abbastanza competente nell'uso di git e nella gestione di server gitosi. Tuttavia, quest'estate ho passato il mio lavoro di consulenza da git a un server Perforce pagato personalmente perché fa molte cose automaticamente che devi fare manualmente con git. Dato che vengo pagato per la consegna del codice e per non avere problemi con il controllo della versione, l'utilizzo e il pagamento del "controllo scadente della versione aziendale" è molto più conveniente rispetto all'utilizzo di git.

— Bob Murphy,

7

L'open source rispetto ai prodotti commerciali è davvero una base "caso per caso" nella mia esperienza.

— MetalMikester,

14

Usare linguaggi "semplici" senza molta espressività

Sì, è più facile trovare programmatori per mantenere il codice, ma è più difficile trovare buoni programmatori che non imparano solo le ultime parole d'ordine che li faranno assumere. Sì, semplifica la comprensione del codice dei singoli bit, ma lo rende anche rigido come un 2x4 e aumenta il volume di codice che deve essere compreso. Sì, è supportato da un'enorme società, ma ha detto che un'enorme società innova lentamente e burocraticamente.

— dsimcha
fonte

4

@burnt_hand: sostanzialmente mi riferisco all'eccessiva avversione al rischio del management in termini di scelta della lingua.

— dsimcha,

1

+1: Continua a usare C perché "abbiamo quelle abilità e l'apprendimento di un linguaggio nuovo come Python / Perl / PHP aumenta il rischio". L'ho sentito più di una volta. Significa che la squadra è troppo stupida per imparare una nuova lingua?

— S. Lott,

1

@ S.Lott Gli agenti di reclutamento pensano che tu sia!, Ma questa è un'altra storia

— burnt_hand

2

vale a dire le aziende che si attaccano con Java e C # e sono troppo paura di toccare Python o Ruby perché non sono "standard", che mi ricorda: paulgraham.com/avg.html

— hasen

1

@hansen: il saggio di Paul Graham è in parte ciò che mi ha ispirato a scrivere questo post. Un'altra mia ispirazione è stata il mio lavoro nello sviluppo di librerie (compresa la libreria standard) per il linguaggio di programmazione D.

— dsimcha,

13

Responsabili di progetto / lead team inadeguati

Dal momento che una persona incompetente ha il potere di rovinare il lavoro di un gruppo di persone. Alla fine, il progetto farebbe molto meglio senza le decisioni del management superiore (project / team lead).

Dose la decisione "Fallo velocemente, rifatteremo più tardi".

— Amir Rezaei
fonte

4

Sono d'accordo che ci sono cattivi gestori, ma "il progetto farebbe molto meglio senza le decisioni del management superiore"? Generalmente queste sono le persone che sponsorizzano il progetto. Questo mi sembra un po 'come gli sviluppatori che ho incontrato che pensano che comprendere la tecnologia sia più importante della comprensione del business e dimenticare chi sia il cliente reale.

— Jon Hopkins,

2

@Jon Hopkins Con la direzione superiore non rimando il cliente. Il punto è che i "cattivi project manager" sono quelli che commettono errori dopo errori e vanno contro un gruppo di persone. Chi pensi che decida "Fallo velocemente, rifatteremo più tardi". Leggi la risposta con il tasso più alto!

— Amir Rezaei,

ah, più chiaro. Rimuovo il mio -1.

— Jon Hopkins,

Ho notato una tendenza inquietante per i project manager che rispettano tempi e costi rispetto alla qualità. Sono sicuro di non essere l'unico. Ai PM piace usare il diagramma a triangolo con costo / qualità / tempo su di esso, ma la qualità ottiene sempre l'avvio. È molto triste e istituzionalizzare e forzare le metriche della gestione dei progetti (PMI) su qualcosa di così complicato come il software sembra solo peggiorare le cose.

— Bernard Dy,

1

@Bernard: tempi e costi sono misurabili. Qualità? Non così tanto. Triste ma IMO vero ...

— Bob Jarvis,

12

Requisiti utente mancanti

Un passaggio importante e difficile nella progettazione di un prodotto software è la determinazione di ciò che il cliente desidera effettivamente che faccia.

Che ci crediate o meno a volte questa parte manca o è obsoleta. Ciò che costa è che si creano funzionalità che l'utente finale non ha mai richiesto.

— Amir Rezaei
fonte

Penso che questo dovrebbe essere al top!

— Roopesh Shenoy,

8

La produttività vale più della creatività

La creatività è difficile da misurare in generale, e molto spesso impossibile persino osservarla, non importa misurare, quando si tratta di sviluppo del software. La produttività, d'altra parte, può essere misurata (spesso male) e può essere osservata.

Di conseguenza, gli sviluppatori che possono (scrivere più righe di codice | scrivere codice più velocemente | recitare tecnobabble più velocemente in risposta alle domande | sono visibilmente più produttivi) tendono ad essere valutati più di quelli che (usano meno righe di codice per risolvere lo stesso problema | impiega più tempo a scrivere codice, ma produce un prodotto più affidabile | capisci l'argomento abbastanza bene da rispondere alle domande in modo chiaro, facile da capire, l'inglese | risolve in modo creativo i problemi).

— blueberryfields
fonte

6

Tutto sotto può essere male se usato o non usato in modo inappropriato

software esterno vs interno
Conformità ISO 9001 (economia - una mitigazione del rischio di perdita MSS se la qualità del prodotto cala)
sviluppo / outsourcing del QA
procedure di sviluppo / costruzione / rilascio / supporto

— 2 giri
fonte

In che modo la ISO 9001 è una (falsa) "economia"?

— Andrew Grimm,

@Andrew Grimm - la conformità garantisce un certo livello di qualità che mitiga i rischi derivanti da una cattiva qualità (perdita di MSS ad esempio), quindi la potenziale economia è chiara. Per i piccoli reparti questo può essere inappropriato perché le perdite generali sono maggiori di quelle a rischio potenziale

— bobah

1

@Andrew - nella mia esperienza dipende da cosa lo desideri. Se vuoi che aumenti la qualità, è probabilmente una falsa economia in quanto tende ad essere costosa e può non essere adatta al software. Se lo desideri come una cosa di marketing o perché è appena previsto nel tuo settore, allora è potenzialmente una buona idea.

— Jon Hopkins,

5

@Andrew Grimm - L'unica "cosa" garantita dalla ISO 9001 è la qualità costante e ripetibile. Non garantisce una qualità "alta". Tuttavia, se una qualifica ISO 9001 è ciò che è richiesto nello spazio di mercato in cui l'azienda vuole essere, allora è richiesto.

— Vatine,

1

@Vatine: ciò che ISO 9001 garantisce è un processo coerente e ripetibile. In alcuni campi, dove processi coerenti producono una qualità costante, questo è importante. Non garantisce alta qualità, ma se un cliente vede qualcosa che hai fatto bene e sa di essere certificato ISO 9001, sarà sicuro di una qualità simile.

— David Thornley,

4

Avere troppi gestori di consegna non fatturabili.

Un paio di anni fa, nella nostra azienda avevamo in corso diversi progetti con budget elevati e il reclutamento era al culmine. A quel tempo la nostra azienda assumeva troppi gestori delle consegne (molti dei quali non erano IT!) E pochissimi programmatori / tester. Il rapporto Manager / Programmer era letteralmente 1: 2. Più tardi, dopo il completamento di quei progetti, abbiamo avuto una situazione in cui molti di questi manager (alcuni erano veri e propri allentatori) seduti su una panchina senza fare nulla. Abbiamo avuto un ciclo di valutazione in cui tutti hanno ottenuto un rilancio scarso / nullo (anche noi programmatori laboriosi, sospiro) in modo che la compagnia non debba licenziare nessuno! Fortunatamente, la società ha capito questa situazione e ha fatto il RIGHTSIZING nel primo trimestre di quest'anno!

— mananjani
fonte

3

Ottimizzazione prima della profilazione (ovvero ottimizzazione prematura).

Troppe volte ho visto qualcuno cercare una soluzione intelligente che complica inutilmente la manutenzione e la leggibilità perché è più veloce. Naturalmente, il codice non è stato contrassegnato da un punto di riferimento (nemmeno con i micro-benchmark), quindi diventa rapidamente "più veloce in base all'argomento più persuasivo" su una sezione di codice che molto probabilmente non ha influito sulle prestazioni complessive dell'intero applicazione di molto.

In quanto tale, è un'economia molto falsa e il tipo di falsa economia che occasionalmente impiglia anche i professionisti esperti.

— Edwin Buck
fonte

3

Accesso a Internet limitato o assente

Perché ovviamente i tuoi dipendenti useranno Internet per giocare a giochi di Facebook e non cercare troppo le risposte a domande tecniche su Stackoverflow.

In realtà, naturalmente, Internet è un enorme aumento della produttività e, sebbene possa essere appropriato utilizzare una sorta di filtro del sito per siti veramente malvagi, c'è qualcosa di sbagliato se blocca il file readme di Visual Studio o blocca le pagine del governo locale per motivi "turismo sessuale"

— jk.
fonte

2

Fare in modo che i tuoi sviluppatori utilizzino un monitor da 15 pollici e un PC con specifiche ridotte poiché è lo standard aziendale.

I monitor di dimensioni ragionevoli sono economici, veloci da installare e rendono i programmatori più produttivi, oltre a far pensare ai programmatori che ti interessano.

— Ian
fonte

2

Troppi Bachelor of Business Administration (o simili), organizzati gerarchicamente, che cercano di applicare ciò che pensano sia il management moderno: disturbare le persone con "KPI", "SLA" e cosa no, che richiedono "report" (senza, ovviamente, preoccupandosi dell'infrastruttura per generarli), in modo che i programmatori perdano le loro giornate compilando fantasiosi fogli EXCEL, rapporti Q4 e cosa no e copiando da un nuovo fantastico strumento di gestione e incollandoli in un altro (sembra essere la regola che questi strumenti non sono mai integrati né integrabili tra loro) e partecipano alle riunioni in cui vengono presentati i rapporti e le cifre (e tutti si sentono in colpa per non aver completato questo o quel KPI).

— Ingo
fonte