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

Trabalho com desenvolvimento de software há mais de 10 anos, e me ocorre que raramente consigo criar algo "novo". Percebo que "novo" é um termo vago, mas o definiria como qualquer coisa, desde um novo projeto óbvio em grande escala até um novo recurso grande em um projeto existente (diga algo que exigiria alguma reflexão em seu design e que poderia levar 2 semanas ou mais para concluir). Talvez uma diretriz aproximada seja algo novo, se exigir uma especificação por escrito. Acho que a maioria dos programadores sabe do que estou falando - você está na zona, escrevendo uma tonelada de código em um ritmo acelerado.

Enfim, pensando no que fiz, eu estimaria que menos de 10% do meu tempo é gasto em trabalhos "novos". Existem coisas como "adaptar esse sistema existente para funcionar nesse novo ambiente", o que certamente exige muito planejamento, mas a codificação real e o "novo material" se resumem a fazer pequenas alterações em muitos lugares do código. O mesmo se aplica a pequenas solicitações de recursos - se eu sei o que fazer, elas geralmente podem ser concluídas em menos de uma hora e, se não, é muita leitura de código e definição do que fazer (o que me frustra porque eu aprendo muito melhor fazendo, não lendo).

Em geral, sinto que não estou criando nada na maioria das vezes. Eu meio que assumi que esse era o caso na maioria dos lugares - um novo produto seria lançado rapidamente e naquele momento todos ficariam empolgados e divulgariam o código em um ritmo acelerado, mas, uma vez ativo, ele passa para o modo de manutenção, onde algumas das alterações subseqüentes seriam consideradas "novas e criativas".

Estou errado? Estou descrevendo com precisão a maioria dos trabalhos de programação ou a maioria dos programadores sente que está frequentemente criando coisas novas?

Uma grande parte do trabalho de software é manutenção. Nenhum gerente de contratação vai realmente dizer isso, é claro, mas certamente é o caso.

Sim, sua percepção é precisa. É um truísmo absoluto que muito mais tempo, dinheiro e esforço são 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 refletirá isso.

Parte do motivo disso é que muitas pessoas, quando fazem "novas e criativas", fazem mal, de modo que a manutenção do sistema é difícil (isso é especialmente provável se eles nunca fizeram manutenção por conta própria - ninguém que trabalhou 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 pontual. Então eles continuam se acostumando por muito mais tempo do que o necessário para desenvolvê-los. Porém, durante esse período, os requisitos mudam (e são adicionados a) devido a alterações na legislação, no mercado, na pesquisa, nos usuários, o que for. E isso significa trabalho de manutenção.

Os 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 tudo em Java ou o que estava na moda na época. Eles tiveram a sorte de que qualquer departamento, empresa ou agência que o software estivesse servindo sobreviveu a vários cortes no orçamento, reorganizações, fusões etc.

Provavelmente menos de 5% do software escrito ainda estará em execução dez anos depois.

Então, ao invés de lamentar, veja como um privilégio trabalhar em uma história de sucesso darwiniana 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 dependem de desenvolvimento mais antigo é projeto greenfield . Ocasionalmente, você pode ver o termo nas listagens de empregos - saber que você começa do zero, em vez de herdar o esforço fracassado de outra pessoa, pode tornar o trabalho mais atraente.

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

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

Depende do trabalho que você procura.

Só trabalhei uma vez para uma empresa pura de produtos de software, onde trabalhei em seu único aplicativo banhado a ouro em uma pequena equipe de start-up.

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

O lado positivo é que eu consigo criar produtos completos de início a fim e praticamente criar o que eu quero. Às vezes, você também pode tentar 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, não faz parte do produto. Por isso, tive projetos enlatados porque 'não estamos desenvolvendo software "/" software não é o principal negócio "= é incrível como as empresas pensam que podem vender uma máquina-ferramenta de US $ 100 mil sem software para operá-la!

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

Pense bem, cada novo recurso adicionado a um sistema é um pequeno projeto em si. Você ainda precisa aplicar o SDLC inteiro para garantir que você concluiu o trabalho corretamente. Certamente, você provavelmente forneceu uma especificação para o recurso, mas geralmente os detalhes foram deixados para você; portanto, cabe a você analisar o problema conforme mostrado, projetar o melhor método para aplicar a alteração, testá-la, codificá-la, e, em seguida, libere-o de volta ao seu sistema de controle de versão e, possivelmente, mantenha-o no futuro.

Tem sido minha experiência que você não costuma trabalhar em um campo completamente verde e, muitas vezes, quando você tem a sorte de fazê-lo, espera-se que você veja o projeto através de uma boa parte de sua manutenção e talvez até por durante a vida útil do produto ou durante todo o tempo em que você estiver 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 a outras coisas. Quando você inicia um produto existente, é porque o empregador perdeu recentemente um recurso ou precisa de mais recursos no projeto, e os negócios da empresa precisam garantir que isso não cause uma perda muito grande no investimento feito em seu software . Essa é a realidade de ser um engenheiro de software.

Trabalho com TI há quase 22 anos com os últimos 15 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 mantendo a manutenção de outra pessoa. produtos. Cada um 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 ENORME série de micro-projetos a serem concluídos.

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

Penso que muitos trabalhos 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, o VMWare acaba de lançar a versão 8, é uma grande atualização para o produto principal. Eu suspeito que alguns dos desenvolvedores que fizeram esse trabalho estavam lá quando a primeira linha de código do VMWare foi escrita. Eles construíram sua grande atualização no código escrito por caras que há muito tempo seguiram em frente.

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

Estou certo de que o Google descobriu que os melhores desenvolvedores querem estar lá na criação de novos produtos de software e acabarão cansando-se de anos adicionando pequenos recursos e aprimorando as GUIs para o próximo lançamento.

Por ter os projetos de 20%, especulo que o desenvolvedor do Google não se importe em ficar para melhorar os projetos do Google, pois ele ainda pode se divertir ao 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 isso de manutenção, mas esse é um termo horrível. É um redesenho e uma refatoração ou recodificação do software para torná-lo compatível com uma nova idéia do que o programa deve fazer.

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

Meu primeiro trabalho foi uma empresa de software de contabilidade cujo principal produto era um sistema ERP, competindo no mesmo nível que Great Plains ou Peachtree (como você mudou para o QuickBooks ou de lado quando se cansou do esquema ofuscado da GP ou qualquer outra coisa) você pensou que estava errado com o PT, então você saiu da camada para um pacote como o SAP). Esse trabalho consistia em 99,99% de manutenção, definido como corrigir bugs e adicionar "pequenas coisas", sem alterar fundamentalmente a maneira como o software funcionava ou o que poderia fazer. Saí da empresa quando o CEO quis fazer uma reescrita da primeira página do sistema, o que seria legal, exceto se ele insistisse em vários recursos de design que são claramente antipadrões, como a plataforma interna (permitindo um alto grau de personalização do programa, basicamente fornecendo ao cliente um VS Designer estúpido,

Meu próximo trabalho depois disso foi uma empresa contratada que fez "desenvolvimento chave na mão"; o sistema que o cliente especificou foi construído desde o início, hardware e software; depois, 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 estava no desenvolvimento de um desses grandes projetos e, enquanto eu trabalhava lá, praticamente tudo o que havia feito não existia antes de começar. Mesmo assim, o desenvolvimento é inerentemente iterativo; você está sempre adicionando ao que já tem (mesmo que o que você tem não seja nada) e precisa evitar e corrigir problemas de regressão (coisas novas quebrando coisas antigas). E uma vez que o projeto passou para o status "garantia",

Meu trabalho atual está de volta 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 em desenvolvimento; novos equipamentos entram no mercado o tempo todo, novos clientes são contratados e desejam que façamos coisas novas, e os produtos existentes não mais atendem às normas da UL e do governo. 99% deste trabalho é "integração"; escrever um novo software que nunca existia antes, para fazer com que um equipamento ou software novo, mas pré-existente, funcione com outro equipamento ou software pré-existente provavelmente mais antigo, para que possamos fazer coisas novas com ambos.

Eu diria que depende muito da natureza do seu papel.

Faço parte de uma equipe pequena e, como tal, tenho que manter e dar suporte a tudo que crio.

Há cinco anos, a maioria do que eu fiz foi "novo" - agora eu diria que a manutenção do código existente ocupa pelo menos metade do meu tempo, com outros 25% sendo versões "novas" dos sistemas existentes.

Mas se você trabalhou apenas como desenvolvedor com uma equipe para assumir a manutenção e o suporte após o lançamento do código, tecnicamente tudo seria "novo". Se você puder encontrar um trabalho em que não é necessário manter seu próprio código, aceite-o!

1. Depende do perigo do seu cargo: ;-)

   Se você trabalha para uma nova empresa que desenvolve novos produtos com um alto risco de sobrevivência, provavelmente cria novos ótimos produtos.

   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 um novo software é sempre muito tentadora . A verdade é difícil fazer isso da maneira certa . Fazer código sustentável não é uma tarefa trivial.

   Se você pensar nessas toneladas de aspectos, deve garantir a boa codificação: registro adequado, monitoramento adequado e aquisição de estatísticas, design descritivo que seja eficiente e ajude até pessoas desconhecidas a se envolverem em seu projeto, documentação, testes automáticos e desenvolvimentos conduzidos por testes.

Como muitas pessoas não estão fazendo o que é certo, devemos manter o código e aperfeiçoá-lo no estado apropriado. ;-)

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 foi um novo desenvolvimento. Isso ocorre porque procuro empregos que me permitam fazer novos desenvolvimentos. Eu não sou um contratado e geralmente não desenvolvo web. 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 desenvolvedor, mercados verticais).

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

O desenvolvimento da manutenção é uma tarefa difícil, mais difícil do que o 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 todo novo desenvolvimento. Havia ótimos desenvolvedores de ambos os lados, mas o pessoal de manutenção era definitivamente mais especializado e usava tecnologia legada.

Posso sugerir que você recue e peça um novo trabalho de desenvolvimento? E se o seu empregador faz apenas manutenção, talvez você precise seguir em frente?

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

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

Parte disso eu sei é como minha empresa funciona. Nem todo mundo na minha equipe de desenvolvimento gasta esse tempo construindo novas funcionalidades. Há um número que concentra seu tempo em nada além de correção / caça de bugs. Se é uma nova funcionalidade ou eles precisam de ajuda, é preciso que eu investigue. Em geral, porém, essa pequena equipe de caçadores de bugs é o que permite que um grupo maior de desenvolvedores prossiga sem interrupção.

Trabalho há quase três anos como o único desenvolvedor de uma empresa que usava QuickBooks e Excel e nada mais quando comecei. Agora, temos um aplicativo Windows Forms , uma instalação do SharePoint , SQL Server + Reports, um suplemento do Excel e um suplemento do Outlook.

Só hoje , eu configurei pela primeira vez um sistema de bilhética porque eu perdi a capacidade de gerenciar solicitações de e-mail a uma taxa que manteve usuários de reclamar, então eu ver 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 imaginei que contaria minha experiência atípica apenas porque mostra que você nunca sabe o que o próximo trabalho trará. Estou exausta, mas a quantia que aprendi neste trabalho valeu a pena.

Algumas organizações maiores, como a empresa em que trabalho, têm uma política de desativação de software após vários anos, talvez porque a linguagem de desenvolvimento em que foi escrita não seja mais usada (Delphi alguém?) Ou a plataforma esteja sendo substituída (Windows XP) , ou requisitos regulatórios exigem. Por exemplo, programas de duas camadas que conversam diretamente com um banco de dados agora 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, é desenvolvida uma versão completamente nova, usando as técnicas atuais de última geração.

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