O mito da caverna e o brain lock-in

Tirado da Wikipedia: “O mito da caverna, também chamada de Alegoria da caverna, é uma parábola escrita pelo filósofo Platão, e encontra-se na obra intitulada A República (livro VII). Trata-se da exemplificação de como podemos nos libertar da condição de escuridão que nos aprisiona através da luz da verdade.“. Referência completa aqui.

Não vou comentar sobre a essência das idéias de Platão, para este fim eu recomendo demais a leitura do texto na Wikipedia. Mas vou traçar um paralelo para situações corriqueiras atuais que nos mostram que a natureza humana não mudou muito nesses mais de 2300 anos que nos separam de Platão

Desenvolvimento com Produtos x Desenvolvimento Customizado

Ao longo da minha carreira, já estive focado no desenvolvimento com produtos e no desenvolvimento customizado de software. Tive contato com uma variedade razoável de produtos e tecnologias, com diferentes visões para o mesmo problema, e abordagens diversas de construção de software. Hoje em dia fico muito feliz por ter traçado esse caminho, pois nunca ficarei aprisionado na caverna.

O desenvolvimento com produtos às vezes tem um efeito colateral sobre a maneira das pessoas lidarem com problemas de software. Os produtos são concebidos de acordo com a visão de algumas pessoas sobre uma determinada classe de problemas. A concepção envolve a análise e o raciocínio de alguns profissionais sobre o problema, e o ferramental para prover soluções ao mesmo.

Isto quer dizer que ao utilizar um produto você está “ganhando” o tempo de raciocinar sobre o problema, e também na construção da solução. É como diz o mantra: “Não reinventar a roda”. Eu concordo plenamente! Porém, quem lê meus textos ou me conhece sabe que eu tenho mais algumas coisas a dizer

Arquiteturas de Referência, Blueprints, Catálogos de Padrões

Em muitas ocasiões eu vi profissionais experientes que viviam do seu expertise em algum produto. Às vezes o cara já fazia aquilo há anos, e com muita competência. Entretanto, na maioria dos casos em que lidei com profissionais assim, eles tinham a forma de raciocinar “engaiolada” pelos produtos. A “arquitetura de referência“, o “blueprint do produto” ou o “catálogo de padrões” do mesmo. A abordagem do produto é o que geralmente orienta o raciocínio do indivíduo, e ele reluta bastante em fugir dessa zona de conforto.

Acontece, meus amigos, que o amadurecimento das pessoas tem tudo a ver com sair da zona de conforto. Para dar mais significado às minhas ponderações, eu vou destacar 2 domínios que eu conheço bem e tenho boa experiência: Portais corporativos e SOA (eu sei que o termo está meio condenado, mas permitam-me a liberdade de usá-lo de forma ilustrativa)

“O que você QUER” x “O que você PRECISA”

Sobre SOA, o principal objetivo de negócio é facilitar a integração de várias aplicações/serviços heterogêneos. Este objetivo pode ser atendido de várias formas, e há muitos produtos focados em prover o “ferramental necessário”. A questão começa a ficar sinuosa quando se discute “O que você QUER” x “O que você PRECISA“. Se você fica “engaiolado” em um produto, vai tender a achar que PRECISA dos recursos oferecidos pelo mesmo, e que a abordagem dele é necessariamente correta.

Normalmente os problemas técnicos de SOA caem em uma combinação de topologias dos Enterprise Integration Patterns. Um profissional maduro neste ramo precisa ter familiaridade com estas topologias de integração propostas. As idéias se aplicam em praticamente qualquer problema de SOA, e te dão uma visão de arquitetura desvinculada de uma implementação específica. Não se prenda à visão do produto, conheça a natureza do problema.

Polyglot Programming

Neal Ford escreveu sobre esta questão um tempo atrás, e essa idéia também está presente no Pragmatic Programmer. Conhecer diferentes linguagens de programação, outros paradigmas de desenvolvimento e outros produtos é sempre importante.

Além de raciocinar sob diferentes pontos de vista, você consegue absorver muitas idéias legais fazendo isso. Inúmeras vezes eu adquiri novas idéias ao conhecer diferentes produtos. Isso se soma às suas ferramentas de raciocínio e amadurece sua visão sobre o problema.

Um programador poliglota consegue aprender novas linguagens, produtos e formas de pensar com muito mais facilidade. Pensar fora da caixa é importantíssimo. Para evoluir essa habilidade é fundamental experimentar diferentes pontos de vista, e ganhar massa crítica.

Bons produtos ajudam a te dar massa crítica

Eu converso bastante com alguns amigos sobre software em geral, e um tema recorrente é a análise de projetos que deram certo e projetos que fracassaram.

Para ter sucesso em um projeto de software, é fundamental que pelo menos um dos membros do time tenha massa crítica avançada sobre o domínio do problema em questão. Se nenhum dos membros tiver, a melhor coisa a se fazer é avaliar um produto bom para o problema que se quer resolver.

Isso não quer dizer que o produto será a solução final adotada, ele pode servir apenas para te dar massa crítica antes de escolher o caminho.

Tendo massa crítica, utilize as facilidades dos produtos a seu favor

Quando você já conhece o domínio e consegue pensar fora da caixa, dá para ter ótimos ganhos de produtividade usando bons produtos. Por exemplo, eu tenho trabalhado muito com portais corporativos, com variadas implementações. Quando analiso um produto de portal, eu verifico, entre outras coisas:

• Plataformas/tecnologias que ele exige/permite usar
• Disponibilidade de wiki, fórum, blog, calendário, etc
• Personalização de estilos/layouts (o cliente quer um portal com a cara dele, não com cara de produto)
• Facilidade de extensão
• Repositório de conteúdo
• Integração de aplicações

Já conhecendo bem os requisitos na construção de um portal, eu consigo em alguns dias analisar um produto ou implementação customizada de portal e avaliar estes critérios acima. O mundo ideal é trabalhar com um portal que te dê resultados rápidos, mas sem dificultar muito que você o ajuste da forma que o cliente deseja.

Não caia no mito da caverna, explore sua criatividade

Fuja dos dogmas, questione os hypes. Não limite a sua visão aos recursos de um produto. Enxergue o que é a complexidade natural do problema e o que é a complexidade introduzida por humanos ou produtos. Não permita que os produtos engessem a sua criatividade. Esteja sempre no controle, e saia da caverna!