La creazione di software completamente nuovo è generalmente una parte importante della maggior parte dei lavori di programmazione? [chiuso]

Gran parte del lavoro del software è la manutenzione. Ovviamente nessun responsabile delle assunzioni ti dirà questo, certo, ma è certamente il caso.

Sì, la tua percezione è accurata. È assolutamente ovvio che si impieghi molto più tempo, denaro e sforzi per mantenere i sistemi che creare nuovi sistemi. Quindi, ovviamente, l'allocazione temporale della maggior parte dei programmatori lo rifletterà.

Parte della ragione di questo è che molte persone, quando arrivano a fare "nuove e creative", lo fanno male, così che mantenere il sistema è difficile (questo è particolarmente probabile se non hanno mai hanno fatto la manutenzione da soli - nessuno che abbia costantemente lavorato su piccoli progetti greenfield può davvero affermare di essere competente).

Un altro motivo (probabilmente più grande) è che la maggior parte dei sistemi è progettata per essere continuamente utile, non solo per un evento singolo. Quindi continuano ad abituarsi per molto più tempo di quanto necessario per svilupparli. Ma durante quel periodo, i requisiti cambiano (e si aggiungono a) a causa di cambiamenti legislativi, nel mercato, nella ricerca, negli utenti, qualsiasi cosa. E questo significa lavoro di manutenzione.

I sistemi legacy sono quelli di successo. Sono sopravvissuti al processo di sviluppo iniziale in cui il 50% dei progetti fallisce (anche dopo che il successo è stato ridefinito!). Sono sopravvissuti ad un ambiente di lavoro in evoluzione. Probabilmente sopravvissero a una decina di proposte di giovani programmatori ingenui per riscrivere l'intera faccenda in Java o qualsiasi cosa fosse di moda all'epoca. Sono stati abbastanza fortunati che qualunque reparto, azienda o agenzia che il software stava servendo è sopravvissuto ai vari tagli di budget, riorganizzazioni, fusioni, ecc.

Probabilmente meno del 5% del software scritto sarà ancora in esecuzione dieci anni dopo.

Quindi, piuttosto che lamentarsi di ciò, considerarlo un privilegio per lavorare su una tale storia di successo darwiniana e un'opportunità per imparare cosa funziona nel mondo reale e perché.

Il termine che viene spesso utilizzato per i nuovi progetti che non dipendono dallo sviluppo precedente è progetto greenfield . Di tanto in tanto potresti vedere il termine nelle schede di lavoro, sapendo che puoi ricominciare da zero piuttosto che ereditare il tentativo fallito di qualcun altro può rendere più attraente un lavoro.

Generalmente, i progetti software di successo impiegano molto più tempo di quanto non siano costruiti come nuovi progetti, quindi non sorprende affatto che non si possa fare un sacco di cose completamente "nuove".

Inoltre, creare qualcosa completamente nuovo è un lotto di lavoro. Anche su un progetto greenfield, probabilmente sceglierai un certo numero di strumenti per aiutarti: piattaforma, compilatore, framework, librerie, ecc. Non appena effettuerai tali scelte, avrai imposto determinati vincoli al tuo progetto. Questo non vuol dire che non stai facendo più un nuovo lavoro, solo che "nuovo" è un termine relativo qui. Non è un grande passo da li per vedere aggiungere una funzione o un modulo a un progetto esistente come "nuovo" anche se non lo chiameresti un progetto greenfield.

Dipende dal lavoro che cerchi.

Ho lavorato solo una volta per una società di prodotti software pura in cui ho lavorato alla loro singola applicazione placcata in oro in un piccolo gruppo di start-up.

Altrimenti ho lavorato per aziende tecnologiche che avevano bisogno di software per supportare la loro R & D interna o prodotti esterni.

Il lato positivo è che posso creare prodotti completi di inizio-fine e praticamente costruire ciò che voglio. A volte puoi provare anche le tecnologie più recenti rispetto a quando non sei riuscito ad aggiungere funzionalità a un'applicazione esistente leader del mercato.

Il lato negativo è che fai parte del costo, non parte del prodotto. Così ho avuto progetti in scatola perché "non stiamo facendo software" / "il software non è il core business" = è incredibile come le aziende pensano di poter vendere una macchina da $ 100 K senza software per farla funzionare!

Invece di vedere il codice legacy come ripulire continuamente il caos di qualcun altro, consideralo un'opportunità per lavorare su molti nuovi progetti.

Pensaci, ogni nuova funzionalità aggiunta a un sistema è un piccolo progetto al suo interno. È comunque necessario applicare l'intero SDLC per assicurarsi di aver completato correttamente il lavoro. Certo, è probabile che venga data una specifica per la funzione, ma di solito i dettagli precisi sono stati lasciati, quindi spetta a te analizzare il problema come mostrato, progettare il metodo migliore per applicare la modifica, testarla, codificarla, e poi rilasciarlo al tuo sistema di controllo della versione, e probabilmente mantenerlo in futuro.

È stata la mia esperienza che non ti capita spesso di lavorare in un campo completamente verde, e spesso quando sei stato abbastanza fortunato da farlo, ti aspetterai di vedere il progetto attraverso una buona parte della sua manutenzione e forse anche per la vita del prodotto, o per tutto il tempo che sei con un dato datore di lavoro. Questo perché la tua esperienza intima con un prodotto significa che diventi un deposito di conoscenza e può essere visto come costoso spostarti ad altre cose. Quando si avvia su un prodotto esistente, è perché il datore di lavoro ha recentemente perso una risorsa o ha bisogno di più risorse per il progetto, e il business deve garantire che non comporti una perdita eccessiva sull'investimento effettuato nel suo software . Questa è la realtà di essere un ingegnere del software.

Ho lavorato in IT per quasi 22 anni con gli ultimi 15 come sviluppatore di software, e in tutto questo tempo ho creato solo circa 5 nuovi prodotti, con la maggior parte del tempo a mantenere questi prodotti a lungo termine, o mantenere il prodotto di qualcun altro. Ognuno mi ha dato sfide e problemi da risolvere, e ognuno è stato trattato non come un semplice progetto di cui faccio parte, ma anche come una serie ENORME di microprogetti da completare.

È incredibile come una piccola ginnastica ritmica possa cambiare totalmente la tua percezione e il godimento del lavoro quotidiano che fai. ;-)

Penso che molti lavori di sviluppo software comportino il miglioramento di un prodotto esistente o l'adattamento del codice esistente a un nuovo cliente o mercato.

Questo non è veramente 'manutenzione'. Ad esempio, VMware ha appena rilasciato la versione 8, è un importante aggiornamento del loro prodotto principale. Sospetto che alcuni degli sviluppatori che hanno fatto questo lavoro fossero lì quando è stata scritta la prima riga di codice per VMWare. Hanno costruito il loro aggiornamento principale sul codice scritto da ragazzi che da molto tempo si sono trasferiti.

Nella Workplace Beta c'è una domanda su come i 20 di Google % sistema di progetto personale funziona .

Sono sicuro che Google ha capito che i migliori sviluppatori vogliono essere presenti alla creazione di nuovi prodotti software e alla fine si stancherà di anni di aggiunta di piccole funzionalità e di pizzicotti di gui per il prossimo punto di rilascio.

Avendo il 20% dei progetti, suppongo che lo sviluppatore di Google non si preoccupi di continuare a migliorare i progetti di Google, dal momento che lui o lei può ancora divertirsi ad essere lì all'inizio di qualcosa di nuovo.

Trascorrerai il tuo tempo creando nuove funzionalità e modificando la funzionalità del codice esistente per conformarti alle nuove specifiche.

Altri lo chiamano manutenzione ma è un termine orribile. È una riprogettazione e un refactoring o ricodifica del software per renderlo conforme a una nuova idea di ciò che il programma dovrebbe fare.

Direi che dipende dalla compagnia per cui lavori.

Il mio primo lavoro è stato una società di software di contabilità il cui prodotto principale è stato un sistema ERP, in competizione a circa lo stesso livello di come Great Plains o Peachtree (come in si è spostato fino ad esso da QuickBooks, o lateralmente quando si sono stancato di GP del offuscato schema o qualsiasi cosa tu abbia pensato che fosse sbagliato con PT, poi sei uscito completamente dal livello in un pacchetto come SAP). Quel lavoro era il 99,99% di manutenzione, definito come correggere bug e aggiungere "piccole cose", senza modificare fondamentalmente il modo in cui il software funzionava o cosa avrebbe potuto fare. Ho lasciato la società quando l'amministratore delegato voleva eseguire una riscrittura di pagina del sistema, il che sarebbe stato fantastico, tranne che ha insistito su diverse caratteristiche di design che sono anti-pattern chiari, come la piattaforma interna (che consente un alto grado di personalizzazione del programma fondamentalmente dando al cliente un Designer VS ridondante e personalizzando le regole aziendali fornendo un linguaggio di espressione.

Il mio prossimo lavoro dopo è stato uno studio che ha realizzato uno "sviluppo chiavi in mano"; il sistema ideato dal cliente è stato costruito da zero, hardware e software, quindi al completamento del progetto è stato consegnato al cliente che poteva mantenerlo autonomamente o mantenere i servizi dell'azienda a un canone mensile. Il mio lavoro consisteva nello sviluppo di uno di questi grandi progetti, e così mentre lavoravo lì praticamente tutto ciò che avevo fatto non esisteva prima di iniziare. Anche allora, lo sviluppo è intrinsecamente iterativo; aggiungi sempre quello che hai già (anche se quello che hai non è nulla) e devi evitare e correggere i problemi di regressione (nuove cose che infrangono vecchie cose). E una volta che il progetto è passato allo stato di "garanzia", le nuove funzionalità sono state completate e dovevamo correggere eventuali difetti riscontrati dal cliente durante i loro UAT.

Il mio attuale lavoro è tornato allo sviluppo interno, per un'azienda di sicurezza che utilizza il monitoraggio video e il feedback audio per fornire la verifica del segnale di allarme e altri servizi di "guardia virtuale". Questo campo sta crescendo rapidamente e continua a svilupparsi; le nuove attrezzature entrano nel mercato tutto il tempo, vengono registrati nuovi clienti che vogliono che facciamo nuove cose e che i prodotti esistenti non soddisfano più i regolamenti UL e governativi. Il 99% di questo lavoro è "integrazione"; scrivere un nuovo software mai esistito prima, per far funzionare una nuova ma preesistente attrezzatura o software con un'altra apparecchiatura o software preesistente, probabilmente precedente, in modo da poter fare nuove cose con entrambi.

Direi che dipende molto dalla natura del tuo ruolo.

Sono parte di un piccolo team e come tale, devo mantenere e supportare tutto ciò che creo.

5 anni fa, la maggior parte di ciò che facevo era "nuovo" - ora direi che la manutenzione del codice esistente occupa almeno metà del mio tempo, con un ulteriore 25% di versioni "nuove" di sistemi esistenti.

Ma se hai lavorato esclusivamente come sviluppatore con un team per la manutenzione e il supporto dopo aver rilasciato il tuo codice, tecnicamente tutto sarebbe "nuovo". Se riesci a trovare un lavoro in cui non sia necessario mantenere il tuo codice, prendilo!

1. Dipende da come il pericolo è la tua posizione di lavoro: ;-)

   Se lavori per una nuova azienda che sviluppa nuovi prodotti con un alto rischio che l'azienda sopravviva, probabilmente creerai alcuni nuovi fantastici prodotti.

   Se lavori per una vecchia società che ha una posizione stabile sul mercato, è più probabile che eseguirai il codice in modalità di manutenzione ;-).

2. La creazione di nuovo software è sempre molto allettante . La verità è difficile farlo in modo giusto . Fare codice mantenibile non è un compito banale.

   Se pensi a queste tonnellate di aspetti devi assicurarti di scrivere un buon codice: registrazione corretta, monitoraggio appropriato e acquisizione di statistiche, design descrittivo che sia efficiente e aiuti anche le persone non familiari a coinvolgere nel tuo progetto, documentazione, test automatici e test sviluppi guidati.

Non molte persone lo stanno facendo bene, quindi dobbiamo mantenere il loro codice e lucidarlo allo stato appropriato. ;-)

La buona notizia è che se sei in compagnia abbastanza a lungo, puoi avere un'influenza su come viene scritto il nuovo codice: -)

Indipendentemente dal fatto che la manutenzione o meno avvenga principalmente sotto il proprio controllo. Nel mio caso, la maggior parte del mio lavoro negli ultimi 15 anni è stato un nuovo sviluppo. Questo perché cerco lavori che mi permettano di fare nuovi sviluppi. Non sono un appaltatore e generalmente non faccio sviluppo web. Ho quasi sempre lavorato per piccoli datori di lavoro e di solito lavoro in aree di nicchia (sviluppo di GUI desktop, strumenti di controllo qualità, strumenti di sviluppo, mercati verticali).

Ho anche visto e sperimentato in prima persona che i migliori programmatori di un team tipicamente (anche se non sempre) ottengono i migliori lavori. Quindi, concentrati sull'essere il miglior programmatore della tua azienda e inizierai a vedere il nuovo sviluppo che ti viene in mente.

Lo sviluppo della manutenzione è un compito difficile, più difficile in molti modi rispetto al nuovo sviluppo. Nella mia esperienza i datori di lavoro preferiscono che uno sviluppatore effettui la manutenzione, soprattutto se sono bravi a farlo. Trovare sviluppatori di buona manutenzione in tecnologie legacy è più difficile che trovare qualcuno in grado di lavorare con l'ultima tecnologia.

Ho lavorato in un'azienda divisa in un team di prodotto, che era tutto di manutenzione, e un team di progetto, che era tutto nuovo sviluppo. C'erano grandi sviluppatori da entrambe le parti, ma i manutentori erano decisamente più specializzati e usavano la tecnologia legacy.

Posso suggerire di respingere e chiedere qualche nuovo lavoro di sviluppo? E se il tuo datore di lavoro fa solo manutenzione allora forse hai bisogno di andare avanti?

Direi che dipende da molti fattori. Dove lavori, che tipo di prodotti produci, come è organizzato il tuo team, ecc.

I quattro anni in cui ho lavorato nella mia azienda, direi che il 70-80% del mio tempo è dedicato alla creazione di qualcosa di nuovo. Probabilmente il 50-60% di questo viene speso per progetti di grandi dimensioni che è un codice completamente nuovo, mentre il resto di quel tempo viene speso per migliorare le funzionalità attuali.

Una parte di ciò che so è come funziona la mia azienda. Non tutti i membri del mio team di sviluppo dedicano questo tempo a sviluppare nuove funzionalità. Ci sono un numero che focalizza il loro tempo in nient'altro che correggere bug / caccia. Se si tratta di una funzionalità nuova di zecca o se hanno bisogno di aiuto, allora mi viene cacciata per indagare. In generale, tuttavia, quel piccolo gruppo di cacciatori di bug è ciò che consente al gruppo più ampio di sviluppatori di continuare a lavorare senza interruzioni.

Ho lavorato per quasi tre anni come unico sviluppatore in una società che utilizzava QuickBooks ed Excel e nient'altro quando ho iniziato Ora abbiamo un'applicazione Windows Form , un SharePoint configurazione, SQL Server + Report, un componente aggiuntivo di Excel e un componente aggiuntivo di Outlook.

Solo oggi , ho installato per la prima volta un sistema di ticketing perché ho perso la capacità di gestire le richieste di posta elettronica a un ritmo che impediva agli utenti di lamentarsi, quindi vedo che questo è un segnale che io Hai inserito la modalità di manutenzione.

I miei precedenti lavori sono stati più simili a quelli che gli altri hanno pubblicato, ma ho pensato che avrei gettato la mia esperienza atipica solo perché mostrerò che non sai mai quale sarà il prossimo lavoro. Sono esausto, ma la quantità che ho imparato in questo lavoro è valsa la pena del lavoro.

Alcune grandi organizzazioni come la società per cui lavoro hanno una politica di disattivazione del software dopo un certo numero di anni, forse perché il linguaggio di sviluppo in cui è stato scritto non è più utilizzato (Delphi chiunque?), o la piattaforma viene sostituita ( Windows XP), oi requisiti normativi lo richiedono. Per esempio. programmi a due livelli che comunicano direttamente con un database vengono ora dismessi a favore di tre livelli che utilizzano connessioni Kerberized per una maggiore sicurezza.

Gli utenti hanno ancora bisogno di quella funzionalità originale, quindi viene sviluppata una versione completamente nuova che utilizza le tecniche dello stato dell'arte.

Aspettatevi un ciclo di sostituzione di 5-7 anni per questo tipo di cose. Per esempio entro il 2020, mi aspetto che il software WPF (Client) / Java (server) che sto scrivendo ora sarà vecchio di tecnologia e sostituito da qualcosa di più recente.