A demo é do "demo"

Bem, eu já mencionei que trabalho aqui na Celesc, mas creio que nunca disse exatamente o que eu faço. Bem, nem vai ser hoje, porque eu acabo fazendo um monte de coisas, hehehe XD.

Uma das tarefas a qual fui designado, foi acompanhar a implantação do novo sistema de suprimentos. Este sistema, chamado Alphalinc, foi comprado/licenciado pela Celesc, e é originalmente desenvolvido pela Disclinc, empresa australiana.

Este sistema, originalmente desenvolvido como sendo um gerenciador de cadeia de suprimentos, está sendo atualmente sendo adequado para o uso aqui na Celesc, pois como empresa 'pública', tem uma série de peculiaridades com relação ao resto do mundo. Estas modificações, o pessoal da empresa, da própria Disclinc-br e sua parceira E-biz, chamam de "customizações".

Só para esclarecer, meu papel neste projeto não é exatamente de desenvolvedor, arquiteto, gerente, ou coisa alguma. Na verdade, eu até ajudo alguma coisa como desenvolvedor, mas a minha verdadeira atribuição é "ficar de olho", já que por um bom tempo, ninguém do DPTI (o departamento de informática) sabia o que acontecia.

(Bem, daí dá pra ver que a Celesc não tem cultura de trabalhar em projetos)

Pois bem, como todo projeto, este novo sistema de suprimentos está atrasado. Opinião pessoal (que já expressei para o mundo todo): está muuuuuuito atrasado, e nem de longe termina no prazo (que por acaso, é outubro).

Hoje termina uma demonstração deste novo sistema, para alguns usuários.

IMHO, esta demonstração foi um pouco a frente do tempo, já que para o usuário final, o que importa são as telas funcionando do jeito que ele quer. Como muitos módulos ainda não foram terminados, muita coisa falta. E para o usuário, não importa muito se a tela está 75% da sua funcionalidade original pronta: ele vai se focar nos 25% que faltam.

Juntando isso com algumas falhas na especificação, polêmicas entre e com usuários, o que sai? Uma demonstração (demo) que deixa usuários frustrados, desenvolvedores tensos e gerentes estressados.

OK, pra ser justo, não foi (ou está sendo, pois escrevo este post durante a apresentação) um pandemônio. E a frustração dos usuários também não foi tão grande (feliz ou infelizmente, com o passar do tempo, as expectativas dos usuários aqui foram ficando cada vez menores).

Erros que identifiquei, e que podem ser úteis para algum leitor deste nem tanto humilde blog:

- pressa em mostrar serviço: se você tem diversos módulos, e todos os módulos não estão completos (mesmo que faltem apenas 10 ou 5%), vc não tem NADA completo. Não se apresse, complete o que tem que ser completado, e depois mostre para o usuário.

- tentar entregar vários módulos de uma vez: entregue poucos módulos, mas entregue-os bem feitos. Nem tudo pode ser modularizado de forma a ficar funcional, mas muitas coisas podem ser feitas. Muitos módulos são interdependentes, neste caso, talvez modularizar ainda mais a sua arquitetura seja interessante. Em vez de um módulo monstruoso, refatore. As vezes não dá, mas isso não é regra.

- espera para entregar algo palpável para o usuário: entregue aos poucos, mas sempre - seja ágil, adote uma metodologia de entregas frequentes, mesmo que estes módulos sejam pequenos (mas devem ser funcionais). Isso é uma mão na roda na hora de identificar erros de especificação (pq o usuário vai chiar), um dos erros mais custosos no desenvolvimento.

Vamos às conclusões e considerações finais.

Listei acima alguns erros do projeto. Veja bem, eles NÃO SÃO OS ÚNICOS PROBLEMAS!! Mas são problemas que nós (da área de informática como um todo), poderíamos ter trabalhado. Muitos outros problemas, que não irei comentar aqui (porque este post iria ficar MUUUUITO maior do que já está), estão fora do nosso alcance.

Este projeto vai vingar? Não sei, e ainda não desenvolvi poderes pra saber o futuro (apesar de eu ser japonês rechonchudo, não tenho nem katana nem dobro o espaço-tempo - se não entendeu, assista Heroes).

Talvez daqui a uns seis meses, eu faça outro post relatando um caso de sucesso. Ou não...

Operadores

Já faz algum tempo que descobri algo no mínimo peculiar sobre a linguagem do Caché, e hoje vou publicar aqui. Não é necessariamente um bug, pois está devidamente registrado na documentação, mas que é algo não natural, isso é.

Se vc se lembra das aulas de matemática do primeiro grau, deve acertar quanto é a expressão 1 + 2 * 3. Se vc respondeu 9, deve ter matado aula, pois a resposta é 7. Isso porque na matemática, o operador de multiplicação tem precedência sobre o operador de adição, ou seja, se você não coloca parênteses (que é o meio "certo" de dizer qual operação vc quer que seja efetuada primeiro), vc deve multiplicar antes de somar.

Bem, a maioria das linguagens que eu conheço leva em conta a matemática (o que é absolutamente normal, visto que a computação como ciência nasceu da matemática).

Exemplos:
No oracle, faça um SELECT 1 + 2 * 3 FROM DUAL, a resposta é 7. Em java, c/c++, delphi/pascal, a resposta também é 7.

Em Caché Object Script, a resposta é 9. Experimente abrir um terminal do Caché, e fazer um WRITE 1 + 2 * 3, a resposta é 9.

Isso porque essa linguagem não segue o padrão matemático, muito menos o padrão da maioria das linguagens. OK, questão de implementação, e está também na documentação, mas não deixo de ver isso com maus olhos. Especialmente se vc está em conformidade com o resto do mundo, acostumado com a precedência certa dos operadores (por "certo", quero dizer conforme a matemática).

Tudo bem, é questão de escolha da linguagem seguir ou não qualquer padrão. Mas isso pode produzir alguns erros. Eu fui atentar para esse fato porque um loop meu estava estourando os limites. Acostumado a programar em outras linguagens, não achava que uma simples continha pudesse estar dando errado. Depois de verificar o algoritmo umas duas vezes, uma luz se acendeu, e resolvi fazer um teste, e descobri que devia ter colocado explicitamente parênteses na expressão. Depois chequei a documentação, e realmente estava lá: a precedência é estritamente da esquerda para a direita.

Mas por que os designers da linguagem fizeram esta escolha? Será que eles queriam ser "cool", diferentes do resto do mundo, ou seriam eles rebeldes com ou sem causa?

Apesar de serem explicações, acredito que não. Acredito que tenha sido por causa implementação da execução do script, que é mais fácil de implementar quando não se considera precedência matemática. Ou seja: preguiça. A lei do menor esforço que move este mundo =P

Se bem que mesmo sendo uma linguagem interpretada, de script, é muito desculpa. Javascript também não vai contra o mundo. Experimenta um 'document.write(1 + 2 * 3)', que ele te devolve 7.

U_U

Juros baixinhos

Bem, quem não mora em Santa Catarina, não deve ter visto a campanha do Besc, o banco estadual (que foi federalizado e que agora está num rolo só, mas esse não é o ponto de discussão). Dentro desta campanha publicitária, que produziu alguns dos melhores comerciais que eu vi em um bom tempo, um dos comerciais (um dos últimos), me fez refletir um pouco, e exercer um paralelo com outras áreas da nossa vida, em especial, a nossa área de informática (não, eu não gosto do termo TI, mas eu acabo usando =/).

O referido comercial pode ser visto no youtube, e eu coloco ele aqui embaixo. Assistam ele antes de continuarem a leitura aqui.



Agora que já devem ter assistido o vídeo, vamos ao paralelo.

Assim como o gerente do banco que fica tentando "mascarar" os juros, temos vendedores e lobistas na área de informática que tentam de toda maneira, empurrar um produto ou serviço, elevando os pontos positivos às alturas, e "esquecendo" de mencionar alguma inconformidade e/ou problema que este venha a ter na empresa, tal como a integração com outros sistemas.

Isso é até de certo ponto, normal e aceitável (não é crime, mas eu pessoalmente acho imoral, mas eu geralmente sou minoria...), o problema é quando esses vendedores/consultores conversam com o pessoal que não é da área de informática, usuários finais, mas que têm poder de decisão, tal como diretores e presidentes.

Por exemplo, no organograma aqui da Celesc, o departamento de informática, vulgo DPTI, está subordinado a diretoria de assuntos financeiros. O que isso quer dizer na prática? Que quem toma decisões pra valer é o diretor financeiro, e que o chefe de TI da empresa, tem poderes (muito) limitados. "Nas empresas onde a área de TI está subordinada à área financeira, os sistemas são um pandemônio". Essa frase (ou melhor, algo parecido, já que eu não lembro palavra por palavra), eu li em algum lugar que eu também não lembro, mas que ilustra uma verdade, pelo menos por aqui.

E então voltamos a situação do nosso gerente de "juros baixos". Representantes, vendedores, lobistas mesmo, fazendo um grande alarde, omitindo "aspectos", e tentando fazer a cabeça de diretores e usuários (isso quando não envolvemos alguns "mimos" ou presentinhos, o que já é caso pra polícia). Se você já não viu essa cena, prepare-se, porque uma hora ou outra, vai. "Do you hear it, Mr. Anderson? It´s the sound of inevitability".

Nestas horas, mesmo o CIO com menos poder, mesmo sem ter CIO no crachá, deveria assumir uma postura. Uma postura que é não influenciar a decisão, mas apresentar TODOS os fatos, como eles são. Se mesmo cientes, os comandantes decidirem pelos "jurinhos mais baixos", aí temos outra discussão, por vezes técnica, mas muitas vezes ética.

Este é um assunto que rende "muito pano pra manga", mas me atenho por aqui.

(P.S.: Um último comentário: aqui não temos um chefe de TI, e sim uma chefa, o que é um fato muito legal. Ter uma mulher comandando TI, que ainda é uma área majoritariamente masculina, é uma alegria para mim, que ando cansado de tanto enxergar testosterona em TI =D)