Advanced Learning - parte 2

Há algum tempo atrás, falei sobre um capítulo de livro que escrevi. O tema é bastante relacionado à minha dissertação de mestrado e trata, essencialmente, do processo de desenvolvimento de software para plataformas móveis, dando atenção especial para o projeto One Laptop per Child (OLPC).

Volto a falar neste assunto porque recebi um e-mail da editora dizendo que o capítulo atingiu 6000 downloads. Achei bastante impressionante e resolvi compartilhar.

O capítulo, assim como os demais do livro, estão sob licença Creative Commons. Fique à vontade para ler e compartilhar também!

Escrevendo mais e melhor

Se você olhar o arquivo do blogue em 2010, vai notar que escrevi bem pouco por aqui. E no primeiro semestre deste ano, também. Justifico: estive escrevendo meu texto de Mestrado.

Uma coisa que considero difícil é escrever. Minha nossa! Mas foi um dos motivos para eu começar este blogue: tentar escrever melhor. Aqui, tento expor minhas ideias e compartilhar experiências, e, se o texto tiver um qualidade mínima,as pessoas vão pelo menos entender o que eu quis dizer.

Não me considero um "bom escritor" (no sentido de conseguir transmitir ideias), mas tenho certeza se que a prática da escrita me ajuda a melhorar. Esta impressão eu já tinha ao escrever por aqui, e reforcei ao escrever meu texto de Mestrado.

Durante um longo período no Mestrado, eu tinha a impressão de que nunca acabaria. Não conseguia estruturar o texto, não tinha texto para completar capítulo, quando tinha alguma ideia legal, não conseguia colocar no papel direito, as poucas ideias que tinha também não faziam muito sentido. Adicione agora a dificuldade intrínseca do tema e o rigor científico para calcular qual era progressão em páginas por dia. É como escrever dez palavras para depois apagar nove e escrever de novo.

Como contornei isso? Escrevendo, apenas. 100% do tempo e sem distração. Resolvi tirar férias só para escrever, no começo do ano (na verdade, não tinha muita opção). Fui escrevendo menos preocupado com frases bonitas e sim com chegar ao final do texto, explorando o tópico. Nem preciso dizer que ficou um monte de frases confusas para revisar, mas pelo menos terminei. Inúmeras revisões depois eu tinha um texto completo e que finalmente fazia sentido.

Curiosamente, minha experiência tem tudo a ver com textos que li esta semana, no Liberal, Libertário, Libertino (este e este outro) e no Coding Horror. Os textos estão em contextos separados, mas são excelentes, recomendo. Escrever é um exercício, e tenho dito.

E a Engenharia de software, é engenharia mesmo?

Algum tempo atrás, eu li artigo argumentando que fazer software não deveria ser considerado um processo de Engenharia. Na época, o argumento pareceu bastante razoável, pois eu acabei lendo estes artigos durante meu período de estudos iniciais de metodologias ágeis (programação extrema em mais detalhes). No laboratório em que trabalho tivemos até um debate acerca do tema e tal, e no final ficou realmente a impressão de que o caráter "artesanal" é forte na maioria das vezes. Daí a ligação fraca entre o processo de fazer software e o processo de Engenharia.

Mesmo assim, sempre me incomodou uma inconsistência: se a Engenharia nada mais é que resolver problemas, porque a designação não serve para os problemas resolvidos por programas de computador?

Depois de um tempo, ao desenvolver meu texto do Mestrado, li um (monte de) artigo(s) muito interessante(s)  sobre as origens dos métodos ágeis, algumas contadas pelos criadores do próprio manifesto ágil.

Em um deles, Williams e Cockburn [1] argumentavam que fazer software é, sem dúvida, um processo de Engenharia. O motivo? Bem, processos de Engenharia podem ser vistos de duas formas: formais ou empíricos. Os processos de formais estabelecem modelos capazes de repetição gerando sempre resultados consistentes. Os processos industriais têm essa característica de repetição. Neste sentido, fazer um carro é um processo que, uma vez formulado, pode ser repetido em outras localidades.

Os processos empíricos, por outro lado, são executados de acordo com a situação, precisando de pequenos ajustes ao longo da própria execução. Cockburn argumentava que fazer software é justamente um processo não-repetitivo, em que cada situação necessita de uma solução distinta. Para mim, este argumento aproxima muito o "fazer software" de Artesanato. Quem prefere não usar o termo Engenharia de software talvez esteja fazendo alguma relação entre programar e o artesanato. Eu, particularmente, a acho a analogia super válida, só não acho que programar deixa de ser Engenharia por isso.

EDIÇÃO: obrigado ao Flávio por apontar que faltou a referência.

[1] - WILLIAMS, L.; COCKBURN, A. Agile software development: it's about feedback and change. Computer, v. 36, n. 6, p. 39-43, 2003. ISSN 0018-9162. Link para o artigo original.