È un ordine aziendale passare a un certo IDE una bandiera rossa? [chiuso]

"Ora ordini, senza discussione , è venuto giù che tutti devono passare ad Eclipse."

Penso che questo sia la vera bandiera rossa. Il tuo team è l'esperto nello sviluppo del software e colui che deve essere influenzato dalla decisione, eppure non sei riuscito a dire una parola nella discussione che ha portato a questo ordine?

Sembra una gestione eccessiva da parte di capi dai capelli a punta. La persona / squadra che ha preso le decisioni ha informazioni rilevanti per quella decisione?

Dato che i decisori sono sufficientemente qualificati per tale decisione, non chiedere l'opinione del team di sviluppo ha almeno due difetti:

• Il team non si sente coinvolto. Coinvolgere la squadra dovrebbe essere una priorità per la gestione. Non mi piacerebbe lavorare come dev da qualche parte dove la mia opinione su questioni così centrali come l'IDE non è valutata abbastanza da essere persino richiesta. Ammesso che chiedere l'opinione di qualcuno e poi decidere contro di esso potrebbe essere peggio, ma in tal caso mi aspetterei una solida motivazione per quella decisione.

• La gestione, per quanto esperta, non funziona al 100% con lo sviluppo di questo specifico codice. Supponendo che le persone che non hanno una visione interessante sarebbero ingenue. Certo, può essere che i manager avessero pensato a tutto ciò che gli sviluppatori hanno inventato, ma l'unico modo per saperlo è chiedere.

È ragionevole che quando si lavora insieme su un progetto comune, su ogni workstation si disponga di tutti gli strumenti disponibili per modificare / compilare / eseguire il debug del software e che gli strumenti principali per eseguire circa il 90% dello sviluppo siano noti a tutti nel team. Questo obiettivo è più difficile da raggiungere se la tua squadra sta crescendo e tutti usano il suo set di strumenti preferiti: più persone, più opinioni. E anche il lavoro amministrativo diventa più semplice se non si aumenta il numero di strumenti più del necessario.

Ovviamente, se uno sviluppatore insiste a utilizzare il suo editor preferito personale, potrebbe essere ok fintanto che si assicurerà che la sorgente non appaia o si comporti diversamente nell'editor principale del team (nel tuo caso Eclipse), quindi se dev b deve modificare la sorgente di dev A, dev b non dovrebbe essere forzato ad apprendere l'editor preferito personale di A per essere in grado di cambiare la sorgente in modo efficace. Ma attenzione, se i due devono collaborare di volta in volta davanti allo stesso display (o fare un paio di programmazione), le cose sono spesso più facili se l'editor scelto è ben noto da entrambi.

Per motivi di programmazione della coppia, è bello che entrambe le parti davanti allo schermo abbiano le stesse abilità quando usano la tastiera. È anche bello sapere che, se il tuo progetto ha esigenze particolari di configurazione nell'IDE, allora è configurato allo stesso modo per tutti. Avviare un nuovo sviluppatore è più semplice quando gli strumenti sono gli stessi per tutti.

Ma se lo paragoni al solo tentativo di essere più efficace, allora non ne vale la pena

Sì, è un po 'una bandiera rossa che il management si considera un giudice migliore su quali strumenti si sarebbero più efficienti di quello che sei.

Non è una bandiera rossa di per sé.

A volte la gestione deve prendere decisioni . Tutti i problemi che richiedono la standardizzazione su qualcosa tendono a rientrare in quella categoria. Una volta ho lavorato presso un cliente che aveva permesso agli standard di andare alla deriva per alcuni anni e avevano più di 20 strumenti SCM diversi. Ciò che è iniziato come scelta indipendente da parte di diversi team di sviluppo si è trasformato in un incubo logistico che ha gravemente ostacolato la condivisione delle competenze e la collaborazione sul codice in tutta l'organizzazione. La build integrata era ..... ehm ..... non molto integrata .....

Inoltre, non è pratico o necessario consultare tutti per ogni decisione . La misura in cui ciò deve essere fatto dipende dalla cultura dell'organizzazione e dall'importanza / complessità della decisione. Di solito prendi una di queste opzioni meno consultive:

1. Prendi la decisione da solo, se hai una conoscenza sufficiente dei pro / contro e non è una decisione abbastanza importante da richiedere un'ampia consultazione.
2. Consulta alcuni individui chiave (che probabilmente sarebbero gli sviluppatori senior più qualificati per prendere la decisione).
3. Aumenta il fatto che stai prendendo una decisione per tutti coloro che potrebbero essere interessati (e-mail, riunione del municipio, riunioni di gruppo). Di 'quello che pensi sia la decisione giusta ma che sei disposto a cambiare questo se emergono nuove prove contrarie. Invita le persone a farsi avanti individualmente se hanno punti di vista importanti
4. Invita le persone a formare un sottogruppo per esaminare le opzioni e raccomandare una decisione. Buona opzione se si tratta di una vera chiamata ravvicinata, non si conosce la risposta e si desidera che gli interessati vengano acquistati nella decisione.

Per qualcosa come gli strumenti per gli sviluppatori (che è un problema potenzialmente controverso) probabilmente farei 2 seguiti da 3 o 4, cioè ci sarebbero sicuramente delle persone con cui non parlerei personalmente sul problema, ma sul D'altra parte la maggior parte delle persone chiave potrebbe avere la possibilità di contribuire al processo decisionale.

Per me la bandiera rossa reale sarebbe intorno se si sente strongmente che è stata presa la decisione sbagliata (sbagliato == danneggia la compagnia piuttosto che il proprio strumento preferito non è stato scelto). Come reagisce la direzione quando si solleva il problema:

• Una buona gestione ascolterà le tue argomentazioni, ti ringraziamo sinceramente per il feedback e riconsiderare la loro posizione nel caso in cui hai sollevato nuove informazioni . Potrebbero non essere ancora d'accordo con te e potrebbero attenersi alla loro decisione, ma apprezzeranno che l'hai sollevato con loro e ti fanno la cortesia di dire perché si attengono alla loro decisione. Potrebbero persino cambiare il modo in cui prendono tali decisioni in futuro, e se hai fatto dei buoni punti potresti includerti nella loro lista di "persone intelligenti da chiedere".
• La cattiva gestione si farà difensiva, dirà che "la decisione è presa" e altre tattiche del genere per evitare di affrontare il fatto che potrebbero aver preso una decisione sbagliata. Potrebbero vederti come un "piantagrane". La compagnia soffre, così come la tua fiducia nella gestione. Questa è una vera bandiera rossa! Esci finché puoi!

Se stai usando Maven o qualcosa di simile, non dovrebbe importare quale IDE stai usando. Potrebbero esserci casi in cui uno è legato a un IDE specifico come Eclipse, se ci sono plugin su cui fare affidamento.

Penso che dovresti essere in grado di scegliere il tuo IDE, l'IDE in cui sei più produttivo. Tuttavia, come ho già affermato, ci sono casi in cui ha senso usare un IDE standard.

Avrei installato l'IDE "mandated corporate", ma continuerei a fare gran parte del mio lavoro in qualsiasi IDE volessi - non è come se qualcuno potesse dire quale IDE è stato utilizzato per modificare un file sorgente.

Sul fronte IDE vs editor ... per quasi tutte le lingue, io preferisco preferire un IDE (IntelliJ) perché c'è molto di più che può fare per te rispetto a un editor. Ci sono alcune cose in cui tengo ST2 o Emacs, ma per la codifica giornaliera, nonostante mi piaccia tanto ST2 / Emacs, l'IDE vince quasi sempre.

Ogni team in cui sono mai stato ha avuto una molteplicità di IDE ed editori: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - non è mai stato un problema. Mai.

Per me questo parla di un fraintendimento agli alti livelli dell'organizzazione, di ciò che conta davvero. Ciò che conta è lasciare che i bravi programmatori facciano ciò che devono fare e utilizzare gli strumenti che li rendono più constrongvoli. L'uniformità IDE ha molto poco a che fare con la comunicazione reale che si svolge sulle questioni essenziali dell'architettura degli oggetti, dei test delle unità, degli algoritmi, ecc.

Avere lo stesso IDE del ragazzo successivo significa solo che entrambi sappiamo come sfogliare il codice con le stesse scorciatoie e come viene configurata la nostra compilation / configurazione. Nessuno dei quali avrà importanza quando si parla di problemi di codice reali.

Guarda, è vivibile, a seconda di altri fattori dell'azienda. Puoi sempre usare il tuo editor preferito per le cose di tutti i giorni. E forse il tuo gruppo sta facendo altre grandi cose che creano una grande cultura. Ma gli IDE mandati sono un enorme IMO falso. Per me, se I stavamo intervistando un'azienda e mi hanno informato quale IDE mi è stato permesso da usare, vorrei ringraziarli gentilmente per il loro tempo.

In il nostro negozio Ruby c'è una strong raccomandazione di usare l'IDE di cui gode la maggior parte del team (RubyMine), perché sappiamo che fa il lavoro e possiamo insegnarci a vicenda scorciatoie ecc.

Gli sviluppatori sono liberi di utilizzare un IDE diverso, ma richiediamo loro di avere solide competenze in quell'editor nel caso in cui lo scelgano. Se vediamo qualcuno che fatica a navigare nel loro progetto o modifica il testo nel proprio FooEdit personalizzato, RubyMine è per loro.

Se un programmatore è un esperto di un dato IDE, dovrebbe utilizzarlo. Se non sono esperti in qualsiasi IDE, probabilmente ci sono uno o due che sono molto comuni per il tuo linguaggio di programmazione o all'interno del tuo team, e probabilmente ha senso che lo imparino.

Essere costretti a standardizzare su un IDE sembra una pessima idea.

Le ragioni per cui un'azienda deve forzare un particolare editor o software in generale sui propri sviluppatori dovrebbero essere esaminate. La paranoica (forse non la parola che sto cercando) parte di me pensa che potrebbe esserci una sorta di tracciamento della produttività aggiunto all'eclissi che stanno chiedendo agli sviluppatori di installare. Un pensiero molto meno paranoico (ancora una volta) sarebbe che hanno speso tempo ad aggiungere strumenti di build del prodotto a questo IDE che renderebbe le cose molto più facili se tutti premessero lo stesso pulsante per testare e compilare il loro ramo di codice.

In ogni caso, quello che sto cercando di dire è probabilmente più di una semplice burocrazia, o un metodo per scherzare con i responsabili degli sviluppatori.

Questa è una massiccia bandiera rossa. Ogni azienda ha alcune idee così stupide, ma se continuano a venire altre bandiere rosse, basta andarsene.

È facile per la motivazione alla base di alcune decisioni di perdersi, soprattutto con una squadra in rapida crescita. La motivazione per passare a Eclipse potrebbe essere il fatto che la maggior parte degli sviluppatori sembra sprecare un sacco di tempo semplicemente configurando l'IDE e che l'esperienza con la tua azienda è limitata.

Vorrei solo prendere l'ordine di passare a Eclipse per indicare che dovresti avere l'installazione di Eclipse nel caso sia necessario, ma continuare a lavorare nel tuo editor preferito. (Potrebbe essere necessario passare a Eclipse gradualmente se la tua azienda inizia a distribuire strumenti interessanti in Eclipse.)

Bandiera rossa: aspetterei se ci siano altri ordini irrazionali di questo tipo prima di essere preoccupati.

Una startup sta generalmente cercando di rimanere agile abbastanza a lungo da capire un modello di business sostenibile. Una volta individuata la parte di denaro, la direzione si sposta per aumentare l'attività. Generalmente, quando tutti i dipendenti della prima tecnologia iniziano a partire, poiché i processi di ingegneria si restringono.

Come sai, non sai che codice farà effettivamente fino a quando non lo esegui. Turing ha dimostrato che nei primi giorni dell'informatica. Ciò significa che non esiste alcuna misura significativa di produttività quando si tratta di scrivere software. Tuttavia, affinché la direzione faccia il proprio lavoro, la produttività deve essere leggibile. Dato che non puoi misurare il codice (e le persone hanno provato - linee di codice, ad esempio), misureranno ciò che possono vedere. I programmatori sono più leggibili del software che sviluppano. Il tipico team di gestione cerca di controllare i programmatori per renderli leggibili (invece di fare il loro vero lavoro: togliersi di mezzo). E poiché misurano le cose sbagliate, non funziona molto bene.

Detto questo, puoi ancora fare un lungo cammino con una squadra poco unita. Il team di sviluppo di Github ha circa 50 persone e infrangono ogni regola nei manuali di gestione aziendale. Sembra che stiano andando bene. I bug vengono risolti (eventualmente). Le caratteristiche vengono aggiunte. Gli incendi si spengono.

Che cosa è una grande bandiera rossa è se stanno cercando di scalare le cose senza aver capito come fare soldi. A quel punto, ti chiedi quante delle tue opzioni e sovvenzioni non investite valgono davvero.

Sicuramente questa è una cattiva idea. È inevitabile che la squadra diventi meno produttiva dal momento che devono imparare a usare nuovi strumenti. E anche allora non saranno efficaci come con gli strumenti che già grok .

Da quando ho provato vari strumenti, ho sempre avuto a un certo punto la sensazione di "accidenti, questo editor mi infastidisce con < inserire qualche bug / differenza dallo strumento preferito >". Quindi sarà anche un limite morale.

Ma ovviamente ci sono anche dei pro per avere un intero team che usa gli stessi strumenti. Condivisione di configs, skripts, plug-in e tutto quel genere di cose. Quale non sarebbe possibile con una varietà di strumenti.

D'altra parte ... quell'ultimo bit non sarebbe necessario se tutti usassero il suo software preferito. ;)

Se stai usando Git e la tua diramazione è inattiva, non dovresti aver bisogno di usare i rispettivi editor in ogni caso. Puoi semplicemente spingere un ramo e fare in modo che un altro sviluppatore lo tocchi per farlo funzionare, se davvero non riesce a capire il tuo set di strumenti. Costringere tutti a usare lo stesso editor sembra un ordine da parte di qualche capo azienda che vuole sembrare intelligente ma non capisce il modo in cui voi ragazzi operate.

Se ci pensi da un punto di vista gestionale, la ragione per cui potrebbero farlo è la conformità legale. La società è responsabile di garantire che ogni strumento utilizzato sia utilizzato legalmente e non ingombrerà anche il prodotto in fase di sviluppo. (Alcuni editor sono gratuiti per uso personale, ma non sono gratuiti per altri scopi, ecc.) Per controllare ogni strumento che ogni sviluppatore potrebbe voler utilizzare può essere costoso. Ho visto che su progetti in cui le linee temporali sono serrate, il management sarà cauto riguardo a quali strumenti / librerie / etc vengono utilizzati per minimizzare le modifiche successivamente nel progetto che sono dirette da persone legali.

Su progetti di sicurezza più elevati c'è anche la preoccupazione di dove gli IDE memorizzano i file temporanei e quali informazioni sono memorizzate tra le sessioni.

Tutto dipende dai motivi per cui consigliano Eclipse. Se gli sviluppatori hanno problemi a configurare i loro ambienti perché tutti organizzano le cose in modo diverso, potrebbe esserci un motivo per raccomandare una camicia di forza. Se, tuttavia, tutti fossero felici e produttivi usando ciò che volevano, non c'è motivo di imporre un cambiamento a qualcosa di così profondamente coinvolto nel processo creativo.

Eclipse è molto più di un editor: puoi continuare a utilizzare il tuo editor preferito per modificare il tuo codice e affidarti a Eclipse per il controllo del codice sorgente, il debug e qualsiasi altra cosa il flusso di lavoro aziendale richiesto desideri.

Un'ultima cosa: l'applicazione del processo in questo livello potrebbe indicare che la società intende espandere il team di sviluppo e desidera disporre di un certo numero di strutture in modo che i nuovi compagni di squadra possano diventare produttivi più rapidamente. Se pensi che Rails (o Django) sia un framework "supponente", ti renderai conto che avere una struttura aiuta a comprendere le nuove applicazioni più facilmente.

La bandiera rossa non è tanto un singolo IDE / editor che viene forzato su ogni sviluppatore, ma che questa decisione, e in particolare la decisione su quale IDE / editor debba essere usato, non è stata presa da tutti gli sviluppatori, e forse nessuno di loro!?!

Certamente sarebbe meglio per gli sviluppatori raggiungere un consenso, soprattutto perché sono ovviamente i più qualificati per la decisione (almeno su quale editor / IDE). Ci possono essere delle buone ragioni per conformarsi e questa decisione dovrebbe pesare - nella preferenza del management, ma quale editore / IDE avrebbe dovuto essere la decisione di tutti gli sviluppatori.

Ottenere 12 sviluppatori per esprimere voti sarebbe facile. Sicuramente c'è stato abbastanza tempo per farlo! La conclusione sarebbe stata dolorosa per alcuni comunque e alla fine potrebbe anche essere Eclipse, ma etichettare il requisito come una "bandiera rossa" in quel caso sarebbe molto più discutibile.