"
Apoiado por

Devíamos ser responsabilizados pela merda que fazemos

Se, ao construir uma ponte, um engenheiro civil fizer mal as contas a ponte cai. Mas não é só a ponte que cai. Esse engenheiro civil provavelmente também cai. Ou pelo menos desequilibra-se. Porque quando fez o projecto da ponte assinou-o, assumindo responsabilidade pelo que fez.

Nós os programadores ABAP não temos esses problemas.

Por muito má que seja a qualidade do nosso código nunca ninguém conseguirá processar-nos. Aliás, muitas vezes até gostam mais de nós quando somos rápidos a dar resposta mesmo sabendo que para sermos rápidos estamos a fazer tudo mal e deixamos um legado problemático e de difícil manutenção.

Não nos acontece nada nem que demoremos seis meses a fazer um programa que fica tão mal feito que, mais tarde, depois de sairmos desse cliente, a pessoa que tem de o manter acabe por decidir deitá-lo fora e começar de novo. Nem assim sofremos qualquer consequência. Se calhar o cliente até continua a elogiar-nos a simpatia e a velocidade com que resolvíamos os problemas. Se calhar até gostam mais de nós do que do outro que acabou por reescrever um programa com mais qualidade e de fácil manutenção mas que afinal só faz o que o nosso já fazia e por isso foi uma perda de tempo.

Também nada nos vai acontecer se fizermos um user-exit com 2000 linhas corridas cheias de CHECKs e código hardcodado, que um ano mais tarde acaba por explodir e paralizar a empresa durante uma manhã, deixando empregados parados no mundo inteiro, com custos de dezenas de milhares de euros. Isto porque pediram a alguém para fazer uma pequena alteração e esse alguém cometeu um erro por não conseguir entender nada do que aquelas 2000 linhas fazem. Provavelmente também terão saudades nossas dizendo que nós não teríamos causado problemas porque já sabíamos os cantos à casa (sendo que a casa era neste caso um labirinto laboriosamente construído por nós ao longo dos vários anos que lá estivemos).

Nós os programadores ABAP não somos responsabilizados por nada. E por não sermos responsabilizados por nada tornamo-nos irresponsáveis. O mais espantoso é que muitos de nós nem sequer temos a noção da nossa irresponsabilidade. Porque, além de não sabermos programar, não sabemos que não sabemos programar. E somos bem capazes de chegar ao fim da nossa carreira ilesos e ignorantes da nossa própria ignorância.

Devíamos ser obrigados a assinar o que fazemos. Devíamos ser responsabilizados pelos resultados do nosso trabalho. O nosso trabalho devia ser regulado pela Ordem dos Engenheiros que deveria ter o duplo papel de defender os nossos direitos e de exigir que cumpríssemos os nossos deveres, nomeadamente no que toca a qualidade. Os clientes para quem trabalhamos deviam exigir que o nosso trabalho fosse assinado (para além do SY-UNAME) e quando algo corresse mal deviam responsabilizar-nos quando se apurasse que o que correu mal resultou de displicência nossa.

Só assim esta profissão ganhará alguma nobreza. Só aí teremos o direito de dizer que somos Engenheiros.

Até lá vamos continuar impunemente a espalhar mau código ABAP por esse mundo SAP fora.

10 comentários a “Devíamos ser responsabilizados pela merda que fazemos”

  1. Antelio Diz:

    Concordo que deve existir um grau mínimo de responsabilidade.
    Já tive várias conversas sobre este assunto e recaiam em dois tópicos:

    1) Regulamentação através de um Conselho Regional, tipo CREA, etc.
    Isto não garante a qualidade e só adiciona burocracia burra.
    Assim como Certificações só garantem um nível mínimo de conhecimento.
    A experiência profissional conta muito mais e é mais valorizada pelo mercado.

    2) Não existem meios de garantia de confiabilidade do código gerado.
    Ao contrário da engenharia, em que definidos os requisitos e seguidas todas as normas (ABNT’s, por ex.). Existe um altíssimo grau de confiabilidade.
    O processamento de testes em códigos não garante bug free, pois existem bug’s que vão além do próprio código. Por exemplo o código ABAP, não está livre de bug’s de código SAP, Banco de Dados, Sistema Operacional e Hardware.

  2. Erick Carvalho Diz:

    Excelente colocação e compartilho totalmente de seus pensamentos.

    Mas esse problema é muito mais complicado, sendo muito sincero eu realmente não lembro o ultimo cliente que estive que seria capaz de julgar a qualidade do software por mim criado. Indo por esse caminho estaríamos apenas criando mais uma profissão.

    Nós como profissionais do conhecimento não acredito que necessitamos desse tipo de auditoria, na verdade o que sobra no mercado é a falta de qualidade na mão de obra.

    Hoje não necessitaríamos de uma pessoa engravatada auditando código, ao contrario disso podemos ter uma validação a cada request liberada validando se foi aplicado TDD por exemplo, isso sim pode melhorar a qualidade.

    Mas ai caímos no ponto, qual profissional ABAPer é capaz de escrever testes? Na minha experiência conheci poucos que conheciam sobre TDD, e falar de quem aplicava ainda estou pra conhecer.

    Levando a outro ponto. Os desenvolvedores possuem formação adequada? será que os cursos de faculdades têm sido suficiente?

    Acredito que temos muitas vantagens perante a área de engenharia, nós como profissionais do conhecimento temos a chance de ter AGILIDADE nas entregas de uma forma que a engenharia talvez nunca venha a ter.

    Valeu!

  3. Furlan Diz:

    Concordo com os resultados de seus motivos, mas acho que a causa raiz ainda é econômica. O que eu quero dizer é que não adianta nada profissionais super capacitados se os clientes não enxergam valor econômico nisso. Vi clientes que somente queriam a NF assinada e ponto final. Se o código é um lixo, isso não é importante, “será problema do próximo ABAPer”.

    Creio que muito mais do que um ABAPer ser responsabilizado pelo seu trabalho, seria se os clientes mesmos dessem valor para códigos de qualidade, penalizando os maus programadores e preferindo profissionais preocupados em aplicar as melhores técnicas da sua profissão.

    Não acho que o correto é nos comparar a engenheiros de pontes, pois nosso código mal feito “somente” dá prejuízo financeiro, já uma ponte, além do prejuízo financeiro há a possibilidade de perdas de vidas o que faz com que um erro de um profissional possa acarretar em um processo penal.

    Na empresa em que eu trabalho, código de qualidade (pelo menos em termos de performance) são itens de compliance, nenhum programa vai para a produção se não for aceito em revisões de qualidade. Mas para isso, a empresa precisou enxergar que no longo prazo, código de má qualidade será um grande prejuízo. O que aconteceu aqui não foi uma iniciativa dos programadores iniciantes ou medianos, mas da própria empresa convencida do valor disso.

    Mas isso aconteceu por conta de bons programadores que fizeram todo o trabalho de convencimento da direção em investir em código de qualidade. Muito dinheiro foi usado, mas isso é enxergado como investimento e não gasto.

    Novamente, tudo começou com os programadores mais experientes e com isso essa responsabilidade recai sobre nós. Eu, você, Erick, Antélio ou qualquer outro programador experiente em vender corretamente a qualidade de software.

    Em resumo, se a empresa não exigir código de qualidade, qualquer coisa além do “faz funcionar que está bom” será visto como desperdício. Para mudar a empresa, é um trabalho de evangelismo que nós temos que fazer com tais empresas. A batalha será árdua, mas se quisermos um mundo onde programadores bons sejam valorizados, é isso que devemos trabalhar.

    Abraços e continue com seu ótimo trabalho aqui!

  4. Jorge Diz:

    Programador de código ABAP é pedreiro que coloca os “tijolos” da ponte. Para fazer um ponte trabalham muitos arquitetos ou engenheiros mas apenas assina um. Achar que escrever código ABAP é o equivalente a desenhar uma ponte e dar valor a mais a aquilo que fazemos.

    Por outro lado quem deve assinar um código é o responsável da equipa técnica, é ele quem deve dizer se o código tem qualidade suficiente.

  5. David Matias Diz:

    Sem dúvida um tema bastante interessante!
    Partilho da opinião de que grande parte do código ABAP ( ABAP em particular mas noutras linguagens acontece o mesmo) usado em meios empresariais é de facto de muito pouca qualidade.
    Tendo a concordar muito com o user Furlan e na motivação económica – de facto o código produzido tem um objectivo primordial: funcionar – a este juntam-se outros, naturalmente. Mas, face ao custo global de um projecto, a qualidade do código acaba por empurrada para segundo (terceiro ou quarto plano). Porquê? Porque o custo de produzir “bom código” é bastante mais elevado do que fazer código “funcional”.
    Saliento também, que o código ABAP, é uma peça no meio de uma “framework” composta por elementos com tanto ou mais contributo para a qualidade da solução- parametrização, arquitectura de landscape, aplicações externas, etc – e que o melhor código em alguns contextos acaba por ter muito pouco valor.
    Importa ainda ter em conta a volatilidade de algumas soluções implemntadas pois uma parte considerável do que produzimos acaba por ter uma vida útil muito curta quer por alterações de negócio, imposições legais, evolução tecnológica etc. É pois diferente este contexto daquele em que são produzidas aplicações críticas para operação durante vários anos.

    Concluindo, concordo acima de tudo com a urgência de reconhecermos o que está mal e trabalhar para melhorar diariamente. Acredito que a maior dificuldade está na evangelização dos mais “juniores” que (infelizmente) tomam os muitos exemplos disponíveis online como “biblia” a seguir sem qualquer espírito crítico.

    Um abraço.

  6. Sérgio Fraga Diz:

    Bom dia!!

    Este é um tema de facto bastante interessante e para um ABAPer se considerar um profissional de conhecimento, citando o Erick Carvalho, há bastantes pontos que necessitam de ser aprendidos de raíz e outos fortalecidos e consolidados.

    Numa industria tão jovem como a nossa é natural que os conceitos que já estão cimentados e aceites em outras áreas da engenharia ainda não sejam prática comum e infelizmente muitas das vezes conhecidos por muitos de nós.

    Como já foi referido é um trabalho de evangelização que é necessário fazer todos os dias de modo a que mais programadores consigam perceber e aceitar as vantagens de desenvolver software segundo as melhores práticas.

    Um dos gurus que sigo regularmento, penso que é do conhecimento geral das pessoas que aqui deixaram um comentário é o Robert Cecil Martin, conhecido por Uncle Bob. Num dos seus muitos videos online sobre profissionalismo na nossa área ele fala sobre procedimentos de desenvolvimento que são completamente alienígenas no mundo SAP, como por exemplo desenvolvimento Ágil ou TDD.

    Na minha opinião o problema começa na base, na metodologia de desenvolvimento.
    Investigando um pouco sobre o tema, ou ouvindo o Uncle Bob, rapidamente me apercebo que a nossa Indústria, embora jovem, já começa a avançar sobre a melhor forma de produzir código utilizando metodologias ágeis, independentemente de qual se escolha.

    Para grande tristeza, em SAP, pelo menos em todos os clientes por onde passei, o conceito de metodologia de desenvolvimento nem sequer está presente, limitando-se os programadores a trabalhar como sempre foi feito em SAP, utilizando a metologia em cascata, muitas das vezes nem consciência que o estão a fazer. Ora está mais que provado que esta metodologia não ajuda à qualidade do código produzido e está fora de moda, mas infelizmente é a prática comum em equipas de desenvolvimento SAP.

    Infelizmente, eu nunca estive numa equipa que praticasse desenvolvimento ágil em SAP. Para mim, esta questão passa muito pelo responsável da equipa de desenvolvimento que se também ele procurar o profissionalismo deverá impor á administração e à equipa o desenvolvimento segundo estas práticas. Mas onde anda esse responsável? Continuo a minha busca pelo senhor.

    É claro que eu tento passar essas ideias aos meus colegas e responsáveis na esperança de mais alguém abraçar a ideia e quem sabe um dia consigo, por meio de motivar a equipa ou por ser reponsável por uma, mas esta é uma mudança na cultura de trabalho transversal a todas as equipas de projecto, e mesmo que a equipa de desenvolvimento esteja preparada para a mudança, se as outras equipas não estiverem, pura e simplesmente não é possível aplicar a metodologia Ágil.
    Dito isto, por curiosidade, quantos de voçês utilizam métodos de desenvolvimento ágil no vosso trabalho?

    Quanto ao TDD tenho tentado interiorizar o conceito o melhor que possa para começar a utilizar mas também este é uma mudança de paradigma no nosso modo de trabalho. No entanto, como está relacionado directamente com o trabalho produzido pessoalmente penso que depende de cada um a sua aplicação, sendo que lá está, num projecto em equipa seria mais inteligente que todos usassem.
    Fico à espera que saia um post de como aplicar TDD em ambiente SAP no bar8 já que o Erick abordou o tema :)

    Num dos videos do Uncle Bob, ele diz para a plateia:
    “Quantos de voçês utilizam o debug? Quantos de voçês sabem todos os atalhos e truques do debugger? Quem for um expert em debug significa que está a fazer o seu trabalho de forma errada porque o tempo de um programador deverá ser utilizado a produzir código que funcione e não a tentar encontrar bugs no código constantemente. Para utilizarem o debugger cada vez menos, nada melhor que aplicar TDD!”

    É certo que o mundo SAP é um mundo muito específico e que por causa de código negligente ou aplicações antigas temos que passar muito tempo no debug e apesar de me ter sentido visado com as palavras do senhor, eu que me orgulho de saber fazer malabarismos com o debug, não deixo de dar razão ao que ele diz, porque me faz sentido que tudo o que se faça, tenha um teste para se validar.
    Deixo então outra pergunta, quando de voçês utilizam TDD diariamente no vosso trabalho?

    Depois há toda a área de como escrever código correctamente, utilizando as melhores práticas e melhores principios mas a guerra precedimental VS OO ainda está tão presente nos dias correntes em ABAPers que se mostram tão resistentes à mudança o que também isso leva a que o código que é produzido não tenha a qualidade desejável.
    Neste ponto penso que as empresas deveriam ser mais exigentes quando contratam programadores, fazendo testes e questionando os entrevistados com exercicios práticos, coisa que nunca me pediram. Mas aqui entra a questão económica que o Furlan refere e que de facto é o impulsionador na nossa indústria.

    E o comentário já vai longo, mas de facto é um tema muito interessante e com muito para discutir.
    O que para mim é mais relevante é saber que não estou sózinho nesta demanda, que também há outros que procuram o profissionalismo porque por vezes uma pessoa sente-se muito sózinha neste processo de aprendizagem com muitos dos colegas ABAPers que vamos encontrando. No fundo, querer ser um pouco melhor hoje do que fomos ontem!

    Obrigado ao Abapinho, ao ABAP101 e ao Bar8 por todo o conhecimento que partilham e por nos mostrarem a luz!

    Um abraço

  7. Luís Filipe Diz:

    Bom dia Gurus,

    Em relação a este tema, na minha opinião o responsável máximo pelo mau código é o cliente que aceita o que o consultor lhe entrega sem questionar.

    O consultor pode ter ou não ter brio, pode ser júnior, pode não ter tempo para fazer melhor, mas se o cliente passar as ordens para produção, o cliente é responsável por não analisar o código.

    Já fiz projectos para clientes que reviram o código e pediram alterações como unassings a field-symbols, alteração de nomenclatura para estar de acordo com a deles. Tive que assinar um formulário, o user que pediu o projecto teve que assinar um formulário e só depois é que passou para produção. Também já estive em clientes que era uma “balburdia”, este tipo de clientes quer é os resultados ASAP e a todo o custo e não fazem revisão de nada, não querem gastar dinheiro em documentação, quem vem a trás que feche a porta e apague a luz.

    Por isso digo, o cliente é sempre o maior culpado do estado do seu sistema. Da mesma forma que nós cuidamos da nossa casa quando fazem instalações de internet, luz, pequenas obras, andamos sempre a controlar se o trabalho é bem feito, e no fim se aceitá-mos um trabalho de fraca qualidade, a culpa é nossa, o mesmo se passa nos sistemas dos clientes.

    Abraço.

  8. Nuno Seara Diz:

    Concordaria se….

    Digamos que para que o que sugeres fosse viável, era necessário que o mundo da programação, não apenas em Abap mas toda, preenchesse um número de requisitos que infelizmente não são cumpridos. Em circunstâncias ideais em que tivesses uma mistura de bom senso, profissionalismo, e ética, então aqui sim, estaríamos inteiramente de acordo. Contudo, na prática, as condições estão longe, muito longe de serem as ideais e quanto a avaliadores, poderei afirmar com toda a certeza que não só os exemplos deveriam vir de cima, ou seja, o código da casa mãe ser TOTALMENTE isento e irrepreensível como quem certifica e avalia não cometer os erros que vemos frequentemente, por vezes mesmo em programas standard com instruções que são precisamente as que um Code Inspector, uma simples SE30, indicam que não devemos utilizar.

    Mas quanto ao “faz o que eu digo mas não faças o que eu faço” falaremos mais adiante neste comentário. Em primeiro lugar, seria necessário que quem transmite a informação aos informáticos e aqui refiro-me concretamente quer a funcionais quer programadores, fosse conhecedor da realidade informática para poder ter sensibilidade quanto ao que pede e em que circunstâncias o faz. A realidade é que só muito raramente encontras pessoas a solicitarem aplicações para ERPs que tenham a noção exata do que é uma base de dados, de como se acede, o que leva a situações até mesmo hilariantes, como uma que presenciei nos primórdios do SAP, quando trabalhei com R2 e depois com R3, em que um responsável de projeto dizia que não podia ser, que a KNA1 não podia ter apenas o código de cliente como chave primária e que tinha de se alterar à medida do que entendia como necessário…. um engenheiro com curso concluído no tempo em que ainda nem havia computadores em Portugal mas que ainda assim achava que percebia de tudo. Ora, o que gostei no SAP e que caminha no sentido que dizes e comunga de certo modo com todas as boas práticas que vais sugerindo no teu blogue, é que o SAP acabou com os pseudo-gurus que sendo licenciados em tudo menos em algo relacionado com informática, passavam a vida a modificar especificações funcionais e técnicas, provocando alterações em chaves primárias de bases de dados com a consequente instabilidade dos programas. Na década de 90 era triste, caótico mesmo, estares tipo um mês a desenvolver uma aplicação para atualizar diversas tabelas criadas à parte, sem ser em ERPs e subitamente um superior hierárquico que nada entendesse de informática dizer que a chave primária de uma tabela tinha de ser alterada. O resultado era que os teus programas, que estavam impecáveis, deixavam de funcionar. Porém, o teu código já não podia ser feito de novo, tendo de o adaptar à nova realidade, correndo o risco de ficar uma lástima, porque entretanto tinhas o arranque do projeto que em teoria era inadiável. Com o SAP, não há diretores nem administradores a dizerem para alterar a chave primária do infotipo PA0000 ou da tabela de faturação de vendas VBRK. É assim porque é assim e mais nada. Porque é assim que tem de ser e a SAP tem toda a razão, felizmente que naquele tempo, o indivíduo a quem cheguei ouvir dizer que a KNA1 tinha de ser alterada acabou por dar a mão à palmatória e as coisas fizeram-se como seria natural, utilizando apenas o KUNNR.

    O segundo facto que pode prejudicar uma empresa é a ignorância de quem manda associado à falta de ética. Aqui não vou aprofundar muitio, embora os 20 anos de carreira em abap me permitissem fazê-lo, mas permite-me apenas uma observação. Imagina que um dia te pedem algo que não é legal e que, no percurso profissional, estando ainda no quase início, com 5 anos de Abap, por exemplo, tens escrito no teu contrato que na ausência e impossibilidade de contactar a chefia, que o chefe de abap e responsável pelo departamento és tu. Durante um período dessa natureza, és confrontado com um pedido de alteração o qual, em conversa com um advogado teu amigo, vens a apurar não ser legal, com o mesmo a sugerir-te que “te sintas mal” e te vás embora para casa, ou que digas que não tens tempo. Eventualmente, ainda que fosse uma mentira descarada, poderias dizer que não sabias sapscript apesar de nessa altura já trabalhares em sapscript há 5 anos. Agora, e se fizesses o que te pedissem, quais as consequências quer para uma empresa quer para ti, na medida em que a responsabilidade jurídica seria tua, pois na ausência do chefe, eras tu quem tomava decisões, logo, o responsável ? Sem mais comentários.

    Mais ainda, nós, programadores de abap ou outra coisa qualquer, não temos culpa nem a responsabilidade de um dia sermos apanhados num lugar em que os donos do sistema queiram ocultar a matéria-prima aos seus próprios colaboradores e até aos responsáveis máximos com a exceção de um ou dois, por exemplo. Imagina que te pedem um programa simples, embora trabalhoso, mas muito pouco ético. Supõe que, por receio de concorrência ou também de medidas legais, te pedem para omitir as descrições de materiais, bem como quantidades, unidades de medida, peso e volume. Imagina que te pedem um programa para ires a todas as tabelas do SAP em MM, SD, etc., e onde existirem descrições de materiais ou componentes, meteres asteriscos. onde existirem quantidades ou valores em moeda, colocares a zero, metendo também apenas UN em todas as unidades de medida, mesmo que sejam gramas, litros, etc. Isto em desenvolvimento e qualidade, claro, Em produção, com diversas delegações espalhadas pelo mundo, só 2 de mais de 10 administradores terão acesso a essa informação. Agora pergunto-te: com que cara é que os teus colegas de abap te iriam olhar se soubessem que o mentor da “bomba” tivesses sido tu ao tentarem testar, quer em desenvolvimento quer em qualidade, um programa de stocks, um relatório de vendas, uma guia de remessa, uma fatura, etc., quaissquer relatórios ou formulários que tivessem dados manipulados daquela forma ? Mas testavas o quê e como ? Stocks por material, mas… que material ? E que stocks ? como é que podem estar certos ? E qual o resultado das transações standard como a MB52, por exemplo, se os teus materiais estiverem todos com asteriscos e valores a zero ? O que está certo nesse SAP em dev e em qualidade ? O que está errado ? Deixaram de saber no preciso momento em que o programa que te pediram correu e porquẽ ? Eventualmente uso de produtos ilegais no fabrico de certas coisas ? Ou medo da concorrência ao ponto da paranóia ? Quem sabe se alguns dos abaps com quem já te cruzaste no teu percurso não tiveram já de codificar coisas destas A PEDIDO. Como ficarão as aplicações desenvolvidas pelos outros abaps a partir deste momento ? Pois…. e vamos responsabilizar o Abap ? Não me parece.

    Finalmente, temos a gestão de recursos humanos. Gerir é uma arte, simplesmente muitos, apesar de o saberem, podem optar pela via mais fácil e lemos isso nos jornais todos os dias. Entre um excelente profissional como o autor deste blogue ou o filho de um empresário que dê muitos e bons negócios a uma empresa, o bom gestor vai escolher o Nuno Godinho, o aprendiz irá optar pelo filho do empresário ou do político, etc., mesmo que este não saiba trabalhar ou que, mais grave ainda, nem nunca venha a saber e termine a carreira profissional como dizes, sem nunca saber trabalhar apesar de pensar que sim. Porém, no país em que estamos inseridos, ao vermos as andanças entre parlamento e empresas, os que hoje são ministros e amanhã estão a mandar na empresa X ou Y ou são conselheiros ou os chamados administradores não executivos, percebemos que nem sempre os melhores profissionais são chamados para trabalhar. Tu, eu, somos profissionais de Abap porque gostamos. Apesar de ter bastantes anos de experiência, leio sempre com gosto o teu blogue porque gosto de aprender, não foi o meu pai ou o tio ou um encarregado de educação que me obrigaram a ir para abap para eu ter um modo de vida mas sim porque gosto, porque quis aprender e tornar-me programador. E nisto, nada como um bom livro para se aprender a fazer contratações. Em “Os códigos e as operações dos espiões portugueses” aprendemos, entre muitas coisas, como não se devem fazer contratações. Diz-nos que para as informações, por exemplo, nem sempre são escolhidas as pessoas com vocação, mas o filho do magistrado, o irmão do deputado, a secretária do minsitro, etc. E, por vezes, o que lemos nas notícias sobre alguns operacionais, nem sempre é o que um profissional gostaria de ouvir dizer de si. Porque para tudo na vida, é preciso vontade, gosto por programar, não pelo que os outros achariam que somos bons a fazer mas por aquilo em que somos mesmo bons a fazer. Tal como dizes, muitos ignoram que não sabem programar, acrescentando eu que muitos não sabem que ao contratarem por mera estratégia financeira e não por mérito e vocação do funcionário, o resultado será aquilo que dizes, indivíduos cujo trabalho servirá apenas para que outros como tu o venham a corrigir um dia mais tarde. Gerir é uma arte, tal como programar. Infelizmente, programar e gerir não são como tocar piano, em que aí são as mãos do pianista e a alma dele que tocam e não adianta ser-se filho do empresário ou do deputado, do ministro, etc., pois reza a História de que quem tem unhas é que toca guitarra. É pena que as escolhas de abap não sejam como quem escolhe um pianista para um concerto, porque aí o cliente, o ouvinte, é soberano e é como ele quer e gosta de comprar para ouvir.

    Tens ainda o cenário em que existindo concorrência e choque de interesses, o teu trabalho possa ser alvo de boicote, eventualmente até uma triangulação no sentido de uma empresa concorrente roubar um projeto a outra provocando um escândalo com a tua pessoa, boicotando-te o trabalho a fim de te colocar em xeque perante um cliente, com o objetivo de induzir o cliente a optar pela outra empresa que não a tua.

    Finalmente, temos de ver a capacidade organizativa e o sentido de responsabilidade de quem pede. Desconfio sempre de tudo o que é tão urgente, mas tão urgente que… olha por acaso acaba por ir para produção 3 ou 4 meses depois, seja abap, seja Natural, Cobol, C#, Java, não interessa qual. E sobretudo quando alguém te obrigue a emendar algo rapidamente para que depois acabes por ver que o que era tão urgente afinal só foi passado para produção meses depois, sem que te tivessem deixado corrigir como devias, porque na realidade se o fizesses, então sim, terias de fazer a aplicação de novo e em escassas horas isso raramente será possível.

    Se, num futuro, conseguirmos reunir todas as condições para que um programador Abap tenha todos os elementos essenciais para levar a cabo as suas tarefas e, sendo ele o criador do código de raíz, ainda assim só faça asneiras, concordaria que fosse responsabilizado, embora saibamos que isso já acontece na prática, visto que ou são despedidos ou não são promovidos, estagnam na carreira, mudam-nos de profissão, etc. Indemnizações já seria caso para estabelecermos uma Ordem dos Informáticos com um batalhão de entendidos em Informática e Direito e então sim, analisando tudo ao pormenor, a forma como os trabalhos foram entregues, as condições para que fossem feitos, etc., se tendo todas as condições e mais alguma o programador só cometesse erros, nessa circunstância poderia sofrer consequências, algo que seria conjugado com as companhias de seguros. Não te esqueças, a título de exemplo, que um médico infelizmente pode matar e que só muito raramente sofre consequẽncias reais do seu comportamento, apesar de existir uma Ordem dos Médicos. E aqui então nem deveriam existir margens para dúvidas.

    No entanto, artigos como o teu são sempre interessantes, pois constituem sempre um ponto de reflexão, algo em que todos devem meditar, desde juniores a seniores e sobretudo arquitectos de informática, no sentido de trabalharem para a excelência de resultados. Obrigado pela opinião e continuação de um bom percurso profissional cheio de sucesso como mereces !

    Nuno Seara

  9. Erick Carvalho Diz:

    Imagino que quando o Sérgio Fraga terminou de escrever seu texto estava uns 2kg mais leve com esse desabafo. kkkkk

    Compartilho de tudo o que você escreveu e concordo muito com o Luís Filipe, acredito que o cliente se qualificando mais, e não apenas terceirizando de forma irresponsável toda a TI para consultorias que até entendem da área de negócio mas tecnicamente são muito fracas, possa ser algo benéfico.

    E pode deixar Sérgio Fraga sempre que pode o Flávio Furlan sempre me lembra sobre escrever um post sobre TDD, quem sabe em breve!

    Valeu!

  10. Nuno Godinho Diz:

    Obrigado pelas partilhas!

    Concordei com boa parte do que todos disseram. É de facto um problema sem solução fácil.

    O código que tenho encontrado neste cliente é tão mau que não resisti a lançar este desabafo.

    Tendo em conta que sou freelancer não me devia queixar porque, na práctica, quanto mais confuso e mau for o código mais tempo vou demorar a trabalhar nele e mais horas vou ter de facturar ao cliente :) :) :) Mas felizmente não penso assim. Estar rodeado de código de qualidade é muito mais estimulante e motivador.

    Curiosamente das coisas que mais gosto de fazer é algo que muitos odeiam: pegar num programa mau e reescrevê-lo. Infelizmente quase nunca é possível encontrar clientes que queiram investir em melhorar a qualidade do código já existente.

    Ok, ok, sei que boa parte das propostas que fiz neste artigo são inviáveis ou insuficientes. Mas há pelo menos uma coisa relativamente simples que se poderia fazer (que aliás em vários clientes já se faz) e que faria uma diferença substancial: ensinar os clientes que devem sempre contratar uma empresa A para desenvolver código e outra empresa B para fazer controlo de qualidade a esse código. Este cenário será talvez o suficiente para, pelo menos, obrigar os programadores ABAP a terem um pouco mais de preocupação com a qualidade do que fazem pois sabem que alguém o vai rever com olhos críticos.

    Nuno

Deixe um comentário


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).