Escravos da Estética

Bem fez Platão, que dissociava o belo do físico. Já no conceito aristotélico, a beleza estava associada à simetria, proporção e perfeição das formas. 

Vivemos uma ditadura da estética. Todos admiramos o belo, mas raramente paramos para refletir acerca de alguns dos seus aspectos não tão nobres.

O preconceito estereotipado a gays, negros, deficientes e diversas outras minorias já virou arroz de festa. E o preconceito ao feio? Normalmente passa despercebido. É comum ouvirmos um comentário despretensioso quando nos deparamos com uma criança loira, bonitinha, passando necessidade.

- Tão linda e nas ruas, pedindo esmola!
 
Como se a miséria fosse uma prerrogativa do feio...
 
Todos buscam o belo; em si próprio e também no outro. O homem fica com a mulher bonita e tola, em detrimento de outra bem mais interessante, porém com menos atributos físicos.
 
Não é de se espantar que assim seja. Voltando à filosofia, Immanuel Kant associava a beleza à sensação de prazer proporcionada pelo objeto observado.
 
Nas relações humanas, a beleza chega a ser negativa, no sentido em que frequentemente orientamos nossas escolhas a aspectos superficiais.
 
Mas há outras abordagens, relativas ao próprio detentor da beleza. O exemplo, obviamente, recai sobre a mulher, que, sem maturidade para lidar com a própria beleza e com o assédio natural dela decorrente, acaba “estragada” pelo excesso de paparicação, pelo amplo leque de possibilidades, pela não-necessidade de conquistar o outro.
 
É aí que a estética constitui-se, de certa forma, um desserviço a quem a possui.
 
Frequentemente, o belo é um ser autocentrado, incapaz de abstrair e enxergar as coisas por uma ótica que não seja a sua – ok, isso ocorre com a maioria das pessoas – e, consequentemente, torna-se alguém extremamente desinteressante.
 
O que se vê hoje é um culto exacerbado ao corpo, à beleza física. Nas academias, o objetivo é corpo bombado e modelado, e não a saúde.
 
A mídia, a TV e o cinema parecem vender cada vez mais a ideia de que o padrão de felicidade passa incondicionalmente pelo culto à estética. E não é bem assim.
 
Ou não deveria ser.

Devemos encontrar mecanismos para nos defender de nós próprios, para que a nossa natureza não acabe conosco, tal qual a parábola do sapo e do escorpião.
 
Uma das ferramentas mais interessantes para o conhecimento das relações interpessoais é a Janela de Johari. Os quadrantes do “eu desconhecido” e, mais ainda, do “eu cego”, são fundamentais para o entendimento do porquê de nossos comportamentos.
 
De qualquer forma, devemos ponderar o quanto estamos dispostos a mergulhar nos nossos “eus”. Afinal, a afirmação mais verdadeira que existe é a de que a ignorância é o segredo da felicidade; o conhecimento, da dor. 

Mas uma dor necessária.

Estética (do grego αισθητική ou aisthésis: percepção, sensação, sensibilidade) é um ramo da filosofia que tem por objetivo o estudo da natureza da beleza e dos fundamentos da arte. Ela estuda o julgamento e a percepção do que é considerado beleza, a produção das emoções pelos fenômenos estéticos, bem como: as diferentes formas de arte e da técnica artística; a ideia de obra de arte e de criação; a relação entre matérias e formas nas artes. Por outro lado, a estética também pode ocupar-se do sublime, ou da privação da beleza, ou seja, o que pode ser considerado feio, ou até mesmo ridículo.
Fonte: Wikipedia

Bits, Bytes e Padrões

Já falei outras vezes sobre padrões e processos. É um assunto até meio cansativo, mas esses dias tive uma conversa na nossa Fábrica de Software que representa bem a importância do tema no mundo de TI.  Acho até que num curso sobre melhores práticas que ministrei há algum tempo tratamos desse assunto específico.

O assunto era a chamada de sub-rotinas dentro de um programa Cobol. Hipoteticamente, temos um programa XXXP0001 que chama a sub-rotina XXXS999.

Quando chegava um programador novo, geralmente passava-se a seguinte orientação:

- Olha, para chamar o subprograma você deve codificar:

Na Working Storage:

XXXS9999 PIC X(8) VALUE “XXXS9999”.

E na Procedure Division:  

CALL XXXS9999 USING “Variáveis”.

- Uai (geralmente os programadores novos eram mineiros)! Disseram-me que era pra chamar direto, entre aspas (CALL ”XXXS9999” USING “Variáveis”)! E funcionou!

Ou ainda:

- Bah (alguns eram gaúchos)! Eu tenho que chamar vários programas! Porque preciso declarar a variável XXXS9999? É melhor criar uma variável genérica, tipo GDA- SUBROTINA! Funciona, fica mais claro e eu posso reusar a guarda!

Nesse caso, o código na Procedure Division ficaria assim:

MOVE “XXXS9999” TO GDA-SUBROTINA.

CALL GDA-SUBROTINA USING “Variáveis”.

MOVE “XXXS8888” TO GDA-SUBROTINA.

CALL GDA-SUBROTINA USING “Variáveis”.

A resposta, nos dois casos, geralmente dada por quem não tinha ido atrás dos porquês, era sempre a mesma:

- Olha, esse é o padrão do pessoal da Governança de TI. Esses caras de processo vivem inventando moda! É melhor fazer como eles querem e ficar quieto.

Assim, as coisas funcionavam, os caras da MDS (metodologia de desenvolvimento de sistemas) eram os chatos e a vida seguia.

Mas não era bem assim. O padrão estava certo. Aliás, perfeito. A única falha dos “chatos da MDS” era não ter comunicado adequadamente qual o motivo do bendito padrão.

Vamos tentar clarear um pouco:

No caso do mineirim, ao dar o CALL na sub-rotina entre aspas, estamos passando ao processo de compilação (na realidade, de linkedição) a informação de que a chamada é estática, e não dinâmica.

Portanto, o executável resultante do processo de compilação e linkedição do programa XXXP0001 teria incorporado também o XXXS999. Funciona? Sim, funciona, inclusive até mais rápido.

No entanto, no momento em que versionássemos a sub-rotina XXXS9999, apareceria um dos seguintes problemas:

• Se a XXXS9999 tivesse instruções SQL, o programa XXXP0001 abendaria com o famoso SQLCODE -805 (acho que já falei sobre isso no post “Desmistificando o Bind”), no momento de acessar o banco de dados DB2, por divergência no timestamp do Cobol X999 com o do package de mesmo nome;

• Se fosse uma sub-rotina em Cobol puro (sem SQL), o problema seria ainda maior. O P0001 continuaria rodando, mas chamando a versão anterior da S9999, embutida no seu executável.

Portanto, ao declarar a variável, o CALL passa a ser dinâmico, com o P0001 chamando a X9999 em tempo de execução, sempre em sua versão mais recente.

Bem, já o caso do gaúcho é um pouco mais sutil, e mesmo “programalistas” experientes não sabem bem o porquê do padrão ser o nome da variável com o mesmo da sub-rotina.

A palavra-chave aqui é rastreabilidade.  Existem ferramentas (na minha empresa temos o X-REF, dentre outras) que buscam a cadeia de chamadas dos módulos. Isso é bastante útil para sabermos qual o impacto de uma alteração em um programa chamado por vários outros.

Essas ferramentas são bem interessantes, mas algumas delas (na realidade quase todas) trabalham por varredura no código-fonte, e não seriam capazes de detectar que o programa P0001 chama o S9999 no “CALL GDA-SUBROTINA”, como ocorre no “CALL XXXS9999”. Na realidade, usamos de um artifício para “enganar” o X-REF, pois ele acha que estamos chamando diretamente o XXXS9999, quando estamos mesmo é chamando uma variável de mesmo nome. Como o seu conteúdo é exatamente o mesmo (ver o VALUE no início do texto), o resultado é a chamada rastreada corretamente.

Bom, o objetivo dessa sopa de bits e bytes era apenas reforçar a importância dos padrões e da comunicação no nosso trabalho.

Um abraço e até a próxima!

Todos do mesmo lado

Quando eu comecei a desenvolver software, lá pelos anos de ... Bem, deixa pra lá quando foi isso... (você percebe que está ficando velho quando algumas pessoas acham que você existe desde a criação do mundo, junto com o Sílvio Santos e o Sarney...)

Bem, voltando ao assunto, nessa época, eu via o pessoal que trabalhava com processos e normatização como burocratas, indivíduos sem nenhuma conexão com o mundo real, que se preocupavam apenas em aplicar seus conhecimentos acadêmicos.

Santa ignorância: Com o passar do tempo, ao aprender um pouquinho mais e enxergar a TI de uma forma um pouco mais holística, comecei a entender a importância das normas e dos padrões.

Gerir um parque de TI como o nosso não é uma tarefa fácil. Se, num determinado momento, a Ditec “fechasse pra balanço” e passasse um tempo sem atender nenhuma demanda da área de negócios (algo impensável no mundo real, obviamente), ainda assim seria necessário um razoável contingente de pessoas apenas para manter tudo funcionando, contingente esse muito maior se não tivéssemos uma governança estruturando e organizando a casa.

Imagine como seria nosso legado de mais de 1000 sistemas desenvolvidos conforme a criatividade de cada um. Um simples B37 (abend por falta de espaço, se não me engano) seria um grande desafio para o analista da madrugada resolver.

Assim é que alguns problemas são triviais simplesmente porque temos padrões de codificação, de compilação, de bibliotecas, de procedures, de documentação, de procedimentos, de nomenclaturas, etc.

Portanto, na minha simplória ignorância (o segredo da felicidade, como costumo afirmar...), eu queria era liberdade para construir os sistemas do jeito que bem entendesse.

No mundo tecnológico, existe uma certa dicotomia entre desenvolvedores e normatizadores. Uns acham que os outros definem coisas não aplicáveis ao mundo real; os outros acham que os “uns” são meio insubordinados, que não leem instruções e fazem as coisas erradas de forma proposital.

Os dois lados estão certos – e errados. Precisamos exercer um pouco mais uma certa palavrinha muito em voga ultimamente: empatia. Colocar-se na situação do outro e entender o porquê dele não fazer aquilo do jeito que queremos.

Embora tenhamos profissionais com características claramente de desenvolvedores ou de normatizadores, é bastante saudável que, periodicamente, as pessoas vivenciem o outro lado, e percebam que somente com retroalimentação de parte a parte as normas se tornam facilitadoras da execução, bem como contribuem para mitigar riscos.

Peter Drucker, austríaco naturalizado americano, considerado o guru da administração, já dizia a algumas décadas que 60% dos problemas organizacionais decorrem de problemas de comunicação.

Todo mundo sabe – mas às vezes esquece – que processos e padrões não são um fim em si mesmo. Cobit, Itil e PMBOK, pra ficar somente nesses três, são frameworks excelentes, mas declaram, salvo melhor juízo, cerca de 110 processos.

Implementações segregadas dessas boas práticas, sem levar em conta o contexto das organizações, certamente levam a redundâncias e overhead.

Já vi o PMBOK ser acusado - injustamente - de atrasar os projetos. Como um conjunto de boas práticas, seu objetivo é exatamente racionalizar sua gestão, mantendo-o sob controle do líder.

Gosto muito de uma frase que já ouvi mais de uma vez em eventos de TI: Framework – adote e adapte.

Padrões e normativos são diretrizes e nunca exaurem todas as possibilidades, notadamente num meio tão complexo como o nosso. 

Um abraço e até a próxima.