Não houve realmente uma coisa nos últimos 20 anos que forneceu enormes ganhos de desenvolvimento de software? [fechadas]

Do developers in 2014 produce software at a rate less than 10x faster than their counterparts in 1986?

Eu imagino que houve pelo menos uma melhoria de ordem de grandeza na produtividade desde então. Mas não aproveitando um único desenvolvimento, em tecnologia ou técnica de gerenciamento.

Os aumentos na produtividade resultaram de uma combinação de fatores. Nota: esta não é uma lista abrangente:

1. Melhores compiladores
2. Computadores muito mais poderosos
3. Intellisense
4. Orientação de objeto
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 strong
10. Teste de unidade
11. Melhor design de 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 tenha produzido uma aceleração de ordem de grandeza.

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

A resposta de Robert Harvey é boa, mas acho que ele deixou de fora 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 ++, e isso era tudo.

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

Nosso produto atual usa uma estrutura de janela de encaixe que compramos de um fornecedor. Isso me permite ter uma interface de janela de docking totalmente funcional em questão de minutos. Eu tremo ao pensar no que seria necessário para fazer isso nos dias de usar a API do win32.

Para fins de argumentação, não concordo com a afirmação de Fred Brooks .

Há uma melhoria na tecnologia que permitiu, por si só, uma melhora na produtividade de forma significativa: a internet e, mais precisamente, a disponibilidade progressiva de conexão à Internet em todas as residências nas últimas duas décadas. / p>

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 n-ésimo elemento no JQuery? A pesquisa do Google leva a uma resposta de a pergunta exata no Stack Overflow . Não sabe como usar overflow em CSS? O MDN da Mozilla está aqui . Esqueceu o que significa virtual palavra-chave em c #? O Google ajuda novamente.

Quando comecei a programar, não tinha internet. Eu tinha livros, bem como algumas documentações em formato digital armazenadas localmente, mas pesquisar em livros e documentos era um processo lento e, independentemente de quantos livros eu tivesse, havia muitos problemas que não eram mencionado lá.

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

• No estouro de pilha, obviamente. Por exemplo, eu não vi nenhum livro que mencionasse este problema .

• Nos blogs. Encontrei muito de ajuda em blogs quando tive problemas particulares, seria na configuração do WCF ou em um servidor proxy que não faz isso? t start ou um bug críptico ao usar uma API específica em uma máquina com cultura diferente da en-US.

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

A importância da disponibilidade imediata de uma resposta para a maioria das questões que se pode encontrar é especialmente perceptível se levarmos em conta que na maioria das vezes uma equipe gasta em um projeto é gasto mantendo isso

• 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.) .

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

• Mas a maioria dos problemas aparecem durante a manutenção, está lá quando a ajuda de outras pessoas pela Internet parece ser crucial . Exemplo básico: um serviço WCF funciona perfeitamente na minha máquina , mas falha sem exceções quando implantado na produção, enquanto funcionava nas últimas duas semanas. Isso aconteceu comigo e agradeço aos redatores do blog e à comunidade do Stack Overflow por me ajudarem a resolver o problema em questão de horas, em vez de semanas.

Justificaria um aumento de x10 na produtividade? Difícil dizer.

• Por um lado, há casos em que você encontra uma resposta imediatamente, enquanto você poderia passar dias pesquisando sozinha (ou ser 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 equipe ( Gerenciamento Radical de Stephen Denning vem à mente), melhores ferramentas (depuradores, profilers, 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 ótimo candidato. O StackOverflow e o 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, você só precisa saber como conhecer as respostas - e isso é um substituto perfeitamente adequado que permite aos desenvolvedores gastar menos tempo lendo e mais tempo codificação, e assim sendo produtivo. Isso significa que todos os programadores do mundo têm acesso a todas das respostas, e tudo o que precisam fazer é saber como fazer as perguntas certas.

Eu sugeriria que as tendências que nos puxam para outra direção (ou seja, para uma produtividade menor) são pelo menos tão strongs quanto as tendências que você perguntou. A experiência de fazer uma ferramenta de desenvolvimento cliente / servidor como VB6 ou PowerBuilder ficou muito próxima do ideal do "Rapid Application Development" (RAD). Você tem que desenhar seus formulários, e existem ganchos óbvios para o seu código procedural ou SQL.

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

Há 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) para o desenvolvimento da Web, nem é completamente justo comparar um processo que depende muito de postbacks com um que produz uma experiência mais perfeita. Mas vou dizer que as práticas atualmente em voga resultam em alguns processos de pensamento surpreendentemente de baixo nível entre pessoas que perderam cliente / servidor, RAD e afins. Os botões cliente / servidor apenas funcionavam, e um deles certamente não precisava se preocupar com os canais de dados subjacentes que coletavam dados para os manipuladores de eventos que faziam isso acontecer.

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

A tecnologia avançou muito e agora temos todas as coisas que Robert Harvey enumera em sua resposta, mas:

• O problema parece ser alterar requisitos . O cliente sabe que não haverá desperdício de materiais ao alterar os requisitos de um projeto de software, portanto, eles o fazem. Esse tipo de exigência quase nunca muda, uma vez que um projeto de mundo físico, como um prédio, está pela metade.

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

• O código continua a ser 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 do que aqueles em outras disciplinas, e muitas vezes a dívida técnica é incorrida para atendê-los, gerando custos ocultos.

• Algo que, sem dúvida, aconteceu é que ocorreu a compartimentalização . A enorme quantidade de tecnologias que se deve conhecer é que os programadores tiveram que se especializar em um pequeno número de tecnologias para se tornarem realmente bons neles, exigindo diferentes tipos de especialistas para concluir um grande projeto.

• Uma coisa que fala sobre a complexidade do software é que existem literalmente centenas de fabricantes de automóveis no mundo, a lista de empresas capazes de criar e manter um sistema operacional , (desktop, móvel, incorporado ou não), pode ser contado com os dedos das suas mãos.

• Todos os itens acima criaram uma situação em que não há pessoas suficientes estudando para serem programadores , de modo que os governos criaram campanhas para motivar mais alunos a seguir o caminho da carreira.

• Um gostinho da maturidade da indústria de software é que as licenças de software continuam a indicar "< companyX > não faz representações sobre a adequação deste software para nenhuma finalidade específica É fornecido "como está" sem garantia expressa ou implícita. " Imagine um fabricante de hardware declarando que seu produto não é adequado para qualquer finalidade específica. Esse é o estado da arte no momento.

Enquanto alguém pode argumentar com métricas específicas (ou seja, melhorar as coisas por um fator de 9,98?), eu (falando como um veterano) tenho que concordar com o sentimento geral do comentário de Brooks.

A tecnologia de compiladores permitiu uma melhoria de 10x na "produtividade" do programador em 1970, quando se calcula a função produzida dividida pelo tempo real de codificação, mas a proliferação de linguagens de programação ou ambientes novos ou "revisados" significa que o programador médio está gastando mais e mais tempo no modo "catch up" e menos na atividade produtiva. A Apple, o Google e a Microsoft cuspiram novas e substancialmente incompatíveis "atualizações" em seus ambientes a uma taxa que está logo abaixo da que provocaria revolta entre seus servidores, programando clientes. Da mesma forma, HTML / CSS / Javascript / o que está ficando cada vez mais complexo.

Adicionado: Eu tenho pensado nisso desde ontem, e em particular pensando sobre o projeto em que trabalhei desde 1978 até 2008. Este projeto (o IBM System / 38 e seus sucessores) Foi algo único, pois desde o início esforços foram feitos para controlar a complexidade do mesmo (sendo um deles 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 de meus colegas de trabalho se dedicaram ao controle da complexidade (embora não tenhamos usado muito esse termo na época). O resultado foi um produto que (no início) foi bastante robusto e um "sucesso" com os clientes praticamente do git-go. E foi um prazer trabalhar - como tocar em uma orquestra bem treinada.

Grande parte 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 um novo software, mas se você não gastar muito ou mais tempo pensando sobre como e quando usá-lo como você salvou ao usá-lo, a longo prazo ele transformará sua aplicação em um pântano de dívida técnica, custando-lhe ordens de magnitude mais tempo e esforço em manutenção. "

O fato de muitos dos itens da lista acima virem em grupos que, juntos, esgotam o espaço da solução conhecida, é muito intencional e deve, por si só, dizer-lhe alguma coisa. Pode-se argumentar que os apenas não ambíguos, aprimoramentos gerais na praxis que tivemos desde que eles ligaram o Z3 pela primeira vez são programação estruturada em bloco (em oposição ao código de espaguete) e proteção de memória ( menino, eu nunca não sinto falta dos dias em que um erro de digitação pode derrubar todo o meu computador).