Ho un'idea sbagliata sull'ingegneria del software? [chiuso]

Ho una domanda che è stata sollevata dal mio ultimo lavoro (piuttosto stagista).

Solo per mettere le cose in un contesto: ho 21 anni e ho già finito il mio secondo anno di università prima di aver avuto circa 2 anni di esperienza nel lavoro di amministratore / QA e in pratica posso dire di aver visto quanto diverso Settori IT operati. Passa avanti ai tempi attuali e qui sto facendo un lavoro di internato presso uno dei principali istituti di ricerca del Regno Unito.

Quello che devo fare è creare alcuni strumenti interni usando un mix di tecnologie - principalmente AWS / Java / Bash - per ottenere il quadro. Va tutto bene, sto facendo il mio lavoro, ma non sono felice. Perché? Perché dovrei lavorare su una questione ad hoc. Ciò significa creare cose rapidamente, senza perdere tempo a progettare. Il mio manager ha detto esplicitamente che ci si aspettava che "si affrettasse" a risolvere i problemi man mano che si presentano e in sostanza. Di conseguenza si è scoperto che le cose dovevano essere rifatte e riprogettate e non sono ancora perfette. Per quanto riguarda i test, tienilo al minimo, finché sembra funzionare, quindi va bene.

Sono in colpa per non essere d'accordo con questo modo di condurre il lavoro? È sbagliato voler pensare al sistema nel suo insieme, quindi concentrarsi su componenti diversi e vedere come potrebbero interagire, concentrarsi su diversi "punti chiave" che potrebbero rivelarsi problematici in futuro? È un crimine voler fare un buon lavoro e non un "lavoro veloce"? È un errore o un atteggiamento sbagliato voler ricercare le strutture di dati applicabili a un problema in modo da poter scegliere il meglio in base a un determinato set di problemi? Per quanto ne so, il bit "Ingegneria" in "Ingegneria del software" ha a che fare esattamente con questo: ricercare il dominio del problema e trovare una soluzione informata, quindi perfezionare se necessario?

Sono stato a un'intervista in uno studio di Arm nel Regno Unito e mi hanno mostrato la loro sala SCRUM e sembrava che avessero una buona idea su come gestire il loro progetto - avevano un arretrato, avevano metriche su quanto a lungo ciascuno il problema potrebbe richiedere una soluzione - le solite cose per SCRUM - completamente diverso dal modo in cui le cose vengono eseguite "qui"

Ho creato un'idea sbagliata sull'industria del software in generale? Mi piacerebbe sentire il tuo contributo al riguardo. Voglio dire che "sono entrato" nello sviluppo del software solo perché voglio creare cose - chiare e semplici, ma voglio creare cose di qualità. Voglio vedere il mio software usato in vari scenari, voglio vederlo a prova di proiettile - non è la forza trainante per tutti gli ingegneri del software? Penso che tutti possano essere programmatori / programmatori semplicemente imparando la sintassi, ma per me dove inizia il vero divertimento è quando devi inventare un design che sia fattibile nel mondo reale.

Ero solito svolgere i miei incarichi universitari semplicemente guardandoli e iniziando direttamente la codifica e potevo facilmente ottenere voti superiori al 75% e non ho mai apprezzato il modulo "Ciclo di vita dello sviluppo software". Ma ora quando ho visto nel mondo reale quanto è brutto lavorare senza alcun processo formale e la frustrazione inerente alla situazione in cui non sai se i requisiti cambieranno domani (oh, ho detto che don hai un'analisi dei requisiti chiaramente definita?)

Mi piace davvero credere di aver appena ottenuto una posizione in cui alcune persone avevano solo bisogno di una scimmia di codice per fare il loro sporco lavoro e questo non è il modo in cui il mondo del software opera in generale.

Rendere il software riutilizzabile e antiproiettile non è la forza trainante dell'ingegneria del software. L'ingegneria riguarda la risoluzione ottimale dei problemi del mondo reale entro i limiti del mondo reale . La maggior parte degli ingegneri preferirebbe lavorare su una Ferrari, ma una station wagon ha bisogno della stessa ingegneria e il motivo per cui una station wagon non funziona altrettanto (in qualche modo) è dovuto a vincoli di progettazione più difficili, non a causa di una peggiore ingegneria .

Quando dici di voler fare un "buon lavoro" piuttosto che un "lavoro rapido", la maggior parte degli ingegneri lo fa, ma a volte parte di ciò che definisce il bene è quanto è veloce il completamento. Quindi non è giusto pensare a "buono" e "veloce" come scelte opposte. O pensare che stai facendo un brutto lavoro, o sei solo una "scimmia di codice", per fare il miglior lavoro possibile nel tempo disponibile.

Certo, è del tutto possibile che il processo non sia ottimale e farebbe meglio con un po 'più di progettazione in anticipo. Il test dell'acido sarebbe, il modo attuale di fare le cose crea più problemi di quanti ne risolva per gli utenti , o sta semplicemente infastidendo gli sviluppatori che devono lavorare in quel modo? Se in realtà sta causando problemi agli utenti, parte del tuo lavoro è provare a dimostrare che è così, e cercare di convincere le persone a un processo leggermente più controllato.

In realtà, questo mi dà fastidio. Hai una professione in cui sviluppi strumenti per i ricercatori, esatto. Tuttavia, ti viene detto di rendere questi programmi veloci e farli sembrare funzionare al minimo. Sorpresa sorpresa. Questo è semplicemente l'approccio tipico del ricercatore alla programmazione con il dollaro passato ad un vero programmatore.

La preoccupazione principale qui è che la mancanza di test in particolare può essere eticamente dubbia se gli strumenti hanno uno scopo importante. Se non si è sicuri che il software presenti difetti poiché si è limitati a un tempo di test minimo, ciò significa che NESSUNO è ritenuto responsabile delle condizioni di funzionamento del software e Atlas fa spallucce.

Fermiamoci e pensiamo a questo per un secondo però. Che tipo di strumenti stai sviluppando? Se stai sviluppando un software che modella i dati, qui c'è un grande dilemma etico . In alcune situazioni, la ricerca scientifica porta a decisioni che riguardano molte persone su larga scala.

Supponiamo per un istante il controverso argomento del cambiamento climatico causato dall'uomo. Diciamo che hanno posto gli stessi standard sul software di modellazione che usano per giungere alle conclusioni che hanno oggi. L'argomento ha un grande impatto sul modo in cui affrontiamo la corretta gestione dell'ambiente e sulla politica internazionale.

Non è etico garantire che il software di modellazione non abbia grossi problemi con le sue previsioni?

L'intero problema non è che i gas serra riscaldano la terra. Il problema è se il risultato netto degli effetti di feedback è un aumento accelerato della temperatura, che dopo aver infranto una soglia non sarebbe più reversibile.

Se si verificasse tale guadagno, l'evidenza di un risultato netto sarebbe marginale, probabilmente all'interno dell'intervallo err.

Pertanto, lievi calcoli errati, persino la metodologia che comporta l'archiviazione e il recupero dei dati sul back-end, potrebbero comportare l'ignorare un grave problema ambientale da un lato del fallimento o la politica internazionale che colpisce molte persone (distrugge posti di lavoro, distrugge pensioni, ecc. ) dall'altra.

Quindi sì, hai ragione. Non mi interessa quale sia il ritmo della ricerca ... Se i ricercatori vogliono fare affidamento su strumenti software per gestire i dati ed eseguire calcoli per loro, devono imparare ad aspettare che il software funzioni correttamente. Altrimenti questo software diventa un punto di vulnerabilità nelle loro teorie a cui non sono ritenuti responsabili, con conseguente cattiva condotta etica.

Non hai un'idea sbagliata di cosa sia l'ingegneria del software. Tuttavia, ti manca un aspetto molto importante: questo è un settore dei servizi. Alcuni di noi lavorano su un prodotto per anni e passano attraverso la progettazione e poi molte iterazioni prima che sia nella v1. Altri devono produrre qualcosa in 3 ore. Dipende da chi stai assistendo e qual è lo scopo.

Se riesci a produrre un'applicazione in 3 ore (o giorni) che fa quello che deve fare, perché dedicare più tempo ad essa per progettare in anticipo? Stai solo sprecando soldi. Lo spreco di denaro è generalmente no a Good Idea ™.

Come altri hanno già detto, gran parte dell'ingegneria del software riguarda i "vincoli estrinseci". per esempio. Tempo, budget, servizio, supporto, soddisfacendo richieste idiotiche irrazionali, ecc.

Molti di noi (me compreso) sono entrati nella programmazione pensando che si trattasse solo della programmazione stessa - codifica pezzi di software belli ed eleganti in un vuoto (o almeno in un relativo vuoto). Raramente lo è. Potrebbero esserci alcuni rari lavori accademici o di ricerca e sviluppo che si avvicinano ad esso, ma per la maggior parte, la stragrande maggioranza del lavoro di sviluppo software non è niente del genere. Soprattutto nella fase di manutenzione - che è in genere il 90% + della vita di un prodotto - e la routine quotidiana di pane e burro della maggior parte dei software commerciali permanenti.

Per molto tempo, ho avuto un conflitto interno su questo che spesso mi ha reso infelice per il mio lavoro (ed è parte di ciò che alla fine ha portato a un esaurimento l'anno scorso). Ho sempre pensato che un lavoro fa schifo se non si tratta solo di creare codice stupendo e di prendersi il tempo necessario per farlo correttamente. Ma davvero, questa è la realtà - e alcune persone prosperano su un flusso di lavoro molto orientato ai servizi. È ciò che li fa sentire pragmatici e utili. Anche se gli aspetti "ingegneria del software pura" di un progetto diventano relativamente frettolosi e sciatti.

Ad ogni modo, è bene che tu lo stia mettendo in discussione ora. Questa è una di quelle cose che non spiegano mai veramente a scuola. E le aziende adorano fingere di seguire ottime pratiche ingegneristiche anche se non lo fanno. Suggerimento: la maggior parte no.

Detto questo, le cose variano. Alcune aziende (principalmente quelle per le quali il software è il loro core business e quelle che lavorano su software altamente critici per la sicurezza come dispositivi medici) seguono un processo di ingegneria molto rigoroso. Ma nel complesso, sì, ti dico subito che la maggior parte dei software commerciali è relativamente sciatta. Di solito esiste un processo formale, ma aderirvi rigorosamente quasi sempre fa un passo indietro per reagire all'input del cliente e ad altre pressioni commerciali. Non è in realtà "sciatteria" di per sé, è solo una semplice utilità pragmatica. Il trucco è trovare la tua nicchia e guardare un ruolo dal punto di vista dal servizio che fornisce, piuttosto che da quello che è "pura programmazione".

EDIT : Penso che avrei potuto sembrare troppo unilaterale nella mia valutazione iniziale. Vorrei aggiungere che spesso ci sono anche veri problemi con le cose che sono troppo sciatte e la mancanza di un buon processo - al punto in cui sta portando il progetto al debito tecnico ed è in realtà un male per il business. Ma vedere questo arriva con l'esperienza. Il punto iniziale rimane sostanzialmente: la maggior parte dei software commerciali oggi non è orientata all'ingegneria rigida come potrebbero piacere i puristi.

Che domanda eccellente! A volte puoi fare qualcosa di prezioso essendo veloce . Questo è in genere il caso di un laboratorio di ricerca in cui più velocemente possiamo imparare ciò che non conosciamo, meglio saremo. Il software che produci esiste solo per rispondere alle domande. È "buttare via il codice". Questo è anche il caso delle startup che non sanno cosa vogliono veramente i clienti. Inoltre, la prima volta che fai qualcosa, sarà schifoso. Leggi The Mythical Man-Month .

A volte puoi fare qualcosa di prezioso essendo buono . Questo è in genere il caso di software termoretraibile come Adobe Photoshop. La ricerca è già stata fatta anni fa e ora la domanda è come aggiungere l'elenco delle funzionalità che i clienti desiderano in modo da non introdurre bug. È una questione di architettura, progettazione e testing, testing, testing. Il codice stesso è ciò che è prezioso, non ciò che impari da esso.

Se non sei soddisfatto della ricerca (fare il primo di qualcosa, apprendere cose nuove che nessuno sapeva prima) allora prova il software termoretraibile. In effetti, alla tua età dovresti provare quante più cose possibile. Vai a rischiare! Imparerai molto e a lungo andare starai meglio.

Penso che tu abbia notato molto presto nella tua carriera che fare le cose in fretta, senza un design adeguato o test adeguati, tende a tornare a morderti. Ovviamente non ti piace questo e hai buone ragioni per non farlo. È ridicolo aspettarsi di "correre attraverso i problemi", soprattutto se è necessario rivederli in seguito quando le soluzioni iniziali sono errate o incomplete. Puoi fornire soluzioni ai problemi solo se li capisci completamente e ciò richiede tempo e un'attenta pianificazione.

Il mio consiglio è di far sapere ai tuoi superiori che questo ti disturba e di suggerire loro un approccio migliore nel fare il tuo lavoro. Se non sono d'accordo e vogliono che tu continui a "correre" attraverso il tuo lavoro, inizierei a cercare lavoro altrove. Non ha senso fare le cose in modo non conforme ai propri standard, per non parlare di uno standard di qualità di sviluppo software che l'industria si aspetta.

Ecco il mio consiglio basato sulle mie esperienze, ho 20 anni e attualmente sto lavorando a importanti istituti finanziari nel Regno Unito e ho avuto le stesse sensazioni che hai avuto qualche mese fa, quello che ho notato è che questo potrebbe essere dovuto alla natura di il lavoro che stai facendo.

Quello che intendo con questo è che hai detto:

"Quello che devo fare è creare alcuni strumenti interni utilizzando un mix di tecnologie - principalmente AWS / Java / Bash"

Ho anche dovuto creare strumenti interni per aiutare a gestire e automatizzare determinati processi e il fatto è che in un ambiente frenetico è necessario implementare "piccole" cose rapidamente. Non ho avuto il lusso di applicare la maggior parte dell'ingegneria del software o degli algoritmi e dei principi della struttura dei dati che mi è stato insegnato durante il mio secondo anno perché in poche settimane era necessaria una versione funzionante dello strumento. non tutto male come ho imparato a scrivere meglio il codice più leggibile.

Ho dovuto essere paziente e recentemente mi sono rivolto a un nuovo team che sta lavorando a una nuova iterazione del sistema costruito internamente utilizzato dagli utenti 10K + e posso assicurarti che l'aspetto dell'ingegneria del software è preso molto sul serio. Mi è stato detto che otterrò un'esposizione all'intero ciclo di vita del software dall'acquisizione / analisi dei requisiti fino all'implementazione e al testing. Credo che acquisirò questa esperienza perché non sto lavorando su strumenti interni ma sto lavorando su un sistema su larga scala con una vasta base di utenti.

Quello che consiglio è di essere paziente, finire di creare gli strumenti e fare un ottimo lavoro in modo che i supervisori acquisiscano maggiore fiducia in te e ti assegnino compiti più impegnativi che richiederanno l'uso dei principi di ingegneria del software. Acquisisci ulteriori conoscenze facendo qualche lettura extra e applica quelle conoscenze a ciò che stai facendo, ricordo di aver saccheggiato l'intera biblioteca di e-book in azienda solo per approfondire la mia conoscenza muhahah, da tutti i libri che ho letto ho sentito che l'effettivo java era davvero un buon libro che mi ha aiutato molto.

Sii paziente, investi molto nelle tue conoscenze e applica quelle conoscenze ove possibile. Se stai facendo un ottimo lavoro qualcuno lo noterà presto.

Concordo sul fatto che il modo in cui opera il tuo lavoro attuale non sia ottimale, sì. Tuttavia, se vuoi dire che non funziona affatto, non sarei d'accordo con te perché ci sono vari risultati e l'istituzione è ancora in circolazione.

La mia principale domanda che ti viene posta è in che misura hai a che fare con incendi che richiedono soluzioni immediate fatte rapidamente, simili a quelle di un pronto soccorso per un paziente medico rispetto a richieste che potrebbero essere configurate come progetti e gestite su una scala molto diversa simile al paziente medico dover programmare test e varie procedure che non sono necessarie da eseguire immediatamente ma a breve termine.

Prendersi il tempo necessario per svolgere bene un lavoro dipende un po 'dalla maturità dell'organizzazione e da quanto sia importante che qualcosa venga fatto bene rispetto a una richiesta di essere fatta.

La domanda sulla ricerca delle strutture di dati è per quanto tempo vogliono farlo. Se vuoi impiegare un decennio a ricercare una struttura di dati che è piuttosto diversa dal volere un paio d'ore. Mentre posso apprezzare il desiderio di ottenere la risposta migliore, c'è qualcosa da dire per i rendimenti decrescenti dopo aver trascorso un po 'di tempo su un problema, ad esempio potresti passare ore a trovare una soluzione a FizzBuzz mentre potresti provare a risolverlo in varie lingue su vari hardware per ottimizzare la velocità di esecuzione.

Mentre può essere importante ricercare, è anche importante fornire qualcosa. Se non offri qualcosa, quanto sei bravo davvero? Duct Tape Programmer sarebbe più un esempio di come fare le cose qui.

Scrum è una metodologia specifica che potresti eventualmente provare ad adottare nel tuo attuale posto di lavoro. Non pensare però che Scrum sia un proiettile d'argento. In quali circostanze possono fallire i progetti in mischia e agili? sarebbe un post sul blog su quell'argomento che potrebbe essere di interesse.

La mia ipotesi è che non stai vedendo quanto siano informali i processi del tuo posto attuale e pensi che l'erba sia immensamente più verde dall'altra parte dove c'è una metodologia formale. Anche se potrebbe essere meglio lì, alcune persone potrebbero preferire ciò che hai ora con la massiccia libertà di essere un cowboy .

Penso che la tua situazione sia ancora nella scala del mondo reale verso una minore enfasi sul lato della qualità. La tua preferenza è dall'altra parte del mondo reale. Le specifiche cambiano, superalo. Le cose devono essere fatte.

Considera i modi per identificare questo tipo di aziende quando ti candidi per il tuo prossimo lavoro. Pochi posti hanno un modello di business in cui possono permettersi che gli sviluppatori analizzino i loro progetti per sempre (anche i professori devono insegnare). I clienti raramente pagano se il tuo lavoro non lascia la lavagna a secco. Odio vederti impazzire così presto nella tua carriera.