Come i manager scelgono i linguaggi di programmazione


23

Non è un segreto per nessuno che i manager possano e spesso imporranno il linguaggio di programmazione che verrà utilizzato per un progetto.

Essendo un programmatore, non sono mai stato in grado di capirlo.

Ma ora penso di sì: ho appena avuto una rivelazione quando Joel Spolsky ha detto sul podcast che avrebbero dovuto usare QuickBooks perché "ogni contabile del mondo lo sa". Mi è sembrato molto simile a "ho scelto Java perché ogni programmatore del mondo lo sa".

Ora che ho visto lo stesso problema da un'altra prospettiva, non so molto sulla contabilità, ma so qualcosa sulla programmazione, mi chiedo come un programmatore può aiutare a assicurarsi che sia scelto il giusto linguaggio di programmazione per un progetto ?


Ricorda sempre che un manager è qualcuno che crede che nove donne possano dare alla luce un bambino in un mese!
meno

Risposte:


29

L'errore che molti programmatori commettono è che discuteranno il punto (o semplicemente saranno d'accordo o in disaccordo con esso) basato esclusivamente sul merito tecnico. Con il management - e il business nel suo insieme - devi discutere il business case e i meriti per il business prima e meriti tecnici in secondo luogo.

Questo va oltre la scelta del linguaggio di programmazione e pervade praticamente ogni decisione tecnica.

Lascia che ti faccia un esempio: PC. Joel sostiene (correttamente) che gli sviluppatori dovrebbero avere macchine di prima qualità perché il tempo degli sviluppatori è costoso. In questo ha perfettamente ragione. Ma come si discute? Semplice:

Esempio: faccio una build del codice circa 20 volte al giorno. Ogni volta ci vogliono 3 minuti. Se avessi un PC veloce potrei costruirlo in 1,5 minuti. Quindi per un extra di $ 1.000 ogni due anni posso ottenere una mezz'ora in più al giorno, che per un programmatore che guadagna $ 100k (con un costo di almeno un altro 50%), che equivale a circa $ 10.000 all'anno.

Ma discutere all'altra estremità è che le risorse umane decidono una taglia per tutti quando si tratta di policy e PC, quindi un lavoratore del call center che guadagna $ 25k e un programmatore che guadagna quattro volte che per qualche motivo dovrebbe avere lo stesso PC.

La piattaforma tecnologica e le lingue avranno molti fattori che vanno nel mix decisionale:

  • Relazione strategica con venditori particolari. Se la tua azienda è un Microsoft Gold Partner (o come si chiama ora), buona fortuna con Java o Python;
  • Il dipartimento IT ha discusso di una configurazione particolare perché i soldi per i PC escono dal loro budget;
  • L'IT che decide che tutti dovrebbero eseguire Windows 2000 perché non hanno persone che usano Linux;
  • Quali altri sistemi ha già l'azienda (ad esempio se usano Java per tutto il resto ha senso usarlo per questo anche se da solo potrebbe non essere la scelta migliore);
  • Avversione al rischio su piattaforme o lingue diverse semplicemente per mancanza di esperienza;
  • Più interessato a discutere dei rischi con il management superiore che a rendere felici gli sviluppatori;
  • Alcuni manager prendono le decisioni che prendono semplicemente perché le loro mani sono legate;
  • Ragioni di bilancio anche se questo può funzionare anche a tuo favore in quanto mantiene costose boondoggles fuori dalla tua casa come il PVC, qualsiasi cosa prodotta da Rational, ecc .;
  • Avversione del dipartimento legale alle licenze open source;
  • Non coinvolgere il personale tecnico nella pianificazione e nella stima del progetto;
  • Familiarità da parte del manager con una particolare piattaforma (anche i tecnici sono colpevoli di questo, ma in entrambi i casi non è necessariamente una cosa negativa - con molti strumenti che possono fare il lavoro meglio del diavolo che conosci).
  • Esperienza dello staff tecnico. Se provengono tutti da uno sfondo C #, perché dovrebbero usare Java, Python o Ruby?
  • Molte altre ragioni

In ogni caso, devi capire il motivo (e ti garantisco che ci saranno diversi motivi) e discutere dei meriti in questi termini. Alcuni programmatori sono abbastanza ingenui in questo dipartimento e sembrano pensare che tali decisioni siano prese dall'ignoranza o addirittura dalla vendetta quando quasi sempre sono in gioco molti fattori.


Risposta molto buona e dettagliata!

1
"costose boondoggles fuori di casa come il PVC, qualsiasi cosa prodotta da Rational". Hah! Divertente perché è vero;)
Rig

La mia azienda è partner Microsoft Gold, ma utilizziamo TUTTO ciò di cui abbiamo ragionevolmente bisogno. Devi presentare il tuo caso e lottare per esso, ma tutto è possibile per le persone intelligenti
Budda,

16

Da quello che mi sembra nella mia azienda: quando i manager scelgono un linguaggio di programmazione, di solito lo fanno in modo molto prudente, tenendo conto del tipo di abilità di programmazione attualmente disponibili nel team (e se sarebbe facile assumere facilmente altri ), sia che si tratti di un linguaggio consolidato, cercando di scegliere qualcosa che si adatti all'infrastruttura attuale e non provochi grandi sforzi per adattarlo a ciò che già esiste. Quando i programmatori scelgono un linguaggio di programmazione, le cose spesso tendono ad essere un po 'diverse: a loro piace avere una nuova sfida e vorrebbero ottenere con l'ultima tendenza calda e scegliere qualcosa in cui possano imparare cose nuove.

Idealmente, tutto si riduce alla discussione dei pro e dei contro tra il manager e il team di sviluppo e alla ricerca della soluzione più adatta al problema. Questo di solito comporta un sacco di chiacchiere e convincenti :-)


Perché i voti negativi?

2
Ho votato per difetto perché non hai risposto alla mia domanda. Hai appena detto un sacco di generalità. Tranne l'ultima frase, che può essere vista come una risposta. Ma è praticamente inutile.

14

Risposta in ritardo, ma poiché non esiste ancora una risposta accettata, la proverò. Lo prendo come due domande e cercherò di rispondere separatamente:

In che modo i manager scelgono i linguaggi di programmazione?

Dipende fortemente dalla dimensione dell'organizzazione e dall'esperienza del manager, ma generalmente implica la valutazione della situazione attuale e degli scenari e requisiti futuri. Questo di solito viene eseguito tramite PESTLE o analisi simili e solo per fornire alcuni esempi in ciascuna categoria:

  • Politico
    • "Nessuno è stato licenziato per aver acquistato IBM" - scelta sicura.
    • Il CEO ha appreso che Java è cool - hype.
    • Chief Architect ama .NET - progetto per animali domestici.
    • La lingua è controllata da un concorrente ostile, perché Google non si affida a C #.
  • Economico
    • Costi di licenza.
    • Costo della formazione degli sviluppatori.
    • Costi di migrazione della base di codice.
  • Sociale
    • Buy-in dal team.
    • Disponibilità di competenze in casa (esigenze di formazione, continuità).
    • Disponibilità di competenze sul mercato.
    • Minaccia allo status quo esistente all'interno del team di sviluppo.
    • Disponibilità di comunità di pratica sufficientemente ampia.
  • Tecnologico
    • Miglioramento della produttività.
    • Miglioramento di qualità.
    • Capacità di interoperare con la base di codice esistente.
    • Aderenza agli standard.
    • Scadenza.
  • legale
    • Termini di licenza.
    • Controllo della tecnologia (Chi possiede e controlla la tecnologia? Qual è probabilmente la futura strategia di licenza?)
    • Conformità legale e normativa.
  • Ambientale
    • Infrastruttura esistente all'interno dell'azienda.
    • Competenze esistenti all'interno dell'azienda.
    • Integrazione con partner esterni.
    • Livello di supporto tecnologico da parte di un ambiente più ampio.

Quindi un gruppo di lingue corrispondenti ai criteri può essere ulteriormente valutato utilizzando SWOT , analisi costi- benefici o simili.

L'intero processo può essere piuttosto complesso, ma come linea di fondo la maggior parte delle aziende o dei team di progetto sceglieranno l'opzione più sicura date le loro attuali circostanze che possono ancora offrire le capacità di cui hanno bisogno. Abbastanza spesso potrebbe significare rimanere più a lungo sulla piattaforma attuale.

In che modo un programmatore può assicurarsi di scegliere il linguaggio di programmazione giusto per un progetto?

Come è stato, si spera, dimostrato che un programmatore tipico avrebbe normalmente solo 1/6 dell'input totale nel processo decisionale. E di norma lei o lui sarebbero interessati principalmente alle capacità linguistiche da solo!

Bene, il modo migliore per influenzare la decisione sembra avere un quadro più ampio del processo di selezione, fare alleati all'interno e all'esterno del team, creare un buon brief sul lato tecnologico delle cose e cercare di non concentrarsi solo sulle capacità linguistiche.

E, naturalmente, è necessario entrare nella posizione in cui un responsabile del progetto o dello sviluppo (o chiunque altro sia responsabile) vede i benefici derivanti dall'intero processo di valutazione ed è pronto a considerare i rischi e le incertezze del passaggio a un altro la lingua in primo luogo. Perché ciò accada, è necessario dimostrare che:

  1. La piattaforma attuale non è più adeguata.
  2. Una nuova piattaforma promette vantaggi che superano di gran lunga la seccatura.

Tuttavia, avresti chiesto "Qual è il modo migliore per essere in grado di utilizzare sul posto di lavoro la lingua che mi piace", probabilmente la risposta sarebbe stata "unisciti a un'azienda che già utilizza la lingua o creane una tua".


5

Il manager A va in un ritiro estivo dove incontra il manager B.

A: Quindi quale lingua usi nella tua azienda? B: Oh usiamo CA Visual Objects, rende i droni molto più produttivi di COBOL.

Ed è così che è stata presa la decisione. Fine della storia vera.


Di che compagnia si tratta?

3

Ogni piattaforma ha lati positivi e negativi. .NET è bello e potente ma sei praticamente bloccato con i server Windows. Il rubino è bello ma lento. Sarebbe difficile trovare sviluppatori per Haskell.

Il punto è che il linguaggio non influisce sulla velocità con cui verrà realizzato il progetto e su quanto sarà bello il codice, ma anche su ciò che interessa ai manager. Quindi, se vuoi influenzarli, ora dovresti preferire e trovare il maggior numero possibile di lati positivi nella loro prospettiva.


1
Sollevi alcuni punti interessanti, ma ti sbagli nel trovare gli sviluppatori Haskell. La maggior parte delle persone che programmano a Haskell non lo fanno in un posto di lavoro, ma vogliono (e sono generalmente piuttosto intelligenti)

1
So che sono intelligenti :) Ma questo significa che non faranno un lavoro di supporto perché è noioso o dovresti pagarli molto. È come COBOL davvero, potresti trovare una persona che lo sa ma dovresti passare molto tempo a cercare e pagare più di quanto faresti per qualsiasi altro ragazzo.

No, non saprei bene oltre 300 sviluppatori Haskell che lavorerebbero gli stessi lavori che fanno ora con una retribuzione considerevolmente inferiore rispetto a quella che ottengono ora solo per lavorare in Haskell.
Rayne,

2

Separando le preoccupazioni. Le imprese dovrebbero essere responsabili delle decisioni aziendali e le tecnologie responsabili delle decisioni tecniche. Mi piace il termine "responsabilità accettata". Se devo accettare la responsabilità, chiedo anche di arrivare a fare le scelte che riguardano il mio dominio del problema. Il business offre a me e ai miei colleghi tecnici le esigenze aziendali e noi rispondiamo con una o due alternative su come possiamo accettare la responsabilità di consegnare. Non dovrebbe mai essere come "lo faremo in Python o C #". Piuttosto;

"Qui possiamo accettare due diverse responsabilità: se andiamo in questo modo, possiamo consegnare così in fretta e soddisfare queste esigenze aziendali molto bene e queste sono un po 'più difficili. Potremmo anche farlo in questo modo e questo dà a queste esigenze la briscola L'alternativa A richiede queste risorse e l'alternativa B significa che dobbiamo fare anche questo e questo ... "

Quindi il business sceglie, ma nota che il business sceglie in base all'impatto sulle cose aziendali, non su quelle tecniche. E non riescono a scegliere tra alternative in cui la tecnologia non è pronta ad accettare la responsabilità della parte tecnologica.


Molto interessante.

1

Diventa il manager. (sorriso)

Seriamente, devi solo discutere la questione con il decisore in questione e presentare le tue argomentazioni. Se scelgono di attenersi a una decisione davvero sbagliata, allora la loro competenza generale probabilmente non è così calda e potrebbe valere la pena cercare qualcos'altro da fare.


Oppure sono le tue abilità comunicative che hanno fallito e dovresti cercare di affinare quelle.

C'è anche quello.

1

Penso che la differenza tra ciò di cui stai parlando e ciò di cui Joel stava parlando è che la programmazione è una competenza fondamentale mentre la contabilità no. Il punto utilizzando QuickBooks è, presumibilmente, perché sei non è un commercialista e ragionieri possono aiutare con esso. Tuttavia, se la programmazione è la tua competenza principale, e presumibilmente lo è se sei un programmatore, le regole del gioco sono leggermente diverse.


2
La programmazione, il più delle volte, non è una competenza fondamentale per i manager.

Bene, presumibilmente, è una competenza fondamentale dell'azienda o del reparto in un modo molto diverso dalla discussione di Quickbooks.

Non posso seguirlo. Stai confrontando le mele con le arance?

Perché il downvote? Ho appena sottolineato la tua logica imperfetta. Per quanto riguarda le mele e le arance, penso che il vaso incontra il bollitore. Ciò di cui Joel stava parlando rispetto a Quickbooks è molto diverso dai manager che scelgono Java.

1

Dipende molto dalla personalità del manager:

Ci sono quelli che vanno per le parole d'ordine. Scopri quali parole d'ordine piacciono e usale quando parli con lui in combinazione con la lingua che vuoi usare.

Altri si fideranno solo delle cose che conoscono (come VB 6.0 per esempio). Rendi la tua lingua preferita facile da capire per loro ("sai, è proprio come nel buon vecchio VB" - anche se stai parlando di Haskell ...)

Ma in realtà, la maggior parte dei manager non sono così stupidi come a noi geek piace pensare e possono essere ragionati. Ciò che è importante qui è che tu capisca il loro punto di vista: di solito non si preoccupano dei dettagli tecnici specifici, si preoccupano dei risultati. Quindi non dire loro che .net o Java o Delphi o qualunque altra cosa abbia questa fantastica funzione megacool. Dì loro che (inserisci la tua lingua qui) è una buona scelta perché la funzione A riduce i tempi di sviluppo in un progetto come questo o quella B riduce i tempi di riduce il numero di bug e riduce il tempo necessario per i test. Assicurati solo che la tua discussione sia valida, non mentirgli.

In altre parole: trattalo come un essere intelligente (probabilmente lo è).


1

Pensa alla lingua che ti viene chiesto di usare molto duramente. Assicurati di sapere che non è una buona lingua per il lavoro, quindi chiedi al manager se potresti suggerire un'altra lingua migliore da usare per il lavoro. Fornisci tutte le informazioni possibili che dimostrino che la lingua non sarebbe buona per il lavoro e vedi cosa dice. Non può far male. :)


Punto interessante Ma sento che l'onere della prova dovrebbe essere sulla persona che impone la lingua, non viceversa.

Forse in un mondo da fiaba.
Rayne,

1

La scelta del linguaggio di programmazione è spesso una decisione aziendale. Ai clienti / utenti non importa. Ecco una breve citazione (da http://www.ericsink.com/bos/Geeks_Rule.html ):

I linguaggi di programmazione sono scelti principalmente per motivi di lavoro. Trascorro la maggior parte del tempo a lavorare con lingue che non mi piacciono molto perché le lingue con cui mi piacerebbe lavorare presentano svantaggi aziendali che superano i loro meriti tecnici. Questa è la natura del gioco. Posso accettare la situazione (la mia scelta) o trovare un nuovo datore di lavoro. Lamentarsi di come non posso usare Java o Python o qualunque cosa al lavoro non è un'opzione.


Sono d'accordo qui. Ma penso anche che sia importante notare che, dati i due ruoli Business e Tech, Tech avrà il contributo più importante su quale linguaggio / struttura soddisferà le esigenze aziendali. Le tute molto raramente hanno le conoscenze tecniche necessarie.

1

Innanzitutto, la programmazione è un'altra forma d'arte. Una forma d'arte molto logica. Se il tuo manager è appassionato dei suoi straordinari progetti software, che sono in qualche misura, opere d'arte, allora chiedi a quel manager appassionato quanto segue:

Quanta energia e tempo costerebbe Rembrandt in più per non dipingere con il suo pennello preferito, ma un pennello che, dopo un'attenta valutazione del team di gestione, gli viene consegnato, 400 anni fa e prima che le sue opere diventassero famose. La sua pittura avrà più o meno valore che pensi?

Allo stesso modo, se stai dicendo a un programmatore quale lingua dovrebbe essere usata, allora sii coerente e dì anche a un pittore quali dimensioni del pennello dovrebbero essere usate! O, in alternativa, lascia questa scelta alle persone che hanno bisogno di lavorarci ogni giorno e (come la maggior parte dei capolavori) ogni notte!


Creare arte usando pastelli e colori ad olio sarebbe un'analogia migliore. Tuttavia, i pro e i contro si trovano ancora sul lato commerciale - anche se l'artista potrebbe preferire i colori ad olio, il progetto potrebbe richiedere materiali a basso costo / potrebbe richiedere meno tempo di preparazione / potrebbe richiedere più longevità per questo cliente / ecc. Detto questo, l'artista dovrebbe avere input in questa scelta, ma deve rendersi conto che l'onere della persuasione e della prova ricade sulle sue spalle.
lunchmeat317,

0

Questi sono concetti diversi.

Nella contabilità, condividi i tuoi risultati: per tasse, legge, investitori ecc. Hanno bisogno di uno strumento per vedere il risultato del tuo lavoro, e questo strumento deve essere ben noto.

Durante la programmazione, si utilizza qualsiasi strumento desiderato, purché generi un .exefile che è possibile eseguire su Windows. Questo è esattamente lo stesso di un documento leggibile Quick Books in caso di contabilità.

Quindi, se sviluppi un tostapane, sei libero di conservare la tua documentazione interna in cinese, ma è meglio fornire un manuale inglese.

C'è ancora una cosa: se le regole della tua azienda assumono che il risultato del tuo codice non sia un prodotto stesso, ma un codice sorgente per esso, allora sicuramente possono decidere come sarà (scegliendo la lingua che vogliono).

Quello che scelgono dipende dai loro obiettivi: se vogliono programmatori facilmente sostituibili scelgono Java; se lo inviano a un altro dipartimento sarà il requisito di quel dipartimento ecc.


Metaforicamente parlando, l'equivalente del tostapane di ciò di cui sto parlando è la gestione che richiede che la documentazione interna sia scritta in spagnolo perché ci sono più persone che parlano spagnolo sulla Terra.

Esattamente. Se gli assemblatori di tostapane di lingua spagnola sono più facilmente disponibili sul mercato del lavoro, la documentazione ovviamente dovrebbe essere in spagnolo.

0

Nella mia esperienza è sempre dipeso da:

  1. Abbiamo le risorse per usare la lingua?
  2. Abbiamo le risorse per mantenere la lingua?
  3. Se non abbiamo le risorse per usare e mantenere la lingua quanto è difficile / costoso ottenere quelle risorse?
  4. Qual è il "futuro" della lingua (sarà presente e in uso per un po '?)

A meno che il progetto non abbia bisogno di qualcosa che solo un linguaggio / una piattaforma / una tecnologia / un quadro specifici forniscano, si riduce a ciò che già conosciamo e utilizziamo. Sia assumere nuove persone che formare programmatori esistenti è piuttosto costoso per la maggior parte delle aziende. Durante l'assunzione consideriamo sempre la lingua e ci assicuriamo che i candidati sappiano quale lingua (e) probabilmente useranno.

Spero che tu abbia un programmatore che è anche un manager e che può rappresentare programmatori in questo tipo di decisioni. Altrimenti, questa è una situazione pericolosa e dovresti parlare con il tuo manager se sai che una tale decisione è stata presa.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.