Desenvolvimento de software é um esporte de equipe

Dãã, grande notícia, certo? Todo mundo sabe disso, não precisa nenhum anúncio. Bem, pelo menos não era pra precisar. Todavia, pelo que converso com outros amigos desenvolvedores e pela minha própria experiência mesmo, seria muito bom se fôssemos lembrados disso mais vezes.

Há uns dias li o fantástico livrito Team Geek, a Software Developer’s Guide to Working Well with Others (ou Equipe Geek, um Guia do Desenvolvedor para Trabalhar Bem com Outros). Deixa ver, como descrever… Um exercício catártico! Um banho na alma! Todo mundo envolvido em desenvolvimento de software deveria ler esse livro e colocar nos seus top 10! E a capa é joinha:

Contrastando com Peopleware, que está por aí (sendo ignorado) há já alguns anos e é mais voltado para gerentes, Team Geek é para os desenvolvedores/engenheiros de software aprenderem a trabalhar com humanos — e justamente por isso que é tão urgente.

Bem, andaram me reclamando do tamanho dos posts, por isso vou tentar pegar leve dessa vez aqui, mas você terá que ler o livro — até porque ele é curto (194 páginas) e barato (10 dólares a edição Kindle). Além disso, tenho receio de tentar resumi-lo: além de deixar grande demais, eu esqueceria coisas importantes e você acabaria não lendo o livro — o que você deve. Serve também como uma boa desculpa para a minha preguiça, é claro. Mas ei, eu tenho outros livros pra ler, ok? Faz meses que estou em 30% do Agile Principles, Patterns and Practices in C# e tremo só de pensar em escrever sobre!

Enfim, hoje você terá que se contentar com minha tradução livre de algumas quotes não muito selecionadas, e depois decidir se vai ler o livro sofregamente ou ver algum dos vídeos da dupla Fitz e Ben Sussman antes.

Citações — livre tradução:

O fator que vai fazer ou destruir^* sua carreira é quão bem você colabora com outras pessoas.

^{* Tenho uma tradução alternativa um pouco mais colorida para esse verbo que rima com o primeiro, mas que cai melhor numa conversa de bar. :D}

Pessoas são inerentemente imperfeitas. Mas antes de entender os bugs em  seus colegas, você precisa entender os bugs em você mesmo.

O Mito do Programador Gênio^* é só mais um aspecto da nossa insegurança. A maioria dos programadores temem compartilhar um trabalho que recém começaram porque isto significa que os colegas vão enxergar seus erros e saber que o autor do código não é um gênio. [...] A reação natural a isso é se esconder em uma caverna e trabalhar sozinho. [...] Se você está trabalhando sozinho, você está aumentando o risco de falhar e reduzindo seu potencial de crescimento.

^{* No Youtube tem um vídeo dos dois autores em busca do programador gênio, funny stuff.}

Trabalhar sozinho é mais arriscado do que trabalhar com outros. Você pode estar com medo que alguém roube sua idéia ou descubra que você não é um gênio, mas você deveria estar com mais medo de gastar enormes quantidades de tempo e energia trabalhando na coisa errada.

Os três pilares que fundamentam toda interação e colaboração saudável são: 
Humildade: você não é o centro do Universo, não é onisciente e nem infalível. Você está aberto a se melhorar. 
Respeito: Você se importa genuinamente com as pessoas com quem trabalha, trata-os como seres humanos e aprecia suas habilidades e realizações. 
Confiança: Você acredita que os outros são competentes e farão a coisa certa, e está confortável em deixá-los pilotar quando apropriado. 
[..] Quase todo conflito social pode ser rastreado a uma falta de humildade, respeito ou confiança.

Às vezes, a melhor coisa a se fazer é apenas dizer: “Eu não sei.”

Quanto mais você for aberto a influência, mais você conseguirá influenciar; quanto mais vulnerável você for, mais forte você parece. [...] Lembre-se que para ser ouvido adequadamente, você precisa primeiro ouvir os outros. [...] Admitir que você errou engloba os três pilares: você demonstra humildade, é um sinal que você confia na opinião dos outros, e as pessoas acabarão por respeitar sua honestidade e integridade.

Políticos profissionais são notórios por não admitir erro ou ignorância, mesmo quando está patentemente óbvio que estão errados ou não têm conhecimento sobre um assunto, e por causa disso as pessoas não acreditam em nenhuma palavra do que eles dizem. Este comportamento existe porque os políticos estão constantemente sob ataque dos oponentes. Contudo, quando você está desenvolvendo software, é desnecessário estar num estado constante de defesa — seus colegas são colaboradores, não competidores.

Uma forte cultura de equipe está aberta a mudanças que a melhorem e resistente a mudanças radicais que a prejudiquem.

Se você é um gerente e está se sentindo inseguro por algum motivo, uma maneira de fazer que ninguém questione sua autoridade ou ameace seu emprego é contratar pessoas que você pode manipular mais facilmente. [...] Em vez disso, você deve se esforçar para contratar pessoas que são mais inteligentes que você e que possam substituí-lo.

Esperança não é uma estratégia. Todavia, esperança é muito usada como estratégia ao lidar com um funcionário que não está rendendo bem.

Falhar é uma opção. Se você não está falhando de vez em quando, é sinal que não está sendo inovador nem tomando riscos o suficiente.

So… that’s it for today and thank you very much. :)

Coisas sobre o VIM que gostaria de ter sabido antes

O Vim ainda é o meu editor predileto. Tentei substituí-lo várias vezes, e as únicas alternativas que chegaram perto de ameaçá-lo foram Emacs e Sublime Text: o primeiro pela quantidade de recursos, o segundo pela interface joiada. Mas sempre que precisava resolver um problema rapidão, acabava voltando pro good ol’ Vim.

^{Ah, só antes de continuar, uma palavrinha para os perdidos: Vim não é o mesmo que vi, okay? Eu não suportaria usar o vi. :P}

Mesmo que sempre gostasse do Vim, por um bom tempo me senti envergonhado por continuar usando ele, pensando que nunca me esforçei de verdade em sair da zona de conforto e usar outra coisa. Mas hoje, considerando que uso regularmente as full-blown IDEs nos projetos Java – além de ter brincado bastante com Emacs e ST2 –, se eu continuo voltando para o Vim, talvez não seja tanto assim por falta de esforço meu pra sair da zona de conforto. Talvez seja porque ele seja uma ferramenta que se encaixe bem no meu modo de pensar — o meu user model. Talvez seja porque ele é uma ferramenta boa o suficiente pra mim. Talvez, em vez de sentir vergonha de usar uma ferramenta com aparência antiquada, eu deveria valorizá-lo mais e melhorar o meu próprio uso dele.

Preferir o Vim não faz de mim um programador menos capaz – a não ser que eu deixe de refatorar um código só porque meu editor não oferece as mesmas facilidades duma IDE. (ahn, não quero falar dos programadores que amam sua IDE mas nunca usam os recursos de refatoração…) Toda escolha envolve tradeoffs, e o Vim certamente tem suas desvantagens, mas é uma escolha muito válida e pode ser mesmo muito divertida.

Enfim, por isso que resolvi finalmente comprar o livro Practical Vim do Drew Neil, que estou lendo (27%, me diz o Kindle) e curtindo muito!

Acontece que o Vim, apesar de não ter uma boa usabilidade para usuários comuns, é uma ferramenta muito boa pra programar ainda hoje. Quem não têm medo de aprender novas linguagens e maneiras diferentes de fazer as coisas fica muito bem com ele, obrigado. O foco do Vim não é usabilidade, mas eficiência. De fato, é uma ferramenta ideal para nerds de eficiência.

Uma das primeiras coisas a sacar pra usar o Vim de maneira eficiente é que o modo Normal não tem esse nome à toa: é o modo planejado pra você usar durante a maior parte do tempo. Se você tentar maximizar o tempo no modo de inserção pra ter uma experiência mais parecida com a dos outros editores, acabará perdendo as grandes vantagens do Vim — como a possibilidade de repetir ações, por exemplo.

Devo ter aprendido isso de alguma forma há um tempo atrás, e já estou até bem confortável com esse estilo, mas tem algumas coisinhas que ainda me deixam pra trás no Vim. O que segue são algumas pequenas dicas da minha redescoberta do Vim dos últimos meses, que teriam feito minha vida um bocado mais fácil se tivesse sabido delas antes.

1) É mais prático voltar para o modo Normal usando <Ctrl-C> em vez de <Esc> — especialmente se você mapeia a tecla <Caps Lock> para um <Ctrl> alternativo, como eu faço. Veja outras maneiras de evitar o <Esc>.

2) Se a meio caminho de uma seleção visual você se dá conta que começou do lugar errado, você pode ir para o “outro lado” da seleção usando a tecla o (caractere o minúsculo), modificar o começo da seleção conforme necessário. Use o novamente pra voltar pro outro lado e continuar o que estava fazendo.

3) Acabou de fazer uma operação numa seleção visual e precisa fazer outra na mesma seleção? Use gv pra reselecionar a última seleção, e mande ver.

4) No modo Normal, <Ctrl-O> leva o cursor pra última posição antes de um pulo. <Ctrl-I> faz o caminho inverso. Aprenda isso hoje e me conte depois como você usou 35 vezes no mesmo dia.

5) Fazer scrolling com <Ctrl-F>/<Ctrl-B> (mesmo que <PageUp>/<PageDown>), <Ctrl-U>/<Ctrl-D> (up/down conforme a configuração scroll) e <Ctrl-Y>/<Ctrl-E> (sobe/desce uma linha) é mais prático do que usar <PageUp>/<PageDown>, setinhas e a rodinha do mouse. Veja mais sobre movimentação no Vim.

6) Descobri que manter uma cópia impressa do cheatsheet gráfico por perto realmente ajuda a aprender mais coisas. Não tanto porque é fácil de consultar, mas porque você acaba batendo o olho em alguma coisa útil quando fica entediado. :)

Sobre plugins, existem muitos que valem a pena conferir (tenho pelo menos uns vinte instalados), mas alguns se tornam essenciais bem rapidinho:

1) Pathogen – ajuda a manter os plugins atualizados e deixa muito fácil para experimentar plugins novos, só por isso já vale muito a pena. Se ainda não conferiu o Pathogen, comece por aqui.

2) CtrlP – ajuda a achar arquivos dentro do diretório de um projeto. Se você usa Eclipse, pense <Ctrl-Shift-R>, só que melhor, porque usa uma busca “fuzzy” por padrão.

3) Surround – mão na roda na hora de editar texto estruturado a la XML, HTML, etc. Veja um tutorial do Surround com vídeo.

Por enquanto é isso! :)

Desenho de Interface do Usuário – para programadores

Joel Spolsky é um cara batuta e muito inteligente. Ele é uma das figuras por trás do Trello e do StackOverflow (e seus sites irmãos), dois produtos show de bola que têm sido parte da minha vida diária ultimamente. Ele também é bastante conhecido pelos excelentes textos que escreveu no blog sobre vários aspectos de desenvolvimento de software, cobrindo assuntos desde gerenciamento de projetos, arquitetura e design de software, usabilidade e também contratação de funcionários. Resumindo: HERÓI! Se você lê inglês, ou quer aprender (e se você é programador, isso é altamente recomendado), dê uma olhada por lá! Aqui, vou deixar fácil: http://www.JoelOnSoftware.com

Num fim de semana desses, gastei duas horinhas lendo a versão online do mini-livro dele voltado para programadores que trata desenho de interfaces de usuário (tem outra versão à venda na Amazon que parece ter mais conteúdo). Tempo muito bem gasto, diga-se de passagem, porque o conteúdo é muito bom! O Joel escreve bem pra caramba, a leitura é muito engajante e as histórias que ele conta são bem divertidas.

^{UPDATE: Recentemente, descobri que tem uma tradução dos posts do Joel Spolsky que fizeram o livro aqui: http://brazil.joelonsoftware.com. Vou deixar aqui em letra miudinha porque né… :D}

Ele comenta sobre o desgosto que alguns programadores têm de fazer interfaces, provavelmente baseado no medo injustificado de ter que fazer design gráfico (não, não é a mesma coisa que desenho de interface — UI design). Programadores tendem a pensar sobre si mesmos como pessoas racionais, com bom raciocínio mas fraco em arte. Todavia, Joel explica, desenho de interface não é nenhuma arte misteriosa, e na verdade existem uma série de regras e princípios que podem ser aplicados para melhorar a interface dos programas para o usuário.

O caso é que a interface é importante porque afeta as emoções das pessoas. Quando um usuário não consegue fazer o que ele queria com o software, fica frustrado. Infeliz, mesmo! Mesmo que sejam algumas pequenas frustraçõezinhas, elas tendem a se somar, principalmente num software que é usado frequentemente. E o resultado é um grupo de usuários bem infelizes, no fim do dia. E eles vão botar a culpa no seu software! Todavia, quando o usuário consegue fazer o que queria, o programa funciona do jeito que ele esperava, o resultado é um usuário bem animado. Funcionou! Ripei um DVD! Que massa esse programa! \o/

Por isso, a primeira coisa importante a se ter em mente é:

Uma interface é bem-feita quando o programa se comporta exatamente como o usuário esperava.

Todas as regras e princípios restantes são corolários a esta.

Quando um usuário senta pra usar um programa, ele tem uma série de expectativas sobre como ele acha que o programa vai funcionar. Se ele já usou outros programas parecidos antes, vai achar que esse vai funcionar mais ou menos como aquele outro. Essas expectativas que devemos tentar descobrir, na hora de fazer uma interface pra o usuário. E você descobre isso de um jeito muito científico, e muito simples: perguntando aos usuários! Você não precisa fazer o que eles querem que você faça, mas você deve pelo menos ouvir o que eles têm a dizer.

Em vez de ficar argumentando e discutindo qual o melhor jeito de tratar determinado problema, simplesmente pergunte a alguns usuários o que eles esperariam como solução. É claro que alguns podem não saber, não se interessar ou simplesmente nunca ter pensado muito a respeito, mas se você perguntar pra gente suficiente eventualmente vai começar a enxergar uma espécie de consenso. E aí você já pode fazer um teste de usabilidade usando um protótipo da interface e pedindo pra alguns usuários tentar completar algumas tarefas, enquanto você observa.

Nessa hora você pode descobrir algumas coisas interessantes, tipo como certos usuários tentam clicar em coisas que não são clicáveis, ou procuram por uma certa opção num lugar diferente no menu. Talvez você perceba que precisará melhorar o suporte a copiar e colar em alguns campos, ou oferecer uma opção para desfazer certas ações, talvez reescrever os rótulos de alguns botões, e outras coisas do tipo. O legal é que você nem precisa fazer o teste com muitos usuários: mais de cinco ou seis pessoas e os resultados já começarão a se repetir! Resumindo, não requer nenhum investimento pesado em pesquisa.

Enfim, fazendo as coisas dessa maneira você consegue ter uma idéia melhor do que é que os usuários esperam. Você pode descobrir que melhorará a vida duma grande porcentagem dos usuários se construir sua aplicação a respeito de tarefas dos usuários, em vez de uma série de recursos genéricos não muito claros. Está no caminho para construir uma interface que atenda essas expectativas.

Uma coisa que reforça esse assunto, é a questão da consistência externa, isto é, a consistência com as outras ferramentas que o usuário está acostumado (este assunto é também tratado no livro sobre experiência do usuário que comentei há uns tempos atrás). Quando as primeiras aplicações começaram a aparecer, todo mundo precisou imaginar os próprios atalhos, menus e botões para determinadas coisas. Ainda existe muito software daquela época que é assim até hoje, em que mesmo o jeito de fechar o programa é bem diferente (hello, Emacs… and vim :).

Hoje em dia, as aplicações Web tentam se aproximar bastante à experiência oferecida pelas aplicações Desktop, porque corresponde melhor às expectativas dos usuários. Estou escrevendo este texto no Google Docs e sou grato ao Google por ter mantido no Docs a interface familiar das outras suítes de Office — menus Arquivo/Editar/Formatar/etc, a barra de ferramentas, a maioria dos atalhos para formatação também simplesmente funcionam. Imagina se eles resolvessem: “ei, nossa aplicação é Web, não tem nada a ver com o Office tradicional, vamos então prover uma experiência totalmente nova! Arquivos são coisas do passado, nós não temos arquivos, temos documentos na nuvem, então esse item File no menu não faz sentido!” Ainda bem que não rolou nada disso, certo? (Certo, Google?)

Por isso, ao fazer a interface do seu programa, faça o favor de seguir as convenções que os outros estão usando — mesmo que elas tenham sido estabelecidas por certas gigantes multinacionais pelas quais você não tem muito carinho. Para construir interfaces usáveis deixe a ideologia de lado, os usuários agradecem. Caso contrário, você corre o risco de ser aquele hotel que resolveu fazer tudo diferente e deixou impossível pra um recém-chegado descobrir como acender as luzes do quarto ou abrir a torneira.

A segunda grande regra de desenho de interface do Joel é:

Cada vez que você apresenta uma opção, você está pedindo ao usuário para tomar uma decisão.

O que obviamente não é necessariamente uma coisa ruim. Todo mundo gosta de poder escolher certas coisas, é por isso que Subway, Spoletto e outros restaurantes do tipo fazem sucesso. Todavia, ninguém gosta de escolher coisas que simplesmente não interessam.

Lembra desse cara chato?

E a verdade é que a maioria dos usuários não se importam com tanta coisa como você pode esperar. Joel dá um exemplo do que não fazer, citando o caso da ajuda do Windows, que em vez de mostrar a ajuda, abria um wizard perguntando como você queria configurar o índice da ajuda… É igual como quando você está tentando trabalhar em alguma coisa e alguém fica interrompendo, exigindo sua atenção para um assunto inútil.

Outro exemplo de problema do tipo foi a possibilidade de configurar a posição das barras de ferramentas… Você pode configurar tanto, que pode inclusive extrair a barra pra uma janela separada (e depois lutar bastante pra colocá-la de volta no lugar original). Aí você tem uma coisa que ninguém quer, mas que acaba atrapalhando para todo mundo.

Resumindo: pense muito bem antes de fazer o usuário decidir sobre uma coisa. Em geral, você deve tentar minimizar a quantidade de decisões, deixando apenas o que realmente importa.

 

Como criar interfaces para pessoas que têm mais o que fazer na vida

Quando você desenha interfaces para o usuário, diz Joel, é uma boa idéia manter dois princípios em mente:

1. Usuários não lêem o manual

2. Na verdade, usuários não lêem nada

Usuários não lêem o manual por diversos motivos. Às vezes, eles nem têm o manual, mas não iam querer ler mesmo se tivessem. Em geral, seus usuários estão tentando fazer alguma coisa. Para eles, ler o manual é interromper a tarefa que estão fazendo, é mais perda de tempo (e tendo em vista como tantos manuais são escritos mal, frequentemente eles estão corretos em assumir isso).

E de fato, usuários não lêem nada! Isso pode soar meio bizarro, mas a verdade é que existem muitas pessoas que simplesmente não lêem as palavras que estão escritas na tela. Isso é muito azarado para o programador, que geralmente gosta de imaginar tendo uma espécie de diálogo com o usuário. Mas se você já parou para observar as outras pessoas usando o computador, provavelmente já percebeu que algumas nunca lêem o que aparece num diálogo e automaticamente clicam em Ok ou Cancelar — dependendo do nível de confiança de cada uma.

Eu conheço de perto um programador que se comporta exatamente dessa forma. O bicho simplesmente não lê as mensagens que aparecem na tela, mesmo quando vai usar um programa que não está acostumado, é incrível! Incidentalmente, ele vive reclamando que os usuários dos programas dele não lêem as mensagens na tela…

Mas é assim mesmo. Os usuários avançados usualmente pulam as instruções. Iniciantes não gostam mesmo de ler muito. E os poucos usuários que realmente tentam ler as instruções, muitas vezes acabam ficando ainda mais confusos depois de lê-las! Por isso, os textos que você põe na tela devem ser polidos para minimização. Substitua explicações por ações auto-explicativas. Dá mais trabalho fazer assim porque você precisa pensar mais para conseguir reduzir os textos, mas vale a pena. Menos é realmente mais.

 

Ok. Joel fala de várias outras coisas também, mas este texto está ficando grande demais, e você é um herói legendário tendo lido até aqui de qualquer forma, então, prometo que já-já vou terminar.

Outra coisa que usuários também não são muito bons em fazer é controlar o mouse. Pois é, eles não controlam o mouse muito bem. Meus pais mesmo tiveram uma certa dificuldade de aprender o duplo clique. Certas tarefas são particularmente complicadas de fazer com o mouse. E às vezes, mesmo se o usuário sabe usar o mouse, ele não funciona muito bem. Eu mesmo cansei de xingar aplicações com barras de rolagem muito chatas, em que algumas tarefas simples viram um exercício de autocontrole pra não socar o monitor. E até hoje ainda tenho alguns medinhos sobre clicar e arrastar…

 

Outra coisa a lembrar: Usuários não conseguem lembrar muita coisa. Praticamente, nadica! E é por isso que menus são melhores interfaces que linhas de comando crípticas. Por isso que escolher um arquivo de imagem selecionando uma miniatura da imagem é melhor do que procurar o nome do arquivo numa lista. E por isso que, mesmo pra quem jura que a linha de comando é uma interface melhor, não larga do autocompletar. :)

E ei, eu sou um que vivo na linha de comando, uso na grande maioria das minhas tarefas no PC. Mas não tem como negar que o Windows Explorer apresentando as pastas em árvore é uma metáfora beeem melhor para o sistema de arquivos. Eu na linha de comando é só eu na minha zona de conforto. Eu devia tentar usar mais a interface gráfica, mas…

Ok, agora sim, estou finalizando! O que segue é provavelmente o ponto mais importante de todo esse texto.

Alguém lendo este texto, pode achar que um princípio geral a ser seguido é: “pense que seus usuários são muito burros”, e talvez achar que essa seja uma atitude arrogante. Não muito, eu diria… Uma arrogância muito pior é achar que o seu software é tão bom e bem-feito que as outras pessoas simplesmente devem se virar pra aprender a usá-lo.

A grande maioria das pessoas sabe operar uma televisão. Uma boa porção dessas pessoas deve ser capaz de usar o PC, navegar na Internet e olhar email. Uma porção pequena dessas pessoas deve saber usar Linux, talvez usar um pouco a linha de comando, e usar o último tablet da moda. Pouquíssimas dessas pessoas saberão programar. E das que sabem, muito poucas saberão programar em C++. (Cá entre nós, quase nenhuma mesmo, mas vai ter muitas que acham que sabem! :D)

O que podemos concluir disso é que quando você melhora a interface do seu programa, mesmo que em pequena quantidade, você aumenta dramaticamente o número de pessoas que pode usá-lo com facilidade. Melhore a interface para o noob que mal e mal sabe usar a TV, e a interface vai melhorar pra todo mundo — inclusive para os hackers barbudinhos! Tipo, melhore a interface em 10%, e ganhe 50% mais usuários. Por isso também, que fazer pequenas melhoras numa aplicação ruim que é usada largamente pode valer muito mais a pena do que criar uma aplicação nova toda perfeitinha, que talvez nem tenha usuário!

Então, não é que os seus usuários sejam tolos, mas se você seguir tentando fazer seu sistema à prova de tolos, você chegará num programa fácil de usar pra todo mundo. De fato, se fazer de tolo é uma boa maneira de avaliar a usabilidade de um programa ou tela. Não ler o que tá escrito na tela, sair clicando onde acha que deve ser sem verificar, usar o mouse com um dedo só. Se a interface não aguenta você sendo imaturo e impaciente, provavelmente ela pode ser melhorada um bocado.

 

Finalmente, o último conselho é: faça seu programa girar em torno de atividades do usuário. Se você vai fazer um produto, não saia simplesmente criando os recursos que acha que será necessário. Imagine alguns usuários (Pedro, pai de família, usa o PC para ver vídeos no YouTube e trocar emails com os amigos. Luana, filha adolescente de Pedro, passa as tardes no Facebook e baixa MP3 via BitTorrent). Isso deve ajudar a despertar empatia por eles. Então você pode imaginar algumas coisas que esses usuários queiram fazer com seu programa. E o passo seguinte é ter certeza de deixar bem óbvio como essas coisas podem ser feitas, na interface do seu programa.

Dessa maneira você evita uma aplicação que os usuários tenham que ler o manual (que ele não tem, lembra?) pra ver o que pode fazer com ela. De cara, ele já pode descobrir como fazer o que precisa. Ripar um CD. Enviar um cartão de Feliz Aniversário. Criar álbum de fotos. Imprimir o artigo inteiro. Achar uma imagem para ilustrar o texto. Revisar os últimos comentários postados.

Uma interface desenhada em torno de atividades detona uma desenhada em cima de quantidade de recursos tranquilamente e de mãos atadas!

Era isso, chega por hoje! :)

Por que as estimativas em desenvolvimento de software normalmente estão erradas por um fator de 2-3?

Aviso 1: Esta é uma tradução livre de uma das melhores histórias sobre estimativas de software já escritas. O original em inglês é uma resposta no Quora à pergunta do título, e essa tradução foi realizada com o consentimento do autor Michael Wolfe. Caso a língua não seja problema, recomendamos fortemente a leitura do texto original… simplesmente melhor e mais engraçado.

Aviso 2: Este post é resultado duma colaboração minha com o senhor Crineu Tres. Isto é, ele fez tudo e eu só traduzi os palavrões.

Vamos dar uma caminhada saindo da costa de San Francisco até Los Angeles para visitar nossos amigos em Newport Beach. Pego meu mapa e desenho nossa rota pela costa:

O percurso é de aproximadamente 400 milhas; podemos caminhar 4 milhas por hora, 10 horas por dia. Dessa forma chegaremos lá em 10 dias. Ligamos para nossos amigos e marcamos uma janta para o próximo domingo às 18h, quando chegaremos de forma triunfante! Eles mal podem esperar!

Acordamos cedo no dia seguinte altamente motivados para essa nova aventura. Colocamos as mochilas, pegamos o mapa e a rota para o primeiro dia. Olhamos então para o mapa. Ai ai:

Caramba, a costa tem um milhão de curvas e reentrâncias! Com apenas um dia de caminhada de 40 milhas não chegaremos nem em Half Moon Bay. Essa viagem tem pelo menos 500 milhas, e não 400! Ligamos para nossos amigos e atrasamos o jantar para a terça-feira. É melhor sermos realistas. Eles ficam meio desapontados, mas não vêem a hora de chegarmos. Além disso, 12 dias de San Francisco até Los Angeles não é um tempo ruim.

Bem, com essa inconveniência resolvida, partimos. Duas horas mais tarde, não passamos nem do zoológico. Qual o problema? Olhamos novamente para nossa trilha:

Jesus, essa trilha não é fácil! Areia, água, escadas, riachos, lobos marinhos furiosos! Estamos caminhando a no máximo 2 milhas por hora, metade da velocidade pretendida… podemos então começar a caminhar 20 horas por dia ou ligar para nossos amigos e atrasar a janta mais uma semana. Ok, vamos dividir o fardo: caminharemos 12 horas por dia e atrasaremos a janta até o final de semana seguinte. Ligamos para nossos amigos e remarcamos o jantar até o domingo seguinte. Eles ficam um pouco irritados, mas confirmam o evento mesmo assim.

Montamos acampamento em Moss Beach após um dia duro de doze horas caminhando. Cacilda, como é difícil montar barracas nesse vento! Não conseguimos dormir antes da meia noite. Nada demais: iremos apertar o passo amanhã.

Dormimos demais e acordamos doídos e cansados às.. 10 da manhã. Caralho! Sem condições de fazer 12 horas hoje! Vamos caminhar 10 e compensaremos com 14 amanhã. Juntamos os equipamentos e partimos.

Após um esforço redobrado nas primeiras horas, percebo nosso colega mancando. Maravilha, bolhas nos pés… precisamos resolver isso agora. Somos do tipo de grupo que resolve os problema individuais antes que comecem a nos atrasar. Eu corro por 45 minutos, 3 milhas para longe da costa até Pescadero, pego alguns band-aids e corro de volta para medicar meu colega. Chego exausto e o sol está se pondo, então declaramos o dia encerrado. Vamos dormir após fazer míseras 6 milhas. Mas temos suprimentos novos. Ficaremos bem. Compensaremos amanhã.

Acordamos na manhã seguinte, protegemos nossos pés de futuras bolhas e começamos a caminhar. Contornamos a encosta. Que?! Que porra é essa?

O maldito mapa não mostra essa merda! Temos que caminhar 3 milhas para o interior, contornar uma propriedade federal rodeada por cercas, nos perder duas vezes, e somente então voltar à costa em torno do meio-dia. A maior parte do dia foi gasta para realizar 1 milha de progresso. Ok, não ligaremos para nossos amigos para atrasar mais uma vez a janta. Caminharemos até meia-noite para voltar ao planejamento inicial.

Após uma terrível noite de sono sob a névoa, meu amigo acorda com uma dor de cabeça infernal e febre. Pergunto se ele consegue continuar e ele responde: “O que você acha, panaca? Estou caminhando nessa névoa gelada por 3 dias sem descanso!”. Beleza… o dia de hoje está perdido. Vamos descansar e nos recuperar. A partir de amanhã faremos 14 horas por dia, já que estaremos descansados e preparados para tudo… são apenas mais alguns dias, então obviamente podemos cumprir o prazo!

Acordamos moídos no dia seguinte. Olho o mapa:

Puta merda! Estamos no dia 5 de uma viagem de 10 dias e não saímos nem da Bay Area! Isso é patético! Vamos trabalhar em uma estimativa mais precisa e ligar para nossos amigos. Provavelmente seremos repreendidos, mas teremos uma data realista pelo menos.

Meu amigo diz: “Bem, fizemos 40 milhas em 4 dias, e é uma viagem de pelo menos 600 milhas, então são 60 dias, provavelmente 70 considerando uma margem para imprevistos”. Eu respondo “Nem fu…… Ok, eu posso nunca ter feito essa caminhada antes, mas eu sei que não demora 70 dias para caminhar de São Francisco até Los Angeles. Nossos amigos irão rir de nós se ligarmos avisando que só chegaremos na Páscoa!”

E continuo: “Se vocês se comprometerem a caminhar 16 horas por dia, podemos compensar o tempo perdido! Sei que será difícil, mas essa é a reta final!”. Meu colega grita de volta: “Pra começo de conversa, não fui eu que liguei dizendo que estaríamos lá no Domingo, tá? Você está acabando com a gente por um erro seu!”

Um silêncio tenso recai sobre o grupo. A ligação não é realizada. Ligarei amanhã, quando meu camarada voltar às suas faculdades mentais e concordar em algo razoável.

Na manhã seguinte aguardamos em nossas barracas até o temporal passar. Levantamos acampamento e saímos às 10h, esticando músculos doídos e novas bolhas nos pés. Não comentamos nada sobre a briga do dia anterior, embora eu tenha xingado um certo colega idiota que esqueceu a garrafa de água e fez a gente gastar 30 minutos para buscá-la.

Faço uma nota mental lembrando que estamos sem papel higiênico e precisamos parar na cidade mais próxima. Contornamos a enseada: um rio está bloqueando nosso caminho. Sinto uma forte dor-de-barriga e a sensação de diarréia iminente…

Aventuras apresentando Java EE a mim mesmo

Cuidado: o texto a seguir contém níveis perigosos de nerdice, acrônimos e javeiragem em geral.

Não sou nenhum fã de Java: a linguagem eu realmente não curto (não tenho culpa de ter conhecido Python e Ruby antes :P), todavia a plataforma tem os seus apelos. Só que eu estava ficando com vergonha de ainda desconhecer o stack do Java EE, ao passo que uso diariamente várias tecnologias relacionadas no meu trabalho. Por isso, decidi que iria tomar vergonha na cara e estudar um pouco mais da parada (e tentar reclamar menos). Comprei o livro do Antonio Goncalves sobre Java EE 6, e caí em cima. Tendo recentemente terminado sua leitura, registro aqui minhas impressões a respeito.

Read the original, dude!

Antes de começar, porém, já adianto uma coisa: apesar do conteúdo do livro ser bem decente, a tradução dele é péssima. Me encontrei frequentemente tendo que adivinhar como seria o texto original em inglês para poder compreender o traduzido, pois este não fazia nenhum sentido. A impressão é que o livro foi traduzido por várias pessoas diferentes (estagiários?), que não sabem muito sobre orientação a objetos e muito menos da plataforma Java EE, resultando numa confusão de palavreado mal-traduzido bem difícil de entender. Resumindo: a tradução atrapalha muito mais do que ajuda! Se soubesse que seria tão desleixada, jamais teria comprado o livro traduzido. Portanto, se você já lê inglês, obtenha a versão original (mesmo que saia mais caro): você vai poupar sofrimento e a leitura será mais tranquila. Se você não lê inglês, leia a versão original também e aproveite pra começar a aprender inglês logo: será mais saudável pra sua carreira não depender de traduções fajutas! OK, fim da reclamação.

O livro fornece uma visão geral da plataforma, e também tenta mostrar o contexto histórico e motivações para o surgimento dos protocolos e APIs. Após apresentar rapidamente o que consiste a plataforma e os programas necessários para rodar os exemplos (JDK, Maven, Glassfish 3, Junit 4 and Derby), o livro começa a apresentar as APIs e conceitos da plataforma numa abordagem meio bottom-up: alguns capítulos sobre mapeamento objeto-relacional com JPA — a API especificada para persistência com Java, depois alguns capítulos sobre as partes de Java EE usadas principalmente para a lógica de negócio (EJBs, Transações, AOP no estilo Java EE com Callbacks e Interceptors), seguidos de uma visão rápida das tecnologias usadas para a parte de apresentação na Web (JSF, JSP, e assuntos relacionados), e culmina com os últimos 3 capítulos dedicados a comunicação entre sistemas: mensageria com JMS, Web Services SOAP e RESTful.

O conteúdo é bom pra “designorantar-se” dos conceitos e tecnologias disponíveis na plataforma, acho que dá pra recomendar pra qualquer pessoa envolvida com Java e ainda não conferiu o Java EE, ou que vem de outras linguagens/frameworks e quer conhecer o padrão. Todavia, pelo que tenho lido no StackOverflow e em alguns outros lugares, a API especificada de Java EE sobre Contextos e Injeção de Dependência (CDI, na sigla em inglês) vem ganhando cada vez mais importância na plataforma, então é um certo pecado o livro simplesmente ignorá-la — em nenhum lugar do texto é sinalizado a omissão de uma parte importante da coisa.

Gostei bastante da cobertura de JPA, relativamente bem completa para um livro de introdução à plataforma. Rapidamente encontrei material pra uso no meu trabalho. A seção sobre EJBs pra mim foi interessante para comparar com a minha experiência com os recursos substitutos do Spring. (Parece que os meus SLSBs são beans do Spring com @Transactional. :) As partes exclusivamente sobre JSF não me reservaram muitas surpresas, mas curti aprender mais sobre o contexto histórico do framework, com a seção descrevendo o surgimento de JSP, JSTL, Facelets, EL, etc. Achei muito boa também a exposição sobre a API Javascript que ganhou especificação no JSF 2, usada para as requisições Ajax.

Por fim, os 3 últimos capítulos sobre interoperabilidade também estão interessantes, embora eu me arrastei na leitura deles. Sobre JMS, não tinha muita novidade (a API andou meio parada por algum tempo, e deverá ter novidades no Java EE 7 com o JMS 2). Fato curioso: o capítulo sobre serviços REST conseguiu ser mais enfadonho do que o de serviços SOAP (e olha que eu tendo a favorecer REST). Começou entrando demais nos conceitos dos protocolos antes de mostrar um exemplo prático que demonstrasse as vantagens da coisa — o que provavelmente teria criado um engajamento melhor com a exposição da API. Mas bem, o estilo REST é relativamente novo no mundo Java, talvez à medida que mais gente compre a idéia, ele deve receber mais atenção no futuro.

Os exemplos do livro servem apenas como um chute inicial mesmo, é só pra você ter uma idéia mesmo do que é possível de atingir com as APIs que estão sendo explicadas. Quase nada dos códigos de exemplo parecem aproveitáveis para uma aplicação real — muito longe de código de produção. Nesse sentido, o livro provavelmente não está longe da vasta maioria das documentações técnicas para programadores, infelizmente.

Apesar de tudo, ler esse livro foi muito bom pra mim, pois expandiu um bocado minha compreensão sobre algumas tecnologias que trabalho e sobre as possibilidades da tal plataforma Java EE. E como uso bastante JPA e JSF no meu trabalho atual, fiquei por dentro de vários recursos úteis dessas APIs que eu desconhecia. Por exemplo, apesar de usar JPA há já uns 2 anos, eu desconhecia os mecanismos de mapeamento com @ElementCollection e @Embeddable. Também, mesmo usando JSF há um bom tempo, desconhecia o composite:insertChildren (meus olhos devem ter pulado essa tag na listagem da documentação mais de uma vez). Essas e outras coisas encontraram uso bem rapidinho no código da aplicação que estou trabalhando. Meio besta eu não saber disso antes, né? Mas bem, isso é pra ser um dos benefícios esperados ao se sentar pra ler uma josca dessas até o final. :)

No final, fiquei com uma sensação um pouco mais positiva em relação ao Java EE (ou devo dizer, menos negativa?). Enfim, parece que do seu próprio modo a plataforma está evoluindo, e as APIs estão ficando bem decentes. E a próxima versão Java EE 7 parece que sairá em breve (essa página tenta registrar o progresso), com mais melhorias em todas as áreas. Contudo, às vezes tenho a impressão que o meu sentimento positivo é mais devido ao péssimo estado anterior das APIs do que aos recursos verdadeiros das versões atuais.

Pessoalmente, das tecnologias para aplicações Web do “mundo Java”, tendo a gostar mais de coisas como o Grails, que oferece várias facilidades semelhantes aos da plataforma Java EE, mas com usabilidade bem melhorada para mim como programador. Sei que não é muito justo comparar, já que Java EE é um conjunto de especificações (tem muita gente que valoriza isso), mas em termos de recursos disponíveis para um programador construir um app, pode fazer bastante sentido compará-los.

Finalmente, tem algumas coisas que me importam bastante num toolkit, e que Java EE ainda precisa melhorar:

• Facilidade de fazer bootstrap duma aplicação Web (IDEs e o Maven ajudam, mas ainda estão longe de grails create-app NOME_DO_APP)
• Facilidade de instalar/publicar uma aplicação — em especial, minimizando a quantidade de configuração a ser feita para os recursos que ela vai usar.
  • Envolve colocar o máximo de configuração possível embutido na aplicação. Isso meio que bate de frente com a idéia prevalente do Java EE de que as configurações devem ser feitas no servidor de aplicação.
• Suporte de primeira-classe a uma linguagem dinâmica nas partes em que faz mais sentido. (Groovy, Python, Ruby ou JavaScript já resolveriam pra mim, mas outras também serviriam).
• Independência de IDE — quero poder acionar facilmente a execução dos testes e geração de builds pela linha de comando. (Aqui usar uma ferramenta como o Maven ajuda bastante, mas ainda depende de muita configuração boilerplate — e frequentemente, bastante esforço).

Concluindo, acho que é bem interessante conhecer o que o Java EE tem a oferecer. Mas é bom não parar por aí: ainda tem bastante coisa interessante por aí pra investigar.

Fatos e Falácias da Engenharia de Software – notas do livro

Acabo de terminar a leitura de um livro simplesmente excelente, Facts and Fallacies of Software Engineering (Fatos e Falácias da Engenharia de Software), do programador/pesquisador/escritor Robert L. Glass. Bob Glass não é um acadêmico que fica falando abobrinha sobre como deve ser feito software mas que nunca quer botar a mão na massa. Ele se descreve como um pesquisador e praticante de engenharia de software (com 45 anos na área), e ele tem mesmo muita coisa interessante pra dizer.

O livro — dedicado aos pesquisadores que acenderam o fogo da ES e aos praticantes que mantêm-no aceso — consiste em 55 fatos apresentados num formato fácil de ler (fato, discussão, controvérsia, fontes & referências) e mais 10 falácias que ele resolveu adicionar depois que começou a escrever o livro. Antes de ser cortado pelos editores o título era “55 fatos fundamentais e frequentemente esquecidos (e algumas falácias)”, o que é uma descrição do conteúdo bem apropriada na visão do autor: uma grande porção dos fatos é coisa que todo mundo envolvido em engenharia de software deveria saber e não sabe, e quem já sabe acaba esquecendo e não faz nada a respeito.

Lendo esse livrinho (é pequeno, não chega às 200 páginas), fiquei surpreso encontrando respostas relevantes para perguntas que aparentemente ninguém estaria prestando atenção, mas que estão disponíveis de fato há algumas décadas! A leitura foi fascinante, mas lendo me senti muito ignorante por ainda não ter lido um material articulando essas coisas.

Espie só:

• Propagandas exageradas (aka hype) são a praga da engenharia de software. A maioria dos melhoramentos envolvendo ferramentas e técnicas ajudam a aumentar entre 5% a 35% em produtividade e qualidade. Não obstante, esses melhoramentos são propagandeados como tendo benefícios de “uma ordem de magnitude”. Adotar uma nova ferramenta ou técnica na verdade diminui a produtividade e qualidade do trabalho, inicialmente. O benefício só é atingido depois da curva inicial de aprendizado, e portanto só vale a pena caso seu valor seja visto de forma realista e se tenha paciência ao medir os benefícios.
• O fator mais importante no trabalho com software não são as técnicas ou ferramentas usadas pelos desenvolvedores, e sim a qualidade dos próprios desenvolvedores. Esse fato é sabido, evidenciado e documentado desde os anos 70. Apesar disso, muita gente decide “cortar custos” na hora de contratar desenvolvedores e depois tenta instigar qualidade com metodologias, processos e ferramentas. Seguidamente aparecem abordagens mesmo anti-pessoas, que tentam transformá-las em engrenagens numa linha de montagem, e serem facilmente substituíveis. Um exemplo famoso é o CMM – Capability Maturity Model do Software Engineering Institute (SEI), que se alastrou nas empresas públicas americanas (e vem fazendo o mesmo nas brasileiras…), que é baseado na percepção errônea de que o caminho para bom software é um bom processo. Not so! Mas veja o site do CMMI… O hype lá cativa qualquer gerente! :P
• As duas maiores causas de projetos saírem do controle são (a) péssimas estimativas e (b) requisitos instáveis. Estimativas são frequentemente feitas pelas pessoas erradas (que não têm conhecimento o suficiente sobre como software é construído), no momento errado (no início do projeto, antes de qualquer trabalho pra descobrir exatamente o que será feito), nunca são ajustadas ao longo do projeto, e apesar disso tudo ainda são levadas a sério por todo mundo — isso acaba gerando expectativas inalcançáveis desde o início, estresse desnecessário e moral-baixa das equipes. Já requisitos instáveis é um problema mais complicado, e a engenharia de software vem tentando abordagens diferentes em busca de soluções (depois de falhar miseravelmente tentando achar um jeito de obter um conjunto fechado de requisitos no início do projeto). Hoje, já é aceito como natural os requisitos sofrerem alterações ao longo do projeto, e a controvérsia está mais em como lidar nessas circunstâncias.
• Reuso em pequena escala (reuse-in-the-small) existe há muito tempo (muito antes de OO, viu?), e é um problema resolvido desde os anos 50. Reuso em grande escala (componentização de soluções de problemas genéricos) é um problema muito difícil, não-resolvido, mas que tem maior chance de funcionar para uma família de sistemas de um domínio específico. Linguagens de domínio específico (aka DSLs) são uma boa idéia, façamos mais coisas desse tipo!
• Para cada 25% de aumento na complexidade do problema, há um aumento de 100% na complexidade de sua solução. Isso não é uma coisa a ser mudada, é só uma constatação de como as coisas são. Esse fato é muito bom saber porque, apesar de pouco conhecido, explica grande parte dos outros. Veja:
  1. Por que pessoas são tão importantes? Porque é necessário habilidade e inteligência para superar complexidade.
  2. Por que estimar é tão difícil? Porque as soluções são bem mais complicadas do que os problemas aparentam.
  3. Por que reuso em larga escala é tão difícil? Porque grande complexidade significa grande diversidade de soluções.
  4. Por que existem tantas maneiras diferentes de abordar uma solução pra um problema? Porque o espaço de soluções é bastante complexo.
  5. Por que conhecer uma solução existente é a tarefa mais difícil de manutenção de software? Porque há muitas soluções possíveis para qualquer problema.
  6. Por que os softwares têm tantos erros? Porque é difícil de fazer direito na primeira vez.
  7. Por que alguns pesquisadores de software recorrem a defesa de idéias não verificadas em vez de fazer pesquisas avaliativas que verifiquem suas declarações? Talvez porque, no mundo de software complexo, é muito difícil fazer as pesquisas avaliativas tão necessárias e que deveriam anteceder as defesas de idéias.

Eu ainda não tinha visto tantas coisas relevantes — e que muito presenciei serem negligenciadas, às vezes por mim mesmo, sem saber como agir — compactadas em tão poucas páginas, e com dados reais, obtidos usando medidas reais e úteis. Isso que a maioria das fontes do livro são pré-2000 (o livro é de 2003), e tem bastante coisa interessante que é pré-1980! Fenomenal… Me senti besta por ainda não ter ido atrás de material como esse.

Comecei a montar a lista acima para funcionar como um “sneak-peak” do material do livro, mas agora tô achando que o formato funciona legal para apresentar um resumão dos pontos importantes do livro (e eu posso ser mais preguiçoso, também :). Por isso, sigo com a lista de fatos:

• Erros em requisitos são os mais caros de consertar quando o software já está em produção (e os mais baratos de consertar cedo no desenvolvimento), sendo os casos de “requisitos ausentes” os mais difíceis de todos.
• Ocorre uma explosão de requisitos derivados (os requisitos para uma solução em particular) causada pela complexidade do processo de solução, que pode assumir proporções 50 vezes maior que os requisitos originais. Isso faz com que seja impossível de se obter o Santo Graal da rastreabilidade na prática.
• Desenvolvedores alternam entre “modos” de análise e implementação quando o programa está sendo decomposto num nível de primitivas (unidades fundamentais conhecidas e facilmente codificadas) que o responsável pela análise domina. Se o implementador não é a mesma pessoa que fez a análise, as primitivas de cada um serão diferentes, e esse confronto gera uma série de problemas, tanto no caso do projetista ou no do implementador ser o profissional mais experiente. Por isso, é melhor que a pessoa que faça a análise seja a mesma que o implemente. Repetidamente se tenta praticar uma divisão de trabalho de análise e implementação, e repetidamente isso só causa mais problemas.
• Remoção de erros é o que mais consome tempo do ciclo de vida do desenvolvimento de um software. Inspeção rigorosa do código é a maneira mais efetiva de remoção de erros, mas esse fato não é muito propagandeado porque inspeções exigem trabalho mental intenso, não existem fabricantes fazendo dinheiro com isso e ainda, da mesma forma que testes, às vezes são vistas como não essenciais. (Note que apesar dos grandes benefícios para remoção de erros, inspeções rigorosas não substituem os testes.)
• Software que um programador típico acredita ter sido testado a fundo, teve apenas de 55% a 60% dos seus fluxos de lógica executados. Analisadores de cobertura ajudam a aumentar isso para entre 85 a 90%, mas é praticamente impossível atingir os 100%. Mesmo se fosse possível atingir os 100%, isso ainda não seria um critério suficiente para os testes. Em torno de 35% dos defeitos em software surgem de fluxos não-existentes e outros 40% resultam de uma combinação única de caminhos de lógica, portanto não seriam descobertos por uma cobertura de 100%.
• Revisões têm aspectos tanto técnicos como sociológicos. Prestar atenção numa parte e não na outra é receita para o desastre. Por mais que se clame pela “egoless programming”, todos nós temos um investimento emocional e intelectual no resultado do nosso trabalho e estamos vulneráveis quando outros o estão revisando. E quando o resultado de um revisor é considerado pelos demais participantes duma revisão, o ego desse revisor também está na reta. Cabem algumas sugestões:
  1. Não permita gerentes participar de revisões, eles tendem a revisar o produtor em vez do produto.
  2. Não permita pessoas despreparadas participar, elas atrapalham os que estão preparados e causam digressões nos tópicos.
  3. Separe o papel do líder da revisão do papel do produtor, para diminuir o envolvimento do ego do produtor.
• Manutenção é uma solução, e não um problema. É a solução ao problema de não saber exatamente o que se quer construir na primeira vez, e por isso é um big deal, dude, very important! Ela consiste tipicamente de 40 a 80% de custos de software (média 60%), sendo por isso a fase mais importante. E 60% da manutenção consiste em melhorias, 17% apenas para correção de erros, 18% manutenção adaptiva (manter funcionando os recursos existentes em um ambiente novo), e os restantes 5% é o popular “outros” (manutenções preventivas — refatorações — estariam nesses 5%). Essa relação 60% do custo de construção de software é manutenção, e 60% da manutenção é adição de melhorias é chamada regra 60/60. Por fim, como manutenção é tão importante, talvez devesse ser ensinada antes de ensinar a produzir software (ensinar a ler antes de ensinar a escrever).
• Qualidade de software é uma coleção de atributos:
  1. Portabilidade é sobre criar um produto de software facilmente movido para outra plataforma.
  2. Confiabilidade é sobre um software que faz o que devia fazer de forma confiável.
  3. Eficiência é sobre um software que economiza em tempo de execução e consumo de espaço.
  4. Engenharia humana (ou usabilidade) é sobre um software que é fácil e confortável de usar.
  5. Testabilidade é sobre um software que é fácil de testar.
  6. Compreensibilidade é sobre um software que é fácil para o mantenedor compreender.
  7. Modificabilidade é sobre um software que é fácil para o mantenedor modificá-lo.
• Não existe uma ordem universal correta desses atributos que deve ser atingida, mas é importante que cada projeto tenha a sua lista priorizada.

Se você é como eu, os fatos acima devem ter ressonados fortemente com sua experiência. Em vários pontos do livro, experimentei uma sensação de alívio, constantando várias comichões minhas sendo coçadas, e numa forma tão coerente, sensata, comedida, auto-avaliativa, madura…  — nuóssa, agora me apavorei comigo mesmo e a minha sacolinha de adjetivos! :)

Pois não se trata de um time de “desenvolvedores chorões e teimosos que só querem bater contra a gerência”, mas sim de evidência científica, informações coletadas e analisadas de forma estudada e organizada, enfim, fatos! Esquecidos frequentemente, sim, mas sempre serão fatos, e não vão deixar de ser verdade mesmo que muitos na indústria e na academia estejam em negação.

Bem, o livro tem bem mais coisas (tô pulando toda a parte específica de codificação), pra quem quiser saber mais pode visitar os links no fim do artigo ou então arranjar uma cópia do livro mesmo, que vale a pena. Só quero ainda falar sobre algumas das falácias apresentadas no fim do livro:

Falácia: Você não pode gerenciar o que não pode medir.
Errado! Na verdade, fazemos isso o tempo todo. Gerenciamos um monte de tipo de coisas que não temos como medir. Na vida diária mesmo, inclusive, desde relações sociais até os hábitos de alimentação. Gerenciamos até a pesquisa do câncer. Gerenciamos análise e projeto de software, que é uma tarefa essencialmente criativa. Gerenciamos muitas coisas que são intelectuais ou mesmo criativas, sem nenhuma idéia que números deveríamos ter pra nos guiar. Gerentes que trabalham com bom conhecimento tendem a gerenciar qualitativamente, e não quantitativamente.
Todavia, não é porque esse dito é uma falácia que devemos rejeitar a mensagem que ele traz. Afinal, gerenciar tendo em mãos alguns dados úteis é mais fácil que na ausência deles, e por isso é muito importante para o gerenciamento de software medir as coisas úteis.
Boa capacidade de julgamento é vital.

Falácia: Você consegue “gerenciar qualidade” para um produto de software (manage quality into a software product)
Errado também! Aqui é basicamente uma reprise da afirmação anterior sobre qualidade ser composta de alguns atributos: portabilidade, confiabilidade, usabilidade, eficiência, testabilidade, compreensibilidade e modificabilidade. Todos esses atributos da qualidade de software têm aspectos profundamente técnicos, e portanto qualidade é uma realização técnica. Não funciona marketar qualidade, ou “metodologizar” qualidade  – as abordagens dos gerentes para atingir qualidade, que tendem a ser um tiro no pé, alienando os profissionais técnicos. E não ajuda que o inimigo número um de qualidade na maioria dos projetos é a pressão do cronograma. A gerência fica querendo enfiar “qualidade” com uma mão e tirar com a outra!
Note que a falácia aqui é que qualidade seja um trabalho da gerência. A gerência tem um papel muito importante em atingir qualidade: estabelecer a cultura de prioridade em primeiro lugar, remover barreiras que impedem os técnicos de instituir qualidade, contratar pessoas de qualidade (a ultimate melhor maneira de atingir qualidade no produto), e sair do caminho dessas pessoas de qualidade, permitindo-as que façam o que queriam fazer o tempo todo: construir algo que eles possam se orgulhar.

Ler mais:

• Post do Jeff Atwood com a lista completa de fatos e falácias (em inglês) — o texto que me instigou a comprar o livro: http://www.codinghorror.com/blog/2008/03/revisiting-the-facts-and-fallacies-of-software-engineering.html
• “You can indeed manage what you can’t measure”:
  • http://www.galorath.com/wp/you-can-manage-what-you-cant-measure.php
  • http://blogs.hbr.org/davenport/2010/10/what_cant_be_measured.html
  • http://corporatedeathspiral.blogspot.com.br/2009/11/managing-what-you-cant-measure.html
• Série de posts em português discutindo os fatos e falácias do livro:
  • http://mr-bin.blogspot.com.br/2011/03/fatos-e-falacias-de-engenharia-de.html
  • http://mr-bin.blogspot.com.br/2011/03/fatos-e-falacias-de-engenharia-de_18.html
  • http://mr-bin.blogspot.com.br/2011/04/fatos-e-falacias-de-engenharia-de.html
  • http://mr-bin.blogspot.com.br/2011/09/fatos-e-falacias-de-engenharia-de.html
  • http://mr-bin.blogspot.com.br/2011/11/fatos-e-falacias-de-engenharia-de.html

Sobre construir excelente experiência de usuário – livro EffectiveUI

Este é o primeiro post na idéia de escrever sobre os livros que leio, na tentativa de fixar melhor o que tô aprendendo. Rezemos pra que não seja o último! :)

O livro é Effective UI: The Art of Building Great User Experience in Software, os autores são os fundadores e os empregados da empresa EffectiveUI, no site deles tem uma página do livro. Pelo que entendi, a empresa trabalha principalmente com consultoria de UX, e o livro é baseado principalmente na experiência deles. Nunca tinha ouvido falar da empresa antes, mas se a O’Reilly pediu pra eles escreverem o livro, imagino que eles devem saber do que estão falando. :)
Ele trata do assunto: “como fazer um projeto de software de qualidade, considerando a experiência do usuário — UX (User eXperience)”. Quando me recomendaram esse livro, pensei que trataria de alguns princípios básicos de interface e que talvez tivesse algumas receitas de bolo para serem aplicadas no desenho de interfaces na prática. Todavia, um projeto de experiência do usuário^* envolve muito mais do que questões de leiaute, tamanhos e tipografia. De acordo com os autores, para fazer softwares que estimulem o envolvimento do usuário e ajudem-no a fazer suas tarefas, é necessário construir um certo clima desde o começo do projeto, que possibilite a equipe ser eficiente, e manter esse clima durante o projeto até o fim. Por isso, acho que posso dizer que esse livro também é sobre como escapar das armadilhas que causam a maioria dos softwares serem muito ruins de usar, e que fazem projetos fracassarem antes de você ouvir falar deles.

_{* minha tradução para User experience design, não sei se existe termo melhor.}

Boa parte dos conselhos do livro são diretamente aplicáveis para pessoas envolvidas com liderança de projetos, mas o conteúdo interessa qualquer pessoa que esteja envolvido em algum esforço pra produzir software de qualidade.

O engraçado é que, se eu soubesse de antemão exatamente do que o livro tratava, acho que eu não teria me interessado. Mas como me recomendaram como sendo um livro muito bom, resolvi ler e ver o que conseguiria aprender, e no fim das contas valeu muito a pena! O livro é bem abrangente, e fala de muita coisa que como desenvolvedor, é muito útil eu me dar conta. Ainda assim, tenho a impressão que algumas lições ainda vão demorar pra amadurecer na minha cabeça.

Alguns pontos importantes do livro:

•  Melhorias na experiência do usuário (UX) de um produto podem render facilmente retorno sobre investimento, pois criam valor ajudando os usuários a atingir seus objetivos.
• A responsabilidade pela experiência do usuário é de todo mundo, e não funciona sendo delegada a alguns departamentos isolados — basta lembrar de como é “divertido” ligar para o call-center da sua prestadora de telefonia…
• Na hora de vender a idéia de melhorar a UX para as partes interessadas (stakeholders), exponha-as ao feedback dos usuários. Os autores inclusive contam uma história de como os stakeholders de um projeto finalmente decidiram priorizar a melhoria da usabilidade de um produto, depois de assistirem o vídeo de um usuário muito irritado com o software a ponto de esmurrar o teclado.
• Você nunca tem todas as respostas antes do produto ser desenvolvido. Especificações e requerimentos funcionais feitos antes de começar o desenvolvimento são instantaneamente deficientes por terem sido feitos da perspectiva menos informada. Em vez de perder tempo definindo especificações, descubra os objetivos e as prioridades dos usuários e do negócio. Atingir os objetivos do negócio por meio de habilitar os usuários a atingir seus objetivos == sucesso.
• Intolerância a incertezas é intolerável. Durante a maior parte do projeto, sempre haverá incerteza e desconhecidos, aprender a lidar com isso é fundamental. Planejamento detalhado demais está fadado ao fracasso porque muito do desconhecido ainda não foi descoberto. Evite os problemas do Big Design Up Front e comece o desenvolvimento o mais rápido possível. Quanto mais adiante no projeto você estiver, mais sábio você será. Por isso, descubra os objetivos cedo e postergue as decisões sobre os detalhes.
• A coisa mais importante que pode ser feita para o sucesso de um projeto é montar a melhor equipe. A equipe deve reconhecer a importância das necessidades dos usuários para o produto. Sem empatia com os usuários, os desenvolvedores podem acabar sacrificando UX pelo que é mais fácil de fazer (ou por um “desejo de elegância” para o modelo), os designers podem focar demais em deixar bonito em vez de funcional, e outros colaboradores podem dar importância demais às suas suposições sobre como o produto deve ser e deixar de lado a pesquisa de usuário: tudo isso sacrifica a qualidade do produto e diminui as chances dum bom retorno sobre o investimento.

Além da parte inicial que apresenta alguns conceitos de UX, explica sua importância e por que você deveria se importar, o livro tem um capítulo muito interessante sobre como capturar a perspectiva do negócio. Nele são descritos alguns exercícios úteis para ajudar a descobrir as expectativas das partes interessadas, encontrar as reais necessidades por trás das idéias formuladas (por exemplo, alguém pode dizer que deve haver um mecanismo para os usuários trocarem emails, em vez de expor a necessidade de  compartilhamento de recursos e facilidades de colaboração), estabelecer o público-alvo do produto e as características de alguns usuários desse público, e ainda, priorizar quais são as partes importantes disso tudo. Basicamente, uma sucessão de negociações e de aplicações do princípio de Pareto para descobrir o que é realmente necessário.

Mas o trecho que mais me chamou a atenção foi o capítulo intitulado Arquitetura Inicial do Produto (Initial Product Architecture), que discorre sobre as decisões iniciais do desenvolvimento, sobre coisas que serão difíceis de mudar depois. A hora em que são respondida perguntas tipo: “Que tamanho é esse troço que vamos fazer?” “Que outros produtos teremos que integrar?” “Quais linguagens/plataformas vamos utilizar?”  “Como os componentes serão conectados?” “Como as pessoas vão usar as coisas que vamos criar?” “Que ‘cara’ o produto vai ter?”, e várias outras. Segundo os autores, são dois tipos de “arquitetos” que trabalham nessa parte: os “arquitetos de UX” e os “arquitetos técnicos”.

Os arquitetos de UX usariam seus conhecimentos (que envolvem usualmente usabilidade, design gráfico, práticas de engenharia de software, etc, até psicologia) para produzir um refinamento das soluções a serem desenvolvidas através de descrições de cenários contextuais, guias de estilos, mapeamento de fluxos da interface, elaboração de nomenclatura, e outras coisas mais. O livro detalha algumas técnicas usadas, e eu curti em especial a parada sobre o uso de cenários (exemplos aqui – em inglês), porque esses tempos comecei a fazer algo parecido num projeto sem saber, e me pareceu que funcionava legal. A sacada desses cenários é que você descreve os passos que o usuário precisa para fazer uma tarefa, mas não precisa especificar cada detalhezinho que você não precisa definir. Dessa forma, os cenários representam as características tradicionais de um framework: deixam fixo e estável o que já se sabe, flexível e maleável o que ainda precisa ser descoberto.

Ainda nesse mesmo estágio de arquitetura inicial, os arquitetos técnicos resolveriam os aspectos técnicos chave do produto que devem ser definidos de antemão, tendo em vista as necessidades e restrições existentes. As tarefas geralmente envolvem coisas como descobrir quais recursos existentes serão aproveitados, quais linguagens/plataformas devem ser usadas, que elementos de infraestrutura serão necessários, e por último mas não menos importante, começar a identificar a lógica de negócio (que usualmente está espalhada em outros softwares, planilhas Excel e às vezes apenas na cabeça de algumas pessoas).

Por fim, os últimos dois capítulos tratam sobre o restante do projeto (onde é gasto a maior parte do tempo), ressaltando a importância de feedback e de comunicação durante todas as etapas do projeto. O primeiro deles discorre especificamente sobre a importância do processo de desenvolvimento ser iterativo, para agilizar a obtenção de feedback e a reavaliação das decisões, restrições e objetivos levando em conta o feedback obtido. Esse capítulo dá algumas idéias interessantes sobre minimizar as desvantagens de um processo de desenvolvimento problemático que você pode estar sendo forçado a trabalhar (como um cascata ou um BDUF):

•  permitir mais liberdade nas etapas posteriores de desenvolvimento; às vezes isso pode ser feito simplesmente renomeando os documentos “requisitos” e “especificações” produzidos para “diretrizes” e “recomendações”. :)
• envolver profissionais de outras disciplinas nas diferentes etapas: colocar alguns profissionais de UX e desenvolvedores também para trabalhar na definição dos requisitos de negócio, envolver também pelo menos um especialista de UX e de negócio na etapa de desenvolvimento.
• apressar as primeiras etapas para chegar logo na etapa de desenvolvimento, que será melhor de responder as perguntas. Qualquer especificação feita antes será cheia de erros e omissões e muitas vezes são criadas apenas por necessidades burocráticas, então é melhor não gastar muito tempo nisso e ir logo para a etapa em que as respostas serão realmente obtidas.

E o último é sobre as ações relacionadas aos releases, que devem ter como objetivo obter feedback (versão alpha para feedback de usuários internos, versão beta para feedback de uma amostra de usuários mais perto do real), e também das tarefas necessárias após o release: marquetar o produto (muito necessário, mesmo que seja para uso interno da organização), montar a documentação para os usuários (de preferência embutida no próprio produto, disponível no contexto), e recapitular as lições aprendidas. É importante verificar se os objetivos do negócio originais estão sendo alcançados, e os objetivos do usuário também: o resultado pode virar material para o próximo projeto. Pode ser útil embutir no produto mecanismos para rastrear as ações dos usuários, para verificar quais áreas requeiram atenção.

Enfim, talvez esse texto tenha ficado comprido demais, mas pode também ser um bom sinal: o livro é bom e até que aprendi bastante coisa. Recomendo!

Valeu, Filipi (NEXTT), pela recomendação do livro. :)