domingo, 23 de dezembro de 2007

Tão simples quanto possível

Gosto da frase “Make everything as simple as possible but not simpler” ou em tradução livre "Torne tudo o mais simples possível mas não seja simplista" do Albert Einstein. Essa frase pode ser interpretada considerando que todo problema possui uma “complexidade essencial” e na medida em que é abordado, fica impregnado com uma “complexidade mundana”. A frase então, quer dizer que você deve evitar o surgimento e buscar eliminar a complexidade mundana, sem perder nenhum elemento da complexidade essencial. A complexidade mundana tem três origens:

1. Na desordem, onde proliferam redundâncias e falta de ortogonalidade;
2. No uso de mais elementos do que os necessários para o problema em questão;
3. Nas escolhas inadequadas de notações e nomenclaturas.

Isso se aplica a qualquer campo de conhecimento, mas em especial, as soluções de TI são fontes inesgotáveis de complexidade mundana e talvez por isso a frase seja tão citada neste ramo. Em programação, o que chamamos de “código obscuro”, são exemplos abundantes dessas três causas de complexidade. Muitos profissionais se vangloriam da memorização de códigos e vocabulários sem relevância para o entendimento do problema original, e são incapazes de explicar qualquer coisa sem recorrer a esses códigos e vocabulários. Pior que isso, algumas vezes essa complexidade é alimentada e usada por maus profissionais para dificultar a entrada de outros no seu domínio (isso também é muito comum em direito e economia).

Em TI, alguns antídotos para a primeira causa são: padronização; estabelecimento de um glossário sem ambigüidades; reorganização periódica de requisitos e código buscando maior ortogonalidade dos elementos e uso do glossário.

A segunda causa é característica da falta de pragmatismo, mas também se alimenta da desordem. Em projetos de software, é comum o engano de pensar que quanto mais genérica uma solução, melhor. Em processos de desenvolvimento, significa trabalhar com processos e artefatos que não tragam retorno de investimento.

A solução da terceira depende de um certo talento e compromisso em ser didático. Requer o uso de nomes adequados para os requisitos, módulos, classes, métodos, funções, variáveis, tabelas e campos nas bases de dados. Os nomes devem estar alinhados com o glossário, que deve ser o mais intuitivo possível.

Para finalizar, considero que a consciência da existência dessa complexidade mundana e o empenho em eliminá-la, pode ajudar qualquer pessoa a aumentar a própria capacidade de entendimento e resolução de problemas complexos.

2 comentários:

Alexandre Bairos disse...

Em http://blog.intentionalsoftware.com/intentional_software/2005/05/feature_x_is_co.html e http://blog.intentionalsoftware.com/intentional_software/2005/05/notations_and_p.html Charles Simonyi expões o conceito de "degrees of freedom" aplicado a programação, que me parece ser o próprio item 2 da suas lista das três causas da complexidade em software.

Unknown disse...

Concordo plenamente com essas considerações. Infelizmente nós trabalhamos em um ambiente em que as metas estão baseadas em "entregas" e "lucro". Esse pensamento nos deixa a mercê de prazos irreais, desinteresse pelo correto e nos leva a fazer as coisas pensando sempre na escolha: Bom, rápido ou barato? Só dá pra escolher um ;-)