Uno sviluppatore dovrebbe discutere contro funzionalità non necessarie o dannose?

Qual è un buon atteggiamento da parte degli sviluppatori quando discutono di nuove funzionalità, e in particolare di funzionalità non critiche / discutibili?

Supponiamo che tu stia sviluppando una sorta di linguaggio simile a Java, e il capo dice: "Abbiamo bisogno di puntatori in modo che gli sviluppatori possano giocherellare direttamente con la memoria degli oggetti!"

Lo sviluppatore dovrebbe abbattere l'idea perché aggiunge complessità inimmaginabili e vulnerabilità della sicurezza, o dovrebbe fare ciò che gli viene chiesto?

Questo potrebbe non essere un buon esempio, ma che dire delle cose che si trovano di più in un'area grigia, come l'aggiunta di pulsanti che interrompono il flusso di lavoro o vanno contro la struttura interna del programma, ecc.?

Qual è la distribuzione ottimale "può fare" rispetto a "non posso fare" per un programmatore regolare?

EDIT: La domanda non riguarda un cattivo capo: D

Mi interessava di più il modo in cui le persone affrontano i nuovi problemi che aggiungono una notevole quantità di problemi pur essendo marginalmente utili.

L'atteggiamento generale dovrebbe essere:

1. si lo faremo, rovineremo la complessità
2. può essere
3. no, la rielaborazione generale e le implicazioni non giustificano il cambiamento

Quale dovrebbe essere la reazione di un buon sviluppatore?

La cosa migliore è avere un incontro e presentare i pro e i contro come gruppo, e basarsi su quello discutere la soluzione migliore. Se hai una squadra, falli concordare sulla soluzione. Una volta che una squadra è d'accordo su qualcosa, i manager e i "capi" tendono ad andare con la soluzione.

Se il tuo capo non è ancora d'accordo, allora hai fatto tutto ciò che puoi fare: hai riunito la tua squadra e i tuoi dirigenti e coperto i pro e i contro e nonostante ciò il tuo capo ha scelto una soluzione potenzialmente inferiore.

La chiave di ciò è discutere i pro ei contro come gruppo. In questo modo stai discutendo quale sia la soluzione migliore con la tua squadra e allo stesso tempo stai sottolineando la decisione del tuo capo (prima che lo faccia) senza il contraccolpo politico di andare in giro dopo il fatto dicendo alla gente perché pensi che la decisione del tuo capo era quello sbagliato.

Questa è una situazione delicata che coinvolge le politiche del lavoro, ma può essere gestita in modo amichevole.

Se il tuo capo ti dice di fare compiti stupidi, allora dovresti (gentilmente) spiegare perché è stupido.

Se lui o lei non capisce il punto, allora sei obbligato a fare cose stupide. Questo è tutto. Lui è il capo. In tal caso, puoi semplicemente fare quello che dice, o parlare con il suo capo o cambiare lavoro.

Potresti dire al capo che, sebbene tecnicamente possibile, costerà X in termini di tempo e denaro speso per sforzi in analisi, progettazione, riscrittura del codice esistente, test, test di regressione, ... E poi chiedere se la funzionalità ne vale la pena . A volte la risposta sarà "sì! Dobbiamo avere questo!", A volte sarà "no, immagino di no".

Se la funzione richiesta viola un principio fondamentale dell'applicazione (come "Aggiungi un pulsante blu!" A un'interfaccia utente specificata e progettata per avere solo pulsanti rossi secondo la richiesta del cliente), penso che sia OK chiedere "Perché?" e menziona che va contro il design prestabilito.

Alla fine, quasi tutto è un "può fare" (potrebbe non essere difficile da un punto di vista tecnico aggiungere un pulsante rosso a un'interfaccia utente solo blu), è più una questione di "dovrebbe fare?"

Per rispondere alla tua domanda modificata, penso che la risposta dovrebbe essere # 2, "Forse", in attesa di ulteriori indagini e analisi.

Non vuoi rispondere # 1 "Sì, incondizionatamente" perché potresti rimanere impegnato a impegnarti in qualcosa che non sei in grado di fornire in un determinato lasso di tempo.

Non vuoi rispondere # 3 "No, è troppo lavoro" perché poi sembra che tu non sia collaborativo e inutilmente difficile.

Dal punto di vista di uno sviluppatore: MAI dire a nessuno che paga le bollette che non possono avere ciò che vogliono. Invece, potresti dire loro che non possono averlo per quel prezzo, o che non possono averlo esattamente come l'avevano concepito originariamente.

Per il tuo esempio "puntatore"; .NET, un ambiente a codice gestito, ha puntatori. Sono fondamentali per molta interoperabilità con codice non gestito. Tuttavia, l'uso "sicuro" di questi è strettamente regolato e, se utilizzato nel codice "non sicuro", quel codice richiede autorizzazioni di sicurezza più elevate in fase di esecuzione. Se stavi sviluppando un linguaggio gestito che richiedesse anche l'accesso diretto alla memoria tramite puntatori, potresti trovare uno schema simile di marshalling dietro le quinte dove potevi, usando puntatori gestiti di sola lettura in cui non era possibile eseguire il marshalling automatico e consentire " true "puntatori solo nelle aree più attendibili della base di codice.

Per i tuoi esempi di GUI: se sai che una nuova funzionalità "interromperà" il flusso corrente di codice, puoi verificarlo e svilupparlo in modo più efficace per ripristinare qualsiasi lavoro precedente svolto dal flusso di lavoro. I tuoi clienti, e talvolta anche il tuo manager, di solito non hanno idea o interesse per la struttura del programma; se qualcosa che vogliono è difficile a causa del modo in cui hai strutturato il programma, per definizione la struttura è sbagliata perché non ti consente di fare ciò che il cliente vuole.

In tutti i casi, questa nuova funzionalità può aumentare la portata del lavoro richiesto oltre a quello che il cliente aveva pensato che sarebbe stato. Ciò a sua volta richiederà un'estensione del programma, più soldi e / o una riduzione di altri lavori pianificati.

Tuttavia, se si conosce un modo per ottenere lo stesso risultato di base in un modo più semplice o più logico, ciò può essere suggerito al client. Sebbene esistano sicuramente, per fortuna devo ancora vedere un cliente che ha rifiutato categoricamente di ascoltare l'input degli sviluppatori, specialmente in un ambiente Agile in cui esiste un "proprietario del prodotto" il cui unico compito è quello di mettersi in contatto con lo sviluppo su vari dettagli necessari come questi.

Se trascorri molti anni a programmare applicazioni di grandi dimensioni e ci pensi in modo critico lungo la strada, svilupperai un senso finemente sintonizzato su quando una funzione causerà problemi che superano la sua utilità. Un'altra parola per questo è saggezza , e proprio come nel caso di altri tipi di saggezza, può essere una sfida far sì che quelli senza di essa vedano il suo valore.

Altri poster hanno sostenuto che dovresti provare a quantificare il costo del problema che verrà introdotto da una caratteristica problematica, e che è una buona idea quando è possibile, ma di solito non lo è. Di solito è possibile solo stimare i costi di implementazione immediati. Anche questo è spesso difficile per funzionalità più grandi. Per quanto riguarda i costi futuri, sei in una situazione difficile. Non si sa con certezza quali altre funzionalità saranno necessarie o per quanto tempo il prodotto sarà in manutenzione. Il costo sarà di solito molto più alto di quanto si possa fare con una stima basata su fatti concreti.

Più competenza hai dimostrato in passato, più margine di manovra dovrai semplicemente dichiarare una caratteristica una cattiva idea. Ciò può venire solo con il tempo e una dimostrazione di successo dimostrato. Detto questo, dovresti sempre esprimere l'entusiasmo per soddisfare la richiesta, poiché è ciò che il tuo cliente desidera. Dovresti esprimere riserve in base alla tua esperienza e, una volta ottenuto, diventa un problema nel 90% dei casi perché inizierai una conversazione che arriva alla radice del problema, ovvero: Perché ti hanno chiesto di aggiungere questa caratteristica in primo luogo? A quel punto puoi offrire alternative o forse concordare sul fatto che sebbene la funzionalità richiesta introduca problemi, è ancora necessaria.

Naturalmente è anche possibile che tu abbia torto. L'ingegneria del software non è divertente?

Poiché la domanda è piuttosto vaga, generalizzerò un po 'con la mia risposta.

Interrogali sempre, ma ascolta il loro ragionamento. A volte, le persone dimenticano semplicemente la praticità di una funzione o il tempo necessario per la programmazione. D'altro canto, a volte restiamo bloccati nella mentalità del programmatore di essere efficienti / senza fronzoli / ecc. E dimentichiamo che ciò che consideriamo non essenziale per un progetto non è davvero per il cliente.

Se hanno una buona ragione, fai loro sapere quanto tempo ci vorrebbe per programmarlo e tutti i possibili dossi che ti imbatterai durante l'implementazione e vedere se vorranno ancora procedere con esso. Altrimenti, spiega perché non pensi che sia una buona idea e vedi qual è la loro reazione. Risciacqua e ripeti.

Quasi tutto è già stato detto, ma c'è una cosa che vorrei sottolineare nel mio attuale ambiente di lavoro. Lavoro per un'azienda che è un appaltatore per altre società e le nostre applicazioni sono legate ai processi aziendali (in buona parte guidano le vendite e la comunicazione con i clienti).

I processi aziendali insieme ai prodotti di accompagnamento possono essere (almeno se l'azienda è abbastanza grande) molto complessi. In una certa misura, se stai modellando una cosa complessa, l'applicazione risultante avrà una complessità relativa. Poiché la maggior parte degli individui del mondo degli affari vede solo la propria parte del processo, l'intera applicazione / processo si basa su una maggiore complessità rispetto a ciò che è visibile a un solo utente.

Il mio punto è che quando si presenta una nuova esigenza aziendale, funzionerà per gli uomini d'affari, perché non aumenta la complessità molto più in alto, ma può avere un impatto maggiore sull'intero sistema. A mio avviso, questo non è un motivo per contestare questo cambiamento. È il punto giusto per discutere gli sforzi (e le spese) con il cliente. Probabilmente non impedirà al cliente di realizzare quella funzionalità, ma col tempo avranno un'idea delle applicazioni e di alcune discussioni su "uh, sei così costoso!" sarà molto meno esigente.

Non so se ti trovi in ​​una situazione comparabile, ma ho imparato che la situazione degli stakeholder non ha necessariamente la stessa complessità che si presenta imminente come quella che devono affrontare gli sviluppatori e gli architetti del sistema IT. In quella situazione la comunicazione aiuta entrambe le parti.

Mi scusi, ma questa domanda sembra un minore che chiede un consiglio paterno. In tal caso, il buon sviluppatore dovrà adottare questi comandamenti:

• Resta fedele a te stesso. Se il tuo istinto si sente a disagio per una funzione, esprimi le tue preoccupazioni in modo udibile. È probabile che la squadra sia in attesa di un'apertura.
• Non cercare di sostituire l'esperienza con le regole empiriche dell'esperto. Per te, ogni situazione è diversa, ogni funzionalità è nuova. Questo è un vantaggio che i tuoi anziani non hanno.
• Lo sviluppo del software non è scienza esatta, non lo sarà mai. Pertanto, accumula saggezza, non comportamento.
• Accetta la sconfitta. Se la squadra concorda diversamente, non ripetere le tue preoccupazioni fino alla nausea.
• Pensare positivo. Se l'idea sta davvero implorando di "abbatterlo", prova a trovare e nominare aspetti positivi prima di elencarne le carenze.
• Scopri come interagire con le persone. Noi sviluppatori spesso mettiamo le conoscenze tecniche sulle competenze sociali. Le capacità tecniche raggiungono il picco all'inizio della vita, ma la competenza sociale può continuare a crescere fino al pensionamento.

Credo nel respingere i cattivi requisiti. Ma credo anche che quando hai dato il massimo per spiegare perché sono cattivi e li vogliono ancora, allora accetti e fai il tuo lavoro.

Ad esempio, ho avuto persone che desiderano requisiti che si escludono a vicenda da qualcosa che l'applicazione già fa. Se lo faccio, allora questo, garantito al 100%, si romperà. Quindi rispedisco il requisito e dico loro che questo infrange questa altra regola aziendale che abbiamo già in atto e vogliono cambiare anche questa regola? Spesso il piccolo gruppo che presenta un requisito particolare non ha accesso al quadro più ampio di ciò che il resto dell'applicazione potrebbe fare. Il più delle volte quando ne ho inviato uno di questi, il cliente si è reso conto che la regola iniziale era più critica e ha deciso che il cambiamento che desideravano non valeva la pena. Quando hanno deciso di apportare il cambiamento, lo hanno fatto dopo aver consultato le persone che hanno spinto il requisito iniziale.

A volte basta fare domande di chiarimento per far capire loro che il problema non è così semplice come pensavano. A volte vuoi chiedere perché vogliono qualcosa e venire alla reale necessità che sta guidando il cambiamento. Una volta che lo capisci, è spesso più facile vedere una soluzione alternativa che funziona per te come sviluppatore e soddisfa le loro esigenze. Se riesci a presentare quella soluzione in termini di come soddisferà meglio le loro necessità rispetto al suggerimento originale, hai notevolmente migliorato le tue possibilità di far accettare il tuo cambiamento.

A volte, quando un cambiamento creerà il caos a un livello di base nella progettazione, basta dare loro la nuova stima delle ore che il cambiamento richiederà per spegnerlo. Se lo combini con una valutazione del rischio che evidenzia in quali funzionalità critiche potresti introdurre nuovi bug nel dire loro che ci vorranno 6 settimane di impegno dedicato da parte di 3 persone, improvvisamente non è più così importante.

Ma a volte dici loro che non è una buona idea e perché e continuano a dire "Peccato che ne abbiamo bisogno". Ne vinci un po 'e ne perdi un po' e, a volte, le esigenze aziendali sono davvero cambiate e l'applicazione deve adattarlo. Una volta che la decisione è stata finalizzata, non è più il momento di mettere in discussione ciò che stai facendo e il tempo di continuare a farlo. Se hai documentato le tue obiezioni, allora dovresti comunque trovarti personalmente in un buon posto quando supera il budget e causa nuovi e più interessanti bug. E potrebbero anche essere più disposti ad ascoltarti la prossima volta che avrai accumulato un track record di essere proprio su questo tipo di cose.

La chiave per vincere molte di queste discussioni (nessuno le vince tutte) è innanzitutto creare un track record per sapere di cosa stai parlando. Successivamente invia un documento scritto che dichiari ciò che hai (molti manager sono avversi al rischio, è più probabile che non desiderino che qualcuno abbia un documento che lo dimostra in seguito in modo errato, quindi prestano maggiore attenzione a ciò che metti per iscritto) per assicurarsi che comprendano tutti i costi (non solo le ore, ma i rischi per la sicurezza, l'introduzione di nuovi bug, le scadenze mancanti, ecc.) della modifica. Il cambiamento non è gratuito e devono capirlo. La chiave successiva è farlo come un adulto e non come un bambino piagnucoloso ("ma non voglio usarlo ... perché non mi piace"). Crea un caso aziendale per non farlo e otterrai molto di più nel respingere un cattivo requisito.

Se ti leggo correttamente, la vera domanda è sulla complessità sconosciuta. Inizialmente ho letto la tua domanda come "Vedo il rischio estremamente probabile di eccessiva complessità ma il capo no" Ma stai dicendo che il capo non è un problema, quindi presumo che tu non sia sicuro di quali rischi di aggiungere una complessità inaccettabile.

In tal caso, consiglierei una sorta di strategia di mitigazione del rischio. Immagine che stai considerando di aggiungere servizi Web / WCF alla tua API, che potrebbe essere eccezionale o molto complessa senza ricompensa:

• aggiungi la funzione su un ramo. Se funziona, uniscilo. Se si trasforma in un nido di topi, uccidilo.
• accendere un nuovo progetto di una pagina e fare una prova del concetto. Se non riesci a fare una prova del concetto in breve tempo, lasciala cadere. Se la prova del concetto funziona, ingrandiscila e integrala con la tua
• setacciare il Web alla ricerca di persone attente a tale funzionalità o tecnologia. Laddove vi sono molti problemi, una tecnologia potrebbe comportare rischi reali di eccessiva complessità. Java Beans e COM + sono probabilmente vecchi, ma buoni esempi di funzionalità che hanno davvero aumentato la complessità e che potrebbero o meno aver offerto i vantaggi dell'equazione

Discutere n. Discutere possibilmente sì. Ma dovrebbe essere trattato come un'aggiunta alla specifica e prioritario con altre funzionalità. Se sai che la richiesta aggiungerà una quantità irragionevole di tempo e complessità da implementare, dichiaralo in anticipo. Non come opposizione a fare la richiesta, ma solo come una spiegazione di ciò che pensi ci vorrà per implementare.

Dipende molto dalla richiesta. L'implementazione del puntatore è abbastanza grande per realizzare un intero progetto, quindi i suoi meriti dovrebbero essere valutati se viene data una scelta.

Implementazione di un pulsante che interrompe il flusso. Forse non è un grosso problema se il modulo può essere strutturato in modo che il pulsante sia facoltativo. In effetti ho fatto proprio questa cosa. Ho aggiunto il pulsante ma ho anche raccolto abbastanza informazioni prima che il pulsante diventasse facoltativo. Gli utenti che si aspettavano che fosse lì lo usavano e quelli che si rendevano conto che era semplicemente ridondante non lo facevano.

Si tratta di bilanciare e sapere quando scegliere le battaglie. Alcune cose sono più facili da implementare comunque rispetto agli aspetti sociali del non includerlo.

Il problema che vedo è che usi la parola argomentare.

Devi far emergere i problemi di progettazione e il ragionamento che li sta dietro, ma fai attenzione perché i programmatori hanno la tendenza a diventare difensivi sulle posizioni che hanno preso e a discutere i punti solo per il gusto di discutere (a volte). Devo impedirmi di discutere un bel po '- e non sempre ci riesco. Inoltre, invecchiando, scopro di sbagliarmi più spesso di quanto non fossi prima o, peggio ancora, non riconoscevo quanto spesso mi sbagliavo :)

Se hai dichiarato chiaramente i requisiti (la lingua deve essere sicura, abbiamo bisogno di indicazioni per accedere alle routine legacy), allora potresti presentare come i due requisiti sono in conflitto e chiedere quale sia più importante. Una volta che hai i requisiti e le ragioni alla base, potresti persino essere in grado di trovare una soluzione completamente diversa che supporti entrambi i requisiti (JNI - kinda).

In caso contrario, forse è un buon momento per codificarli!

1. Renditi conto che non sai tutto e non puoi fare tutto.

2. Se sei sicuro che sia una cattiva idea, dì ciò che è male.

3. Se provano a spingerti su di te, dì uno di questi: hai bisogno di più tempo per analizzare, se hai bisogno di più tempo o dici che non abbiamo trovato una buona soluzione a questo problema.

4. Se insistono ancora nell'implementare la cattiva idea, ottieni una conferma da loro che hai sconsigliato, inclusi i tuoi motivi. Puoi persino inviare un'email al riepilogo della discussione con una copia al tuo responsabile. Questo potrebbe salvare il tuo ** in un secondo momento.

In uno scenario ideale avresti uno sviluppatore principale che prende le decisioni finali sul lato tecnico e un responsabile commerciale che prende le decisioni finali sul lato aziendale. Ciò risponderebbe alle due domande principali:

1) Cosa? Cosa vuole il cliente?

2) Come? Come possiamo ottenere questo risultato dal punto di vista tecnologico.

Ciò che il cliente desidera è il decisore finale in quanto sono quelli che pagano le bollette

Come sviluppatore, non dovresti davvero preoccuparti di quali requisiti sono richiesti per essere implementati.

Tuttavia, dovresti spiegare se qualcosa non è realistico e se ci sono modi migliori.

A volte è effettivamente la sua richiesta del cliente (proveniente dalla politica interna del cliente). Quindi è senza speranza e deve essere fatto (ma il management dovrebbe anche considerare se continuare tale progetto o se dovrebbero rinegoziare il prezzo.)

Questo è quasi un compito quotidiano per me, e in effetti sono contento che lo sia.

Se hai la possibilità di esprimere la tua opinione sul fatto che determinati requisiti debbano o meno essere parte della domanda, le persone non tecniche si aspetteranno che tu compili le tue conoscenze tecniche (ad es. "L'uso di puntatori renderebbe instabile l'applicazione" o "usando un parametro GET a scopo X è un rischio per la sicurezza "). I colleghi tecnici apprezzerebbero anche il tuo feedback su alcuni vantaggi o svantaggi specifici a cui potrebbero non aver pensato.

Certo, è difficile quando tutti vogliono la funzione X e si finisce per dire "potrebbe non essere buono", ma alla fine tutti cercano di creare un'applicazione sicura, robusta e stabile (gestibile, flessibile, ecc ... ) e ogni voce dovrebbe contare.

Rispondere alla tua domanda, non fa parte del lavoro di uno sviluppatore (che è di sviluppare), ma è un "extra" che offre qualità e lavoro di squadra.

Se sei in grado di capire i contro di farlo (complessità, mancanza di usabilità, ecc.), Allora è nel miglior interesse di tutti per te spiegarlo al meglio delle tue capacità. Spesso i non sviluppatori non comprendono i problemi legati all'aggiunta di nuove funzionalità. È facile per loro perché non devono fare nulla o nemmeno pensarci.

Tuttavia, se i poteri che determinano l'aggiunta della nuova funzione, dovresti fare il miglior lavoro possibile. È una sfida.

E, se la nuova funzionalità è troppo stupida o l'ambiente di lavoro troppo scadente, allora è tempo di trovare un altro lavoro.