A política do pão e circo no desenvolvimento de software

5 04 2011

Ainda me lembro do Célio meu ex-professor de história entrando na sala de aula todo animado e dizendo: “Meus alunos, hoje iremos estudar sobre a política do pão e circo, falaremos da Roma antiga, do Coliseu e das lutas de gladiadores”. Realmente foi uma aula muito interessante e desde então jamais me esqueci desse assunto.

Um pouco de história

Na Roma antiga houve um alto crescimento urbano que gerou muitos problemas sociais. Isso foi impacto da escravidão que acontecia na zona rural que fez com que vários camponeses perdessem o emprego, tendo como alternativa a migração para a área urbana. Com medo que a população se revoltasse devido às péssimas condições de vida e a falta de emprego, o imperador resolveu criar a política “panem et circenses”, a política do pão e circo. Basicamente essa política tinha como base a realização de lutas de gladiadores pelos estádios da cidade (o mais famoso foi o Coliseu), sendo que nesses eventos havia a distribuição de alimentos como trigo e pão. O imperador tinha como objetivo distrair a população, pois quando se alimentavam esqueciam os problemas sociais e não pensavam em se rebelar.

Voltando ao desenvolvimento de software

Depois de termos relembrado a história, vocês devem estar se perguntando onde quero chegar com isso. Então vamos ao que interessa.

Antes de começarmos a desenvolver ou até mesmo durante a manutenção de um software, são comuns aquelas reuniões entre a equipe para definição das tecnologias, metodologias, padrões, técnicas, todo este emaranhado de coisas que irão fazer parte do desenvolvimento/manutenção do software. Porém, o que acontece é que em alguns casos isso tudo acaba se tornando “pão e circo” para esconder um pouco da nossa falha no desenvolvimento de software, que é quando não buscamos o entendimento completo do negócio para o qual o software está sendo concebido, perdendo o foco daquilo que realmente agrega valor para o cliente.

Acompanho alguns grupos que falam sobre desenvolvimento de software, mas quase todas as discussões que rolam são voltadas para o uso de uma determinada tecnologia ou uma das outras coisas que citei anteriormente. Dificilmente encontramos por aí discussões que tratam com mais ênfase da fase de entendimento do negócio. Quero destacar aqui a necessidade de focarmos mais no negócio/domínio do cliente. Já temos muitas soluções que funcionam, e muito bem, quando falamos da fase de desenvolvimento do software, o ponto que tem que ser resolvido agora começa antes mesmo de colocarmos a mão na massa. A concepção do domínio é um assunto que tem que ter uma importância maior nas nossas discussões sobre desenvolvimento de software.

A verdade é que os clientes também querem o “pão e o circo”, só que assim como aconteceu na Roma antiga “pão e circo” demais pode ser um sinal que às coisas não estão como deveriam. “O pão e o circo” faz parte do software que estamos desenvolvendo, porém cabe a nós definir a dose certa. Não devemos esquecer as coisas que realmente agregam valor e que serão diferenciais para alavancar os negócios dos nossos clientes.

Anúncios




O trivial pode não ser simples

27 01 2011

Provavelmente muitos de vocês já passaram por alguma situação, onde tiveram que alterar/construir algum código ou funcionalidade que aparentemente se mostrava muito simples, mas quando realmente colocaram a mão na massa perceberam que o buraco era mais fundo do que o imaginado. O trivial agora não é mais simples. Bem, é exatamente nesse ponto que quero tocar, falar um pouco dessas situações que complicam o desenvolvimento e furam as previsões.

Eu também já passei por situações onde uma determinada tarefa se mostrou bem mais complicada do que o esperado, isso, tanto no papel do desenvolvedor que realizaria a tarefa quanto no papel do analista que delegava a tarefa. Aprendi muito nesses casos, e vou comentar um pouco de alguns fatos que podem nos levar a tachar algumas tarefas como triviais.

  • É simples já mexi nisso

Muitas vezes a tarefa que está nos sendo passada é algo que a pessoa responsável em delegar a tarefa já mexeu. Isso pode ser ruim porque o responsável em passar a tarefa acaba esquecendo que softwares evoluem, e em alguns casos de forma desorganizada, o que complica muito a manutenção e até mesmo a inserção de novas funcionalidades.

  • Nem sempre entender o que tem que ser feito é o suficiente

O fato de entendermos o que tem que ser feito nem sempre é o suficiente para dizer que uma tarefa é trivial, pois a simples alteração de algo no software pode gerar ajustes em outras coisas que estão relacionadas com a nossa tarefa, fazendo com que o trabalho seja bem mais longo e complexo. Temos sempre que analisar o impacto de nossas mudanças no software, claro que temos algumas técnicas para isso como o TDD, mas nem todos os softwares podem estar utilizando essa técnica.

  • Se basear apenas em tarefas parecidas. Lembre-se cada caso tem suas particularidades

Estimar a complexidade e o tempo para desenvolver uma determinada tarefa com base em tarefas parecidas, em muitos casos pode ser um tiro no pé. Podemos sim desenvolver algo que pode parecer com o que já desenvolvemos anteriormente, porém com maiores impactos no software, e a diferença está aí, isso que pode levar uma tarefa a ser mais complicada.

  • Sair fazendo sem analisar o problema

Isso é muito complicado, desenvolvedores e analistas pecam muito nesse ponto. O que deve ser feito antes de cada tarefa é uma análise, mesmo que mais simples, mas que mostre um pouco dos impactos das alterações que irão ser feitas no software. Nada de sair fazendo para depois ver o que vai dar.

Quando estamos no papel do desenvolvedor e colocamos como trivial algo que não é, podemos nos sentir frustrados durante o desenvolvimento, pois o sentimento que fica é que não estamos conseguindo evoluir com a tarefa. No papel do analista ou aquele que delega alguma tarefa, temos que tomar mais cuidado ainda, afinal, o fato de acharmos que uma tarefa é simples, pode nos levar a cobrar mais do desenvolvedor e em muitos casos ficar com o pensamento que o mesmo está gastando muito tempo em algo fácil, quando na verdade o que está acontecendo é o contrário, o tempo que está sendo curto devido à complexidade da tarefa. Outro problema que pode ocorrer é que o fato da tarefa ser tratada como trivial, faz com que o desenvolvedor seja mais pressionado, fazendo com que o mesmo não seja valorizado como merecido ao término da tarefa.

É isso aí pessoal, o recado é esse, e quem já passou por essas situações onde o trivial não foi simples, comente aqui. O mais importante é essa troca de informação e conhecimento entre nós.