segunda-feira, março 30, 2009

Jack Ganssle e Engenharia de Software

Na semana passada tive o prazer de assistir ao Workshop "Better Faster Firmware", promovido pela Tempo Real Eventos em conjunto com o Portal Embarcados. Embora a palestra fosse voltada para Sistemas Embarcados, e tivesse algumas partes bastante específicas de hardware e de software de baixo nível, grande parte da palestra se referiu a aspectos de Engenharia de Software que se aplicam a todo tipo de software.

Neste post vou comentar um pouco sobre o workshop e apresentar um resumo (muito simplificado) destes pontos mais genéricos.

Jack Ganssle

Não vou repetir aqui o currículo da fera, que você pode conferir aqui (em português) e aqui (em inglês). Basta dizer que tem muito tempo de experiência na área e hoje é um consultor que auxilia inclusive a NASA. Pessoalmente é um grande sujeito. Foi extremamente atencioso com todos, tanto durante o workshop como nos intervalos e no pequeno encontro no final.

O Workshop

A Tempo Real Eventos está de parabéns pela iniciativa de trazer um especialista estrangeiro, ainda mais para uma área não muito conhecida e badalada.

A crise infelizmente atrapalhou um pouco o evento e deve-se louvar também a coragem dos envolvidos em seguir em frente mesmo com um cenário adverso (ao custo de algumas pequenas economias secundárias). O custo do evento pode também ter assustado algumas pessoas, acostumadas com especialistas locais e/ou eventos subsidiados por fabricantes, mas estava dentro do que se pode esperar de um evento com um especialista estrangeiro de primeira grandeza.

O resultado foi uma sala não muito grande, com um pouco menos de 50 pessoas. Talvez alguém reclame que os coffee breaks não tinham muita variedade ou se arrependido de ter dito que entendia bem inglês (o que permitiu dispensar a tradução simultânea no evento), mas se tiver é uma minoria que estava silenciosa por lá. O que mais se escutava eram elogios e crença de que se seguirmos alguns dos ensinamentos vamos evitar muitos bugs em campo (o que representa um ganho imenso frente ao custo do workshop).

Engenharia de Software

O primeiro ponto mais genérico abordado é que as mudanças normalmente falham. Existem três abordagem possíveis para as mudanças: fazer nada, impor de cima para baixo ou criar de baixo para cima; apenas a última costuma dar resultados.

A estratégia básica para gerar produtos mais rapidamente consiste em usar boas idéias técnicas, inciar os testes no primeiro dia, gerenciar características para garantir prazo, detonar bugs agressivamente e criar um ambiente eficiente de desenvolvimento.

Uma coisa para tomar cuidado é com as medidas. Medidas podem ser usadas como motivadores, para gerar recompensas/punições e para entender o que está acontecendo. As duas primeiras aplicações costumam gerar distorções.

A qualidade é outra questão complicada. Todos querem, desde que seja de graça. É ela sai de graça para quem estiver disposta a investir pesado nela. Quem define o que é a qualidade é o cliente.

Todo mundo considera que reuso de código é bom, certo? Que tal então um slide avisando que reuso é veneno? O reuso requer uma vontade de reusar, um código bom e bem documentado e um código com poucas dependências. Antes de desenvolver um código para reuso, você precisa ter escrito este código pelo menos três vezes. E você só vai ter lucro a partir da terceira vez que reaproveitar o código.

Um fato conhecido é que o tempo de desenvolvimento aumenta de forma não linear com a complexidade do projeto. Um dos motivos disso é que um projeto maior requer mais pessoas, o que aumenta o tempo gasto na comunicação entre elas. A solução é particionar o código em pedaços pequenos com poucas dependências entre eles.

Um projeto possui metas técnicas, pessoais e de mercado. É preciso definir de forma honesta as prioridades entre estas metas, que acabam sendo conflitantes. É o famoso triângulo cronograma, qualidade e características - escolha duas.

Bugs são uma realidade da programação. Jack defende que os bugs devem ser resolvidos imediatamente, antes de se acrescentar código novo. A maioria dos bugs se concentram em poucos módulos - eles devem ser jogados fora e refeitos.

Além de funcionar um software deve comunicar a sua estrutura a outros projetistas. Para isto é fundamental a empresa ter um padrão de desenvolvimento (nomes, proibir variáveis globais, comentários, etc).

O programador deve gerenciar a complexidade (se depurar é duas vezes mais difícil que programar e você programa da forma mais 'esperta' que conseguir, o que vai acontecer?). Existe uma medida simples de complexidade, a complexidade ciclomática, que basicamente mede a quantidade de caminhos existentes dentro de uma rotina. Um código com complexidade ciclomática acima de 50 é considerado intestável de altíssimo risco.

Um método de reduzir bugs de forma eficiente é a Inspeção de Código, o que pressupõe existir um padrão de desenvolvimento. As inspeções não atrasam projetos, defeitos sim.

Uma segunda técnica para reduzir bugs é o Projeto Por Contrato, onde se explicita para cada rotina o que se espera das entradas (pré-condições), o que se promete para a saída (pós-condições) e o que será mantido (invariantes). Se você não é capaz de dizer exatamente o que uma rotina faz, é pouco provável que ela faça o que você espera.

O contrato pode ser garantido por teste adicionais no código. Na medida do possível, estes testes devem ser mantidos no código de produção - é a filosofia 'test what you flight, flight what you test' da NASA (isto é, os testes devem usar condições iguais à de produção e a produção deve rodar exatamente o código testado).

Na parte de metodologia, Jack recomenda o modelo evolucionário (também conhecido como espiral) e tem algumas boas restrições ao XP. Para estimar a duração, recomenda o método 'Wideband Delphi'.

Não esquecer que o código se deteriora com o tempo. É preciso investir periodicamente na limpeza do código (o que tem um custo linear), pois a deterioração tem um custo exponencial e rapidamente chega ao ponto em que o código tem que ser abandonado por não ser mais viável mantê-lo.

Em termos de ambiente de trabalho, existe um famoso estudo que mostra uma nítida correlação entre o ambiente de trabalho e a qualidade do código (Jack ficou abismado com ao saber que a maioria dos presentes trabalha em um ambiente aberto, não contando nem mesmo com um cubículo). Não esquecer também que tocar vários projetos simultaneamente reduz fortemente a produtividade.

Desastres

A última parte do workshop é a apresentação de uma sucessão de desastres, algum com custo de milhões de dólares e outros com custo de vidas. O padrão é claro:
  • teste insuficiente e em condições diferentes das reais
  • ausência de revisão de código
  • tratamentos de exceção inexistentes ou ridículos
  • pessoas cansadas cometem erros
  • nunca engane as ferramentas (como o sistema de controle de versão)
  • verifique valores antes de processá-los ou apresentá-los
O pior é que os erros são repetidos continuamente pelas mesmas pessoas. Daí a importância do postmortem: investigar no final do projeto o que deu certo e o que não deu.

5 comentários:

Breno Faria disse...

Realmente, este Workshop deve ter sido o máximo! Obrigado por compartilhar conosco o que viu por lá!

Não conhecia o Jack Ganssle, mas pelo seu currículo, dá pra perceber que ele é uma autoridade na área... Vou me informar mais...

Grande abraço Daniel...

techberto disse...

Postmortem ou Lições Aprendidas, o importante realmente é se aperfeiçoar com a análise dos erros!

A métrica da complexidade ciclomática foi algo que me chamou muito a atenção, não mais do que a angústia que é ver a importância que a inspeção de código realmente tem, com um pensamento paralelo e concorrente de como é complicado convencer sua implementação nas empresas.

Ver dicas de otimização matemática para firmware entre dicas de ferramental e engenharia de software foi algo muito precioso e proporcionou uma convergência sensacional.

Agora uma situação recorrente foi ver que muito do que já lemos, conhecemos ou aprendemos não utilizamos na prática; ver este workshop apresentado pelo Jack foi muito enriquecedor e gratificante.

Fiquei muito feliz por não ter ouvido nada similar como os conceitos de NNPP: http://blog.jayfields.com/2009/01/cost-of-net-negative-producing.html
...mas sim ter ouvido exaustivamente uma máxima muito verdadeira:

- pessoas cansadas cometem erros!!


Parabéns pelo post!

Abração

Alberto Fabiano

techberto disse...

Outra assunto que apesar de ter sido tratado brevemente, mas que gostei muito, foi ver a abordagem objetiva, prática e centrada do conceito de "dívida técnica".

Sobre este conceito há um artigo muito interessante do Steve McConnell que talvez seja um dos que melhor explana esta metáfora:

http://tiny.cc/Technical_Debt

WT disse...

Se o resumo é bom desse tanto, imagino como deve ter sido o evento. Parabéns.

DGrillo disse...

Parabéns pelo ótimo resumo. Uma pena eu não ter ido.