Dare a uno sviluppatore una macchina di sviluppo più lenta comporta un codice più veloce / più efficiente? [chiuso]

Supponiamo che io dia ai miei sviluppatori una macchina veloce e urlante. VS2010 basato su WPF si carica molto rapidamente. Lo sviluppatore crea quindi un'applicazione WPF o WPF / e che funziona perfettamente sulla sua scatola, ma molto più lentamente nel mondo reale.

Questa domanda ha due parti ...

1) Se do a uno sviluppatore una macchina più lenta, significa che il codice risultante potrebbe essere più veloce o più efficiente?

2) Cosa posso fare per offrire ai miei sviluppatori un'esperienza IDE rapida, offrendo allo stesso tempo esperienze di runtime "tipiche"?

Aggiornare:

Per la cronaca, sto preparando la mia risposta imparziale alla direzione. Questa non è una mia idea e voi mi state aiutando a correggere le richieste sbagliate del mio cliente. Grazie per avermi fornito più munizioni e riferimenti su dove e quando affrontarlo. Ho + 1 casi d'uso validi come:
- ottimizzazioni di programmazione lato server specifiche
- laboratori di test
- l'eventuale acquisto di un server migliore anziché delle schede grafiche di fascia alta

Assolutamente

È anche vero che i manager dovrebbero condurre tutti gli incontri in latino-maiale. Migliora le loro capacità comunicative in generale per averle svantaggiate quando parlano frasi semplici. Dovranno fare più affidamento sulle espressioni facciali e sul linguaggio del corpo per ottenere il loro punto e sappiamo tutti che è almeno il 70% di tutte le comunicazioni comunque.

I CFO dovrebbero usare solo un abaco e un gesso. Altrimenti finiscono per fare troppo affidamento sui "dati grezzi" e non abbastanza sulla loro "sensazione viscerale".

E i vicepresidenti e superiori dovrebbero essere tenuti a tenere tutti gli incontri di lavoro importanti in contesti di distrazione come campi da golf quando sono semi-intossicati. Oh scatto ...

La risposta è (sarò audace e dirò) sempre

NO .

Sviluppa il meglio che puoi ottenere con il tuo budget e testa sulla gamma di specifiche min-max delle attrezzature che implementerai.

Ci sono emulatori, macchine virtuali, macchine reali con tester che possono testare tutte le prestazioni per vedere se è un fattore.

1) Molto, molto improbabile. No, e i tuoi sviluppatori potrebbero mettere qualcosa di brutto nel tuo caffè per suggerirlo. Il tempo che gli sviluppatori trascorrono in attesa della compilazione del codice o che l'IDE faccia qualsiasi cosa stia facendo o qualunque sia il tempo che non impiegano per migliorare il codice. Interrompe anche il loro flusso mentale. Tieni a mente il problema e saranno molto più efficienti a risolverlo.

2) Offri a ciascuno un secondo PC che rappresenti le specifiche più basse che desideri effettivamente supportare, con uno switch KVM per passare da quello a quello reale.

Mi piacciono i tempi di compilazione lunghi. Mi dà più tempo per lavorare sul mio curriculum.

Questa è un'idea terribile. Vuoi che i tuoi sviluppatori siano il più produttivi possibile, il che significa dare loro una macchina il più veloce possibile, in modo che non siedano tutto il giorno in attesa che le cose vengano compilate. (Leggermente OT, ma aiuta anche a non bloccare il loro accesso a siti potenzialmente utili con WebSense e simili.) Se sei costretto ad avere utenti che utilizzano ancora la tecnologia Stone-Age, dovrai disporre di una macchina di prova con specifiche simili, e assicurati di testare presto e spesso per assicurarti di non seguire la strada sbagliata in termini di scelte tecnologiche.

Lo sviluppo dovrebbe essere fatto nel miglior ambiente possibile. I test dovrebbero essere eseguiti nel peggior ambiente possibile.

Se mi venisse data una macchina lenta passerei la giornata a ottimizzare il processo di sviluppo e non a ottimizzare il mio codice consegnato. Quindi: NO!

I programmatori di sistemi integrati si imbattono sempre in questo! E c'è una soluzione in due parti:

1. I tuoi requisiti devono specificare le prestazioni X sull'hardware Y.
2. Prova su hardware Y e quando non ottieni prestazioni X, bachi di file.

Quindi non importa su quale hardware lavorano i tuoi sviluppatori.

Una volta che lo hai fatto, supponiamo che un'attrezzatura più veloce possa far risparmiare ai tuoi programmatori mezz'ora al giorno o 125 ore all'anno. E diciamo che costano $ 100.000 all'anno con benefici e spese generali (ridicolmente bassi per la Silicon Valley), o $ 50 l'ora. Quel 125 ore * $ 50 / ora è $ 6250. Quindi, se spendi qualcosa di meno di $ 6250 all'anno in hardware di sviluppo rockin per programmatore, stai risparmiando denaro.

Questo è ciò che dovresti dire alla tua direzione.

Tim Williscroft ha praticamente detto la prima metà di questo in un commento, e in un mondo giusto, otterrebbe la metà di tutti i punti che ottiene questa risposta.

Aggiunto il 24 ottobre:

Il mio ex datore di lavoro aveva questa teoria e li ha aiutati a far incazzare circa $ 100 milioni.

Sono un conglomerato con base giapponese che era abituato ad assumere programmatori in Giappone, Corea e Cina. Le persone sono fantastiche nell'utilizzare hardware di sviluppo scadente, giorni di lavoro di 13 ore, dormire nei loro banchi e non avere una vita. Così hanno pensato quando hanno acquisito una nota azienda della Silicon Valley per fare un sistema operativo basato su Linux per telefoni cellulari, quegli sciocchi californiani che volevano equipaggiamento moderno erano solo lamentosi prima-donnas e in realtà non avevano una buona ragione per farlo (come la produttività).

Quattro anni dopo, il sistema operativo funzionava come una cazzata, tutti i programmi erano saltati e i clienti erano incazzati e avevano terminato i contratti a destra e a sinistra. Infine, il progetto OS è stato annullato e una grande percentuale della forza lavoro mondiale del conglomerato è stata licenziata nell'ultimo anno. E francamente, non avrei voluto essere uno dei dirigenti che ha dovuto spiegare agli azionisti dove sono andati tutti quei soldi e gli sforzi.

Non sono state solo le macchine a sviluppo lento a causare questo fiasco. C'erano molti altri errori strategici e tattici, ma erano lo stesso tipo di cose in cui le persone che lavoravano nelle trincee potevano vedere arrivare il disastro ferroviario e si chiedevano perché i decisori non potevano.

E la marcia lenta è stata sicuramente un fattore. Dopotutto, se sei sotto la pistola per consegnare in tempo, è davvero una cosa intelligente rallentare deliberatamente il lavoro?

Nella programmazione, c'è un vecchio detto che " l'ottimizzazione prematura è la radice di tutti i mali ". Penso che tu sia riuscito a creare con successo un'altra "radice" (o almeno il primo ramo) di tutti i mali. D'ora in poi, possiamo dire "la deoptimizzazione prematura degli sviluppatori è la radice di tutti i mali".

In breve, la risposta è che ciò rallenterà i tempi di sviluppo e renderà più difficile l'ulteriore manutenzione. I tempi di compilazione richiederanno più tempo, la ricerca di codice su disco rallenterà, la ricerca di risposte online richiederà più tempo e, soprattutto, gli sviluppatori inizieranno a utilizzare il codice in modo prematuro per poter anche testare le funzionalità necessarie.

Quest'ultimo punto è il problema più critico e non viene sollevato in molte delle altre risposte. Potresti ottenere la tua prima versione ok, ma poi quando vuoi aggiornare il codice in futuro, scoprirai che l'ottimizzazione prematura degli sviluppatori ha spostato il focus del tuo codice lontano da un buon design e lo ha avvicinato a "Devo farlo a almeno lavoro per mantenere il mio "stile di codice di lavoro. L'aggiunta di funzionalità aggiuntive diventerà più difficile perché le ottimizzazioni scelte al momento potrebbero non essere necessarie e bloccare il codice in un percorso di hack semi-ottimizzati oltre ad altri hack semi-ottimizzati.

A titolo di esempio, immagina che il requisito minimo di sistema della tua versione attuale sia un singolo processore con una velocità piuttosto bassa. Metti gli sviluppatori in questa scatola e escono con una soluzione intricata a thread singolo che si basa su molti hack perché volevano sviluppare rapidamente il prodotto. Ora 5 anni dopo, hai una nuova versione del prodotto che ha un requisito minimo di una macchina a doppio processore. Vorresti essere in grado di separare in modo chiaro parti del programma che puoi eseguire in parallelo, ma la decisione che hai preso 5 anni fa che ha costretto i tuoi sviluppatori a creare un software hacky ora ti impedisce di sfruttare tutta la potenza del tuo nuovo requisito minimo .

Quello che dovresti fare è aggiungere una fase alla fine del tuo ciclo di sviluppo in cui esegui i test di accettazione nelle caselle con limite inferiore. Certamente parte del codice sarà troppo lento a causa della macchina più veloce dello sviluppatore, ma puoi isolare quella parte e ottimizzarla lì. Il resto del codice rimane pulito e gestibile.

Vedo la tua domanda dire: "Posso forzare i miei sviluppatori a ottimizzare in anticipo dando loro macchine sviluppatrici povere ma ancora ottenere un buon codice?" E la risposta è no.

Lettura interessante, tutte quelle risposte.

Ma penso che alla maggior parte delle persone che rispondono qui manchi il punto. La domanda, come ho letto, non riguarda (almeno almeno) il dare realmente agli sviluppatori un P1 per rendere il codice più veloce.

Il punto è che molti software oggi sono altrettanto lenti o persino più lenti dei software di base che abbiamo usato nell'ultimo millennio nonostante computer molto più potenti. A giudicare dalle risposte qui la maggior parte degli sviluppatori non ha questo suggerimento. Questo è molto evidente nelle applicazioni web. Questo sito fa un'ottima eccezione, ma molti siti hanno una prima pagina in 1 mb. Cosa ottengo in attesa del download? Non lo so. Penso che si tratti di un'ignoranza da parte dello sviluppatore che non rispetta il tempo che l'utente ha bisogno di spendere per esso, o peggio ancora se paghi per mb. Il fatto è che tutte quelle pagine web non contengono nemmeno immagini ad alta risoluzione. Spesso è solo un po 'di codice di merda fornito da un ambiente di sviluppo. Beh, ovviamente non è un codice di merda, immagino, ma non mi dà alcun vantaggio come utente.

In generale non si tratta solo di ottimizzare il codice, ma anche di scegliere di non includere le cose che rallentano più di quanto non dia.

Alcune settimane fa ho avviato un laptop dal 1995. Windows 3.x era attivo e funzionante in pochissimo tempo. Il database dovrei ottenere alcuni dati da avviare prima che la chiave di invio fosse completamente rilasciata (almeno).

So che oggi otteniamo molto di più dal nostro software, ma abbiamo anche computer molte volte più veloci. Perché l'industria dello sviluppo non decide di mantenere la velocità del software dal 1995 e indurre le persone ad acquistare nuovo hardware perché desiderano nuove funzionalità. Oggi è più come i programmi di tutti i giorni e i siti Web costringono le persone ad acquistare nuovo hardware per fare esattamente le stesse cose che facevano prima. Ma ovviamente in modo più elaborato.

Devo dire che penso che lo sviluppo di Linux sembra gestirlo meglio. Le distribuzioni Linux sono state per molti anni molto più avanti di Windows anche nella fantasia con molte cose accattivanti come le finestre animate. Il fatto è che, nonostante ciò, hanno funzionato sui computer di oggi e anche di ieri. Non solo su hardware all'avanguardia.

Ormai suppongo che molti sviluppatori abbiano un livello malsano di adrenalina. Sì, ho trovato un modo per restituire un po 'di frustrazione da tutte le attese di fronte a:
server sql (avvio console di gestione) arcgis (avvio e utilizzo) acrobat reader (avvio) agresso (utilizzando, almeno come applicazione web) windows (fissando e usando, beh non ho ancora provato 7) pagine web .net (download)

e così via

Mi sento bene :-)

Saluti
Nicklas

1) Se do a uno sviluppatore una macchina più lenta, significa che il codice risultante potrebbe essere più veloce o più efficiente?

Abbiamo sviluppato software negli ultimi 6 decenni e abbiamo ancora domande come queste? Sembra più un ennesimo tentativo di tagliare gli angoli. Senza offesa, ma dai, pensi che la domanda sia persino logica? Pensaci in questi termini (se puoi): vuoi costruire un veicolo 4x4 che possa operare in condizioni difficili, pioggia, fango, qualunque cosa. Metterai i tuoi ingegneri e la catena di montaggio sotto gli elementi solo per assicurarti che il veicolo risultante possa operare su di essi?

Voglio dire, Gesù Cristo! C'è sviluppo e test. I test vengono eseguiti in un ambiente diverso e più rigido, oppure lo sviluppatore sa come assemblare un banco di prova nel proprio ambiente di sviluppo in un modo adatto per le prove di stress. Se non ci riesce, sostituiscilo con uno sviluppatore migliore.

2) Cosa posso fare per offrire ai miei sviluppatori un'esperienza IDE rapida, offrendo allo stesso tempo esperienze di runtime "tipiche"?

Dovresti chiedere questo ai tuoi sviluppatori. E se non possono darti una risposta obiettiva e valida, devi sostituirli con sviluppatori reali.

Ma per intrattenere la domanda, dai ai tuoi sviluppatori (supponendo che tu abbia buoni sviluppatori), buoni strumenti e buon hardware, il meglio che puoi permetterti. Quindi imposta un ambiente di base comune più basso in cui il tuo software deve operare. Ecco dove dovrebbero verificarsi i test. È molto meglio la pratica ingegneristica avere un ambiente di test che sia distinto dall'ambiente di sviluppo (preferibilmente uno che ti permetta di fare stress test).

Se i tuoi sviluppatori sono bravi, dovrebbero averti comunicato questo (supponendo che tu l'abbia chiesto).

Il risultato è un sacco di sviluppatori puttanati. Questa roba è abbastanza dura com'è, non peggioriamo l'esperienza.

Ti incoraggio a disporre di hardware simile ai tuoi utenti in un ambiente di prova o di controllo qualità per eliminare eventuali problemi di prestazioni. Questa è una buona idea.

Rispetterò la norma e dirò di sì SE E SOLO se stanno scrivendo un software server. Ridi tutto ciò che vuoi, ma il team più efficiente che abbia mai visto era un gruppo di ragazzi del Perl con terminali Wyse. Era la fine degli anni '90, era un negozio off-shoot dell'Università e stavano scrivendo un software di griglia spaziale (che sostanzialmente calcola). Stavano comunque parlando con alcuni relativamente potenti RS / 6000 del modello recente.

Solo per aggiungere interesse all'evento, c'era un programmatore cieco lì. Sono rimasto molto colpito.

Questa non è una cattiva idea, ma vuoi che i tuoi sviluppatori abbiano un ambiente di programmazione veloce.

Potresti implementarlo dando ai tuoi programmatori due macchine: una scatola di sviluppo veloce e una scatola di merci più lenta (possibilmente virtuale) per i test.

Alcune modifiche al processo di compilazione VS potrebbero rendere la distribuzione nella casella di test la norma, con il debug remoto.

Esistono altri modi per considerare di forzare i programmatori a sviluppare codice più efficiente, ad esempio è possibile includere obiettivi di prestazioni e utilizzo della memoria nei test delle unità. Anche impostare budget per l'uso della memoria è un obiettivo eccellente. Anche l'impostazione dei budget di peso pagina per il codice html.

Il problema non è lo sviluppatore che sviluppa codice inefficiente su una macchina veloce, il problema è che non hai definito le metriche delle prestazioni che devono essere misurate.

È necessario definire, nell'ambito dei requisiti del prodotto, un obiettivo specifico che può essere misurato su tutti i computer sulla base dell'esperienza del cliente richiesta. Esistono molti siti Web (Verifica specifiche) che consentono di mettere in relazione il computer con altri tipi di computer.

Questo è buono per molte ragioni. Ti consente di definire più facilmente l'hardware minimo supportato in modo da poter limitare il numero di reclami dei clienti - sappiamo tutti che la maggior parte dei software viene eseguita sulla maggior parte dei computer, è solo una questione di prestazioni - se impostiamo le nostre specifiche in modo che le persone rientrino nella gamma dei requisiti minimi ha prestazioni ragionevolmente accettabili, si limitano i reclami dei clienti - e quindi quando un cliente chiama, è possibile utilizzare i parametri di riferimento per determinare se esiste davvero un problema o se il cliente non è soddisfatto del funzionamento del prodotto.

Sono convinto che avere un computer più lento per lo sviluppo si traduca in un codice più veloce, ma questo ha un prezzo. La logica è che ho sperimentato questa prima mano: avendo un lungo tragitto giornaliero, ho comprato un netbook per lavorare in treno, un netbook che è più lento di qualsiasi computer che ho comprato negli ultimi 5 anni. Poiché tutto è così lento, vedo molto rapidamente quando qualcosa è insopportabilmente lento su questo netbook e sono consapevole dei punti lenti molto più rapidamente (non c'è bisogno di fare un benchmark per tutto il tempo). Lavorare su un netbook ha davvero cambiato il modo in cui mi sono sviluppato.

Detto questo, non sto sostenendo di farlo, specialmente in un ambiente professionale. Innanzitutto, è demoralizzante. Il fatto stesso che quasi tutti dicessero che l'idea non aveva nemmeno senso dimostrava che i programmatori reagivano male all'idea.

In secondo luogo, avere tutto più lentamente significa che le cose che potresti voler fare su una macchina veloce (diciamo 1 minuto) non sono più realmente realizzabili su una macchina lenta, a causa della pigrizia, ecc ... È una questione di incentivo.

Infine: il codice prodotto potrebbe essere più veloce, ma quasi sicuramente impiegherà più tempo a produrlo.

Punto 1, NO! Studio è progettato per essere eseguito su macchine decenti e tale requisito è diventato solo più potente con ogni versione. Puoi effettivamente bloccare alcune versioni di studio se accendi intellisense e usi un box single core non HT.

Al punto 2 ci sono alcune funzionalità nei progetti di test che consentono di limitare alcune risorse. Non sono perfetti, ma ci sono. Immagini VPC o VM a bassa specifica per un buon lavoro di vincolo. Ho avuto utenti seduti su macchine difettose per fare test occasionalmente in modo che possano vedere le implicazioni delle funzionalità che hanno richiesto.

No, in effetti si tradurrebbe in più bug perché non eseguiranno così tanti test e non useranno più strumenti extra come i profiler. Offri loro le migliori macchine che puoi permetterti (incluso l'hardware di accelerazione grafica se sei uno sviluppo di giochi o un negozio di grafica) e falli testare all'interno delle VM. Le specifiche della VM possono essere ridimensionate in base alle esigenze.

Penso che questa sia una domanda interessante e non vorrei fare un "no" così rapidamente. La mia opinione è: dipende dal tipo di team di sviluppo di cui stiamo parlando. Esempio: se stai guidando un gruppo in esecuzione per il concorso annuale di programmazione ICFP, forse avere buoni risultati dopo una piccola quantità di tempo di sviluppo su un cluster HPC non significherebbe necessariamente che la soluzione che hai trovato è buona. Lo stesso si può dire se stai scrivendo un algoritmo scientifico o numerico: sul tuo vecchio AMD Duron 600 MHz con 64 MB di memoria sei costretto a stare attento al modo in cui stai facendo le cose, e questo può influire anche su alcuni progetti scelte.

D'altra parte, un programmatore / scienziato intelligente / qualunque cosa dovrebbe fare attenzione comunque. Ma mi sono ritrovato a scrivere alcuni dei miei migliori codici quando non avevo NESSUN computer in assoluto e dovevo prendere appunti su carta. Ciò potrebbe non valere per i grandi progetti che coinvolgono enormi framework, quando un IDE è strettamente necessario.

Una cosa è certa: macchine veloci e buoni risultati immediati rendono i programmatori (cattivi) viziati e possono essere uno dei motivi di alcune cazzate che troviamo sui computer.

Lavoro su un pacchetto che impiega circa un'ora per costruire sulla mia macchina 8G 8 core (build completamente pulita). Ho anche un laptop relativamente di fascia bassa su cui collaudo. Il laptop di fascia bassa non gestisce due build complete in una singola giornata lavorativa.

Sono più produttivo sulla macchina veloce con alcuni test deliberati eseguiti sul laptop o dovrei fare tutte le mie build sul laptop?

Tieni presente che questi non sono numeri inventati.

È una demo truccata in cui normalmente non ho bisogno di fare una build pulita ogni giorno (posso fare molti test su singoli moduli), ma anche le build parziali mostrano all'incirca un ordine di differenza di magnitudo nei tempi di compilazione / collegamento .

Quindi il vero problema è che sulla mia macchina più lenta una tipica costruzione è abbastanza lunga da farmi prendere una tazza di caffè, mentre sulla mia macchina più veloce posso solo sorseggiare un caffè.

Dal punto di vista del lavoro svolto preferisco fare lo sviluppo su una macchina veloce. Posso rispettare scadenze molto più affidabili. D'altra parte immagino che se la gestione mi facesse fare lo sviluppo sulla mia macchina lenta, farei molto più navigazione sul web, o almeno leggendo i libri.

È interessante notare che ho lavorato in una startup in cui abbiamo finito per farlo. Penso che in realtà abbia funzionato abbastanza bene, ma solo a causa della situazione specifica in cui ci trovavamo. Era un negozio mod_perl in cui il ricaricamento automatico di classe in realtà funzionava correttamente. Tutti gli sviluppatori hanno utilizzato vim come IDE di loro scelta (o hanno utilizzato alcuni software di editing remoto). Il risultato finale è stato che è stato perso pochissimo tempo (se presente) in attesa della compilazione / ricarica / ecc. Del codice.

Fondamentalmente, mi piace l'idea IFF che ha un impatto trascurabile sul ciclo di sviluppo per tutti gli sviluppatori e influisce solo sul funzionamento del runtime del codice. Se il tuo codice è comunque compilato, preelaborato, ecc., Allora stai aggiungendo tempo al ciclo "fix bug; test; next" in cui gli sviluppatori stanno lavorando.

Dal punto di vista interpersonale, le persone non sono mai state costrette a utilizzare i server lenti, ma se si utilizzano i server lenti, non è necessario eseguire alcuna manutenzione o configurazione. Inoltre, questa configurazione esisteva fin dall'inizio, non riesco a immaginare di provare a venderlo a un team di sviluppo affermato.

Dopo aver riletto la tua domanda originale, mi viene in mente che una cosa che mi terrorizza perpetuamente sono gli ambienti di sviluppo che differiscono dagli ambienti di produzione. Perché non utilizzare una macchina virtuale per l'esecuzione di codice che è possibile paralizzare per il runtime senza influire sulla workstation di sviluppo? Ultimamente sto usando / amando VirtualBox.

Ho intenzione di invertire anche la tendenza qui.

Aneddoto: ho lavorato per una società di sviluppo software olandese che ha aggiornato 286 computer a 486 es (sì, sono così vecchio). Nel giro di poche settimane le prestazioni di tutte le nostre librerie interne sono diminuite del 50% e i bug sono aumentati ... Una piccola ricerca ha dimostrato che le persone non hanno più pensato al codice stesso durante il processo di debug, ma hanno fatto ricorso a un codice successivo "rapido" -> compila -> test -> correggi (codice) ecc. cicli.

Correlati: quando ho avviato una filiale per quella stessa azienda negli Stati Uniti, ho finito per assumere programmatori russi perché erano abituati a PC con meno funzionalità / meno potenza ed erano programmatori molto più efficienti.

Mi rendo conto che questi erano tempi diversi e che le risorse erano molto più scarse di quanto lo siano oggi, ma non smette mai di stupirmi di come, con tutti i progressi compiuti sul fronte hardware, il risultato netto sembra essere che ogni passo avanti è negato dalla programmazione più sciatta che richiede specifiche minime più elevate ...

Quindi ... Sento che i programmatori dovrebbero essere costretti a testare le loro applicazioni su macchine che non superano la potenza di calcolo di "Joe medio" e le specifiche hardware.

L'hardware è meno costoso del tempo di sviluppo.

La maggior parte dei colli di bottiglia si trova nel database non nel PC client, ma ciò non scusa i test su macchine più lente rispetto allo sviluppatore. Utilizzare strumenti di test per testare l'ottimizzazione.

Assolutamente no. Offri ai tuoi programmatori il miglior laptop che il denaro possa comprare, una tastiera a loro scelta, più grandi schermi di grandi dimensioni, un ufficio privato, niente telefono, bevande analcoliche gratuite, tutti i libri che desiderano (che sono pertinenti), viaggi annuali a conferenze tecnologiche chiave e otterrai grandi risultati. Quindi testare le combinazioni hardware / software / browser / larghezza di banda limite superiore e inferiore.

Questo è un pensiero interessante (dare agli sviluppatori una macchina lenta può portarli a ottimizzare di più).

Tuttavia, la soluzione è strutturata in un modo migliore: inserisci i tempi di risposta nei requisiti per i programmi e disponi di una macchina di fascia bassa disponibile per i test.

Inoltre, se disponi di un compilatore / linguaggio veramente sfrenato, potrebbe essere in grado di escogitare diversi modi per generare codice e scegliere quello migliore. Ciò sarebbe aiutato solo da un computer più veloce.

Altri hanno risposto che in genere vuoi che gli sviluppatori abbiano macchine veloci. Sono d'accordo. Non saltare sulla RAM - vuoi più memoria che puoi - alcuni processi di compilazione sono molto pesanti sull'utilizzo del disco.

Le cose che potresti prendere in considerazione per sbarazzarti sono l'antivirus sulle unità di build! Questo rallenta solo e può essere un fattore di rallentamento estremamente forte.

Potresti voler lasciare che gli sviluppi si sviluppino su Linux, se possibile. Gli strumenti sono molto migliori per tutti i tipi di attività extra (basta grep per qualcosa in un file, ecc.). Questo elimina anche l'antivirus.

Il mio Macbook Pro al lavoro ha qualche anno. Tra Linux e Windows (per testare le stranezze di IE) vms così come un paio di browser Web e terminali aperti, la ruota che gira OSX si presenta molto. Indovina cosa faccio quando gira, mi siedo e aspetto. In questo caso, una macchina lenta rallenta la produttività.

Per molte applicazioni il problema sta spingendo gli sviluppatori a testare con set di dati del mondo reale prima che vengano "completati". Per le applicazioni interattive, sarebbe necessaria una macchina / VM di test di base.

Lavoro su una macchina Windows95 lenta e mi consente di scrivere in modo efficiente l'intelligenza artificiale MindForth in Forth e in JavaScript.

Chiedere ai programmatori se i programmatori dovrebbero ottenere un buon hardware è come chiedere a un uomo grasso se gli piace il cibo. So che questo è lo scambio soggettivo, ma comunque ... vale la pena farci una domanda? : P

Detto questo, ovviamente sono d'accordo con la maggioranza: NO .