asaudate wrote:

Quanto à questão do resultado rápido, uma metodologia ágil muitas vezes resolve o problema, não? Nesse caso, vocês usaram alguma metodologia ágil?

asaudate wrote:
Antes de mais nada: Go Horse NÃO funciona. Essa é a maior ilusão que pode haver. Dá impressão que funciona porque, no começo, as funcionalidades são, sim, entregues mais rapidamente. O problema é que o software tem um ciclo de vida muito, muito maior do que a fase de desenvolvimento. Quando outros começam a desenvolver funcionalidades em cima de uma base "quebrada", todo o software começa a ruir. Mas tem sempre um gerente de projeto, ou gerente comercial, ou gerente não sei das quantas, que é um especialista na arte do tapinha nas costas. Quando o software começa a ir pro buraco, ele já fez amizade com o cliente e aí, é só dar tapinha nas costas que está tudo resolvido. Se está indo pro buraco, a culpa é dos programadores que são incompetentes, não do gerente, já que, no começo, estava indo tão bem...

YvGa wrote:

asaudate wrote:
Antes de mais nada: Go Horse NÃO funciona. Essa é a maior ilusão que pode haver. Dá impressão que funciona porque, no começo, as funcionalidades são, sim, entregues mais rapidamente. O problema é que o software tem um ciclo de vida muito, muito maior do que a fase de desenvolvimento. Quando outros começam a desenvolver funcionalidades em cima de uma base "quebrada", todo o software começa a ruir. Mas tem sempre um gerente de projeto, ou gerente comercial, ou gerente não sei das quantas, que é um especialista na arte do tapinha nas costas. Quando o software começa a ir pro buraco, ele já fez amizade com o cliente e aí, é só dar tapinha nas costas que está tudo resolvido. Se está indo pro buraco, a culpa é dos programadores que são incompetentes, não do gerente, já que, no começo, estava indo tão bem...

Sim, funciona, e a grande maioria dos profissionais da nossa area so consegue fazer funcionar usando Go Horse.

Com funcionar eu quero dizer, conseguir chegar ao ponto de entregar e manter o sistema vivo. E isso muitas vezes acontece, mesmo em ambientes sem um minimo de organizacao.

Quando eu disse que só o Go Horse funciona para a maioria eu estava tentando enfatizar que o correto nao eh o que a maioria ve como correto. Que normalmente eh documentacao detalhada, bduf, congelamento de fases dos projetos e etc...

Quem nunca teve um gerente que em um momento ou outro disse: "A partir de hoje vamos especificar e documentar tudo". Os que de fato fizeram isso devem ter afundado o projeto, os que nao fizeram continuaram com Go Horse e talvez tenham conseguido entregar aquela parafernalha.

Eu disse isso porque eu ja estou cansado de ver, ouvir e ler gente reclamando de codigo ruim, codigo isso e aquilo, mas essas mesmas pessoas nao sao capazes elas mesmas de escrever algo melhor, nao sao elas mesmas capazes de arrumar o que esta errado.

Ai se irritam quando tem que dar manutencao em codigo de outro e saem aos quatro ventos reclamando, mas quando finalmente descobrem o que precisa ser feito, poem mais um "if" la, viram as costas e vao embora.

Entao, o que eu quero dizer é: se voce nao eh capaz de lidar com código ruim e melhora-lo, voce nao pode reclamar, porque no fim das contas faz a mesma coisa, e se pegar codigo bom pela frente, vai acabar estragando.

Concluindo, Go Horse nao funciona, mas entrega. O contrario, nao funciona e nao entrega.

asaudate wrote:

Mas aí, você só está vendo como se fosse uma moeda e só tivesse dois lados. E metodologias ágeis, já viu? Não tem documentação, mas também não tem Go Horse. Tem software funcionando =)


Você já viu códigos em empresas como Caelum? Thoughtworks? Posso te garantir que eles não dão a mínima pra documentação, mas o software sai de lá redondinho.


Quanto a dar manutenção no código, é uma ótima oportunidade para exercitar o princípio do escoteiro (esboçado pelo Uncle Bob): sempre, sempre, sempre, deixe o lugar um pouco melhor do que quando você chegou. Mesmo que seja pra deixar uma variável com nome mais legível, é importante sempre refatorar de modo a melhorar um pouco o código.

E, insisto... não adianta "entregar" e o software não durar um ano. Software tem vida útil e, quanto mais XGH, menor a vida.

YvGa wrote:
Eu entendo o que voce diz e concordo, eu sei q eh possivel fazer bem feito sem precisar documentar tudo, nem sair fazendo a primeira coisa que vem a cabeca.

Talvez eu nao esteja sabendo me explicar, mas eu nao estou defendendo o Go Horse sob nenhuma hipotese, o que me preocupa sao os que ao lerem sobre o Go Horse acharem que a outra ponta eh a correta.

Por isso eu digo: Go Horse eh ruim? Sim, eh ruim. Mas BDUF eh pior ainda. A minha critica eh aos que criticam o codigo dos outros incessantemente, mas nao conseguem criar codigo decente eles mesmos.

kicolobo wrote:
* Nossa produtividade não é constante (tem dias em que você produz mais, noutros, menos)
* O que produzimos não é tangível, e portanto cria a impressão de ser "fácilmente modificável"
* O cliente não entende os dois fatos anteriores
* Quem gerencia e deveria instruir o cliente também não

adriano_si wrote:

kicolobo wrote:
* Nossa produtividade não é constante (tem dias em que você produz mais, noutros, menos)
* O que produzimos não é tangível, e portanto cria a impressão de ser "fácilmente modificável"
* O cliente não entende os dois fatos anteriores
* Quem gerencia e deveria instruir o cliente também não

posso usar essa sua citação para um Post no meu Blog ???

Abs []

asaudate wrote:
Ah, sim. Mas acredito que isso é uma questão de maturidade do desenvolvedor. Como o ViniGodoy já disse (e eu reitero), nós mesmos somos culpados pela aplicação do XGH.