A arte do desenvolvimento de software

Frequentemente ouço opiniões contraditórias sobre Desenvolvimento de Software.

Alguns adeptos da Engenharia de Software encaram o Desenvolvimento de Software como um processo mensurável que chega ao resultado desejado se as técnicas  forem corretamente aplicadas. Em alguns casos, é dado pouco valor ao ser humano que é considerado somente uma das engrenagens do processo.

Outros afirmam que a Engenharia de software está equivocada porque Desenvolver Software é uma arte. É um trabalho criativo feito por pessoas com todos os “defeitos” dos seres humanos como amor, ódio, paciência (e a falta de), desejos, necessidades, interesses. Portanto devemos evitar tolher a criatividade dos desenvolvedores com burocracias, fórmulas prontas, controles, métricas, etc. Todos os problemas do desenvolvimento de software podem ser resolvidos fazendo o que o ser humano faz de melhor, se comunicar.

Eu acho que é uma arte. Um programador usa a criatividade para codificar assim como um pintor precisa ser criativo para pintar um quadro. Mas assim como um pintor, o desenvolvedor precisa aprender técnicas, precisa desenvolver um processo pessoal de execução da arte, precisa transferir  da melhor maneira as idéias para o mundo físico, como disse Brooks, “Como criadores de coisas, a incompletude e inconsistência de nossas idéias tornam-se claras apenas durante sua implementação”.

Mas há uma situação no Desenvolvimento de Software que é preciso ir além da arte e as técnicas de Engenharia voltam a ser de suma importância.

Ocorre quando o sistema a ser desenvolvido é maior que a capacidade de uma única pessoa para construí-lo num tempo aceitável.

Diferente de uma pintura que é criada para expressar idéias para os sentidos e o prazer de outras pessoas, o software existe para resolver um problema de alguém (mesmo um jogo resolve um problema, o de como ocupar o tempo ocioso). O problema pode ser bem grande exigindo um software bem complexo. Quanto mais complexo, mais pessoas precisam trabalhar no seu desenvolvimento e os problemas de comunicação começam a ter um peso maior no tempo. Mais pessoas, mais falhas de comunicação podem ocorrer. Mais pessoas, e mais problemas decorrentes da diferença de “estilo” entre  programadores.

Softwares grandes demandam  planejamento,  técnicas de engenharia,  documentação,  meios adequados de comunicação,  processos,  controle. Só que tudo isso na medida certa. Não adianta, por exemplo, planejar tudo antes, pois, como todos sabem, os requisitos vão sofrer alterações. Mas precisa de algum planejamento mínimo antes de começar a executar. Não adianta exigir documentação de todos os aspectos do software. Boa parte deles vai ficar desatualizada. Precisa só dos documentos que comunicam informações que outros precisam saber para continuar com o trabalho (Isso que código é a única documentação que importa é balela, com certeza código não é o melhor documento para um usuário final ou para o pessoal de infra).

E nessa “medida certa” é que reside todo o problema. Quem sabe qual é a medida certa? Para quem acredita nos processos de engenharia, a medida certa é mais. Para quem acredita nas pessoas e interações entre elas, a medida certa é menos. Encontrar alguém para quem  a medida certa é a adequada é o segredo do sucesso. Se você souber de alguem assim, me avisa.

2 pensamentos em “A arte do desenvolvimento de software”

  1. Olá Boton!
    A respeito sobre a “medida certa”. Respeito a sua opinião, no entanto nao concordo com relacao a afirmacao de que o código nao é a documentacao. Na minha opiniao o código é sim a melhor documentação que uma app pode ter. Principalmente pelo aspecto que um documento ms-word/pages/txt nao é “compilável” e muito menos “linkavel” com a aplicacao sendo desenvolvida. Existem técnicas extremamentes simples que visam minimizar a falta de garantia na disparidade entre uma documentacao formal e o código/app por exemplo TDD. Nao vou entrar no mérito de ter ou nao uma taxa de cobertura de código 100% é o minimo aceitável, eu particularmente nao acredito nisso, mas existem evidencias de que um código testado – JUnit por exemplo. Uma “cola” entre todos os participantes desse processo – Código + Testes – com o intuito de gerar uma documentação de “alto” nível para gerentes pode ser o Fitnesse (http://fitnesse.org/).
    Em algumas equipes é fácil de implementar um processo de desenvolvimento/testes de forma extremamente prazerosa e de certo modo simples (fácil e indolor) mas isso depende e muito o quao apaixonado os “artistas” são por sua “obra”
    CYa!

  2. Márcio, concordo com você que código é a melhor documentação que uma app pode ter. Só não concordo que deva ser a única. Acho que criar uma documetação para o usuário ou para a equipe de infra é importante também. Muitas vezes só visualizamos as inconsistências da aplicação quando tentamos explicar para os usuários.

Os comentários estão desativados.