José Buscapé

Cadeia de felicidade

2006-09-26T10:21:00.000-07:00

Esses dias atrás tivemos uma tremenda carga de trabalho aqui. Horas estressantes cheias de "não dá", "estamos perdidos" e outras frases que não dá pra publicar em um blog inocente.

Passada a carga, sistema entregue, o cliente sorri de orelha a orelha. Então o gerente sorri e faz piada, aí eu sorrio e me sinto bem. Toda a pressão se foi, consigo até endireitar as costas na cadeira.

Essa é mais uma das vezes que vejo esse efeito "cadeia de felicidade", cliente feliz, gerente feliz, desenvolvedor feliz. Não sei se é pelo alívio de pressão, se é pelo prazer de ouvir o cliente elogiar ou o quê. Ignoro a causa, mas percebo o efeito.

Resultado, meu lema últimamente virou: "Mantenha o cliente feliz". Isso não tem nada de altruísta ou profissional, é completamente egoísta: EU sou o cara que fica feliz no fim dessa cadeia.

Em tempo... o contrário também costuma verdadeiro.

Custos

2006-08-29T11:02:00.000-07:00

(pré-requisito: saber como funcionar o Planning Game do Extreme Programming)

Problema que vejo frequentemente por aí: o sistema está indo razoavelmente bem, então o cliente começa a pedir coisas e mais coisas. Algumas delas fazem sentido, outras são puramente cosméticas ou desnecessárias. O sistema começa a atrasar e o cliente fica bravo porque as funcionalidades agendadas não foram implementadas em tempo... Mas não conta que as coisas que ele pediu consumiram tempo.

Moral da história: um pouco mais de má fama para o nosso lado.

Caso 2: O cliente não tem a menor noção de quanto custa implementar uma funcionalidade. E o pior, não sabemos como mostrar ao cliente esse custo.

Moral da história: o cliente pede e não percebe que está pagando. Efeito colateral: a empresa de desenvolvimento é quem acaba pagando boa parte das funcionalidades. No mínimo, desgastando a equipe com horas extras que poderiam ser facilmente evitadas.

E aí? Como resolver?

Tirei uma boa experiência do XP nesse ponto. Como cada funcionalidade recebe uma estimativa em "unidades de tempo relativo". Bastou medir quantas dessas unidades a equipe fazia por mês e dividir o quanto o cliente pagava no período. Isso dá o custo por unidade. A partir desse momento, cada funcionalidade passa a ter automaticamente o custo assim que recebe a estimativa.

Aí, é questão de receber a requisição, estimar e devolver para o cliente com o custo. Resolve bem:

Exemplo:
Unidades mensais no projeto: 100.
Pagamento mensal (ou parcela): 8.000,00

Qto custa cada unidade? 8K / 100 = 80,00

Chega uma requisição, estimamos ela em 3 unidades. Custo = 80,00 x 3 = 240,00. Uau! Caro!

Simples demais pra servir pra algo? Talvez, mas a precisão é suficientemente boa para dar ao cliente uma noção de custo e simples o suficiente para eu não precisar implementar um processo somente para isso. Um bom custo benefício, diria eu.

Se você pensar um pouco, consegue estrapolar a idéia, calculando seu custo por unidade ou então o custo por hora (baseado em unidades/hora). E, é óbvio, o melhor é que isso dá automaticamente o seu custo por projeto no momento em que a estimativa inicial fica pronta.

Achou falhas na idéia? Ótimo, posta aí. Pra mim, anda funcionando particularmente bem. Posso ser simplório, mas acho que nossa área reclama de barriga cheia, é bastante simples calcular o custo de 90% das coisas que fazemos. O que dá um pouco de trabalho é o ROI, mas com um pouco mais de estimativas dá pra ter uma excelente noção.

Mas aí é outro post.

Dividir para conquistar

2006-08-22T18:04:00.000-07:00

Qualquer especificação de sistema ("A especificação"), costuma ser grande e cheia de furos, faltando detalhes importantes, explicando parcialmente o processo, assumindo conhecimento comum em partes que somente um especialista de negócio saberia entre outros horrores.

Particularmente, penso que o problema está no tamanho da coisa. É meio simplória a idéia, mas veja:
1 - Qto maior, naturalmente mais complexo (senão é encheção de linguiça), portanto, mais difícil de estimar. É por isso que costumamos quebrar em funcionalidades primeiro.
2 - Em uma massaroca de detalhes, é fácil deixar escapar alguns importantes, tb é fácil deixar de incluir algum importante inadvertidamente.
3 - O mesmo texto frequentemente mistura overview do sistema com detalhes dos módulos, quando mal redigido (e frequentemente é), causa uma tremenda confusão. Já vi especificações que não seguiam uma linha de pensamento, descrevendo módulos e funcionalidades ao léu.

Pois bem, parte do problema seria resolvido se a mesma pessoa que redige a especificação fosse um especialista no sistema E um bom escritor. Porém, mais frequentemente do que eu gostaria, é um analista de sistema que não é nem uma coisa, nem outra.

Inspirado em User Stories e Use Cases, fico imaginando se "A" especificação não deveria na verdade ser toda picotada. Textos menores descrevendo casos de uso ou funcionalidades, mais um overview que juntasse as partes. Fica mais fácil avaliar e pensar em cada parte e verificar os detalhes, tudo porque um texto menor e mais focado é menos em que se pensar.

Será que consigo fazer um teste com isso?

Programming as a Theory Building

2006-08-09T06:34:00.000-07:00

Sempre fiz parte daqueles que acham que o conceito de "fábrica" de software segue um modelo pouco adequado, pra não dizer completamente sem noção. Software não se produz em linha de produção: "Entra requisito, sai programa". Tentativas de fazer isso, principalmente com o objetivo de baratear o "peão-programador", costumam dar muita dor de cabeça (ou não?).

Acredito que, se fosse possível uma comparação, talvez a programação fosse o desenvolvimento do projeto do carro. A produção do carro em si, como tudo mais na informática, é compilação e cópia.

Opinião pessoal: acho que software é o paraíso pra essas coisas. O problema é que a "produção" é tão simples que é difícil evitar que qualquer um faça. E vive la piraterie!

Bom, de volta ao assunto, ontem um colega apresentou um trabalho interessante e se baseou em um artigo de 1985 de Peter Naur (Turing-award 2005, é fraco?!) que expressa a mesma linha de raciocínio.

Então eu fiquei feliz, além de outra meia dúzia de retardado mental com a mesma opinião, tem doutor que pensa a mesma coisa desde o tempo que microcomputador era um teclado conectado na televisão.

O artigo chama-se "Programming as a Theory Building", achei várias referências ao seu conteúdo, mas nada de achar ele online. Finalmente, achei uma referência dizendo que o Agile Software Development do Alistair Cockburn tem uma cópia dele. Maravilha! Dureza é comprar um livro de US$38 + taxa de entrega por que você tem interesse real só em um artigo. Não que o livro seja ruim, deve ser bom, mas comprar ele ia ser efeito colateral do que eu quero.

O ponto agora é tentar juntar todas as referências que eu puder sobre a mesma linha de pensamento e ver o que eu consigo montar. Vamos ver :D

Contra as patéticas Universidades

2006-07-26T06:38:00.000-07:00

Eu fico de cara no chão o quanto as universidades desse nosso Brasil querido são completamente ineficientes em formar profissionais da área de informática, especialmente programadores. Cursos que ninguém sabe sobre o que são, currículo "abrangente" que não abrange nada que interesssa. Vai mal.

Temos curso de "Engenharia da Computação", o desgastado "Análise de Sistemas" e o antigo mas ainda com prestígio "Ciências da Computação", sem falar em uma infinidade de variantes novas como "Tecnologia da Informação" e sei lá mais qual nome andam inventando. Agora, se você perguntar a qualquer pré ou pós universitário qual a diferença entre um em outro você vai receber um tímido "não sei muito bem" bastante insípido de se engolir.

Bonito né? Quer melhor, pergunte a alguns _professores_ do curso qual a diferença entre os cursos e me diga quantos souberam responder certo e sem embromation. O único cara que deve saber com certeza é o coordenador do seu curso.

Agora vou pegar mais embaixo. Qual desses cursos ensina programação? Uh... todos...
Jóia, então já dá pra entender porque as empresas todas colocam nos anúncios de emprego "curso superior em informática", sem especificar qual. Pra quê? Todos sabem informática e é tudo uma coisa só.

E qual desses cursos forma "programadores" (é.. programador; não cientista, nem analista: eu disse "p r o g r a m a d o r")? Nenhum??? É... como eu desconfiava, pra programação não precisa estudo, é coisa de peão mesmo. Programador é igual pedreiro. (O que me lembra uma frase de um cara num concurso pra lixeiro: "Não sei se é bendito ou maldito o país que exige pelo menos segundo grau para lixeiro mas não para Presidente da República").

Ah... Cientista da Computação, Analista de Sistema e afins todos sabem programar, é o mínimo, não é? Correto... aprenderam técnicas de debug? Conseguem fazer um teste automatizado? Sabem pelo menos o que são idiomas, certo? Ahhh... não... mas sabem fazer um programinha. Esses tópicos são avançados, talvez mestrado. Ou talvez dia a dia no mercado de trabalho.

Ops, esqueci. Universidade ensina teoria, e essas técnicas e conceitos não tem respaldo científico. Hmmm... será que RUP, XP ou qq dessas técnicas têm?

Bom, então já sei, é que o mercado não precisa de programadores. Só de pessoas que saibam analisar a ordem de um algoritmo ou descobrir os casos de uso de um sistema. Ambos muito úteis, infelizmente só atacam um pedaço muito pequeno do que se faz numa empresa.

Não adianta, programador é peão mesmo. Já entendi, segundo grau completo e boa. Se tiver um certificado melhor

(Vixi... Isso ficou com cara de desabafo. Mas deixando a brincadeira do rabugento de lado, não é de hoje que as Universidades da área de TI formam pessoas completamente despreparadas para o mercado de trabalho. Depois reclamam que o mercado é "pouco seletivo" na hora de contratar pessoas na área, quer dizer, frequentemente não exigem ou aceitam qualquer curso superior)

Software enterprise vs open source

2006-07-19T19:12:00.000-07:00

Um colega no mestrado soltou uma que me fez pensar na última terça:

"Mas o pessoal usa teste de unidade?"

Bom... quem eu vejo usando teste de unidade? Quase todo projeto open source que se preze. Hoje ficou raro você ver bons projetos open source sem teste de unidade. Pelo menos para Java e Ruby. Só olhar no sourceforge e no rubyforge.

E no ambiente corporativo (leia-se "enterprise software"), é muito raro, praticamente inexistente. A prática tem que ser "provada" para entrar em um ambiente enterprise :p

Conclusão: Você paga caríssimo por um "software enterprise" e ele não tem o mínimo de qualidade que um open source (frequentemente gratuito) pode ter... :|

Ah tem? Me mostrem seus testes então. :) Ahhhh... sei... QA, teste manual, claro, claro, muito confiável, completamente independente de falha humana, executado do começo ao fim sempre que existem alterações. É... como não pensei nisso, bobo eu.

Trabalho em paralelo

2006-06-19T07:40:00.000-07:00

Engraçado, não sei o que passa na cabeça do pessoal de TI às vezes.

Quantos de vocês trabalham eme paralelo? Quero dizer, fazem duas ou três coisas "ao mesmo tempo" ou trabalham em mais de um projeto ao mesmo tempo?

Acho que a gente acostuma tanto que o computador consegue lidar com várias coisas ao mesmo tempo que a gente acha que consegue fazer o mesmo. Só que enquanto o processador de um micro fica a maior parte do tempo ocioso, não é nosso caso. Se vc pegar um computador que está trabalhando a 100% de CPU e colocar outra coisa pra rodar junto, ambos os serviços vão demorar o dobro do tempo (ou mais) para serem concluídos. O mesmo ocorre conosco porque, via de regra, não temos tempo "ocioso".

Me lembra um caso que eu gosto de contar: Um antigo chefe meu me chamou na sala dele, me deu um escopo e disse:
"Por alto, quanto tempo você acha que dá pra fazer isso?"...

Perdi uns 15 minutos olhando e falei:
"De um a dois meses".

Ele:
"E esse?"

Gastei mais um tempo olhando e disse:
"É parecido com o primeiro, deve levar mais ou menos o mesmo tempo".

O olho dele brilhou:
"Ótimo! Isso significa que no próximo mês temos tudo pronto, certo?"

Eu:
"???... Não... se cada projeto leva 1 a 2 meses, daqui 2 meses temos um pronto e daqui a 4 meses temos o segundo pronto!"

Ele:
"Mas e se você trabalhar nos dois ao mesmo tempo?"

...

Não sei o que passa na cabeça das pessoas pra conseguir formular uma lógica dessas.

Rules to live by

2006-06-08T06:52:00.000-07:00

"Complaining don't fix things,
Blaming just causes more trouble,
We are trying to get things done here,
If you can't help, at least get out of the way."

"You're not able to tell me if that's easy or not,
you're not able to tell me if that's fast to make of not.
Unless you are the one who will do it."

"I don't care about the best way. I need a good way that works."

"Double things to do, double time. Triple things, triple time. That's basic arithmetic, right?"

"If you can't put it in numbers, you don't really know about it"

And the basic principles for any developer: K.I.S.S. and D.R.Y. (I would also add "C.O.C." - Conventions over Configurations, but that's a nice thing to have, not a must one)

As partes que precisam ser especificadas em um sistema web

2006-06-06T16:16:00.000-07:00

A aparente simplicidade de sistemas web (tela -> banco, banco -> tela) faz com que a gente subestimar coisas e NÃO especificar nem pensar muito em algumas delas que são simplesmente essenciais.

Aproveitando o tema da aula de hoje (teste de especificação), comecei a bolar um check list de coisas que deveriam ser especificadas para cada TELA em um sistem web.

A lista é só um rascunho, mas acho que já é um bom começo.

Quais entidades e campos precisa para carregar a página?
Quais entidades e campos precisa pra gravar? São os mesmos para carregar a página?
Quais validações cada campo precisa, estão todas especificadas individualmente?
Para poder gravar, alguma entidade tem que estar em algum estado específico? Tem que existir alguma outra entidade que não as que foram listadas nos dois primeiros itens?
O que acontece quando não é possível gravar?
A tela tem espaço para exibir os erros? Lembrando que ficar exibindo um erro de cada vez na gravação é muito chato para o usuário.
Se a tela grava em mais de uma entidade, é possível que ela seja um processo, não simplesmente um caso de tela -> banco, banco -> tela. Esse processo está descrito como tal? Possui validações? Você consegue buscar todas as entidades envolvidas com as campos que tem na tela? Os campos que tem na tela são suficientes para você alterar os estados das entidades de acordo?

Bom, acho que tem mais coisas na lista, mas vou melhorando aos poucos.

Deixei passar algo óbvio?

Tela, banco - banco, tela.

2006-06-01T10:09:00.000-07:00

Tava pensando nas aplicações de hoje em dia. Todo mundo quer fazer elas pra web (quando não pr rodar em celular). Isso facilita muito as coisas.

Dada a natureza "em lote" da web, as aplicações acabam ficando muito mais simples e desconectadas. Já que uma página não consegue se conectar com outra direito, e quando consegue é obrigada a passar um "pacote" de dados ao invés deles individualmente, você acaba criando (inadvertidamente) vário protocolos de comunicação entre elas :)

No final das contas, as aplicações web viram um monte de páginas com a seguinte estrutura: "Da tela pro banco" ou "do banco pra tela", com algumas transformações no meio que o pessoal chama de lógica de negócio (e validações).

Migrar uma aplicação dessas é bem mais simples. Alterar ela é BEEEEM mais simples. No final das contas, as limitações acabaram formando um ambiente mais saudável.

Tá certo que tem uns Zé Ruelas que conseguem fazer a coisa tão complicada que os dados de um lado pro outro são passados meio por Session, meio por Request, e um pouco por banco. Fazer isso em partes diferentes da aplicação é normal, duro é quando de uma simples página pra outra vc recebe as coisas por mais de um lado :| tipo "bombardeio de dados"

Agora, com AJAX (legal!!!) as aplicações estão ficando muito mais inteligente (finalmente!). Mas está abrindo brecha pra cada barbaridade :p

Vai ser interessante, aguardemos e observemos.

Nossa área sacaneia o cliente, não tem jeito!

2006-05-31T12:09:00.000-07:00

Tava ouvindo um colega nosso agora há pouco entrevistando um cliente para saber como funciona um sistema. Que sacanagem! A gente complica o cliente.

O cara tem uma idéia bem simples: "Olha, é um cadastrinho, o cara ganha um brinde se cadastrar 10 colegas".

A gente explode a idéia simples em 10 segundos!

- "Mas e se o cara cadastrar ele mesmo 10 vezes?"
- "ahhh.... não sei... deixa ver... O sistema não permite e-mail duplicado"
- "E se alguém se cadastrar com o e-mail de outra pessoa, essa pessoa não pode nunca mais entrar no sistema?"
- "ahhh..... não sei, tem que poder cancelar, então."
- "Então tem que ter uma área de administração pra poder cancelar?"
- "Área de administração??? Não, não, é só um cadastrinho, só uma pagina simples resolve"
- "Mas sem senha? Qualquer um pode entrar?"
- "ahhhh.... er..."
- "E se cancelar errado? Tem que ter como voltar?"

Tenho dó dos clientes, a gente consegue fazer com que nenhuma idéia simples seja simples depois da primeira entrevista...

Desculpas boas para cancelar Speedy sem encheção de saco

2006-05-26T09:21:00.000-07:00

Sabe que toda vez que se tem que tenta cancelar Speedy/Linha Telefônica/Serviços da Linha o coitado do atendente ainda tem que ficar tentando te vender alguma outra merda que você não quer, não precisa e não tem a menor intenção de adquirir.

Quando o atendente perguntar porque você está cancelando o serviço, use alguma das desculpas abaixo para se livrar da encheção:

"Por que o senhor gostaria de cancelar a linha?"

Estou mudando de país...
Minha casa pegou fogo...
Estou indo preso e não vou mais precisar...
O diretor da prisão não deixa mais a gente usar speedy...
Minha religião não permite usar internet... Aliás, deixa eu te dizer como eu mudei, você deveria visitar minha igreja e conhecer meu pastor, deixa eu te falar... (garanto que o atendente pergunta "mais alguma coisa, senhor", no mesmo instante)
Perdi meu emprego hoje...
Sabe... é que eu fiquei cego...

Essa última é muuuuuito do mal (né, Bart, seu doente!!!)

Usando sua própria interface

2006-05-25T04:12:00.000-07:00

Já ouviu falar daquela história de que, se todo político fosse obrigado a andar de transporte público, nós teríamos os melhores ônibus do mundo?

Pois é, ontem e hoje estou tendo que usar muito a interface do programa que estou fazendo. Conclusão? Percebi um monte de coisas que deveriam ser melhoradas. Nada grave, a maioria pequenos detalhes que custariam pouca programação e tornariam a vida bem mais divertida. Coisas como cores diferentes em situações diferentes, um texto explicativo aqui e ali. Essas coisas.

A lição que tiro disso? A gente não costuma usar os programas que faz pelo simples fato de que fazemos eles para outras pessoas, mas um ou dois dias usando ele intensamente somente para pegar o "feeling" de usuário podem ser bem aproveitados.

Ou não?

Projetos que eu gostaria de fazer

2006-05-18T11:34:00.000-07:00

Projetos que eu gostaria de fazer:

"JMiss" -> Pequenas coisas úteis que o Java não tem. Tais como "join" para String, um File capaz de iterar o arquivo linha a linha, tipo de dados Fraction (Rational), etc e tal.
Um jogo web nos modelos do meteorus (www.meteorus.com.br) em Ruby on Rails com MUITO uso de Ajax, mas muito meeesmo... só pra ver como fica.
Um site para o comércios dos meus pais (já viu, né?! Casa de ferreiro...)
Um gerador de código para Java que crie a camada de persistência com o padrão ActiveRecord. Mesmo esquema do Rails, só que com código gerado ao invés de dinâmico. Provavelmente vou usar Groovy ou outra coisa pra gerar isso, porque mecanismo de template no Java é uma lástima (tá tá tá, Velocity, Tapestry, blah blah blah... qualquer dia eu olho isso)

Olha só... até q não tem muita coisa. Descontando que cada projeto desses eu demoraria mais ou menos um mês de trabalho contínuo, sozinho e no gás...

Tá, okay, entendi... o "JMiss" deve ser mais fácil, uns poucos dias e eu tenho uma pacolada de coisas prontas fáceis.

Web Services: Teoria e Prática

2006-04-12T15:37:00.000-07:00

(Da série: "Ceticismo de Mau Humor" ou "A Teoria na Prática é Uma Merda")

Na teoria, Web Services são para integrar sistemas em diferentes linguagens. Você precisa do método, gerar WSDL para que a aplicação cliente gere stubs automaticamente, enviar e receber objetos inteiros usando XML, etc e tal.

Na prática, são usados para sistemas .NET se comunicarem (cadê a integração?) entre si e volta e meia com um Java muito doido. Quanto você precisa de fato integrar seu sistema com algum outro, você cria uma página que recebe um post e fornece um XML que é muito mais simples e fácil.

Na teoria, Web Service é popular porque é uma boa idéia para integrar negócios.

Na prática, é popular porque a Microsoft bolou um jeito de fazer ele funcionar adicionando apenas uma linha de código. Se fosse qualquer outro protocolo por baixo, rodando na porta 80, ia ser igualmente popular.

Da série "Torne-se um Programador Profissional"

2006-04-11T12:08:00.000-07:00

Método Philber para Debug

"Se há um erro na linha 10, remova a linha 10".

Método Sokoban para Debug

(Lembra do joguinho "Sokoban"? Onde vc tinha q empurrar umas caixas?)

"Se você aplicar o Método Philber e remover a linha 10, o erro vai para a linha 11. Aplique o Método Philber novamente e remova a linha 11 e assim por diante. Inadvertidamente, uma hora o programa vai ficar sem bugs".

Por quê esse blog?

2006-04-07T11:33:00.000-07:00

Meus colegas brincam que eu reclamo muito. E olhando meu outro blog ví que metade das coisas que eu posto é porque estou p* da vida com o Java, ou com algum software, ou com Java, ou com algum site, e também com o Java, ou com Engenharia de Software, ou então com Java. Então resolvi aposentar o outro blog e fazer esse aqui pra ficar mais "de acordo".

Então é isso. Esse é o meu novo blog (é, tou aposentando o outro). Pelo menos vou ter um lugar certo pra resmungar :D