A criação de software novo é geralmente uma parte importante da maioria dos trabalhos de programação? [fechadas]

Uma grande quantidade de trabalho de software é a manutenção. Nenhum gerente de contratação lhe dirá isso, é claro, mas certamente é o caso.

Sim, sua percepção é correta. É um truísmo absoluto que muito mais tempo, dinheiro e esforço sejam gastos na manutenção de sistemas do que na criação de novos sistemas. Então, obviamente, a alocação de tempo da maioria dos programadores vai refletir isso.

Parte da razão para isso é que muitas pessoas, quando conseguem fazer "novas e criativas", fazem isso mal, de modo que manter o sistema é difícil (isso é especialmente provável se elas nunca fazer manutenção por conta própria - ninguém que tenha trabalhado constantemente em pequenos projetos greenfield pode realmente afirmar ser competente).

Outra razão (provavelmente maior) é que a maioria dos sistemas é projetada para ser continuamente útil, não apenas para um evento único. Então, eles continuam se acostumando por muito mais tempo do que o necessário para desenvolvê-los. Mas durante esse tempo, os requisitos mudam (e são adicionados) devido a mudanças na legislação, no mercado, na pesquisa, nos usuários, etc. E isso significa trabalho de manutenção.

Sistemas legados são os bem-sucedidos. Eles sobreviveram ao processo de desenvolvimento inicial, onde 50% dos projetos falham (mesmo após o sucesso ter sido redefinido!). Eles sobreviveram a um ambiente de negócios em mudança. Eles provavelmente sobreviveram a cerca de dez propostas de jovens programadores ingênuos para reescrever a coisa toda em Java ou o que quer que estivesse na moda na época. Eles tiveram a sorte de que, seja qual for o departamento, a empresa ou a agência que o software estivesse servindo, sobreviveram aos vários cortes no orçamento, reorganizações, fusões etc.

Provavelmente menos de 5% do software gravado ainda será executado dez anos depois.

Então, em vez de reclamar, veja como um privilégio trabalhar em uma história de sucesso de Darwin e uma oportunidade de aprender o que funciona no mundo real e por quê.

O termo que é frequentemente usado para novos projetos que não são dependentes de desenvolvimento antigo é projeto greenfield . Você pode ocasionalmente ver o termo nas listas de empregos - saber que você começa do zero ao invés de herdar o empreendimento falho de outra pessoa pode tornar o trabalho mais atraente.

Projetos de software bem-sucedidos geralmente gastam muito mais tempo sendo mantidos do que sendo construídos como novos projetos, então não é de todo surpreendente que você não consiga fazer muitas coisas completamente "novas".

Além disso, criar algo completamente novo é um lote de trabalho. Mesmo em um projeto greenfield, você provavelmente escolherá várias ferramentas para ajudá-lo: plataforma, compilador, estruturas, bibliotecas, etc. Assim que você fizer essas escolhas, terá imposto certas restrições em seu projeto. Isso não quer dizer que você não está mais fazendo um novo trabalho, apenas que "novo" é um termo relativo aqui. Não é um grande passo para ver adicionar um recurso ou módulo a um projeto existente como "novo", mesmo que você não o chame de um projeto totalmente novo.

Depende de qual trabalho você procura.

Eu trabalhei apenas uma vez para uma empresa de produtos de software pura, onde trabalhei em sua única aplicação banhada a ouro em uma pequena equipe de start-ups.

Caso contrário, trabalhei para empresas de tecnologia que precisavam de software para dar suporte a seus produtos internos de R & D ou externos.

A vantagem é que eu começo a construir produtos completos de acabamento e praticamente construo o que eu quero. Às vezes, você também pode experimentar tecnologias mais recentes do que se estivesse preso ao adicionar recursos a um aplicativo líder de mercado existente.

A desvantagem é que você faz parte do custo e não faz parte do produto. Então eu tive projetos enlatados porque 'não estamos fazendo software' / 'o software não é o core business' = é incrível como as empresas acham que podem vender uma máquina-ferramenta de $ 100 K sem nenhum software para operá-lo!

Em vez de ver o código legado a limpar continuamente a bagunça de outra pessoa, veja-o como uma oportunidade para trabalhar em muitos projetos novos.

Pense nisso, cada novo recurso adicionado a um sistema é um pequeno projeto em si. Você ainda precisa aplicar o SDLC inteiro para garantir que tenha concluído o trabalho corretamente. Claro, você provavelmente recebe uma especificação para o recurso, mas geralmente os detalhes foram deixados para trás, então cabe a você analisar o problema como mostrado, projetar o melhor método para aplicar a mudança, testá-la, codificá-la, e, em seguida, liberá-lo de volta ao seu sistema de controle de versão e, possivelmente, mantê-lo no futuro.

Tem sido minha experiência que você muitas vezes não consegue trabalhar em um campo completamente verde e, freqüentemente, quando tiver sorte o suficiente para fazê-lo, espera-se que você veja o projeto em uma boa parte de sua manutenção e talvez até mesmo pelo tempo de vida do produto, ou pelo tempo todo que você está com um determinado empregador. Isso ocorre porque sua experiência íntima com um produto significa que você se torna um repositório de conhecimento e pode ser visto como caro para levá-lo para outras coisas. Quando você inicia um produto existente, é porque o empregador recentemente perdeu um recurso ou precisa de mais recursos no projeto, e o negócio precisa garantir que ele não cause uma perda muito grande no investimento que ele fez em seu software. . Essa é a realidade de ser um engenheiro de software.

Trabalhei na área de TI por quase 22 anos com os últimos 15 anos como desenvolvedor de software e, durante todo esse tempo, criei apenas cerca de 5 novos produtos, com a maior parte do tempo mantendo esses produtos a longo prazo ou manter o produto de outra pessoa. Cada um deles me deu desafios e problemas para resolver, e cada um deles foi tratado não apenas como um grande projeto do qual sou apenas parte, mas também como uma série ENORME de micro-projetos para completar.

É incrível como um pouco de calistenia mental pode mudar totalmente a sua percepção e o prazer do trabalho diário que você faz. ;-)

Acho que muitas tarefas de desenvolvimento de software envolvem a melhoria de um produto existente ou a adaptação do código existente a um novo cliente ou mercado.

Isso não é realmente 'manutenção'. Por exemplo, a VMWare acaba de lançar a versão 8, é uma grande atualização para seu principal produto. Eu suspeito que poucos dos desenvolvedores que fizeram este trabalho estavam lá quando a primeira linha de código para VMWare foi escrita. Eles construíram sua grande atualização no código escrito por caras que há muito se mudaram.

Na Workplace Beta, há uma pergunta sobre como o Google 20 % de sistema de projetos pessoais funciona .

Com os projetos de 20%, especulo que o desenvolvedor do Google não se importará em continuar melhorando os projetos do Google, já que ele ainda pode ter a diversão de estar lá no início de algo novo.

Você gastará seu tempo criando novas funcionalidades e alterando a funcionalidade do código existente para estar em conformidade com a nova especificação.

Outros estão chamando essa manutenção, mas esse é um termo horrível. É um novo design e uma refatoração ou recodificação do software para torná-lo compatível com uma nova ideia do que o programa deve fazer.

Eu diria que depende da empresa em que você trabalha.

Meu próximo trabalho depois disso foi uma empresa contratada que fez "desenvolvimento turnkey"; O sistema que o cliente especificou foi construído a partir do zero, hardware e software e, em seguida, na conclusão do projeto, tudo foi entregue ao cliente, que poderia mantê-lo ou manter os serviços da empresa por uma taxa mensal. Meu trabalho foi no desenvolvimento de um desses grandes projetos, e assim, enquanto eu trabalhava lá praticamente tudo que eu tinha feito não existia antes de eu começar. Mesmo assim, o desenvolvimento é inerentemente iterativo; você está sempre adicionando ao que você já tem (mesmo se o que você tem é nada), e você tem que evitar e consertar problemas de regressão (coisas novas quebrando coisas velhas). E assim que o projeto entrou no status de "garantia", a nova funcionalidade foi concluída e era esperado que corrigíssemos quaisquer defeitos que o cliente encontrasse durante os seus UATs.

Meu trabalho atual é voltar ao desenvolvimento interno, para uma empresa de segurança que usa monitoramento de vídeo e feedback de áudio para fornecer verificação de sinal de alarme e outros serviços de "guarda virtual". Este campo está crescendo rapidamente e ainda está se desenvolvendo; novos equipamentos entram no mercado o tempo todo, novos clientes são contratados e querem que façamos coisas novas, e os produtos existentes não atendem mais à adaptação dos regulamentos da UL e do governo. 99% deste trabalho é "integração"; escrever um novo software que nunca existiu antes, para fazer com que um equipamento ou software novo, mas pré-existente, trabalhe com outro equipamento ou software pré-existente provavelmente mais antigo, para que possamos fazer coisas novas com ambos.

Eu diria que isso depende muito da natureza do seu papel.

Eu faço parte de uma equipe pequena e, como tal, tenho que manter e dar suporte a tudo que eu criar.

Cinco anos atrás, a maior parte do que eu fiz era "novo" - agora eu diria que a manutenção de código existente ocupa pelo menos metade do meu tempo, com outros 25% sendo versões "novas" de sistemas existentes. p>

Mas se você trabalhou apenas como desenvolvedor com uma equipe para fazer manutenção e suporte depois de liberar seu código, então, tecnicamente, tudo seria "novo". Se você puder encontrar um emprego em que não seja necessário manter seu próprio código, aproveite!

1. Depende de como o perigo é o seu emprego: ;-)

   Se você trabalha para uma nova empresa que desenvolve novos produtos com alto risco de que a empresa sobreviva, é provável que você crie ótimos produtos novos.

   Se você trabalha para uma empresa antiga que tem uma posição estável no mercado, é mais provável que você codifique no modo de manutenção ;-).

2. A criação de novos softwares é sempre muito tentadora . A verdade é difícil fazer isso de uma maneira correta. Fazer código de manutenção não é uma tarefa trivial.

   Se você pensar nesses vários aspectos, certifique-se de escrever um código bom: criação de log adequada, monitoramento adequado e aquisição de estatísticas, design descritivo que seja eficiente e ajude pessoas até mesmo desconhecidas a se envolverem em seu projeto, documentando, testando e testando automaticamente impulsionado desenvolvimentos.

Não há muitas pessoas fazendo certo, então devemos manter seu código e polá-lo para o estado adequado. ;-)

A boa notícia é que, se você estiver na empresa por tempo suficiente, poderá influenciar a forma como o novo código é escrito: -)

Se você faz principalmente manutenção ou não está pelo menos parcialmente sob seu controle. No meu caso, a maior parte do meu trabalho nos últimos 15 anos tem sido um novo desenvolvimento. Isso porque busco trabalhos que me permitam fazer novos desenvolvimentos. Eu não sou um empreiteiro, e eu geralmente não faço desenvolvimento web. Eu quase sempre trabalhei para pequenos empregadores, e geralmente trabalho em áreas de nicho (desenvolvimento de GUI de desktop, ferramentas de controle de qualidade, ferramentas de desenvolvimento, mercados verticais).

Eu também vi e experimentei em primeira mão que os melhores programadores em uma equipe normalmente (embora nem sempre) conseguem os melhores trabalhos. Então, concentre-se em ser o melhor programador da sua empresa e você começará a ver novos desenvolvimentos em seu caminho.

O desenvolvimento de manutenção é uma tarefa difícil, mais difícil em muitos aspectos do que um novo desenvolvimento. Na minha experiência, os empregadores gostam de manter um desenvolvedor fazendo manutenção, especialmente se eles são bons nisso. Encontrar bons desenvolvedores de manutenção em tecnologias herdadas é mais difícil do que encontrar alguém que possa trabalhar com a tecnologia mais recente.

Eu trabalhei em uma empresa que foi dividida em uma equipe de produto, que era toda manutenção, e uma equipe de projeto, que era totalmente nova. Houve grandes desenvolvedores em ambos os lados, mas os caras de manutenção foram definitivamente mais especializados e usaram tecnologia legada.

Posso sugerir que você retroceda e peça algum novo trabalho de desenvolvimento? E se o seu empregador só faz manutenção, então talvez você precise seguir em frente?

Eu diria que isso depende de muitos fatores. Onde você trabalha, que tipo de produtos você faz, como sua equipe está organizada, etc.

Nos quatro anos em que trabalhei na minha empresa, eu diria que 70 a 80% do meu tempo é gasto criando algo novo. Provavelmente, 50-60% disso é gasto em projetos grandes que é um código totalmente novo, enquanto o restante desse tempo é gasto em aprimoramentos para a funcionalidade atual.

Parte disso eu sei é como minha empresa funciona. Nem todo mundo na minha equipe de desenvolvimento gasta esse tempo criando novas funcionalidades. Há um número que concentra seu tempo em nada além de correção / busca de bugs. Se é uma peça nova de funcionalidade ou eles precisam de ajuda, então é chutado para mim para investigar. Em geral, essa pequena equipe de caçadores de bugs é o que permite que um grupo maior de desenvolvedores continue sem interrupções.

Estou trabalhando há quase três anos como o único desenvolvedor em uma empresa que usou o o QuickBooks e o Excel e nada mais quando eu comecei. Agora temos um aplicativo Windows Forms , um SharePoint , SQL Server + Reports, um suplemento do Excel e um suplemento do Outlook.

Apenas hoje , configurei pela primeira vez um sistema de tickets porque perdi a capacidade de gerenciar solicitações de e-mail a uma taxa que impedia que os usuários se queixassem, portanto, vejo que isso é um sinal de que eu entrou no modo de manutenção.

Meus trabalhos anteriores foram mais parecidos com o que os outros postaram, mas eu imaginei que eu iria jogar minha experiência atípica só porque isso mostra que você nunca sabe o que o próximo trabalho trará. Estou exausta, mas a quantia que aprendi nesse trabalho valeu a pena.

Algumas organizações maiores, como a Empresa em que trabalho, têm uma política de descomissionamento de software após alguns anos, talvez porque a linguagem de desenvolvimento em que ela foi escrita não seja mais usada (qualquer um dos Delphi?) ou a plataforma esteja sendo substituída ( Windows XP), ou requisitos regulamentares exigem isso. Por exemplo. dois programas de nível que conversam diretamente com um banco de dados estão sendo descomissionados em favor de três camadas que usam conexões Kerberizadas para maior segurança.

Os usuários ainda precisam dessa funcionalidade original, e assim uma versão completamente nova usando as técnicas atuais de ponta é desenvolvida.

Espere um ciclo de substituição de 5 a 7 anos para esse tipo de coisa. Por exemplo, em 2020, espero que o software WPF (Cliente) / Java (servidor) que estou escrevendo agora seja antigo e seja substituído por algo mais recente.