Uno sviluppatore dovrebbe argomentare contro caratteristiche non necessarie o dannose?

La cosa migliore è avere una riunione e presentare i pro e i contro come gruppo, e sulla base di ciò discutere la soluzione migliore. Se hai una squadra, convincili a trovare una 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, hai fatto tutto quello che puoi fare: hai unito la squadra e i dirigenti e coperto i pro ei contro e nonostante il tuo capo abbia scelto una soluzione potenzialmente inferiore.

La chiave per questo è discutere i pro e i contro come gruppo. In questo modo stai discutendo quale sia la soluzione migliore per il tuo team e allo stesso tempo stai indicando la decisione del tuo capo (prima che lo faccia) senza la reazione politica di andare in giro dopo aver detto alla gente perché pensi che la decisione dei tuoi capi era quello sbagliato.

Questa è una situazione delicata che coinvolge la politica del lavoro, ma può essere gestita amichevolmente.

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

Se lui o lei non capiscono 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 il lavoro.

Potresti dire al capo che, mentre è tecnicamente possibile, costerà X in termini di tempo e denaro speso per l'analisi, la progettazione, per riscrivere il codice esistente, i test, i test di regressione, .. E poi chiedi se vale la pena. A volte la risposta sarà "sì! Dobbiamo averlo!", A volte sarà "no, non credo".

Se la funzione richiesta viola alcuni principi fondamentali dell'applicazione (come "Aggiungi un pulsante blu!" a un'interfaccia utente specificata e progettata per avere solo pulsanti rossi secondo la richiesta del cliente), allora penso va bene chiedere "Perché?" e dire che va contro il design prestabilito.

Alla fine, quasi tutto è un "può fare" (potrebbe non essere difficile da un punto di vista tecnico per aggiungere un pulsante rosso a un'interfaccia utente solo blu), è più un domanda 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 al n. 1 "Sì, incondizionatamente" perché potresti rimanere bloccato impegnandoti in qualcosa che non sei in grado di fornire nel tempo stabilito.

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

Dal punto di vista di uno sviluppatore: NON dire mai a nessuno che paga i conti che non possono avere ciò che vogliono. Invece, potresti dire loro che non possono averlo per quel prezzo, o che non possono averlo esattamente nel modo in cui lo hanno originariamente concepito.

Per il tuo esempio di "puntatore"; .NET, un ambiente con codice gestito, ha dei puntatori. Sono criticamente necessari per un sacco di interoperabilità con il codice non gestito. Tuttavia, l'uso "sicuro" di questi è strettamente regolamentato e, se utilizzato in codice "non sicuro", tale codice richiede autorizzazioni di sicurezza più elevate nel runtime. Se stavi sviluppando un linguaggio gestito che richiedesse anche l'accesso diretto alla memoria tramite i puntatori, potresti creare uno schema simile di marshalling dietro le quinte dove potresti, usando puntatori gestiti di sola lettura in cui non puoi eseguire il marshalling automatico e consentire " veri "puntatori solo nelle aree più attendibili del codebase.

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

In tutti i casi, questa nuova funzionalità può aumentare lo scopo del lavoro richiesto oltre a quello che il cliente aveva pensato che sarebbe stato. Ciò richiederà a sua volta 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, è possibile suggerirlo al cliente. Anche se sicuramente esistono, fortunatamente non ho ancora visto un cliente che ha rifiutato categoricamente di ascoltare input dagli sviluppatori, specialmente in un ambiente Agile in cui esiste un "product owner" il cui unico compito è quello di collaborare allo sviluppo su vari dettagli necessari come questi.

Se trascorri molti anni nella programmazione di applicazioni di grandi dimensioni e ne pensi in modo critico lungo il percorso, svilupperai un senso preciso di quando una funzionalità 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 ne vedano il valore.

Altri poster hanno sostenuto che dovresti provare a quantificare il costo del problema che verrà introdotto da una caratteristica problematica, e questa è una buona idea quando è possibile, ma di solito non lo è. Solitamente è possibile solo stimare i costi immediati di implementazione. 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 richieste o per quanto tempo il prodotto sarà in manutenzione. Il costo di solito sarà molto più alto di quanto potresti eseguire con una stima basata su fatti concreti.

Più competenze hai dimostrato in passato, più margine di manovra dovrai semplicemente dichiarare una caratteristica come una cattiva idea. Ciò può venire solo con il tempo e una dimostrata dimostrazione di successo. Detto questo, dovresti sempre esprimere il desiderio di soddisfare la richiesta, poiché è ciò che il tuo cliente desidera. Devi esprimere le prenotazioni in base alla tua esperienza e, una volta ottenuto, diventa un non-problema nel 90% dei casi perché inizierai una conversazione che arriva alla radice del problema, che è: Perché ti hanno chiesto di aggiungere questa caratteristica in primo luogo? A quel punto puoi offrire alternative, o forse essere d'accordo sul fatto che sebbene la funzione richiesta introduca dei problemi, è comunque necessario.

Naturalmente è anche possibile che tu stia sbagliando. Non è divertente l'ingegneria del software?

Dato che la domanda è abbastanza vaga, generalizzerò un po 'con la mia risposta.

Interrogali sempre, ma ascolta i loro ragionamenti. A volte, le persone dimenticano semplicemente la praticità di una funzione o la durata della programmazione. Il rovescio della medaglia, a volte siamo bloccati in una mentalità di programmatore di essere efficiente / senza fronzoli / etc e ci dimentichiamo che ciò che consideriamo non essenziale per un progetto in realtà non è per il cliente.

Se hanno una buona ragione, allora fai sapere loro quanto tempo ci vorrà per programmarlo e tutti i possibili dossi che incontrerai durante l'implementazione e vedrai se vorranno continuare a farlo. Altrimenti, dichiari perché non pensi che sia una buona idea e vedi qual è la loro reazione. Risciacqua e ripeti.

Scusami, ma questa domanda sembra una piccola richiesta di consigli paterni. Se questo è il caso, il buon sviluppatore dovrà abbracciare questi comandamenti:

• Rimani fedele a te stesso. Se il tuo istinto si sente a disagio per una funzione, pronuncia le tue preoccupazioni in modo udibile. È probabile che il team stia solo aspettando un'apertura.
• Non cercare di sostituire l'esperienza con le regole pratiche 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 è d'accordo, non ripetere i tuoi dubbi fino alla nausea.
• Pensa positivo. Se l'idea è davvero implorante di "abbatterlo", prova a trovare e nominare gli 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 culmine della vita, ma la competenza sociale può continuare a crescere fino al pensionamento.

La maggior parte è già stata detta, 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 applicazioni sono correlate ai processi aziendali (ad un livello equo promuovono le vendite e la comunicazione con il cliente).

I processi aziendali insieme ai prodotti di accompagnamento possono essere (almeno se la società è abbastanza grande) molto complessi. In una certa misura, se stai modellando una cosa complessa, l'applicazione risultante avrà una relativa complessità. Poiché la maggior parte degli individui degli uomini d'affari vedono solo la loro parte del processo, l'applicazione / processo completo si basa su una complessità maggiore 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 potrebbe avere un impatto maggiore sull'intero sistema. A mio parere, questo non è un motivo per discutere contro questo cambiamento. È il punto giusto per discutere gli sforzi (e le spese) con il cliente. Probabilmente non impedirà al cliente di avere quella feature build, ma col tempo acquisiranno un feeling per le applicazioni e alcune discussioni su "uuh, sei così costoso!" sarà molto meno schizzinoso.

Non so se ti trovi in una situazione paragonabile, ma ho appreso che la situazione dello stakeholder non ha necessariamente la stessa complessità crescente imminente come quella che gli sviluppatori e gli architetti del sistema IT devono affrontare. In quella situazione la comunicazione aiuta entrambe le parti.

Se ti leggo correttamente, la vera domanda riguarda la complessità sconosciuta. Inizialmente ho letto la tua domanda come, "Vedo il rischio estremamente probabile di eccessiva complessità ma il capo non lo fa" Ma stai dicendo che il capo non è un problema, quindi lo prendo non sei sicuro di quali rischi di aggiungere complessità inaccettabile sono.

In tal caso, raccomanderei una sorta di strategia di mitigazione del rischio. Immagine che stai considerando di aggiungere WCF / servizi web alla tua API, che potrebbe essere fantastico o molto complesso senza ricompensa:

• aggiungi la funzione su un ramo. Se funziona, uniscilo. Se si trasforma in un nido di ratti, uccidilo.
• avvia un nuovo progetto di una pagina e fa una dimostrazione del concetto. Se non riesci a fare una dimostrazione del concetto in poco tempo, quindi rilasciarlo. Se la dimostrazione del concetto funziona, ingrandiscila e integrala con il tuo
• setaccia il web perché le persone si aggrappino a quella caratteristica o tecnologia. Dove c'è un sacco di problemi, una tecnologia potrebbe essere un rischio reale di eccessiva complessità. Java Beans e COM + sono probabilmente vecchi, ma buoni esempi di funzionalità che hanno davvero sollevato la complessità e potrebbero o meno aver fornito vantaggi nell'equazione

Discutere di no. Discutere possibilmente sì. Ma dovrebbe essere trattato come un'aggiunta alle specifiche e prioritizzato con altre funzionalità. Se sai che la richiesta aggiungerà una quantità irragionevole di tempo e di complessità da implementare, allora affermala in anticipo. Non come opposizione a fare la richiesta, proprio come una spiegazione di ciò che pensi che ci vorrà per implementare.

Dipende molto dalla richiesta. L'implementazione del puntatore è abbastanza grande per effettuare 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 disposto in modo tale che il pulsante sia opzionale. Ho fatto proprio questo, infatti. Ho aggiunto il pulsante ma ho anche raccolto abbastanza informazioni prima che il pulsante diventasse opzionale. Gli utenti che si aspettavano che fosse lì lo usavano e quelli che si rendevano conto che non era proprio ridondante.

Tutto ruota attorno all'equilibrio e sapere quando scegliere le tue battaglie. Alcune cose sono più facili da implementare in ogni caso e affrontare gli aspetti sociali del non includerlo.

Il problema che vedo è il tuo uso della parola discute.

Devi sollevare questioni di progettazione e il ragionamento che sta dietro a loro, ma fai attenzione perché i programmatori tendono a difendersi sulle posizioni che hanno preso e discutono i punti solo per il gusto di argomentare (a volte). Devo smettere di discutere un po '- e non sempre ci riesco. Inoltre, invecchiando, trovo che mi sbaglio più spesso di quanto non fossi - o peggio non riconoscevo quanto spesso avevo torto:)

Se hai dei requisiti chiaramente definiti (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 chiedi quale è più importante. Una volta soddisfatti i requisiti e le relative motivazioni, potresti persino riuscire a trovare una soluzione completamente diversa che supporti entrambi i requisiti (JNI - kinda).

Se così non fosse, beh 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, allora di 'cosa c'è di male.

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

4. Se insistono ancora nell'attuare l'idea sbagliata, ottenere da loro una conferma che hai sconsigliato, comprese le tue ragioni. Potresti anche inviare un'e-mail riassumendo la discussione con una copia al tuo manager. Questo potrebbe salvare il tuo ** dopo.

In uno scenario ideale avresti un Lead Developer che prende le decisioni definitive sul lato tecnico e un Business Lead che prende le decisioni definitive sul lato business. Ciò risponderebbe alle due domande principali:

1) Cosa? Cosa vuole il cliente?

2) Come? Come realizziamo questo da una prospettiva tecnologica.

Ciò che il cliente desidera è il decisore finale in quanto sono coloro 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 la sua attuale richiesta del cliente (che parte dalla politica interna del cliente). Quindi è senza speranza e deve essere fatto (ma la direzione dovrebbe anche considerare se continuare tale progetto o se dovrebbe rinegoziare il prezzo).

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

Se hai la possibilità di dare la tua opinione sul fatto che alcuni requisiti debbano o non debbano far parte della domanda, le persone non tecniche si aspettano che tu faccia riferimento alle tue conoscenze tecniche (ad esempio "l'uso di indicatori renderebbe l'applicazione instabile" oppure "l'utilizzo di un parametro GET per lo scopo X è un rischio per la sicurezza"). I borsisti tecnici apprezzerebbero anche il tuo feedback su qualche vantaggio o disavanzo specifico a cui forse non avrebbero pensato.

Certo, è dura quando tutti vogliono la funzione X e alla fine si dice "potrebbe non essere buono", ma alla fine tutti cercano di creare un'applicazione sicura, solida e stabile (manutenibile, flessibile, ecc. ...) e ogni voce dovrebbe contare.

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

Se sei nella posizione di comprendere gli aspetti negativi del farlo (complessità, mancanza di usabilità, ecc.), allora è nell'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 decidono di aggiungere la nuova funzione, dovresti fare il miglior lavoro possibile. È una sfida.

E, se la nuova funzione è troppo stupida o l'ambiente di lavoro è troppo schifoso, è ora di trovare un altro lavoro.