Código = Documentação?

Na pequena série sobre o "Agile BA" eu prometi um post para falar especificamente sobre Documentação - o 2º maior pesadelo dos programadores.

Nick Malik, do Inside Architecture, chegou antes, e no último dia 11/jul publicou 4 razões para não acreditarmos que código é documentação suficiente para processos de negócio.

O excelente artigo do Nick não me isentará de voltar ao assunto. Acontece que eu quero ir um pouco além, tentando entender ou explicar o trauma que é a tal "documentação". Enquanto trato de outras prioridades, fica a provocação:

"Software is the leaky abstraction. It makes poor documentation for a business process."

.:.

Marcadores: , ,

segunda-feira, 16 de julho de 2007 | | Compartilhe: Adicionar esta notícia no Linkk

neste post

 

Anonymous Phillip Calçado "Shoes" disse:

Eu ia té assinar o feed do cara mas essa afirmação:

"@Brian

"Show me a business process not documented in the code and I'll show you an out of date, innacurate process documentation."

And I will show you an organization at Level 1 of process maturity."

É simplesmente ridícula. É só passear por empresas e cases de empresas com maturidade de processo (i.e. CMMi) e ver que é mentira. Acabo de concluir o phase-out de um sistema comprado de uma empresa com CMMi 5 e os Casos de Uso pararam de ser atualizados quando a empresa se deu conta que não conseguiria mantêr seu processo burocrático com tnatas mudanças de escopo. Um desastre completo, pelo menos para mim como cliente.

De qualquer modo bloguei sobre o tema:

[]s

 
 

Anonymous Phillip Calçado "Shoes" disse:

Ops, faltou o link:

http://blog.fragmental.com.br/2007/07/27/model-driven-development-e-durepoxi/

 
 

Blogger Paulo Vasconcellos disse:

Estranho isso, mas vou reproduzir aqui o comentário que deixei no blog do Phillip "Shoes" Calçado:

Caro Philip “Shoes”,

O ponto forte do artigo citado são as 4 razões pelas quais código não é uma boa documentação para processos de negócio. Esqueça (ou perdoe) bullshitagens sobre níveis de maturidade e afins. Simplesmente, não é o caso.

E casos de uso, como documentação, são tão ‘fracos’ quanto código. Tanto que são totalmente ignorados pela EPBE (Eriksson-Penker Business Extensions), extensão da UML que indico para a modelagem de negócios.

Como você, quero crer que DDD e DSL’s caminham para reduzir muito (ou eliminar totalmente) o gap que temos entre negócio e código. Tá na fila: vou mergulhar no tema. Espero em breve ter condições de transcrever seus exemplos a partir do outro ponto de vista.

[]’s

Paulo

 

Qual é a sua opinião?

A T E N Ç Ã O

Esta é uma versão antiga do finito. Só é mantida aqui porque o Google ainda direciona algumas buscas para cá. E eu seria louco se simplesmente o desativasse, certo? Mas, por favor, não deixe de visitar o finito certo. Todo o conteúdo aqui disponível está lá também.
  • Catálogo de Serviços

  • Contato Imediato

    • My status

    Assine & Compartilhe

    Busca

    Technorati


  • Temas & Tags

  • Lista completa no del.icio.us
  • Últimos Posts

  • Créditos & Débitos