- 2007, 2000 linhas de código

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

• No início de 1982, a equipe de software do Lisa estava concentrada no esforço final para lançar o software nos seis meses seguintes.

• Alguns gerentes acharam que seria uma boa ideia acompanhar semanalmente a quantidade de código escrita por cada engenheiro e criaram um formulário que precisava ser entregue toda sexta-feira, incluindo um campo para registrar o número de linhas de código escritas naquela semana.

• Bill Atkinson, autor do Quickdraw e principal designer da interface de usuário, achava que contar linhas de código era uma forma idiota de medir a produtividade em software, e via isso apenas como um incentivo para escrever código bagunçado, inflado e cheio de erros.

• Atkinson vinha trabalhando recentemente na otimização do mecanismo de cálculo de regiões do Quickdraw e reescreveu completamente o motor de regiões usando um algoritmo mais simples e geral, que, depois de alguns ajustes, tornou as operações de região quase 6 vezes mais rápidas.

• Como efeito colateral, essa reescrita acabou economizando cerca de 2000 linhas de código.

• Na etapa final da otimização, chegou a hora de preencher o formulário gerencial pela primeira vez e, ao chegar à parte do número de linhas de código, ele pensou por um instante e escreveu o número -2000.

• Não se sabe ao certo como os gerentes reagiram, mas algumas semanas depois eles pararam de exigir que Atkinson preenchesse o formulário, e ele aceitou isso de bom grado.

Opinião do GN⁺

• Este artigo traz uma lição importante: a quantidade de código não representa a produtividade real no desenvolvimento de software. Medir desempenho com base no número de linhas de código não só é ineficiente, como às vezes pode até ser contraproducente.
• O exemplo de Bill Atkinson destaca a importância da otimização de software. Alcançar desempenho mais rápido com menos código é um dos princípios centrais da engenharia de software.
• Essa história ajuda a entender por que práticas modernas de desenvolvimento, especialmente abordagens como metodologias ágeis e integração/entrega contínua (CI/CD), são importantes. Elas valorizam mais a qualidade, a manutenibilidade e a experiência do usuário do que a quantidade de código.
• No setor, diversos instrumentos e métricas são usados para medir e melhorar a qualidade do código. Por exemplo, ferramentas de análise estática de código, processos de code review e acompanhamento de cobertura de testes.
• O artigo relembra aos desenvolvedores como é importante focar na qualidade em vez da quantidade de código, evitar complexidade desnecessária e otimizar o desempenho.

[GN⁺]

Opiniões do Hacker News

• Conflito sobre linhas de código entre Microsoft e IBM

  • Na série de TV da PBS "Accidental Empires", há uma cena em que Steve Ballmer explica sua experiência durante o co-desenvolvimento do OS/2. Enquanto a Microsoft trabalhava com a postura de uma empresa pequena, a IBM, internamente, estava focada em usar o número de linhas de código (em milhares de linhas, KLoC) como métrica de produtividade dos programadores. Ballmer critica a IBM por se importar apenas com a quantidade de código, e não com sua qualidade.

• Links para discussões anteriores

  • Discussões sobre o uso de linhas de código como métrica de produtividade aparecem com frequência. São fornecidos links que mostram vários debates entre 2010 e 2022.

• Usar linhas de código como métrica de produção é extremamente tolo

  • Menciona experiências de resolver um bug de 20 anos que não havia sido resolvido com uma única linha de código, ou de corrigir um bug de 3 anos com um order by, levantando a questão de como medir o impacto de uma única linha de código. Compartilha a experiência de que programadores ruins escrevem mais código e apresenta o caso em que um desenvolvedor da Microsoft reescreveu 33.000 caracteres de código da IBM em 220 caracteres. Por causa disso, o trabalho da Microsoft acabou sendo avaliado de forma "negativa".

• Perguntas simples às vezes causam o maior impacto

  • Uma pergunta simples sobre como implementar uma funcionalidade ("Como vamos tratar X?") pode levar à decisão de não criar essa funcionalidade, o que acaba economizando todo o custo de tentar fazê-la. Esse tipo de contribuição não pode ser medido numericamente e às vezes pode até criar inimizades, mas ainda assim presta homenagem àqueles que têm coragem de fazê-lo.

• Compartilhando uma experiência de otimização de código no início da carreira

  • Compartilha a experiência de otimizar um programa em C com mais de 10.000 linhas para menos de 500 linhas. Partindo da simples suposição de que o desenvolvedor anterior talvez não soubesse usar funções ou como fornecer dados variáveis a consultas SQL, encontrou o mesmo comando SQL escrito repetidamente de forma inline. Substituiu o código duplicado reescrevendo as chamadas SQL como chamadas de função e passando a chamar a função dentro de um loop, buscando os valores de bind alterados em um array.

• Falta de direção clara no início de um projeto

  • Ao iniciar um projeto, às vezes não se sabe exatamente qual direção seguir; à medida que se aprofunda nele, passa-se a entender melhor o problema e a resposta desejada, o que pode levar à remoção de grandes partes e à substituição por algo menor e melhor. Numa situação assim, desenvolvedores que precisavam colocar tudo em uma ROM de 64KB sofriam forte pressão para tornar o código menor.

• Experimento mental sobre usar remoção de código como métrica

  • Propõe um experimento mental: se um gestor ler este artigo e decidir de forma simplista usar a quantidade de linhas removidas como métrica, a situação melhoraria ou pioraria?

• Atkinson Dither, de Bill Atkinson

  • Fornece um link sobre Bill Atkinson e sua técnica Atkinson Dither.

• Percepção sobre linhas de código

  • Questiona o uso de "linhas adicionadas - linhas removidas" ao escrever código. Assim como uma corrida de 10 km que começa e termina no mesmo lugar não é chamada de corrida de 0 km, o mesmo valeria para linhas de código.

• O papel como funcionário

  • Compartilha a lição de que, mesmo sendo tão inteligente quanto Einstein, você continua sendo um funcionário, e há coisas que um funcionário precisa fazer.