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

Rendere il software riutilizzabile e a prova di proiettile è non la forza trainante dell'ingegneria del software. L'ingegneria consiste nel risolvere i problemi del mondo reale in modo ottimale entro i limiti del mondo reale . La maggior parte degli ingegneri preferirebbe lavorare su una Ferrari - ma una station wagon ha bisogno di altrettanto ingegneria, e il motivo per cui una station wagon non si comporta altrettanto bene (in qualche modo) è dovuto a vincoli progettuali più difficili, non dovuti a un peggior engineering .

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

Naturalmente, è possibile che il processo non sia ottimale, e farebbe meglio con un po 'più di design in anticipo. Il test dell'acido sarebbe, è il modo attuale di fare cose creando più problemi di quanti non risolva per gli utenti , o è solo un bug per gli sviluppatori che devono lavorare in questo modo? Se in realtà sta causando problemi agli utenti, parte del tuo lavoro è provare a dimostrare che questo è il tuo caso e provare a convincere le persone a un processo leggermente più controllato.

In realtà, questo mi infastidisce. Sei in una professione in cui sviluppi strumenti per ricercatori, corretto. Tuttavia, ti viene detto di rendere questi programmi rapidi e farli apparire minimamente funzionanti. Sorpresa sorpresa. Questo è semplicemente l'approccio tipico del ricercatore alla programmazione con il dollaro trasferito a un programmatore effettivo.

La preoccupazione principale qui è che la mancanza di test in particolare può essere eticamente discutibile se gli strumenti hanno uno scopo importante. Se non si è sicuri che il software presenti dei difetti, poiché uno è limitato a un tempo di test minimo, ciò significa che NO ONE è ritenuto responsabile delle condizioni di lavoro del software e Atlas si stringe nelle spalle.

Fermiamoci e pensiamoci 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 messo gli stessi standard sul software di modellazione che usano per arrivare alle conclusioni che hanno oggi. L'argomento ha un grande impatto sul modo in cui affrontiamo correttamente la gestione dell'ambiente e la politica internazionale.

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

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

Se il guadagno suddetto stava accadendo, la prova di un risultato netto sarebbe marginale, probabilmente all'interno dell'intervallo err.

Quindi, lievi errori di calcolo, anche la metodologia che coinvolge la memorizzazione e il recupero dei dati sul back-end, potrebbe portare a ignorare un grave problema ambientale a una fine del fallimento oa una politica internazionale che colpisce molte persone (distrugge posti di lavoro, distrugge le pensioni) , ecc.) dall'altro.

Quindi, sì, hai ragione. Non mi interessa quale sia il ritmo della ricerca ... Se i ricercatori vogliono affidarsi a strumenti software per gestire i dati ed effettuare calcoli per loro, devono imparare ad aspettare che il software sia fatto correttamente. Altrimenti questo software diventa un punto vulnerabilità nelle loro teorie di cui non sono responsabili, causando una condotta etica scorretta.

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

Se puoi produrre un'applicazione in 3 ore (o giorni) che fa ciò che è destinato a fare, perché dedicare più tempo a progettare in anticipo? Stai solo sprecando soldi. Sprecare denaro non è generalmente una buona idea ™.

Come altri hanno già detto, una grande parte di ciò che riguarda l'ingegneria del software sono "vincoli estrinseci". per esempio. Tempo, budget, servizio, supporto, soddisfazione di richieste idiote irrazionali, ecc.

Molti di noi (me compreso) sono entrati in programmazione pensando che tutto riguardi la programmazione stessa - codifica pezzi di software belli ed eleganti nel vuoto (o almeno un vuoto relativo). Raramente lo è. Potrebbero esserci alcuni rari lavori accademici o di software R & D che si avvicinano ad esso, ma per la maggior parte, la stragrande maggioranza del lavoro di sviluppo del software non è affatto così. Soprattutto nella fase di manutenzione, che di solito è il 90% + della durata di un prodotto, e la routine quotidiana di pane e burro della maggior parte dei software commerciali permanenti funziona.

Per molto tempo, ho avuto un conflitto interno su questo che spesso mi rendeva infelice per il mio lavoro (ed è parte di quello che alla fine ha portato ad un esaurimento l'anno scorso). Ho sempre sentito che un lavoro fa schifo se non è tutto ciò che riguarda la creazione di codice bello e il tempo necessario per farlo in modo propizio. Ma in realtà, questa è la realtà - e alcune persone effettivamente prosperano su un flusso di lavoro molto orientato ai servizi. È ciò che li fa sentire pragmatici e utili. Anche se gli effettivi aspetti della "pura ingegneria del software" di un progetto sono relativamente frettolosi e sciatti.

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

Tutto ciò che ho detto, 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 gli attrezzi medici) seguono un processo ingegneristico molto rigido. Ma nel complesso, sì, ti dirò a bruciapelo ora che la maggior parte del software commerciale è relativamente sciatta. Di solito c'è un processo formale, ma attenendosi strettamente ad esso, quasi sempre, ci si mette in secondo piano per reagire all'input del cliente e ad altre pressioni commerciali. Non è proprio una "sciatteria" di per sé, è solo una pragmatica utilità. Il trucco è trovare la tua nicchia e guardare un ruolo dal punto di vista da quale servizio fornisce, piuttosto che quanto sia bello l'aspetto della "pura programmazione".

EDIT : penso che avrei potuto sembrare troppo unilaterale nella mia valutazione iniziale. Mi piacerebbe aggiungere che spesso sono anche problemi genuini con cose che sono troppo sciatte e mancanza di buon processo - al punto in cui sta portando il progetto in debito tecnico ed è in realtà un male per il business. Ma vedere questo arriva con l'esperienza. Il punto iniziale è ancora fondamentalmente valido: la maggior parte del software commerciale oggi non è rigidamente orientato all'engineering come potrebbero piacere i puristi.

Che bella domanda! A volte puoi fare qualcosa di prezioso essendo veloce . Questo è tipicamente il caso in un laboratorio di ricerca dove più velocemente possiamo imparare ciò che non conosciamo, meglio sarà. 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 Il mitico Man-Month .

A volte puoi fare qualcosa di prezioso essendo buono . Questo è tipicamente il caso di un software con involucro termoretraibile come Adobe Photoshop. La ricerca è già stata fatta anni fa e ora la domanda è come aggiungere l'elenco di funzionalità che i clienti vogliono in un modo che non introduce bug. Si tratta di architettura, progettazione e test, test, test. Il codice stesso è ciò che è prezioso, non ciò che si impara da esso.

Se non si è soddisfatti della ricerca (facendo il primo di qualcosa, apprendendo cose nuove che nessuno conosceva prima), allora provate a provare il software confezionato. Infatti, alla tua età dovresti provare quante più cose possibili. Vai a rischiare! Imparerai molto e alla lunga starai meglio.

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

Il mio suggerimento è di far sapere ai tuoi superiori che questo ti infastidisce e di suggerire loro un approccio migliore per 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 un modo che non è all'altezza dei propri standard, per non parlare di uno standard di qualità di sviluppo del software che il settore si aspetta.

Ecco il mio consiglio basato sulle mie esperienze, ho 20 anni e sono attualmente in stage presso importanti istituti finanziari nel Regno Unito e ho avuto le stesse sensazioni che hai avuto qualche mese fa, quello che ho notato è che forse è dovuto a la natura del lavoro che stai facendo.

Ciò che intendo è che hai detto:

“What I have to do is create some internal tools using a mix of technologies - mainly 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 occorrono rapidamente "piccole" cose. Non avevo il lusso di applicare la maggior parte dell'ingegneria del software o degli algoritmi e dei principi della struttura dei dati che mi erano stati insegnati nel mio secondo anno perché in alcune settimane era necessaria una versione funzionante dello strumento. Ero molto frustrato per questo, tuttavia era non male come ho imparato a scrivere un codice migliore e più leggibile.

Dovevo essere paziente e di recente ho fatto un giro su un nuovo team che sta lavorando su una nuova iterazione del sistema costruito in-house utilizzato dagli utenti di 10K + e posso assicurarti che l'aspetto dell'ingegneria del software è preso molto sul serio. Mi è stato detto che otterrò esposizione all'intero ciclo di vita del software dall'acquisizione / analisi dei requisiti fino all'implementazione e al test. Credo che acquisirò questa esperienza perché non sto lavorando su strumenti interni ma sto lavorando su un sistema completo con una vasta base di utenti.

Ciò che raccomando è che tu sia paziente, finisci di creare gli strumenti e fare un ottimo lavoro in modo che i tuoi supervisori acquisiscano maggiore fiducia in te e ti assegnino compiti più impegnativi che richiedono l'uso di principi di ingegneria del software. Ottieni ulteriore conoscenza dal fare alcune letture extra e applica questa conoscenza a ciò che stai facendo attualmente, ricordo di aver saccheggiato l'intera biblioteca di e-book in compagnia solo per approfondire la mia conoscenza, muhahah, da tutti i libri che ho letto ho sentito che java efficace era libro davvero buono che mi ha aiutato molto.

Siate pazienti, investite molto nella vostra conoscenza e applicate tale conoscenza laddove possibile. Se stai facendo un ottimo lavoro, qualcuno lo noterà presto.

Sono d'accordo sul fatto che il modo in cui opera il tuo attuale lavoro è subottimale, 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 domanda principale su di te è fino a che punto ti stai occupando di incendi che richiedono soluzioni immediate fatte rapidamente come dare un pronto soccorso al paziente medico rispetto a richieste che potrebbero essere impostate come progetti e gestite su una scala molto diversa simile a il paziente medico deve programmare test e varie procedure che non sono necessarie da fare immediatamente ma a breve termine.

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

La domanda sulla ricerca delle strutture dati è quanto tempo vorranno farlo. Se vuoi impiegare un decennio per cercare una struttura di dati che sia abbastanza 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 es. potresti passare ore a trovare una soluzione per FizzBuzz as potresti provare a risolverlo in varie lingue su vari hardware per ottimizzare quanto velocemente potrebbe essere eseguito.

Anche se può essere importante per la ricerca, è importante anche consegnare qualcosa. Se non consegni qualcosa, quanto sei bravo? Duct Tape Programmer sarebbe più di un esempio sul fare le cose da parte qui.

Scrum è una metodologia specifica che potresti provare ad adottare nel tuo attuale luogo di lavoro. Non credo che Scrum sia un proiettile d'argento. In quali circostanze possono essere realizzati i progetti Scrum And Agile Fail? sarebbe un post sul blog che potrebbe interessarti.

La mia ipotesi è che non stai vedendo quanto siano informali i processi del tuo posto corrente e pensando che l'erba sia immensamente più verde dall'altra parte dove c'è una metodologia formale. Anche se potrebbe essere migliore, alcune persone potrebbero preferire quello 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, passaci sopra. Le cose devono essere fatte.

Pensa a come identificare questi tipi di aziende quando fai domanda per il tuo prossimo lavoro. Pochi luoghi 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 pagano raramente se il tuo lavoro non lascia la lavagna a secco. Odio vederti impazzire così presto nella tua carriera.