In che modo i manager scelgono i linguaggi di programmazione

L'errore che molti programmatori fanno è che discuteranno il punto (o semplicemente acconsentiranno o non saranno d'accordo con esso) basandosi esclusivamente sul merito tecnico. Con la gestione e l'azienda nel suo complesso, devi prima discutere il caso aziendale e i meriti per il business e i meriti tecnici in secondo luogo.

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

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

Esempio: eseguo una compilazione 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 guadagna $ 100k (con costi on-cost di almeno il 50%), che equivale a circa $ 10.000 all'anno.

Tuttavia, argomentando dall'altra parte, le risorse umane decidono che una taglia si adatta a tutti, quando si tratta di politica e PC, quindi un lavoratore del call center guadagna $ 25k e un programmatore guadagna quattro volte per avere lo stesso PC.

La piattaforma tecnologica e le lingue avranno molti fattori in gioco nel mix decisionale:

• Relazione strategica con determinati fornitori. Se la tua azienda è un Microsoft Gold Partner (o come si chiama ora), allora buona fortuna con Java o Python;
• Il dipartimento IT discute una configurazione particolare perché i soldi per i PC escono dal loro budget;
• Decidere che tutti dovrebbero eseguire Windows 2000 perché non hanno persone che eseguono Linux;
• Quali altri sistemi l'azienda ha già (per esempio se usano Java per qualsiasi altra cosa ha senso usarlo per questo anche se da solo potrebbe non essere la scelta migliore);
• avversione al rischio per piattaforme o linguaggi diversi semplicemente per mancanza di esperienza;
• Più interessati a discutere i rischi con il management superiore rispetto a rendere felici gli sviluppatori;
• Alcuni manager prendono le decisioni che fanno semplicemente perché hanno le mani legate;
• Ragioni di bilancio, anche se questo può funzionare anche a tuo favore, poiché mantiene costosi problemi di fuori casa come PVCS, qualsiasi cosa prodotta da Rational, ecc.
• avversione del reparto legale alle licenze open source;
• Non coinvolge lo staff tecnico nella pianificazione e nella stima del progetto;
• Familiarità da parte del manager con una piattaforma particolare (anche le persone tecniche sono colpevoli di questo, ma in entrambi i casi non è necessariamente una brutta cosa - con molti strumenti che possono fare meglio il lavoro del diavolo che conosci).
• Esperienza dello staff tecnico. Se provengono tutti da uno sfondo C #, perché dovrebbero usare Java, Python o Ruby?
• Molti altri motivi

In ogni caso, devi capire il motivo (e ti garantisco che ci saranno diverse ragioni) e discutere dei meriti in questi termini. Alcuni programmatori sono piuttosto ingenui in questo reparto e sembrano ritenere che tali decisioni siano prese per ignoranza o addirittura sfrenatezza quando quasi sempre sono in gioco molti fattori.

Da quello che ho visto nella mia azienda: quando i manager scelgono un linguaggio di programmazione, di solito lo fanno in modo molto conservativo - prendendo in considerazione che tipo di competenze di programmazione sono attualmente disponibili nel team (e se sarebbe facile assumere più facilmente), che si tratti di una lingua ben consolidata, che cerca di scegliere qualcosa che si adatti all'infrastruttura attuale e non causa grandi sforzi per adattarlo a ciò che è già presente. Quando i programmatori scelgono un linguaggio di programmazione, spesso le cose tendono ad essere un po 'diverse: spesso preferiscono avere una nuova sfida e vogliono ottenere l'ultima tendenza e scegliere qualcosa in cui imparare nuove cose.

Idealmente, tutto si riduce alla discussione dei pro e dei contro tra il manager e il team di sviluppo e trovare la soluzione che meglio si adatta al problema. Questo di solito comporta molto parlare e convincere: -)

Risposta tardiva, ma poiché non ci sono ancora risposte accettate, farò un tentativo. Lo prendo come due domande e cercherò di rispondere a loro separatamente:

In che modo i gestori scelgono i linguaggi di programmazione?

Dipende molto dalle dimensioni dell'organizzazione e dall'esperienza del manager, ma generalmente coinvolgerà la valutazione della situazione attuale e degli scenari e requisiti futuri. Di solito ciò avviene tramite PESTLE o analisi simili, e solo per dare alcuni esempi in ogni categoria:

• Politica
  • "Nessuno è stato licenziato per aver acquistato IBM": scelta sicura.
  • Il CEO ha sentito che Java è cool - hype.
  • Chief Architect ama .NET - progetto pet.
  • La lingua è controllata da un concorrente ostile: perché Google non si affida a C #.
• Economico
  • Costi di licenza.
  • Costo della formazione per sviluppatori
  • Costi di migrazione del codice base.
• Sociale
  • Buy-in dal team.
  • Abilità disponibilità in casa (esigenze di formazione, continuità)
  • Disponibilità di competenze sul mercato.
  • Minaccia lo status quo esistente all'interno del team di sviluppo.
  • Disponibilità di una community di pratica sufficientemente ampia.
• tecnologica
  • Miglioramento della produttività
  • Miglioramento della qualità.
  • Capacità di interoperare con la base di codice esistente.
  • Aderenza agli standard.
  • Maturità.
• Legale
  • Termini di licenza.
  • Controllo della tecnologia (Chi possiede e controlla la tecnologia? Qual è la probabilità che la futura strategia di licenza sia?)
  • 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 un ambiente più ampio.

Quindi un gruppo di lingue che soddisfano i criteri possono essere ulteriormente valutate usando SWOT , costo benefit analysis o simili.

L'intero processo può essere piuttosto complesso, ma come linea di fondo la maggior parte delle aziende o dei team di progetto sceglierà l'opzione più sicura data la loro attuale situazione che può ancora fornire le funzionalità di cui hanno bisogno. Molto spesso potrebbe significare rimanere fedeli alla piattaforma attuale più a lungo.

In che modo un programmatore può aiutare a garantire che venga scelto il linguaggio di programmazione corretto per un progetto

Come è stato, si spera, dimostrato che un tipico programmatore di solito ha solo 1/6 dell'input totale nel processo decisionale. E di regola lei o lui erano interessati principalmente alle sole capacità linguistiche!

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

E, naturalmente, è necessario entrare nella posizione quando un Project o Development Manager (o chiunque altro è in carica) vede i benefici di attraversare l'intero processo di valutazione ed è pronto a considerare i rischi e le incertezze del passaggio in una lingua diversa in primo luogo. Affinché questo accada, è necessario dimostrare che:

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

Tuttavia, avresti chiesto "Qual è il modo migliore per essere in grado di utilizzare sul lavoro la lingua che mi piace", la risposta sarebbe stata probabilmente "entrare in una società che già utilizza la lingua o iniziare da sola".

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

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

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

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

Il punto è che il linguaggio non influenza la rapidità con cui il progetto sarà realizzato e quanto sarà bello il codice, ma anche i responsabili di questo settore. Quindi, se vuoi influenzarli, dovresti ora avere le loro preferenze e trovare più lati positivi nella loro prospettiva che puoi.

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

"We can accept two different responsibilities here: If we go this way, we can deliver this fast and we meet these business demands really well and these are a bit harder. We also could do it this way and that gives these business demands the trump. Alternative A calls for these these resources and alternative B means we need to also do this and this..."

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

Diventa il manager. (Sorriso)

Seriamente, devi solo discutere la questione con il decisore in questione e avanzare i tuoi argomenti. Se scelgono di seguire una decisione sbagliata veramente , allora la loro competenza generale probabilmente non è così calda e potrebbe valere la pena cercare qualcos'altro da fare.

Penso che la differenza tra ciò di cui stai parlando e ciò di cui parlava Joel sia che la programmazione è una competenza di base mentre la contabilità non lo è. Il punto che usa Quickbooks è, presumibilmente, perché sei non un ragioniere e ragionieri possono aiutarti con esso. Tuttavia, se la programmazione è la tua competenza principale, e presumibilmente lo è se sei un programmatore, le regole del gioco sono un po 'diverse.

Dipende molto dalla personalità del manager:

Ci sono quelli che fanno le parole d'ordine. Scopri le parole d'ordine che preferiscono e usalo quando parli con lui in combinazione con la lingua che desideri utilizzare.

Gli altri si fidano solo delle cose che conoscono (come ad esempio VB 6.0). Rendi il tuo linguaggio di scelta facile da capire per loro ('sai, è proprio come nel vecchio vecchio VB' - anche se stai parlando di Haskell ...)

Ma in realtà, la maggior parte dei manager non è così stupida come noi pensatori amiamo pensare, e possono essere ragionate con. Ciò che è importante qui è capire il loro punto di vista: di solito non si preoccupano di dettagli tecnici specifici, si preoccupano dei risultati. Quindi non dirgli che .net o Java o Delphi o qualsiasi altra cosa abbia questa fantastica funzionalità megacool. Dì loro che (inserisci qui la tua lingua) è una buona scelta perché è dotato di A per tempi di sviluppo più brevi in un progetto come questo, o quella caratteristica B fa meno errori e quindi riduce il tempo necessario per il test. Assicurati che il tuo argomento sia valido, non mentirgli.

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

Pensa al linguaggio che ti viene chiesto di usare molto duramente. Assicurati di sapere che non è una buona lingua per il lavoro, quindi chiedi al manager se puoi dare un suggerimento su un'altra lingua migliore da usare per il lavoro. Fornisci tutte le informazioni che puoi che dimostra che la lingua non sarebbe buona per il lavoro e vedere quello che dice. Non può far male. :)

La scelta del linguaggio di programmazione è spesso una decisione commerciale. I clienti / utenti non si preoccupano. Ecco una breve citazione (dal link ):

Programming languages are chosen mainly for business reasons. I spend most of my time working with languages that I don't really like because the languages that I'd like to work with carry business disadvantages that outweigh their technical merits. That's the nature of the game. I can accept the situation (my choice) or find a new employer. Whining about how I can't use Java or Python or whatever at work just isn't an option.

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

Quanta energia e tempo costerebbe a Rembrandt extra non dipingere con il suo pennello preferito, ma un pennello che, dopo un'attenta considerazione del team di gestione, viene consegnato a lui, 400 anni fa e prima che le sue opere diventassero famose. La sua pittura sarà più o meno degna di ciò che pensi?

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

Questi sono concetti diversi.

Quando si conta, si condividono i risultati: tasse, legge, investitori, ecc. Hanno bisogno di uno strumento per vedere il risultato del lavoro, e questo strumento deve essere ben noto.

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

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

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

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

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 disponiamo delle risorse per utilizzare e mantenere il linguaggio, quanto è difficile / costoso ottenere tali risorse?
4. Qual è il "futuro" della lingua (sarà in giro e in uso per un po '?)

A meno che il progetto non abbia bisogno di qualcosa che solo una lingua / piattaforma / tecnologia / framework specifica fornisce si riduce a ciò che già conosciamo e usiamo. Sia assumere nuove persone che addestrare programmatori esistenti è piuttosto costoso per la maggior parte delle aziende. Quando assumiamo, prendiamo sempre in considerazione 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 i programmatori in questi tipi di decisioni. In caso contrario, si tratta di una situazione pericolosa e dovresti parlare con il tuo manager se sai che tale decisione è stata presa.