Come spiegare a un laico gli svantaggi di HardCoding e non utilizzare i principi OOP?

Organizza una riunione. Coinvolgi più persone che il tuo manager immediato come osservatore di terze parti.

Spiega in termini molto concettuali cosa stai facendo e quanto tempo ci vorrà, e spiega le opzioni.

Ad esempio:

Dear Manager & Co, you have expressed that you are seeking to build a Business Dashboard and to you the end product look simple. But to build it it is not so. I need parts A, B, C, D, and they take respectively 1 month, 2 month, 4, month and 8 month to build.

There are also 2 approaches to building software: Hardcode and OOP.

Hardcode will make it work sooner but it will create a lot of problems for me and other programmers down the road. This phenomenon is so frequent it got a name of Technical Debt.

OOP will get you the product in X amount of time longer, but it will be much easier to modify and change it to your needs over a longer period of time.

Use analogy, for example .. it may take you faster to build a ladder to climb on top of 2nd floor building, but ladder cannot hold two persons at once and will break. It will take you a lot longer to build stairs to the 2nd floor, but many people will use it for a long time. It is a lot easier to maintain stairs in the long run, because the structure is sturdy, while ladders have to be fixed more often from wear and tear because they are just planks hammered together with nails.

Now with that information what product do you want and how well-built do you want it?

Alla fine, il gestore dovrà

• fidati o non fidarti del tuo giudizio (tu sei l'esperto, lei non lo è)
• fai una scelta (Hardcode con debito tecnico o OOP)
• assumere o non assumere più programmatori per aiutarti

Per riepilogare devi

• spiega in termini concettuali (senza troppi dettagli) ciò che ti viene chiesto di fare
• fidati del tuo gestore di fidarti di te (o di uscire)
• chiedi ciò che il gestore vuole che tu costruisca, una volta che hanno conoscenza delle loro opzioni

Inoltre, avere una buona idea delle stime temporali di quanto tempo ci vorrà per costruire parti di software usando questo o quel modo, e perché, ed essere pronti a rispondere alle domande a riguardo. Potrebbe aiutarti a mettere insieme un documento sulle caratteristiche del software proposto e il tempo e la complessità approssimativi necessari per realizzarle.

E inoltre, sei l'esperto e puoi rifiutare (o nemmeno menzionare) che ci sono modi carenti per fare il lavoro. Puoi rifiutarti di fare un brutto lavoro.

Non cerca di spiegare o giustificare le decisioni di progettazione tecnica per un manager non tecnico. Non dovresti introdurre termini come hard-coding o OOP. Il tentativo di spiegare i principi di progettazione OO e così via a un profano senza alcuna preparazione tecnica non ti porterà da nessuna parte.

Non è nemmeno chiaro dalla tua domanda se si tratta di "OOP" contro "hardcode" (qualunque cosa significhi). Per quanto ne sappiamo lei potrebbe ancora pensare che la soluzione "rapida e sporca" richiederebbe troppo tempo, o forse lei vuole la soluzione manutenibile, ma pensa che non lavori abbastanza ore e passi il tuo tempo in Facebook.

Devi ascoltare prima di iniziare a insegnare . È tipico mentalità degli sviluppatori pensare che qualsiasi disaccordo debba essere dovuto al fatto che l'altra parte semplicemente non capisce, quindi "come spiegarlo ...". Ma non è chiaro che tu hai fatto abbastanza sforzi per capire il motivo dell'insoddisfazione del tuo capo.

Prima di tutto devi capire perché non ha fiducia in te. Dato che sei l'unica persona tecnica che hai bisogno di fidarti di te con una decisione tecnica, quindi devi capire perché hai perso questa fiducia e ciò che puoi per ottenerlo di nuovo. Un'organizzazione semplicemente non può funzionare se un capo non tecnico non si fida del lead tecnico con le decisioni tecniche.

Devi chiederlo a . Qual è il motivo per cui pensi che stai impiegando troppo tempo? Pensa che stai rallentando, o pensa che tu stia progettando troppo e che debba fare meno lavoro? Qual è il suo quadro di riferimento per quanto tempo crede che un compito dovrebbe prendere? Ha esperienza con altri sviluppatori su progetti simili? Devi capirlo prima di poter rispondere.

È possibile che tu abbia un capo manipolatore che sta cercando di farti vergognare a lavorare di più o a fare gli straordinari non pagati. È anche possibile che abbia una preoccupazione legittima a causa di cattiva comunicazione o mancanza di trasparenza nel processo di sviluppo.

Innanzitutto non vedo questo come un conflitto tra hard coding (o piuttosto veloce e sporco) e OOP.

Sono un sostenitore di OOP, ma a volte ciò che viene richiesto non è una soluzione longeva, a volte il quick-and-dirty è esattamente ciò che è richiesto.

Sei sicuro che il tuo manager voglia che tutto sia perfetto? Devi davvero discutere delle aspettative dei tuoi dirigenti, prima di poter discutere del modo migliore per raggiungere l'obiettivo.

Forse al tuo manager è stato affidato il compito di realizzare un prototipo di tiro veloce come prova del concetto.

Se l'obiettivo è una soluzione a lungo termine, allora è il momento di discutere su come evitare il debito tecnico. Per questo un manager ha spesso bisogno di conoscere le migliori pratiche non OOP.

Parlerò di alcuni cambiamenti che potresti essere in grado di fare, non perché penso che tu abbia torto qui, ma perché il tuo è l'unico comportamento su cui hai il controllo. Ho imparato molto tempo fa che argomenti migliori raramente convincono qualcuno. Devi cambiare qualcosa per mostrarli .

Hai menzionato che credi di essere un programmatore agile. Non so se questo significa che stai praticando "agile", ma ti consiglierei:

• Creare un backlog per gli utenti e sedersi con il tuo manager per dare la priorità.
• Fornire miglioramenti incrementali ogni due settimane se non più frequentemente / continuamente.
• Avere una demo di questi miglioramenti ogni due settimane.

Nella mia esperienza, questo ciclo di feedback e in particolare la demo possono davvero cambiare la dinamica. Dimostra che stai facendo funzionare le cose. Puoi mostrare perché è un passo importante. Ti tiene concentrato sul fatto che finisci davvero le cose. Sei più bravo nello spiegare la necessità di cose in un modo che la gestione comprenda. E la gestione in genere ottiene un apprezzamento migliore per la quantità di lavoro che viene utilizzata per mantenere alta la qualità.

Diventa una specie di "Sono orgoglioso del lavoro che ho fatto nelle ultime due settimane, quindi ti invito tutti a un incontro per dimostrarlo", invece del manager che pensa, "Devo ottenere di nuovo da lui. Sembra che mi stia nascondendo qualcosa. " I manager si preoccupano meno degli orari "dietro" quando c'è più trasparenza.

Prenderò l'ipotesi che questa domanda sia solo alla ricerca di una metafora / spiegazione per qualcuno che non sia un programmatore. Inoltre, hai portato questa risposta a lavorare stamattina.

Spiegherei al tuo manager che la costruzione di un programma è molto simile all'assemblaggio di un'auto. La maggior parte delle macchine viene costruita nelle fabbriche da un gruppo di persone, tutte utilizzando una serie simile di schemi e convenzioni per arrivare al prodotto finale. Ognuna delle parti della macchina ha anche fatto un certo modo, quindi se è più economico portarle da un altro posto, è possibile senza intaccare la funzione finale della vettura (refactoring). Fare le cose in questo modo rende più facile indossare un body kit (cambiare il modo in cui la macchina guarda), farlo andare più veloce (ottimizzando il motore), o mettere cose come lanciarazzi su di esso (strano, ma aggiunge una nuova funzione).

L'altro vantaggio di costruire la macchina in questo modo è che se l'auto si guasta o si rompe, puoi portarla in un negozio di carrozzeria (sviluppatore front-end) o meccanico (sviluppatore back-end) o il rivenditore ( sviluppatore full-stack) per capire cosa ha rotto e sostituirlo più facilmente o fare cose semplici come cambiare l'olio (manutenzione). Vale la pena sottolineare che il tempo messo in primo piano durante la costruzione iniziale della vettura viene ripagato in meno tempo che si è bloccato fissando - o peggiorando la ricostruzione - l'auto dopo che qualcuno si è schiantato.

Confrontalo con una macchina che aveva parti interamente personalizzate costruite molto velocemente da un costruttore di automobili che usava parti personalizzate e morì all'improvviso. Se non ha seguito regole o convenzioni accettate da chiunque altro, potrebbero volerci anni per svelare il modo in cui la macchina viene assemblata prima di poterla aggiustare quando si rompe.