Mergulhando no Caos

Você já notou como tornar seu código bonito e elegante não é tão difícil uma vez que você sabe exatamente o que ele tem que fazer? Quando o problema está bem definido, não há muita dificuldade em tornar a solução mais elegante. Veja o problema da ordenação, por exemplo. Ao longo dos anos surgiram várias soluções justamente porque o problema é suficientemente simples e bem compreendido. Mas se você quiser se aventurar no reino das aplicações-corporativas-de-intranet-nossas-de-cada-dia, é melhor se preparar para ver um bocado de código feio.

Horrível, na verdade.

Esse tipo de código não é feio porque quem o escreve não saiba programar direito. Os programadores que fazem essas aplicações não podem deixar o código bonito porque na maioria dos casos eles não sabem muito bem o que construir. Para escrever código bonito, eles precisam primeiro saber o que o código deve fazer. Claro que também precisam estudar bastante e dominar as técnicas de programação mais recentes, mas não vão ter a mínima chance se não souberem o que estão tentando construir.

Entender bem os requisitos e fazer o que o cliente precisa é insanamente mais importante do que escrever código bonito (não que a beleza do código também não seja importante). É o trabalho que realmente importa em desenvolvimento de software, certo?

Então vamos todos parar de escrever código, ora bolas! Os requisitos é que interessam!

Nosso trabalho todo agora vai ser entender direito as necessidades do cliente. Há várias técnicas e ferramentas para fazer isso. Você pode tentar entender os requisitos usando diagramas, documentos de casos de uso e até um poster de papelão colado em uma parede na sala de desenvolvimento.

Ou então você pode usar — veja só — código.

Não precisamos separar as atividades de escrever código e analisar requisitos. A escrita do código pode muito bem fazer parte da análise de requisitos, assim como o tempo que se gasta escrevendo casos de uso ou pintando aquele poster lá.

Se o software está minimamente “pronto”, os clientes podem experimentá-lo, vê-lo funcionando e solicitar modificações quando necessário. Eles não podem fazer isso com casos de uso. Eles não conseguem ver os casos de uso funcionando até que alguém os transforme em código. Pode ser até pior: eles podem ver um diagrama (que também não funciona) e imaginar que vai funcionar de um jeito diferente do que a equipe de desenvolvimento imagina.

O famigerado código pode ser usado como uma ótima ferramenta para análise de requisitos. Nós somos programadores, não arquitetos. Não precisamos esperar os pedreiros levantarem o prédio para ver como vai ficar. No lugar dos pedreiros temos compiladores e interpretadores, não seres humanos. Arquitetos não podem se dar ao luxo de construir o prédio errado (bem que gostariam de poder fazer isso), por isso precisam investir bastante tempo nas especificações para ter certeza de que tudo vai funcionar como desejado. Nós não precisamos. Para um programador, derrubar o prédio e construir tudo novamente é tão simples quanto `make clean && make`. Ao invés de nos debruçar sobre especificações mortas, podemos observar como a coisa real se comporta. A coisa é chamada de software justamente porque é fácil (e barata) de ser modificada. Não tirar proveito da maleabilidade da nossa mídia é perda de tempo.

Então a lógica fica mais ou menos assim: o código não interessa porque o trabalho mais valioso é o de acertar os requisitos. Acertar os requisitos é descobrir o que o cliente precisa. Fica muito mais fácil descobrir o que o cliente precisa quando você tem software funcionando para mostrar. Software funcionando precisa de código. Logo, o código interessa.

Bom, na verdade o código não interessa tanto assim, mas precisamos desejar muita sorte para quem tentar entender os requisitos sem código.

Corre um boato novo dizendo que Rails é o novo ASP, mas isso não é exclusividade de Rails (nem de ASP): qualquer coisa pode ser o novo ASP, basta apresentá-la às pessoas erradas. Programadores ruins serão ruins usando qualquer tecnologia. Tecnologicamente falando, não há nada que se possa fazer para torná-los menos ruins. Não há como projetar uma tecnologia que os impeça de ser ruins. Não é com novas linguagens, bibliotecas ou frameworks que eles vão melhorar. Algo que talvez ajude são idéias novas, mas eles precisam estar abertos a elas. No fim das contas a transformação depende somente deles mesmos. Parece auto-ajuda mas é bem verdade.

Há basicamente duas maneiras de novas tecnologias influenciarem programadores ruins a escreverem software menos ruim. A primeira é tornar as boas práticas extremamente fáceis de modo que simplesmente pareçam o jeito natural de fazer as coisas. A segunda é tomar o caminho contrário e tornar práticas ruins mais difíceis ou feias de se fazer. Pode-se usar algo como vinagre sintático para fazer isso. O problema de tornar práticas não recomendadas mais feias é que os programadores ruins vão escrever o código feio e ignorar completamente a feiúra. Os olhos deles são incapazes de enxergar feiúra em um trecho de código. Se você quiser realmente seguir por este caminho, precisa dar um jeito de proibir por completo as asneiras mais gritantes.

Mas só é possível enxergar as mais gritantes.

Mesmo que você consiga evitar os piores erros, surgirão novas idéias igualmente burras. Você pode tentar bloquear essas também e continuar tentando proteger as pessoas delas mesmas até um certo ponto. Mas infelizmente não é possível proibir um idiota de estragar tudo. Os idiotas precisam estragar tudo. É a natureza deles. É isso que os define. É por isso que eles são chamados de idiotas. Não importa quantas bolas de chumbo você amarre aos pés deles, os verdadeiros idiotas vão arrumar um jeito de fazer besteira. Se sua tecnologia resolver seguir por este caminho, vai precisar proibir tanta coisa e ficar tão limitada que só os tapados serão atraídos. Aqueles que sabem o que estão fazendo simplesmente não aceitam trabalhar acorrentados.

Já que o caminho da proibição não é tão promissor, é melhor explorar a alternativa: tornar o “certo” idioticamente fácil. Desse modo, os bons profissionais serão atraídos pela elegância das soluções e vão começar a falar sobre a sua tecnologia. Com o burburinho todo mundo vai querer dar uma olhada nesse novo negócio de que os caras da moda andam falando tanto. As idéias ruins serão contidas por algum tempo, mas há um efeito indesejável que você não vai conseguir evitar.

Este efeito está intimamente ligado à maldição da popularidade. Mais popularidade significa mais gente e mais gente significa mais gente tapada. Sua tecnologia preferida simplesmente não pode conseguir se tornar popular e só atrair gênios da computação, eles não são muitos. Para ser popular ela vai precisar dos idiotas. E os idiotas têm um talento natural para estragar as coisas, lembra? Se você quiser ter uma tecnologia amplamente difundida, vai precisar aceitar que ela se torne o novo ASP. Não tem jeito.

Já há quem fale sobre a obsolescência das iterações como as conhecemos. Um dos maiores “culpados” por esse novo movimento é uma prática antiga da produção just-in-time: o Kanban. Mas este texto não é para falar de coisas tão novas assim. Isso aqui é sobre como boa parte da indústria ainda nem digeriu a idéia que veio antes: as iterações.

Mas espera aí. Todo mundo usa iterações, não?

Bom, na verdade não. Como podemos observar a partir de alguns relatos bem recentes, desenvolvimento de software em cascata ainda é realidade em muitos lugares. Pode parecer uma realidade bem distante para você, mas é algo bem próximo para essas pessoas. Tão próximo e tão incômodo que elas tomaram o tempo de sentar-se e escrever sobre o assunto. O pessoal do 1up4Developers até dedicou um site inteiro a isso. Eles deviam estar verdadeiramente sofrendo quando começaram isso.

A triste realidade é que não é tão incomum assim encontrar organizações onde uma “iteração” normalmente dura seis meses e onde é terminante proibido tocar em uma única linha de código enquanto a equipe não atravessar oficialmente a “fase de requisitos” (e talvez mais algumas outras fases depois dela). O pior é saber que o modelo da cascata nasceu somente como contra-exemplo (pdf), algo que deveria ser evitado tanto quanto possível. Não sei que seqüência de eventos esdrúxula consegue levar um modelo de contra-exemplo fabricado a prática padrão de toda uma indústria, mas foi o que aconteceu.

Felizmente, já existe uma solução para isto e ela, sem muita surpresa, atende pelo nome de iteração. Não iterações de seis meses para camuflar um processo em cascata, mas iterações de verdade que permitam feedback rápido e adaptação a mudanças. Antes que possamos começar a tornar as iterações obsoletas, precisamos apresentá-las a quem ainda não as conhece. Mais importante ainda: a quem acha que as conhece mas nunca viu nada além de desvirtuações do conceito.

Podemos até mesmo começar com cascatas iteradas. Já que eles parecem gostar da cascata, dividiremos os projetos em cascatas menores com entregas de software real ao final de cada ciclo. Todo mundo continua trabalhando do mesmo modo de sempre, mas agora os prazos para cada fase e o escopo da iteração como um todo serão reduzidos. A diferença é que os clientes terão software para observar mais cedo, algo real e bastante vivo que possam usar como base para novas idéias ao invés de serem obrigados a fazer especulações baseadas em documentos mortos. Certamente não é o ponto a que queremos chegar, mas quem disse que ia ser fácil?

Uma questão essencial para esta estratégia é o tamanho das iterações. Cascatas iteradas muito longas seriam somente casos especiais do processo de desenvolvimento anterior. Seis meses certamente é muito tempo e três meses ainda parece muito. A partir de um mês de duração começamos a conversar. Ainda é bastante longo, mas, novamente, é só um ponto de partida.

Depois disso o próximo passo provavelmente deve ser mostrar como representações intermediárias podem ser ineficientes. Novamente o encolhimento das iterações deve nos ajudar. Prazos de um mês já devem estar suficientemente difíceis de cumprir quando se tem representações intermediárias para criar e as equipes provavelmente já começaram a eliminar as práticas mais ineficientes neste ponto. Encolher as iterações para quinze dias deve dar conta de eliminar a maioria das ineficiências restantes. Você simplesmente não consegue produzir porções significativas de software funcionando se tiver que escrever treze documentos e aprovar cinco solicitações de mudança pra cada linha de código que precisar alterar.

Quando chegarmos a este ponto, será que deveríamos parar aí? A beleza deste processo de encolhimento das iterações é poder continuar diminuindo-as. Iterativamente, se você me permite. O limite será alcançado quando em uma iteração couber somente um requisito. Neste ponto, a única maneira de continuar encolhendo as iterações é encolher os próprios requisitos, tornando-os cada vez mais simples e atômicos.

Mas será que sua organização vai ter coragem para chegar lá?