Realmente não houve uma coisa nos últimos 20 anos que proporcionou enormes ganhos no desenvolvimento de software? [fechadas]

Em No Silver Bullet , Fred Brooks faz uma variedade de previsões sobre o futuro da engenharia de software, resumindo melhor:

Não existe um desenvolvimento único, seja na tecnologia ou na técnica de gerenciamento, que por si só prometa até uma melhoria de ordem de magnitude na produtividade, na confiabilidade e na simplicidade.

Seu argumento é muito convincente. Brooks estava escrevendo em 1986: ele estava certo? Os desenvolvedores em 2014 produzem software a uma taxa inferior a 10x mais rapidamente do que seus colegas em 1986? Por alguma métrica apropriada - qual foi o tamanho do ganho de produtividade?

Os desenvolvedores em 2014 produzem software a uma taxa inferior a 10x mais rapidamente do que seus colegas em 1986?

Imagino que tenha havido pelo menos uma melhoria de ordem de magnitude na produtividade desde então. Mas não aproveitando um único desenvolvimento, seja na tecnologia ou na técnica de gerenciamento.

Aumentos na produtividade ocorreram por uma combinação de fatores. Nota: Esta não é uma lista abrangente:

1. Melhores compiladores
2. Computadores imensamente mais potentes
3. Intellisense
4. Orientação a objetos
5. Orientação funcional
6. Melhores técnicas de gerenciamento de memória
7. Verificação de limites
8. Análise de código estático
9. Digitação forte
10. Teste de Unidade
11. Melhor design da linguagem de programação
12. Geração de código
13. Sistemas de controle de código fonte
14. Reutilização de código

E assim por diante. Todas essas técnicas se combinam para produzir ganhos de produtividade; não há uma única bala de prata que já tenha produzido uma ordem de aumento de magnitude.

Observe que algumas dessas técnicas existem desde os anos sessenta, mas só observaram amplo reconhecimento e adoção recentemente.

A resposta de Robert Harvey é boa, mas acho que ele deixou de lado o que pode ser a maior razão pela qual os programadores são mais produtivos do que nunca: ampla disponibilidade de bibliotecas de software.

Quando comecei minha carreira, não havia STL, .NET, QT, etc. Você tinha C ou C ++ em bruto, e foi isso.

Coisas que costumavam levar dias ou semanas ou trabalho (análise XML, conexões TCP / IP, comunicação HTTP) agora podem ser feitas com algumas linhas de código C #. É aqui que obtemos ordens de magnitude melhores em termos de produtividade geral do desenvolvedor.

Nosso produto atual usa uma estrutura de janela de encaixe que adquirimos de um fornecedor. Isso permite que eu tenha uma interface de usuário da janela de encaixe totalmente funcional em questão de minutos. Estremeço ao pensar no que seria necessário para fazer isso nos dias de uso da API do win32.

Por uma questão de argumento, discordo da afirmação de Fred Brooks .

Há uma melhoria na tecnologia que permitiu uma melhoria de produtividade em ordem de magnitude: Internet e, mais precisamente, a disponibilidade progressiva da conexão à Internet em todas as residências nas últimas duas décadas.

Ser capaz de encontrar instantaneamente uma resposta para quase todos os problemas que você pode encontrar como desenvolvedor permite um enorme aumento na produtividade. Não sabe como selecionar o enésimo elemento no JQuery? A pesquisa do Google leva a uma resposta da pergunta exata no Stack Overflow . Não sabe usar overflowem CSS? O MDN da Mozilla está aqui . Esqueceu o que a virtualpalavra-chave significa em C #? O Google ajuda novamente.

Quando comecei a programar, não tinha internet. Eu tinha livros, assim como alguma documentação em formato digital armazenada localmente, mas a pesquisa em livros e documentação foi um processo lento, e não importa quantos livros eu tivesse, havia muitos problemas que não foram mencionados lá.

Mais importante, quase todos os problemas que você encontra já foram encontrados por outra pessoa antes. A Internet ajuda a encontrar pessoas que tiveram esse erro e o resolveram com sucesso. Este não é um tipo de informação encontrada em livros ou documentação oficial como o MSDN. Em vez disso, essas informações geralmente são encontradas:

• No Stack Overflow, obviamente. Por exemplo, eu não vi nenhum livro que mencionasse esse problema .

• Nos blogs. Encontrei muita ajuda em blogs quando tive problemas específicos, seria na configuração do WCF ou em um servidor proxy que não é iniciado ou um bug enigmático ao usar uma API específica em uma máquina com cultura diferente dos EUA.

• Nos relatórios de erros relacionados ao software de código aberto. Por exemplo, foi muito útil recentemente quando tentei usar o MAAS do Ubuntu e quando usei o PXE. Você também não encontra esse tipo de informação nos livros.

A importância da disponibilidade imediata de uma resposta para a maioria dos problemas que podemos encontrar é especialmente perceptível se levarmos em conta que na maioria das vezes uma equipe gasta em um projeto é gasta em sua manutenção .

• A Internet não ajuda muito durante as fases de arquitetura e design (Programmers.SE pode ajudar, mas seria muito mais valioso para um arquiteto ler livros sobre arquitetura e design, aprender padrões de design etc.).

• Começa a ser útil durante as etapas de teste e implementação, quando surgem problemas reais.

• Mas a maioria dos problemas que aparecem durante a manutenção está presente quando a ajuda de outras pessoas através da Internet parece crucial . Exemplo básico: um serviço WCF funciona perfeitamente na minha máquina , mas falha, sem exceção, quando implementado na produção, enquanto funcionava nas últimas duas semanas. Isso aconteceu comigo e sou grato aos criadores de blogs e à comunidade Stack Overflow por me ajudarem a resolver o problema em questão de horas, em vez de semanas.

Isso justificaria um aumento de 10 vezes na produtividade? Difícil de dizer.

• Por um lado, há casos em que você encontra uma resposta imediatamente, enquanto você poderia ter passado dias procurando por ela sozinho (ou forçado a reescrever uma grande parte do aplicativo).

• Por outro lado, a produtividade geral melhorou com base em vários fatores, como melhor gerenciamento de projetos (Agile, TDD etc.), melhor gerenciamento de equipes ( Radical Management de Stephen Denning vem à mente), melhores ferramentas (depuradores, criadores de perfil , IDEs etc.), melhor hardware (não, não serei muito produtivo se forçado a escrever no Assembler para uma CPU lenta e RAM muito limitada), etc.

Eu diria que a internet é um bom candidato. StackOverflow e Google são as ferramentas mais poderosas de um desenvolvedor moderno. Compartilhamento instantâneo de conhecimento em uma base global! Hoje em dia, você não precisa saber as respostas, precisa saber como conhecê- las - e esse é um substituto perfeitamente adequado que permite que os desenvolvedores passem menos tempo lendo e mais tempo codificando e, assim, sejam produtivos. Isso significa que todos os programadores do mundo têm acesso a todas as respostas e tudo o que precisam fazer é saber como fazer as perguntas certas.

Eu sugeriria que as tendências que nos puxam na outra direção (ou seja, em direção à menor produtividade) são pelo menos tão fortes quanto as tendências que você perguntou. A experiência de criar uma ferramenta de desenvolvimento de cliente / servidor como VB6 ou PowerBuilder chegou bem perto do ideal "Rapid Application Development" (RAD). Você precisa desenhar seus formulários e havia ganchos óbvios para seu código processual ou SQL.

O desenvolvimento da Web, pelo menos inicialmente, destruiu muitas das técnicas e infra-estruturas que tornaram essas coisas possíveis, e muitos desenvolvedores de clientes / servidores simplesmente deixaram de ser desenvolvedores ou se apegaram desesperadamente ao VB6.

A transição para o desenvolvimento da Web fortemente direcionado ao cliente foi mais uma experiência de corte e queima; A Microsoft estava voltando ao ideal da RAD com o WebForms, e logo caiu em desuso. Em vez disso, esperava-se que os desenvolvedores abusassem da infraestrutura (por exemplo, XMLHttpRequest, que raramente é usada para XML) e, de outra forma, se esquivariam de um baixo nível de abstração, em um esforço para tornar seus sites mais interativos.

Existem boas razões por trás de todas essas transições e não é justo comparar um processo que produziu um .EXE nativo (exigindo instalação e gerenciamento no cliente individual) ao desenvolvimento da Web, nem é completamente justo comparar um processo que depende muito em postbacks com um que produz uma experiência mais perfeita. Mas direi que as práticas atualmente em voga resultam em alguns processos de pensamento surpreendentemente de baixo nível entre as pessoas que perderam cliente / servidor, RAD e similares. Os botões cliente / servidor funcionaram e certamente não era necessário se preocupar com os canais de dados subjacentes que levavam dados aos manipuladores de eventos que fizeram isso acontecer.

Por outro lado, desenvolvedores mais contemporâneos tendem a pensar que aqueles de nós que desenvolveram cliente / servidor (ou até mesmo desenvolvimento da Web baseado em postback) tendem a recorrer a atalhos (e isso significa que é ruim). Isso é compreensível, mas ainda acho que a maneira como o desenvolvimento contemporâneo é feito é surpreendentemente baixo, e os dias de busca por uma "bala de prata" parecem ter dado lugar à era de zombar daqueles que questionam a sabedoria da mineração e da mineração. fundindo nossa própria liderança.

A tecnologia avançou muito e agora temos tudo o que Robert Harvey enumera em sua resposta, mas:

• O problema parece estar mudando os requisitos . O cliente sabe que não haverá desperdício de materiais ao alterar os requisitos de um projeto de software. Esse tipo de alteração de requisitos quase nunca acontece quando um projeto do mundo físico, como um prédio, é concluído pela metade.

• Outro aspecto importante é que a programação continua sendo altamente trabalhosa . Raramente, se alguma vez, o código gerado pelo RAD entra em produção sem ser modificado manualmente manualmente.

• O código continua sendo altamente complexo , e essa complexidade não parece diminuir com as novas tecnologias.

• A taxa de prazos não cumpridos ou orçamentos excedidos continua a ser maior que a de outras disciplinas e, muitas vezes, é incorrida uma dívida técnica para cumpri-los, gerando custos ocultos.

• Algo que aconteceu, sem dúvida, é que ocorreu a compartimentalização . A grande quantidade de tecnologias que se deve conhecer é para que os programadores tenham especializado um pequeno número de tecnologias para se tornar realmente bom nelas, exigindo diferentes tipos de especialistas para concluir um grande projeto.

• Uma coisa que fala sobre a complexidade do software é que, embora existam literalmente centenas de montadoras no mundo, a lista de empresas capazes de criar e manter um sistema operacional (desktop, móvel, embutido ou outro) possa ser contada com os dedos de suas mãos.

• Tudo isso criou uma situação em que não há pessoas suficientes estudando para serem programadores , de modo que os governos criaram campanhas para motivar mais estudantes a seguir essa carreira.

• Uma amostra da maturidade da indústria de software é que as licenças de software continuam afirmando "<empresaX> não faz representações sobre a adequação deste software a qualquer finalidade específica. Ele é fornecido" como está "sem garantia expressa ou implícita". Imagine um fabricante de hardware afirmando que seu produto não é adequado para nenhum propósito específico. Esse é o estado da arte agora.

Embora se possa argumentar com métricas específicas (isto é, as coisas melhoraram em um fator de 9,98?), Eu (falando como algo antigo) tenho que concordar com o sentimento geral do comentário de Brooks.

Primeiro, houve muito pouca tecnologia verdadeiramente nova inventada desde talvez 1970. Sim, os circuitos integrados ficaram mais longos, mais baixos, mais largos e a fibra de vidro melhorou as velocidades de comunicação, mas a cada passo à frente há um retorno.

A tecnologia do compilador permitiu uma melhoria de 10x na "produtividade" do programador em relação a 1970, quando se calcula a função produzida dividida pelo tempo real de codificação, mas a proliferação de linguagens e ambientes de programação novos ou "revisados" significa que o programador médio gasta cada vez mais tempo no modo "recuperar o atraso" e menos atividade produtiva. Apple, Google e Microsoft lançam "atualizações" novas e substancialmente incompatíveis em seus ambientes a uma taxa um pouco abaixo do que provocaria revolta entre seus servos ... ou clientes de programação. Da mesma forma, HTML / CSS / Javascript / o que for cada vez mais complexo.

Ao mesmo tempo, a taxa em que a documentação poderia ser produzida e propagada teria limitado e encurralado toda essa "inovação", mas, graças à Internet, uma documentação rigorosa não é mais realmente necessária - apenas expanda as funções e conte com os blogueiros para descobrir os detalhes e disponibilizá-los.

Adicionado: estive pensando sobre isso desde ontem e, em particular, sobre o projeto em que trabalhei de 1978 a 2008. Esse projeto (o IBM System / 38 e seus sucessores) foi um pouco único, pois desde o início os esforços foram feito para controlar a complexidade dele (sendo uma a divisão do software em duas partes aproximadamente iguais, com uma interface de "máquina" entre elas). Na área específica em que trabalhei, vários colegas de trabalho se dedicaram da mesma forma a controlar a complexidade (embora não usássemos muito esse termo na época). O resultado foi um produto que (a princípio) era bastante robusto e um "sucesso" com os clientes praticamente desde o git-go. E foi um prazer trabalhar - como tocar em uma orquestra bem treinada.

É claro que, ao longo dos anos, a complexidade surgiu, geralmente a pedido de planejadores e gerentes de mercado que não apreciavam o controle da complexidade (que é de alguma forma diferente de apenas manter a simplicidade). Eu não tenho a sensação de que isso era inevitável, mas era impossível impedir neste caso sem um gerente (como Glenn Henry fez originalmente) pressionando as forças da confusão.

Muito do que aprendemos na prática de engenharia de software nos últimos 30 anos é da forma "a tecnologia X pode acelerar o desenvolvimento inicial de novo software, mas se você não gastar tanto ou mais tempo pensando em como e Quando usá-lo como você salvou, a longo prazo, transformará seu aplicativo em um pântano de dívida técnica, custando a você ordens de magnitude mais tempo e esforço em manutenção ".

As tecnologias que se enquadram nessa ferramenta incluem: linguagem assembly codificada manualmente, compiladores, intérpretes, bibliotecas de procedimentos, programação imperativa, programação funcional, programação orientada a objetos, alocação manual de memória, coleta de lixo, tipos estáticos, tipos dinâmicos, escopo lexical, escopo dinâmico , ponteiros "seguros", ponteiros "inseguros", ausência de ponteiros como conceito de linguagem, formatos de arquivos binários, formatos de arquivos de marcação estruturada, macros, modelos, evitação de macros e modelos, memória compartilhada, passagem de mensagens, threads, corotinas, loops de eventos assíncronos, serviços remotos centralizados, serviços distribuídos, software instalado localmente, matrizes, listas vinculadas, tabelas de hash e árvores.

O fato de muitos dos itens da lista acima aparecerem em grupos que, juntos, esgotam o espaço conhecido da solução é muito intencional e deve, por si só, lhe dizer uma coisa. Pode-se argumentar que a única inequívoca, todo-o-board melhorias na práxis que tivemos desde que primeiro acendeu a Z3 são bloco estruturado de programação (em oposição ao código espaguete) e proteção de memória (menino, eu já não falta os dias em que um erro de digitação pode derrubar meu computador inteiro).