Oldbooks

Esses novos netbooks são muito práticos, mas não são realmente uma novidade. Em 1988, a Cambridge Computer Ltd lançou o Z88. Ele tinha uma pequena tela LCD de 640 x 64 pontos, 32KB de RAM e 128KB de ROM. No ROM estavam o sistema operacional e 5 aplicações (diário, editor de textos com planilha, linguagem BBC BASIC, emulador de terminal VT52 e um editor de configurações de impressão). Ele podia ser expandido até 4MB (512KB para ROM e 3,5MB para RAM), o que era muito naquele tempo.

Ele ligava instantaneamente (como todos os micros de 8 bits) e usava 4 pilhas AA, que podiam durar até 20 horas!

O preço de lançamento era 199,95 libras, que hoje seriam 400 libras ou R$1.060; praticamente o mesmo valor dos netbooks modernos. Não havia wi-fi nem internet e os gráficos eram limitados, então o público dele era mais restrito. Mesmo assim, por ser tão prático e tão econômico com as baterias (ele tinha um processador Z80A a 3,2768 MHz), ele ainda tem muitos fãs.

Mesmo hoje, seria uma máquina muito útil para digitar textos. E o teclado é surpreendentemente parecido com os atuais.

Carga produtiva

O ápice da esquizofenia gerencial por mim presenciada foi o momento em que fui compelido a procurar atividades para cadastrar, mesmo não havendo nenhum projeto a executar. Num mundo sano, teriam me dispensado pelo dia ou pela semana. Mas parece que é fundamental cumprir a carga horária. Logo, eu devo produzir horas!

Paul Graham escreveu que as empresas têm horários de trabalho porque não sabem medir produtividade. Então, como não sabem se os funcionários estão produzindo, elas tentam ao menos impedir que façam algo horripilante como se divertir, ler um livro ou dormir. Felicidade e trabalho devem ser incompatíveis.

Acho que um bom primeiro passo seria trocar a expressão "carga horária" por "carga produtiva". Tendo produzido o que deveria, tanto chefe como empregado deveriam ficar bastante felizes.

Num projeto particularmente complicado, eu tinha um contrato por atividade. A cada passo completado, uma parcela do meu pagamento era liberado. O gerente deixou bastante claro que não liberaria os pagamentos se não cumpríssemos as metas. Pois não só as cumprimos, como nos adiantamos; a equipe era realmente boa. Como prêmio, fomos compelidos a passar a cumprir horas. Qual seria o contrato desse gerente? Devia haver um bônus por má vontade produzida.

E vejo que o resultado disso tudo é que muita gente apenas vende tempo, compra tempo, gasta tempo, conta os dias para se aposentar. Melhorar a qualidade do trabalho, fazer mais com menos, servir melhor o cliente, ganhar mais dinheiro, viver melhor: tudo acaba sendo esquecido.

Produtividade

Tem certos hábitos do dia-a-dia que nos prejudicam e sequer percebemos. No Brasil, um deles é ter o almoço como principal refeição. E isso é um grande problema quando ocorre em conjunto com uma carga horária de trabalho excessiva.

Por trabalharmos 44 horas por dia, temos que chegar cedo e sair tarde. Os gringos entram às 9h e saem às 17h. Eles mal almoçam; fazem apenas um lanche rápido. A principal refeição deles é o café-da-manhã. Já que estamos nisso, é bom ressaltar que as 40h deles incluem o almoço; pela mesma métrica, os brasileiros têm jornada de 49h, não 44h.

Pois, eu não posso falar pelos outros, mas o meu momento de menor concentração é a manhã. Eu até tenho bastante energia, mas tenho pouca atenção. Vejo que muita gente sequer tem energia pelas manhãs.

E o que acontece quando estamos entrando num período de maior ativação dos neurônios? Comemos uma farta refeição e mandamos todo o sangue para o ventre. Não é das atitudes mais inteligentes.

Eu proponho adaptar o estilo dos gringos. Reduz-se a carga horária para 40h e flexibiliza-se o horário de almoço. Meia-hora para quem quiser comer pouco e sair cedo e 1h30 para quem quiser continuar comendo muito (e que tirem uma sesta!). Os primeiros sairão às 17h30 e os comilões sairão às 18h30, supondo que a jornada tenha começado às 9h.

Entrando mais tarde, é possível ter um café da manhã mais nutritivo e concidir a digestão com o período de menor atenção. Otimizam-se as tardes!

Essa conversa de que diminuir a carga horária vai diminuir a competitividade do Brasil é conversa para boi gordo dormir. Muito mais inteligente seria admitir que pessoas não são máquinas e que é preciso organizar o dia conforme seus ciclos.

Velhas ferramentas

Algumas velhas ferramentas continuam úteis mesmo depois da aparição de modernidades muito mais sofisticadas. A linguagem Tcl/Tk surgiu um 1988 e tive o primeiro contato com ela por volta de 1996.

Ela é uma linguagem muito simples, projetada para facilitar a vida de quem quer montar uma interface gráfica para um programa ou oferecer uma linguagem de programação simples para um sistema.

Existem alternativas muito mais sofisticadas, como Perl ou Python, mas o Tcl/Tk tem uma grande vantagem: além de ser portável, é muito simples gerar um executável para Windows. Ela está sempre presente em todas as plataformas *nix. Eu já vi um Unix sem um compilador C, mas nunca vi um sem Tcl/Tk.

Em Tcl/Tk, tudo é um comando seguido de parâmetros separados por espaços.

comando parm1 parm2 parm3...

Até mesmo as estruturas de controle são comandos. O if é um comando cujo primeiro parâmetro é uma condição, o segundo uma ação a executar se a condição for verdadeira, etc. É fácil escrever um comando em C e adicioná-lo ao ambiente.

Pois, há pouco precisei de um find com expressão regular no Windows, como no Linux. Eu podia ter procurado o find do GNU, mas resolvi brincar um pouco com o Tcl.

O resultado foi muito mais simples do que eu esperava:

if {$argc<2} {
  puts "Usage: find dir regexp";
  exit
}

set dir [lindex $argv 0]
set re [lindex $argv 1]

proc find {filename re} {
  set total 0
  if {[regexp $re $filename]>0} {
    puts $filename
    incr total
  }
  if {[file isdirectory $filename]>0} {
    set files [glob "$filename/*"]
    foreach f $files {
      catch { incr total [find $f $re] }
    }
  }
  return $total
}
puts "[find $dir $re] files"

Esse pequeno programa recebe dois parâmetros: um diretório e uma expressão regular. Ele percorre os diretórios recursivamente (a partir do indicado) e vai imprimindo na tela os nomes dos arquivos que são reconhecidos pela expressão regular. No fim, ele ainda diz quantos arquivos foram encontrados. Por exemplo:

find C:\Windows\ .*dll

Testei-o no Linux e ele funcionou sem nenhuma modificação, coisa que seria difícil, mesmo para o Java. O executável tem cerca de 1,5MB. É um pouco grande, mas a maior parte se deve ao interpretador, que é empacotado junto com o programa. Portanto, programas maiores não devem crescer muito de tamanho. De qualquer forma, é muito mais prático que forçar o usuário a instalar o Java Runtime (uns 15MB) ou o Perl (uns 5MB).

Não-palavra do momento: capabilidade

O ramo da informática é rico em anglicismos, porque boa parte da tecnologia vem dos gringos mesmo. Mas também há uma falsa criatividade que constantemente aflora: pessoas que não conhecem sua própria língua são as primeiras a adotar barbaridades como capabilidade.

Na música, usam-se termos italianos há séculos, mas não para substituir termos simples do dia-a-dia. Se alguém quiser usar software, hardware, mouse, etc., que seja, mas não vamos começar a escrever high, fast e morning.

O que há de errado em usar "capacidade"? Nada. Mas com capabilidade há, porque capabilidade está para capar assim como amabilidade está para amar. Geometricamente provado está que a palavra não serve para o fim proposto.

Há também um motivo histórico para não usar o termo! O Webster me diz que capability entrou no inglês em 1587, quando o português já estava mais que estabelecido. Os ingleses o copiaram do francês e os franceses já esqueceram de onde o tiraram. A citação mais antiga no CNRTL (Centre National de Ressources Textuelles et Lexicales) é de 1350. Em 1350 Portugal já fazia muito cozido alentejano.

Pelo menos com esta palavra não somos os únicos culpados, porque os engenheiros também a usam bastante. É cômico que gente com tanta habilidade com os números tenha tanta dificuldade com as letras.

Então, tenha respeito com sua língua e use a palavra certa: capacidade.

Armadilha

A comissão de formatura foi um empreendimento do qual não participei muito, porque sou avesso a cerimônias. Sempre tenho a impressão de estar num documentário da National Geographic: "o estudante, vestindo a tradicional toga cerimonial, recebe o diploma, símbolo de seu novo status no clã".

Na minha, votei a professora de Lisp para paraninfa. A aula dela tinha sido muito interessante e divertida, mesmo com os parênteses todos.

O alfa da comissão, sem medir os passos, perguntou: "Por quê? Dormiste com ela?".

Nem me preocupei em expor meus motivos. Quando chegou a vez do engraçadinho, ele propôs o professor de Arquitetura de Computadores, que também era um excelente professor e um sujeito divertido.

A resposta saiu sem que eu precisasse perguntá-la.

Inspiração

Um dos compositores mais divertidos é Rossini. As aberturas das óperas dele colocam um sorriso na cara do metaleiro mais tatuado.

Ele descreveu o processo criativo dele assim:

"Espero até a tarde da véspera da Prima (primeira noite). Nada melhor para excitar a inspiração que a presença de um copista esperando pelo seu trabalho e o desespero de um empresário arrancando os cabelos. Em meu tempo, todos os empresários eram carecas como a palma da mão aos 30 anos de idade."

Numa dessas tardes, o empresário o colocou no segundo piso de uma casa, perto da janela. A orquestra ensaiava no pátio abaixo enquanto ele escrevia as partituras. O empresário deu ordens que, faltando partituras, ele fosse jogado ao pátio.

Esses momentos são bem conhecidos na informática também. E como empresários, os gerentes pouco podem fazer, exceto desesperar-se e arrancar os cabelos.

Prokofiev compôs na União Soviética durante a Segunda Guerra. No dia anterior à derrota dos alemães, ele estreiou uma sinfonia em Moscou. Isso dá novo sentido a trabalhar sob pressão!

E isso, por analogia, diz algo sobre a natureza do trabalho de programação. Os programadores não são substituíveis nem previsíveis. X horas de trabalho não resultam, sistematicamente, em Y linhas de código. Se eles têm talento, entregam a obra a tempo. Se não são competetentes o suficiente para a tarefa, não entregam um produto satisfatório nunca. Em alguns casos, não chegam a entregar qualquer coisa. Alguns conseguem entregar um produto no prazo justamente porque escrevem menos código, talvez porque saibam escolher a ferramenta certa.

Programadores barrocos abundam. Eles escrevem linhas e mais linhas de código maravilhoso e pronto para ser aproveitado no próximo projeto (desde que seja igual a este). Utilizam todos os frameworks disponíveis e parametrizam até os parâmetros com XML.

Rossini e Prokofiev são econômicos. Eles colocam a nota certa no momento exato em que ela vai dizer algo importante. Ambos usam muitas pausas e sabem usar os instrumentos certos para cada passagem. Os compositores barrocos, como os programadores prolixos, são pesados, porque usam muitas notas e dizem pouco.

Rossini tinha vários projetos concorrentes e não hesitou em usar para Barbieri algo que tinha preparado para uma ópera chamada Elisabetta. O resultado, segundo ele, "agradou o público". Prokofiev agradava o público, mas não aos burocratas do Partido Comunista que, como alguns gerentes de hoje, não tinham humor nem senso artístico.

Pérolas dos usuários II

Trocar emails muito extensos com usuários que sofrem de deficit de atenção é sempre um martírio.

Certa vez, após colocar em funcionamento várias melhorias num sistema para a Internet, enviei um email detalhando uma a uma as modificações e informando a senha nova.

O cliente respondia: "e a função X? Também não estou conseguindo entrar com a senha". E eu ia encolhendo minha lista de alterações e reforçando: "alterei a senha para *******". Foi um embate digno de um curso de Lisp ou Prolog.

Quando finalmente restou apenas a questão da senha, o email foi curto: "a nova senha é *******"

E a resposta também: "a senha antiga não está funcionando".

Tive que ceder e colocar de volta a "senha certa".

Um Método Lúdico: diagrama Mickey Mouse

Na maior parte dos casos de uso, o fundamental pode ser reduzido a três questões:

1. De onde vêm os dados?
2. O que se deve fazer com eles?
3. Onde devem ser gravados?

A maior parte dos analistas sabe disso de forma intuitiva, mas como nunca lhes foi apresentado de forma clara, o tratam com descaso.

Já vi casos de uso com enunciados como este:

Ao preço, somam-se a margem de lucro e os impostos.

Parece simples, mas onde é que eu encontro o preço? E a margem e os impostos? Como é feito o cálculo? E o que eu faço com o resultado?

Neste exemplo em particular, para dificultar, a base de dados tinha tabelas e colunas com nomes do tipo CSX0023. O resultado é que o programador acaba tendo que fazer a análise novamente.

Então, para resolver esta questão, Um Método Lúdico apresenta o diagrama Mickey Mouse:
Também é chamado de diagrama do alumbramento.

A idéia é simples:

1. No círculo da esquerda, descreve-se a origem dos dados (o nome das tabelas, dos arquivos, etc.);
2. No círculo do meio, descreve-se o que fazer com os dados;
3. No da direita, indica-se onde gravar os resultados.

O analista deve entregar o diagrama com um sorriso nos lábios e um pirulito na mão esquerda.

Weltschmerz

Essa palavra é um daqueles termos psico-filosóficos do alemão que são intraduzíveis e justificam a teoria de que aquela seja a melhor língua para filosofar. Pois, uma tradução literal seria algo como "dor-do-mundo". Ai.

Ela representa a dor que uma pessoa sente ao perceber que a realidade não condiz com uma noção pré-concebida e idealizada.

Na informática, há muitas oportunidades para Weltschmerz. Há o momento em que o analista percebe que não vai conseguir tirar os requisitos do cliente. Há também o momento em que o cliente percebe que o sistema não vair sair tão barato quanto o estagiário achou que seria.

Há uma classe de profissionais cujos indivíduos parecem, numa proporção assutadora, incapazes de compreender o conceito: os gerentes. Não que todos sejam assim (alguns são excelentes), mas há um número surpreendente que não entende o desconexo entre a planilha do Project e o projeto.

Acho que o problema nasce na seleção e se agrava no cursinho de MBA. Pelo Princípio de Dilbert, os piores analistas são escolhidos para gerenciar. E um bom analista é aquele que sabe analisar e sintetizar a realidade.

Mais adiante, no curso de MBA, os candidatos à glória gerencial são apresentados a variados exercícios do tipo "Você tem uma semana para construir uma ponte e as atividades necessárias são estas...".

A grande falha aí está em que não é possível construir uma ponte em uma semana. É um exercício teórico, mas se for repetido o suficiente, o aluno adquirirá fé nos seus superpoderes na medida da sugestionabilidade de sua mente. Dá-me uma planilha do Project, que eu alavanco o mundo!

Isso me faz lembrar com tristeza as aulas de modelo OSI na faculdade. Que reconfortante gastar um semestre analisando as 7 camadas do apocalipse, sabendo que no mundo exterior a probabilidade de achar algo diferente de TCP/IP seria quase nula. A de achar uma rede OSI então... Ó Weltschmerz!

Insegurança forte

Segurança é uma coisa difícil de acertar hoje em dia. Os sistemas operacionais são complicados, as redes são grandes e os softwares são cheios de furos. A criptografia tem matemática cabeluda e é fácil deixar uma brecha.

Mesmo assim, tem certos problemas que a gente vê de longe. Uma já defunta empresa tinha um sistema interno que exigia uma senha. Só uma senha. O usuário, acredite, era implícito.

Obviamente, um problema surgiria quando uma pessoa escolhesse uma senha que já havia sido registrada. Mas o autor da obra antecipou os problemas! Ao tentar introduzir uma senha repetida, o sistema informava ao usuário que:

Essa senha já existe. Tente outra.

Pronto, agora tenho duas.

Entrevista precoce

Entrevistas são daquelas coisas que os cursos que "preparam para o mercado" ignoram completamente, mesmo sendo fundamentais para o sucesso de uma carreira.

Um fator crítico é não ser franco demais. A verdade é que os candidatos vestidos de terno têm mais sucesso que os de bermuda. E os penteados mais que os descabelados.

Pois, certa vez tive que enfrentar a franqueza desconcertante de uma bela entrevistadora. Assim que entrei na sala, ela informou:

"Já preenchemos a vaga, só queríamos conversar contigo."

Passei meia hora pensando se deveria convidar a moça para alguma coisa depois do trabalho. Afinal, estávamos lá só para conversar. Meu instinto profissional prevaleceu e eu mantive a conversa séria.

Pensando bem, não sei o que ser profissional tem a ver com convidar uma mulher bonita para um encontro. E eu nunca cheguei a trabalhar naquela empresa mesmo. Então, a lição fundamental deste evento é:

Se a entrevistadora for interessante, não hesite em convidá-la para sair.

Pronto, isso não ensinam na faculdade.

Pérolas dos usuários

Certo dia, uma senhora liga para a empresa e reclama que o sistema está lento. O suporte envia uma moça para averiguar o que se passa.

Chegando lá, ela descobre que a empresa na qual a senhora trabalha tem internet banda larga. Promissor, mas suspeito.

Tudo parece estar funcionando bem, então a moça pede à senhora que mostre como ela usa o sistema.

A senhora então desconecta a banda larga, puxa um fio telefônico até o micro e inicia uma conexão discada.