Os lemmings corporativos Vs Os buzzwords do momento
Isso mesmo lemmings é aquele joguinho do super nes, que por sinal era muito bom! Nos últimos 5 anos vem acontecendo dois fenômenos distintos nas empresas de TI, eu chamo esses fenômenos de Lemmings corporativos e Buzzwords do momento.
Vamos começar pelos lemmings. Lemmings são criaturinhas pequenas que ficam andando de uma lado pro outro até que você faça alguma coisa, que pode ser explodir uma bomba ou até mesmo matar um lemming, muitas empresas de ti no mercado se encaixam nesse cenário. Eu digo isso não só por experiência própria mas também por relatos de colegas e amigos.
Muitas empresas seguem a abordagens de desenvolvimento by the book, ou seja, a risca e isso muitas vezes é um problema. Esse fato acontece tanto para tecnologias como para processos e métodos. Um exemplo disso: A empresa usa todo o RUP e para desenvolvimento segue um padrão orientado a dados ou uma solução clássica de Swing com EJB.
OBS: Não estou criticando aplicações orientadas a dados, até por que em determinados cenários é muito mais simples e se resolve o problema de maneira muito mais eficiente do que uma abordagem OO. Também não estou criticando Swing e EJB que em determinados cenários podem realmente ser uma boa solução.
A questão é ficar seguindo essas "Arquiteturas de Referências" e os processos by the book, muitas vezes gerando um tempo de resposta muito baixo e outras até afundando o projeto literalmente. Essa filosofia é muito comum em empresas grandes que preferem seguir fazendo os projetos da mesma forma mesmo sabendo que existem perdas, mas pelo menos com a garantia de que funciona.
Tanto é que linguagens como Cobol e PL/I ainda estão por ai. Mas o fato é que existe essa tendência de seguir o caminho conhecido já. Essa abordagem tem pontos positivos e pontos negativos.
O outro fenômeno é o do Buzzwords do momento. Consiste em *palavras* mágicas, que adicionadas ao projeto dão falsas idéias de:
O que acontece é que as pessoas acham que devem apenas aprender frameworks, pojos e web e pronto, já posso montar uma arquitetura, e isso no mercado tem muito!
Imagine a seguinte situação você vai ao médico por que está com dores de cabeça;
Em termos práticos o que isso significa? Significa que enquanto você não levantar os Casos de uso/Requisitos/Features não é possível construir uma solução. Nesse ponto tanto faz se você usa casos de uso que seria uma abordagem mais RUP e Open UP, ou se você usa Features no caso do FDD ou se você usa Requisitos no caso de uma abordagem mais estilo engenharia de requisitos.
Precisamos construir software de forma pragmática, mais uns meses e essa palavra entra para lista de buzzwords também, mas equilibrando as anciendades de uma solução precoce e a possível copia de uma solução estilo leemings.
Nesses aspectos eu gosto muito da abordagem do RUP e do Open Up, se no marco de concepção essas coisas não ocorrerem e prosseguirem corretamente no marco de elaboração o projeto não avança para próxima etapa. Claro que isso pode ser perigoso, pode levar ao cascateamento do projeto.
Abraços.
Vamos começar pelos lemmings. Lemmings são criaturinhas pequenas que ficam andando de uma lado pro outro até que você faça alguma coisa, que pode ser explodir uma bomba ou até mesmo matar um lemming, muitas empresas de ti no mercado se encaixam nesse cenário. Eu digo isso não só por experiência própria mas também por relatos de colegas e amigos.
Muitas empresas seguem a abordagens de desenvolvimento by the book, ou seja, a risca e isso muitas vezes é um problema. Esse fato acontece tanto para tecnologias como para processos e métodos. Um exemplo disso: A empresa usa todo o RUP e para desenvolvimento segue um padrão orientado a dados ou uma solução clássica de Swing com EJB.
OBS: Não estou criticando aplicações orientadas a dados, até por que em determinados cenários é muito mais simples e se resolve o problema de maneira muito mais eficiente do que uma abordagem OO. Também não estou criticando Swing e EJB que em determinados cenários podem realmente ser uma boa solução.
A questão é ficar seguindo essas "Arquiteturas de Referências" e os processos by the book, muitas vezes gerando um tempo de resposta muito baixo e outras até afundando o projeto literalmente. Essa filosofia é muito comum em empresas grandes que preferem seguir fazendo os projetos da mesma forma mesmo sabendo que existem perdas, mas pelo menos com a garantia de que funciona.
Tanto é que linguagens como Cobol e PL/I ainda estão por ai. Mas o fato é que existe essa tendência de seguir o caminho conhecido já. Essa abordagem tem pontos positivos e pontos negativos.
O outro fenômeno é o do Buzzwords do momento. Consiste em *palavras* mágicas, que adicionadas ao projeto dão falsas idéias de:
- Maturidade
- Solução Correta
- Elegância
- Confiança
- Frameworks
- Pojos
- Web
- Ajax
- SOA
O que acontece é que as pessoas acham que devem apenas aprender frameworks, pojos e web e pronto, já posso montar uma arquitetura, e isso no mercado tem muito!
Imagine a seguinte situação você vai ao médico por que está com dores de cabeça;
- Médico: Olá, o que você tem?
- Você: Tenho dores de cabeça doutor.
- Médico: Hm... entendo...
- Você: Mas é grave doutor, o que eu tenho?
- Médico: Câncer e se duvidar AIDS também
- Você: o que ???
- Médico: É e os remédios são A, B e C.
Em termos práticos o que isso significa? Significa que enquanto você não levantar os Casos de uso/Requisitos/Features não é possível construir uma solução. Nesse ponto tanto faz se você usa casos de uso que seria uma abordagem mais RUP e Open UP, ou se você usa Features no caso do FDD ou se você usa Requisitos no caso de uma abordagem mais estilo engenharia de requisitos.
Precisamos construir software de forma pragmática, mais uns meses e essa palavra entra para lista de buzzwords também, mas equilibrando as anciendades de uma solução precoce e a possível copia de uma solução estilo leemings.
Nesses aspectos eu gosto muito da abordagem do RUP e do Open Up, se no marco de concepção essas coisas não ocorrerem e prosseguirem corretamente no marco de elaboração o projeto não avança para próxima etapa. Claro que isso pode ser perigoso, pode levar ao cascateamento do projeto.
Abraços.
