A tarefa de programar está se tornando cada vez mais comum, porém ainda existem muitos fatos que as pessoas não conhecem sobre programadores e a programação em si. Acompanhe comigo o conteúdo deste artigo que apresenta 15 fatos pouco conhecidos sobre a programação.

Assim como outras atividades intelectuais, a tarefa de programar e de como as pessoas aprendem a programar computadores é muito estudada. De fato, com cada vez mais pessoas aprendendo a programar, independentemente da linguagem, ferramenta ou plataforma utilizada, é natural que poucas pessoas realmente saibam de certos fatos importantes já bem conhecidos sobre programação e desenvolvimento de software.

Do ponto de vista acadêmico, as áreas de engenharia de software e educação apresentam diversos pontos muito interessantes obtidos por meio de experimentos cujos resultados são apresentados em teses de mestrado e doutorado ou papers da área. E com base nesses resultados escolhi os fatos a serem citados neste artigo, junto com as devidas referências. Ou seja, se você, leitor, ficou com vontade de saber mais sobre cada um dos pontos discutidos aqui, recomendo fortemente procurar a referência completa para mais informações.

Com base nesse contexto, vou apresentar 15 fatos importantes e que, infelizmente, são pouco conhecidos por quem programa. Mas antes faço um aviso: esses fatos apresentam resultados de pesquisas experimentais e empíricas que possuem contextos específicos. O que quero dizer é que existe certa margem para discussão da aplicabilidade e generalização, porém conhecer o que já foi estudado e descoberto é importante e, no mínimo, pode instigar a discussão e o quão perto da realidade do leitor estão essas informações.

1) Programadores demoram para pedir ajuda quando têm problemas

Este é um fato relacionado à maneira como as pessoas aprendem a programar, pois basicamente o ensino segue a linha de aprendizado da matemática: um pouco de teoria, um ou dois exemplos e muitos exercícios. Esse formato leva os aprendizes a tentar muito nos exercícios e, muitas vezes, tentando resolver tudo sozinhos sem pedir ajuda.

Essa atitude não é ruim e é até recomendada, mas é preciso saber até que ponto deve-se deixar de tentar e pedir alguma forma de ajuda.

Referência: Andrew Begel e Beth Simon. Novice software developers, all over again. ICER ’08 Proceedings of the 4thinternational Workshop on Computing Education Research, 2008.

2) Programadores possuem uma tendência a reportar de forma incompleta seus problemas

Este fato é relacionado a pesquisas da área da psicologia, indicando que quando uma pessoa tem algum problema ela não fornece todas as informações completas sobre os problemas, especialmente quando ele é o responsável de forma direta ou indiretamente.

Esse resultado já foi comprovado experimentalmente com programadores, e uma das principais justificativas é a seguinte: reportar de forma completa um problema é visto como sinal de fraqueza que pode levar a algum tipo de julgamento de habilidade e proficiência por quem está ouvindo o relato. Essa situação é muito mais comum quando se trata de um erro básico de principiante.

Referência: Shrauger, J.S. and T.M. Osberg. The Relative Accuracy of Self-Predictions and Judgments by Others in Psychological Assessment. Psychological Bulletin, 1981. 90(2): p. 322-351.

3) Programadores procuram outras formas de ajuda antes de falar com colegas de trabalho

O fato de a comunicação com outras pessoas não assumir a prioridade quando um programador precisa de ajuda está relacionado novamente à sensação de julgamento que outras pessoas fazem ao saber da dificuldade.

Não obstante, sites como o StackOverflow floresceram explorando esse tipo de comportamento por meio da agregação da ajuda com diversos conceitos de comunidade para desenvolvedores.

Referência: LaToza, T.D., Venolia, G., and Deline. R. Maintaining Mental Models: A Study of Developer Work Habits. in Proc. ICSE. 2006: IEEE.

4) O progresso na programação pode ser classificado em quatro fases

A classificação do progresso de um programador é importante para auxiliar diversas métricas envolvidas no desenvolvimento de software, além de ajudar gerentes de projeto e outras pessoas a avaliar como anda o projeto como um todo.

Além disso, é importante saber em qual fase de progresso o desenvolvedor está para, entre outras atitudes, oferecer algum tipo de ajuda para que ele não fique muito tempo emperrado em um local específico a ponto de atrasar alguma entrega. Uma classificação interessante identificou (de forma automática) quatro possíveis estados de progresso:

1. Programação complexa
2. Fazendo progresso
3. Progresso lento
4. Emperrado (stuck)

Referência: Jason Carter, Prasun Dewan. Design, Implementation, and Evaluation of an Approach for Determining When Programmers are Having Difficulty. ACM Group 2010.

5) Programadores encontram barreiras superáveis e insuperáveis

Este fato pode parecer óbvio, mas ele é muito importante de ser detectado, uma vez que uma barreira de programação pode levar sérios problemas de prazo, moral da equipe e confiança.

Uma das principais dificuldades de se detectar barreiras e classificá-las está no fato de que essa informação pode ser subjetiva. Ou seja, perguntar diretamente para o programador se ele está com alguma barreira superável ou insuperável já afeta o resultado, pois ele nem sempre pode ser sincero. Há também algumas implicações em termos de ego e moral, apenas pelo fato de identificar esse tipo de barreira na programação,

Referência: Andrew J. Ko et al. Six Learning Barriers in End-User Programming Systems. 2004 IEEE Symposium on Visual Languages – Human Centric Computing.

6) São 6 os tipos de barreiras relacionadas à programação

Além da classificação de barreiras de programação superáveis e insuperáveis, há um estudo muito interessante que caracterizou cada uma das possíveis barreiras de programação. Para ajudar a entender as barreiras, os pesquisadores evidenciaram frases comuns em cada uma das classificações abaixo:

1. Design: “Eu não sei o que o computador deve fazer”.
2. Seleção: “Eu sei o que fazer, mas não sei o que usar”.
3. Coordenação: “Sei o que usar, mas não sei como combinar o que preciso”.
4. Uso: “Eu sei o que usar, mas não sei como usar”.
5. Compreensão: “Pensei que sabia usar X, mas ele não faz o que eu esperava”.
6. Informação: “Compreendo o que aconteceu, mas não consigo checar”.

Referência: Andrew J. Ko et al. Six Learning Barriers in End-User Programming Systems. 2004 IEEE Symposium on Visual Languages – Human Centric Computing.

7) Programadores passam aproximadamente 30% do tempo navegando no código-fonte

Quem programa sabe que a maior parte do tempo é gasta dentro de uma ferramenta de edição de código-fonte. Contudo, o tempo é divido entre as tarefas de edição do texto representado pelo código-fonte.

De acordo com um estudo muito importante, descobriu-se que aproximadamente 30% do tempo de trabalho de um programador não são gastos editando o texto (incluindo, alterando o excluindo), mas sim navegando entre diversos arquivos com códigos-fontes. Essa navegação envolve pesquisa, observação, coleta de informações, memorização e outras atividades. Ou seja, dá para dizer que a programação é uma atividade cuja terça parte é apenas contemplativa.

Referência: Andrew J. Ko et al. An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks. Journal IEEE Transactions on Software Engineering archive Volume 32 Issue 12, December 2006 pp. 971-987.

8) Produtividade de programadores remotos é menor que a produtividade de programadores locais

Esta afirmação sobre produtividade é polêmica, especialmente no momento em que se fala cada vez mais em home office, trabalho remoto e projetos globais de desenvolvimento de software. De qualquer maneira, existem evidências concretas baseadas em diversas métricas de software que, de fato, programadores remotos não produzem tanto quanto programadores que estão no mesmo local.

Faz sentido pensar dessa maneira se analisarmos os outros fatos desta lista, como a preferência pela falta de comunicação com outras pessoas. De fato, a comunicação informal é um dos principais fatores que influenciaram o resultado dessa pesquisa, pois pedir aquela dica no encontro durante uma pausa para o café é muito importante de acordo com que foi apurado.

Referência: Herbsleb, J.D., et al. Distance, dependencies, and delay in a global collaboration. In: Proceedings of the 2000 ACM Computer-Supported Cooperative Work conference.

9) A maioria dos programadores é masculina, branca e jovem

Esta afirmação sobre a diversidade de programadores não veio exatamente de uma pesquisa acadêmica, mas sim de Adda Birnir, que é a fundadora do site de recrutamento e seleção Skillcrush. Essa declaração foi apresentada no vídeo “Is CODE the most important language in the world?”.

Atualmente, é muito comum destacar minorias na programação, especialmente a baixa quantidade de mulheres. Contudo, como certos dados mostram, esse não é o único grupo de possui baixa representatividade na programação, e isso pode ter uma implicação séria quando falamos em código de aplicações que precisam lidar de forma adequada com certos grupos de usuários.

Referência: declaração da Adda Birnir sobre diversidade de codificadores no vídeo “Is CODE the most important language in the world?”.

10) As principais mensagens de erro, erro em tempos de execução e erros de compilação e o tempo médio para resolvê-los

Mensagens de erro, problemas de tempo de execução e erros de compilação são muito específicos para cada linguagem. Para destacar alguns casos, cito a tese de mestrado da pesquisadora Suzanne Marie Thompson, pois ela analisou uma grande quantidade de programadores Java em diversos cenários e coletou muitos dados interessantes sobre isso. As tabelas abaixo contam um pouco da história sobre erros e tempo médio para corrigi-los.

Apesar de o estudo se concentrar em um contexto muito específico (aprendizado da linguagem Java), é possível fazer um paralelo com outros cenários e situações, e comprovar que realmente boa parte dos erros mais comuns é replicada por programados em diferentes contextos.

Referência: Thompson, Suzanne Marie. An exploratory Study of Novice Programming Experiences and Erros. Tese de mestrado defendida em 2004 na inversidade de Victoria, Canadá.

11) A manutenção de software consome mais de 50% do esforço

A manutenção de um software envolve a manipulação de código legado, assunto que já abordei antes. Porém, desta vez, cito um estudo que fala sobre esforço e que mostra como resultado que a divisão não é igual entre a criação e a manutenção.

No estudo que citou esse valor de mais de 50% de esforço, há uma ótima discussão sobre evolução do software no sentido da sua manutenção e das tarefas necessárias para tanto. Com certeza vale a pena dar olhada uma nessa referência antes de tomar aquela decisão sobre começar do zero ou trabalhar com uma base de código existente.

Referência: Kemerer C.F. and Slaughter S. An Empirical Approach to Studying Software Evolution, IEEE Transactions on Software Engineering, 25(4), pp. 493-509, 1999.

12) A manutenção de software consome entre 40% e 90% dos custos

Uma das principais regras de quem trabalha com negócios diz que é muito mais caro conseguir um cliente novo do que manter um cliente já existente. Contudo, de acordo com pesquisas da área de engenharia de software, a realidade é um pouco diferente quando se fala de código: manter um código em funcionamento por meio de tarefas de manutenção pode chegar a custar até 90% de todos os custos do projeto.

Essas estatísticas são bem genéricas e foram obtidas em um contexto muito particular das 487 organizações estudadas nessa pesquisa, sem contar que o estudo é de 1980. Certamente existem diversos fatores a serem considerados, mas ao menos existe um ponto de partida para analisar cursos e discutir sobre esse aspecto quando se fala de manutenção de software.

Referência: Lientz, B.; Swanson, E.B. Software maintenance management: a study of the maintenance of computer application software in 487 data processing organizations. Addison Wesley, 1980.

13) O trabalho de manutenção de software é dividido em 4 tarefas básicas

Ainda falando sobre manutenção de código-fonte, um estudo que influenciou muito a comunidade de engenharia de software classificou por meio da análise de resultados de questionários as principais práticas da manutenção de software. Quatro práticas foram identificadas:

1. Melhoria: envolvem mudanças de funcionalidades.
2. Adaptativa: são mudanças no ambiente para adaptação a requisitos
3. Corretiva: atividades para a correção de erros
4. Preventiva: melhorias para evitar problemas futuros

A classificação das práticas de manutenção é muito importante para auxiliar medições, organizar e rastrear bugs, agrupar funcionalidades em novas versões e gerenciar o trabalho de programadores.

Referências: Lientz, B.; Swanson, E.B. Software maintenance management: a study of the maintenance of computer application software in 487 data processing organisations. Addison Wesley, 1980.

Lientz, B.; Swanson, E.B.; Tompkins, G.E. Characteristics of applications software maintenance, Communications of the ACM, Vol. 21, pp.466-471, 1978.

14) Custos da correção de defeitos após a implantação são 10x maiores do que na fase de construção, e 100x maiores do que na fase de design

Este fato é um clássico da área e motivou a evolução dos processos clássicos de desenvolvimento de software até chegarmos ao que temos hoje. O principal ponto aqui é a identificação de custos elevados quando não se dá a devida atenção à construção e design do software.

Referências: Barry W. Boehm: Software Process Management: Lessons Learned from History. ICSE 1987: 296-298.

15) Revisão de código pelos pares consegue descobrir até 60% dos defeitos

A revisão de código feita por outras pessoas, seja na modalidade de pair programming ou não, é realmente efetiva. Existem diversos estudos sobre isso, mas um dos principais indica que até 60% dos defeitos podem ser descobertos (mas não necessariamente corrigidos) quando mais de uma pessoa revisa o código-fonte.

Esse estudo é relativamente antigo e pode-se dizer que ele é um dos principais influenciadores de técnicas envolvendo processos ágeis (Agile) e outras formas de desenvolver software cujo principal foco é nas atividades, etapas, organização e outras habilidades não tão técnicas quanto a programação.

Referência: Barry W. Boehm: Improving Software Productivity. IEEE Computer 20(9): 43-57, 1987.