Me engano, porque eu gosto "I"

     Quando coloco o "I" no título acima, já demonstro minha má intenção, estou declarando que não vou terminar este tema hoje, na verdade apenas vou introduzi-lo, mas nesta linha de confidências esclareço que sendo o texto escrito com base na comunidade de TI, só o é por ser o organismo social no qual estou inserido, oposto que o mesmo adapta-se a tantos outros grupos organizados, senão a todos.

     Lendo "eles fazem de conta que me pagam e eu faço de conta que jogo", cuja origem é uma declaração de um famoso jogador de futebol, imediatamente eu sou tentado a catalogar o texto como folclórico, por puro preconceito a este ramo do entretenimento, devido a sua característica de mais transpiração que inspiração típica do esporte, mas em nossas equipes de desenvolvimento de sistemas essa situação acontece bem mais vezes do que seria desejável supor.

     Partindo do raciocínio exposto na frase "nada é mais contra a vida que a civilização", e comparando o homem de hoje da sociedade "previsão de vida de mais de 70 anos" com o homem da "expectativa de vida de 30 anos" de décadas atrás, não encontro nenhum indicativo que vivemos mais agora, ao contrário o que vejo é criarmos intermináveis mecanismos para não viver.

     Na análise do que é nossa comunidade a vejo muito similar à vida, pois viver nada mais é que resolver problemas, começando pelo primeiro tenho fome, o problema está posto, ou arrumo comida e o resolvo ou estou morto, a similitude aparece quando defino a tarefa básica da comunidade de TI como um eterno resolver problemas.

     Bom, nossa fama de alto grau de fracasso começa por não entenderem a definição acima, sendo muito raro que nos chamem para resolver problemas quase sempre somos convocados a escrever milhares de linhas de código que não fazem nenhum sentido, começamos o jogo perdendo, pois nos preparamos para solucionar problemas e nos colocam a escrever linhas de código, cujo porquê escrevê-las por certo nós não entendemos e mesmo eles não o sabem.

     Imagino que as organizações façam isso apenas para nos manterem ocupados, dentro daquela dinâmica que escrevi antes, baseada em "criar mecanismos para evitar viver". Vou continuar neste tema no próximo post analisando os diversos papéis na área de TI e como estes colaboraram nesta direção, a do engano.

Inovação presa na engrenagem conservadora.

     Não resta dúvida, quando falamos em tecnologia a palavra "inovação" vem a tiracolo, comporta-se como um mantra sagrado, parece impossível qualquer esforço em desenvolvimento de sistemas sem seu componente inovador.

      Por certo já verificamos que a sempre eficiente sociedade conservadora estabeleceu neste caminho um novo negócio, estruturam-se mecanismos de intervenção por parte do governo e da iniciativa privada, criam-se instituições para trazer ao mundo e cuidar desta nova herdeira da tecnologia, porém fazemos uma análise mais profunda e descobrimos que apenas fazem deste modismo o seu ganha-pão, estamos querendo gerar inovação em um mecanismo não inovador.

      Não pretendemos desafiar a voz comum até porque de imediato descobrimos o grande ganho: A tomada de consciência sobre a importância de inovar, porém achamos oportuno refletir um pouco sobre o tema, me parece que a inovação se atinge por talento associado a um conjunto de boas práticas e não por planejar com o objetivo de obter, resumindo, tenho dificuldade de aceitar que inovação seja fruto da simples vontade.  

      Usualmente definida como fazer mais com menos recursos em processos produtivos, ou administrativo-financeiros ou ainda na prestação de serviços potencializando a capacidade de competitividade, podemos concluir que a inovação é inerente ao ser humano, isto é, na verdade o que precisamos é evitar todos os maus hábitos que nos afastam de "pensar" em cada um dos passos que executamos para cumprirmos as metas as quais nos propomos.

      O desafio é este, vasculhar as ferramentas que criamos identificar nelas tudo que afasta seus utilizadores do pensar sua execução, revitalizá-las destinando espaço a incentivar o uso permanente da criatividade nas tarefas independente de seu grau de complexidade, enfim criando um ambiente propício para que a inovação possa aparecer.

      Estamos simplesmente postulando um ambiente de trabalho favorável, onde a comunidade encarregada de executar tarefas as faça exercendo na plenitude o que as caracteriza que é ser humano.

Murphy a TI apostando nas bruxas

     Entre a Lei de Murphy, "tudo que pode dar errado, vai dar errado", e um conhecido adágio espanhol, "Nós não acreditamos em bruxas, mas que elas existem, existem!”, dividimos nosso dia a dia de profissional de TI convivendo com projetos bem-sucedidos e outros nem tanto, são os problemáticos que explicam e popularizam as afirmações anteriores, na prática essa abordagem é apenas um erro contábil, na coluna do débito colocamos os problemas esquecendo-nos de colocar as soluções que oferecemos na coluna do crédito.

     A garantia contra as bruxas, nas quais não acreditamos, provoca grandes esforços no desenvolvimento de mecanismos e estruturas de proteção, subtraindo parcela significativa do escasso tempo que dispomos de dedicação ao projeto, em busca de minimizar esse esforço me aventuro a sugerir pequenos passos que talvez nos ajudem.

     Primeiro cuidado, dedicar todo o tempo necessário para entender os objetivos e as metas a serem atingidas por nosso cliente, isso não representa falta de fé no descritivo do projeto que ele nos apresenta, apenas significa que é preciso saber onde queremos chegar e não o que fazer, o detalhamento apenas nos tira do foco do que é básico, a clareza nos objetivos nas metas vai facilitar o caminho.

     Pesquisa sobre o tema é o passo seguinte preciso antes de discutir o detalhamento com o futuro utilizador preparar-me para as conversas que terei com o mesmo, como discutir com alguém um assunto que não domino? Não me preparando onde vou achar o espírito crítico para analisar suas solicitações e garantir sucesso no desenvolvimento, o segredo é fazer as perguntas certas.

     Negociar, sim negociar prioridades é fundamental, agrupando conjuntos de funcionalidades com o objetivo de dividir para eliminar a complexidade, investir tempo na descoberta de "onde estão os ganhos", identificar alternativas, buscar o melhor caminho obtendo uma programação de entregas priorizadas.

     Trabalhar com times pequenos de talentos complementares, ter sempre como parte do time um especialista no tema, consultor interno ou externo que possibilite enriquecer a proposta, não em número de funcionalidades e sim em qualidade.

     Caros agentes de soluções em TI, que por acaso me privilegiaram com a leitura destas linhas, tenho certeza que a vossa experiência em muito vai corrigir e complementar essas ideias, de minha parte eu espero apenas que tenham alguma utilidade.

Meu aplicativo destruindo postos de trabalho

     Cinema mudo, Chaplin e aquela sequência maravilhosa, o nosso simpático herói completamente desajustado na linha de produção da fábrica, por que me lembrei disto? Porque me vejo hoje inserido em uma sociedade cada vez mais comprometida com a qualidade de vida, começando enfim a romper com esta perversa cadeia construída com a revolução industrial.

     Hoje com maior constância ocorrem surpresas, caminhos alternativos, manifestações poderosas, inesperadas e surpreendentes em praça pública, jovens etiquetados como "bem encaminhados profissionalmente" buscando e principalmente criando outro modo de trabalho, são tempos que nos apontam para direções novas.

     São oportunidades para a comunidade de desenvolvimento de sistemas, elas aparecem em suas duas faces, por um lado o compromisso de construir produtos que automatizando eliminem estes enfadonhos postos de trabalho que ferem a dignidade humana e por outro lado aplicativos que sirvam de oportunidade para a manifestação dos talentos inerentes a cada um de nossos clientes.

     Na primeira oportunidade a grande "vedete" é o Workflow, gerenciador de processos de negócio (BPM), rico em facilidades para desenhar e automatizar processos, que permite trabalhar em uma capa de alto nível e com um poderoso instrumental para institucionalizar a melhoria contínua.

     Na segunda o "astro" é a Inteligência de Negócios (BI), que privilegia ações pró-ativas, ou seja, tudo começa pela visualização dos alertas e seus indicadores expostos nas diferentes dimensões que analisados permitem ao cliente gestor decidir e iniciar os processos mais adequados.

     As oportunidades vêm do mercado, a tecnologia é disponibilizada por ferramentas de TI, no meu caso o Genexus integra no ambiente de desenvolvimento tanto o workflow (GXflow) como o BI (GXquery/GXplorer), e eu com desenvolvimento de aplicativos contribuo para mais qualidade de vida, turnos de trabalho menores e a consequente ampliação do tempo dedicado à convivência humana.    

Meu aplicativo minha a mesa de trabalho

        Participante ativo de uma sociedade de trocas, onde ora sou cliente ora sou fornecedor, tenho a oportunidade de atuando como cliente desenhar as melhores soluções para meu papel de fornecedor, identificando os pontos fortes que me ajudam e principalmente os pontos fracos que me atrapalham e os utilizo como apoio na modelagem da solução que vou oferecer.

       Minha experiência pessoal oportunizou o uso de vários softwares de CRM, alguns desenvolvidos na própria oficina, outros contratados de terceiros, apesar da qualidade destes produtos sempre me defrontaram com a necessidade de somar ao seu uso em paralelo algum recurso manual ou informatizado.  

        Vivendo o evento "negociação com o cliente" necessito um relatório com as últimas negociações, uma síntese das vendas anteriores, uma planilha com os preços e condições, um bloco de notas para minhas anotações, meu foco está todo dedicado na valorização da conversa com o cliente logo o acesso a todos esses recursos deve ser direto, em um mesmo lugar, no modo "em um click", evitando percorrer menus em busca de cada um destes itens.

         Na prática lá estava eu utilizando um excelente software e em paralelo a cada momento necessitando agregar um novo recurso, uma simples folha de papel para anotações, relatórios para consultas ou ainda sofisticadas planilhas, em outras palavras o aplicativo não conseguia substituir a minha boa e velha mesa de trabalho.

         Assim aprendi a olhar o dia a dia de meus clientes, identificando a cada evento como disponibilizar todos os recursos necessários para sua execução, servindo em um formulário a mesa de trabalho na medida em facilidades e quantidades de recursos.

   

         Não foi difícil perceber que o excesso também nada somava, nega o que penso ser básico que é a simplicidade, agregar engenhosas funcionalidades que em verdade mais alimentam o ego do escritor do software do que ajudam o cliente, quando disponibilizadas acabam poluindo a tela e por consequência gerando dificuldade e não facilidade.

         A tecnologia disponível, os novos modelos de relacionamentos entre as pessoas e o trabalho adicionam valor ao software devido ao fato de a mesa de trabalho, por ser virtual, em cada momento acompanhar o seu usuário.

Se devo ensinar a usar, então meu SW não existe

     Minha proposta não é analisar a existência física das linhas de código escritas e sim a aderência destas ao mundo real, aquele vivido por nosso usuário no seu dia a dia quando planeja, executa, avalia, e onde o sistema não o ajudando pode ser apenas um fardo a mais a ser carregado.    

     Muitas vezes participei de desgastantes e cansativas reuniões na busca de culpados, onde transferimos para os usuários via crédito na conta "uso incorreto do software" nossos problemas, se tem algo que foge da responsabilidade de quem utiliza nosso produto é o seu conhecimento do mesmo, o sistema oferecido é quem deve conhecer as necessidades do utilizador.

     Meu cliente, por óbvio, não tem nada a aprender sobre o software que disponibilizo, sua tarefa é conhecer o próprio negócio, suas principais regras e funcionalidades e é nesta direção que deve ser feito todo e qualquer investimento de tempo e treinamento, aparecendo o software apenas como um recurso de otimização do trabalho.

     O profissional no processo de informatização, independente do setor, concentra seus recursos em investimentos necessários para aumentar sua produtividade, utilizando sistemas que devem ser naturais, navegados de maneira intuitiva, com conceitos e símbolos usuais na sua comunidade.

     Somos tentados a propor sistemas que pecam pela falta de simplicidade, onde mostramos nosso apego à tecnologia que bem serve nossa vaidade, porém pouco compatível com as necessidades do usuário, de alavanca passamos a objetivo e com isso estamos roubando precioso tempo de nosso cliente.

      

     Ter um software vivo no mercado significa evitar somar obrigações para seu utilizador, significa simplificar tarefas agregando potência a cada uma delas, significa via bons resultados acrescer alegria e autoestima.

     Traçando um paralelo com o Futebol onde falamos que um bom juiz é aquele que não aparece durante o jogo, poderíamos na informática dizer: "Quanto mais transparente ao usuário, melhor é o software".  

TI parceira na luta contra o talento pessoal

     A maioria dos agentes financeiros e suas áreas de TI inibe o talento nas suas empresas, Daniel, você enlouqueceu? Nunca se investiu tanto em linhas de código para agentes financeiros, em aplicações web, em redes locais de agências e em quiosques eletrônicos.

     Fracasso na utilização de talentos? Nunca agentes financeiros obtiveram tanto lucro, arrecadações tão espetaculares como hoje no Brasil, calma deixa eu me explicar, analisem comigo as situações que vivenciei.

     Adolescente eu pude testemunhar, em cidade pequena, vinte mil habitantes, a agência local conseguiu o maior valor em números absolutos de depósitos juvenis entre todas as agências do banco no país, fato improvável, só explicado por existir autonomia local, com suas iniciativas e responsabilidades.

     Nos tempos atuais a cada visita ao banco encontro um interlocutor totalmente dependente de um programa de computador, de um lado eu e minhas necessidades e de outro um gerente de conta sem autonomia, sem caminhos para mim e consequentemente para a instituição.

     Os resultados positivos da área financeira, sustentados por sistema definido pelo privilégio, não escondem uma gestão que engessa os profissionais, regras definidas de cima para baixo apoiadas por um software destruidor de talentos.

     A simples análise da premiação dos funcionários, conhecendo um pouco o sistema, atesta o que afirmo, paga-se comissão o que os define como vendedores e não como gestores, que por seus méritos e talentos seriam contemplados por um plano de carreira.

     Tenho absoluta certeza de que poderíamos ter um software que permitisse via indicadores alavancar decisões por parte dos gerentes, adubando seus talentos pessoais, para obter os melhores resultados tanto para o agente financeiro como para o cliente. Lutar por isso é também uma obrigação nossa, da área de TI.

     Imagino que todos vocês devem ter vivenciado o por mim relatado, aposto por nossa já famosa "falta de competitividade Brasil" no mundo globalizado que esse exemplo é reproduzido nas mais diferentes atividades exercidas na sociedade e o fato de seus gestores serem os principais avalistas do problema não isenta de responsabilidade os profissionais de TI.

Casa de ferreiro espeto de pau

     O que é bom para meu cliente não serve para mim? Vendo a ideia que ele vai ganhar produtividade automatizando seus processos, por que o mesmo não seria válido para o meu processo de desenvolvimento de sistemas? Fugir da automação do meu dia a dia nada mais é do que "casa de ferreiro, espeto de pau", como se diz aqui no sul entre nós gaúchos.

     O que quero dizer com essa frase popular é que advogo uma causa que não adoto, e tenho encontrado na comunidade de informática, que tem como missão aumentar a produtividade de seus usuários através da automação de seus processos de trabalho, dificuldade em aceitar que sua produtividade pode ser aumentada pela automação do seu trabalho de codificação.

         

     Obviamente que uma parte dos desenvolvedores trabalha na produção de ferramentas de produtividade para a própria comunidade de TI, estes certamente escolhem a linguagem mais apropriada para desenvolvimento dessas ferramentas, porém eu como analista de negócio que vai informatizar o usuário final, tenho obrigação de utilizar todos os recursos possíveis para atender meus clientes com mais qualidade e produtividade evitando penalizá-los em tempo e valor.

     Lembro novamente Warnier, o tempo tem comprovado acerto de suas pesquisas quando afirmava que no desenvolvimento de sistemas dez por cento de nosso tempo é dedicado à solução do problema e noventa por cento à tarefa enfadonha de escrever código, defendendo a ideia de que deveríamos separar o analista de negócio do codificador, inclusive salientando que após a solução do problema durante a codificação a tendência é de perda de foco, e por isso nessa hora geramos ao escrever o código a maior quantidade de erros, nossos famosos bug's.

     Felizmente evoluímos, hoje podemos descrever a solução do problema e automatizar a tarefa de codificar substituindo-a por ferramentas, com a vantagem de estas serem construídas por especialistas que para cada diferente regra de negócio escolhe as linhas de código mais adequadas para cada linguagem e banco de dados.

     Em mais de vinte anos, convivendo com uma grande comunidade distribuída por todo o mundo utilizando uma destas ferramentas, o Genexus, não encontrei desafios, independente de complexidade, que não pudesse resolver com sua utilização liberando em tempos consideravelmente menores excelentes aplicativos.

Seguir as "tábuas da lei" é certeza de sucesso para meu projeto?

     Posso ser tentado a procurar um Moisés, com seus dez mandamentos gravados na Pedra, e seguindo-o passo a passo obter o paraíso para meu negócio? Seria possível assim chegar aos melhores resultados? Parece-me difícil aceitar que entre tantos outros que seguirão as mesmas leis terei algum diferencial que me permita o tão almejado sucesso.

     O mercado nos apresenta inúmeras receitas, sempre receitas de sucesso garantido, sempre escritas depois do sucesso alcançado, curioso é que enquanto estou atrás da receita do momento, sempre um não seguidor atinge seus propósitos e por seu êxito gera uma nova receita.

     A melhor imagem que vi retratando com força essa opção decadente é a crítica ao sistema educacional no filme "The Wall", em que aparece uma animação mostrando milhares de estudantes todos iguais gerados a partir de uma máquina de moer carne que os põe a marchar em enormes filas indianas.

     Parece-me óbvio que o bom caminho só pode ser criado, nunca copiado, muito mais importante do que seguir as trilhas já percorridas é refletir sobre o contexto, sobre os desafios enfrentados e detectar onde se manifesta a criatividade, quais e que talentos humanos participam do processo.

     Como desenvolvedor, tanto em uma casa de software como em uma corporação, o processo envolve não só a área de Tecnologia da Informação, mas a organização como um todo, certamente não adianta ser criativo para informatizar um negócio preso a uma camisa de força.

     Por isso acredito na gestão horizontal através das pessoas com seus pontos fortes e fracos, na estrada construída sob medida para cada organização, caso a caso, aproveitando o conjunto de recursos humanos internos e externos disponíveis, buscando o tal do "encaixe", figura de linguagem muito utilizada no futebol que identifica os times ganhadores.

Bom, postei e então, calma, me explico.

     Depois de três textos postados, me senti na obrigação de explicar-me, sim não é de hoje que tenho este projeto, pois finalmente resolvi colocar em prática, espero que as linhas que seguem sejam claras. 

     Observando uma impressora 3D, camada a camada compondo um objeto novo em três dimensões, revi como em um flashback, um processo similar compondo o que hoje sou também: os projetos, consultorias, treinamentos, churrascos e conversas de bar foram aos poucos construindo o meu pensamento.

     A comunidade, vista pelo seu aspecto mais amplo como encontro de seres vivos, foi e sempre será o agente provocador da construção de um pensamento atuante, como me classifico, graças a inegável influência das pessoas com quem convivi, isto é, de vocês.

     Assim como me defini no Twitter: "Sim pistas, paixão, livros, pessoas, tecnologia da informação, sim vida; Apenas personagens sobrepostas no tempo de mim mesmo e seus rastros", esse resultado é o que me proponho deixar por aqui.

     Bom, ficou fácil adivinhar porque resolvi postar um ou dois textos por semana, nada mais é do que devolver para vocês algo do qual são coautores.

     Transparência, eu nunca acreditei nas ideias como um tesouro a ser guardado e sim sempre as vi como um bem a ser compartilhado, compartilhar é um privilégio para quem disponibiliza, e sou grato pela possibilidade de talvez alguém ler, comentar, contestar ou simplesmente ignorar.

     Pretendo através de uma linguagem simples, direta escrever estas linhas sem que pensem que tenho algo a demonstrar, nem mesmo a propor, apenas quero deixar registrado o que tenho conversado com vocês nas muitas ou poucas vezes que nos encontramos, ou seja, nada mais que um log embaralhado na sua cronologia.

Desenvolvendo software e talentos

     Participando de projetos, independente do grau de envolvimento como desenvolvedor, analista ou consultor, sempre me atraiu as questões referentes a prazos e qualidade, pois confirmando as estatísticas quanto ao sucesso dos projetos de Tecnologia da Informação sempre enfrentamos dificuldades para que o usuário tenha a solução no momento que lhe é mais conveniente e que atenda as suas expectativas.

     Sou tentado a considerar indicadores como falta de talento, equivocada metodologia de trabalho ou ainda as ferramentas de trabalho adotadas como causa de insucesso quanto às metas de prazo e qualidade, certamente as diversas combinações possíveis desses três itens aparecerão na avaliação.

     Treinamento é o item que sempre tenho identificado como deficiente, não temos cultura de investir no treinamento, o que nos custa prazo e qualidade no projeto, obviamente essa deficiência não é privilégio da área de TI, também os usuários dos nossos projetos não são treinados, ou seja, estamos potencializando o problema.

     Treinamento deve ser um processo contínuo e multifacetado, estamos falando de considerar no projeto horas de treinamento como subconjunto das horas de desenvolvimento e atendendo todos os componentes como ferramentas, metodologia, tecnologia e negócio alvo, e todos envolvidos no projeto devem ter a visão global independente de suas especializações.

     A maneira convencional que utilizamos para treinamento, estudar um conjunto de temas completamente desvinculados das tarefas do nosso dia a dia, nos serve como referencial para quando enfrentarmos os problemas termos segurança para assim apreender resolvendo o problema real.

     Tem se mostrado muito mais eficiente distribuirmos o treinamento durante o processo de desenvolvimento, ou seja, à medida que assumimos as tarefas incluímos também como tarefa os módulos desejáveis de treinamento, associando a teoria à prática da maneira mais adequada ao problema que está sendo resolvido.

     Este conceito de treinamento contínuo representa garantia de acréscimo de qualidade, pois aumenta em muito a reflexão sobre as melhores práticas para resolver um problema específico e real.

     O acréscimo de pequenos turnos de treinamento (normalmente duas horas por tema) indicaria a princípio um tempo maior de projeto, porém na prática, o fato de eliminar dificuldades e rescritas devido a erro por deficiência de formação acaba garantindo os prazos desejados.

     Importante salientar que acreditamos em gestão distribuída o que permite que o time identifique, à medida que assume as responsabilidades do desenvolvimento, os conteúdos nos quais deverão ser treinados na tecnologia, nas ferramentas, na metodologia e no próprio negócio, neste último item sendo extremamente desejável a participação do usuário.

Estou escrevendo um Software que nasce morto?

     Sim, penso que sim, certamente não nos seus componentes, não no desenho de suas funcionalidades, mas na maneira como o concebo, na sua capacidade de aderência a organizações eficientes em uma sociedade globalizada, conectada e altamente competitiva.

     O que foi desejável por muito tempo, postos de trabalho disciplinados, comprometidos com processos repetitivos, trabalhando no conceito de linha de produção, hoje as organizações estão os substituindo por operadores que tenham talento, que tomam decisões, que sejam criativos.

     A tecnologia com seu avanço em velocidade geométrica tem possibilitado isso via automação de todas as tarefas repetitivas e substituição desses postos de trabalho.

     Estamos investindo muito dinheiro em linhas de código destinadas a engessar os operadores no dia a dia com regras e mais regras que inviabilizam a criatividade e o talento destes.

     Talento que cada vez mais é oportunidade única de promover a organização ao seleto grupo das bem-sucedidas.

     Quando penso que este tipo de organização está destinada a reorganizar-se ou desaparecer, estou dizendo que todo o investimento que faço em Software nessa organização está morto, isto é, estou sim construindo um Software que nasce morto, a empresa necessitará de um Software adequado à mudança ocorrida que a viabilize no mercado, sendo que, caso venha a sucumbir, não precise mais do Software.

     Como desenvolvedor, como analista, como consultor preciso escrever Software já pensando na empresa do amanhã onde quem vai utilizá-lo são talentos, tomadores de decisão, distribuídos por toda a organização, não no Software que os conduz por um caminho único pensado de cima para baixo. Tenho que oferecer muitas opções com alto grau de interação, oportunizando que a organização seja o conjunto criativo de seus colaboradores.

Eliminar complexidade e Orientação a Dados

     Quando escrevo software, seguindo conselho de DESCARTES busco eliminar a complexidade, ou seja, divido o complexo em suas unidades mais simples, obtenho através desse método um código enxuto e ganho produtividade.

     Se estivermos falando em escrever aplicações de TI, certamente podemos colocar a lógica como a principal qualificação desejável ao desenvolvedor, logo o ferramental disponibilizado nas ciências exatas nos parece o mais adequado para garantir o sucesso das mesmas.

     Desenvolvendo aplicações adequadas à sociedade conectada (Web 2.0, SaaS, mobilidade), reencontro na orientação a dados o caminho científico para o melhor código, WARNIER e sua Lógica de Construção de Programas mais atual do que nunca.

     Sim, Warnier tem como pilares da sua teoria a construção dos Diagramas de Entrada e de Saída de Dados, diagramas estes baseados na teoria dos conjuntos e na obtenção de unidades simples e indivisíveis de dados, por conseguinte de código.

     Estamos claramente falando em orientação a Dados, estamos falando em um método científico de saber qual código escrever, o que nos dá suporte a automatizar esta tarefa, pois se os dados nos orientam sobre o código a ser escrito podemos ter um programa que analise esses dados e escreva o código adequado.

     Na indústria de TI temos um exemplo prático na Tecnologia Genexus, em que utilizamos o objeto declarativo "Data Provider", no qual apenas descrevo a estrutura de dados de entrada e de saída com o programa oferecido pela Genexus. Escrevendo na linguagem que escolhemos o procedimento correto para percorrer as diversas tabelas, gera-se o resultado esperado sem que se necessite de nenhuma linha de código procedural.