Decepção

[quote=kicolobo]
O grande problema é que desenvolvimento de software é visto como manufatura convencional quando não é. Acredito que dai surjam todos os problemas.

  • 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

E as quatro dificuldades essenciais do software também são normalmente ignoradas:

  • Complexidade
  • Conformidade (você precisa estar de acordo com outras interfaces e com seu requisito)
  • Invisibilidade (software é difícil de visualizar por ser intangível)
  • Mutabilidade (software, ao contrário de prédios, muda o tempo todo, o que justifica a necessidade de uma base sólida)

Ai entram as sabedorias “lugar comum”. Já trabalhei em uma empresa que escutei o seguinte de um dos clientes internos: “já gerenciei N construções de IMENSA escala. Você tá me dizendo que gerenciar este projeto de software não é a mesma coisa?”[/quote]

Nossa, essa das construções é impagável! Deve dar vontade de ir trabalhar, no dia seguinte, com um daqueles chapéus de pedreiro! :lol:

[quote=asaudate]
Nossa, essa das construções é impagável! Deve dar vontade de ir trabalhar, no dia seguinte, com um daqueles chapéus de pedreiro! :lol: [/quote]

Você não tem noção do quão preciso você foi. Isto ocorreu na época em que eu trabalhava com engenharia de minas.

[quote=kicolobo][quote=asaudate]
Nossa, essa das construções é impagável! Deve dar vontade de ir trabalhar, no dia seguinte, com um daqueles chapéus de pedreiro! :lol: [/quote]

Você não tem noção do quão preciso você foi. Isto ocorreu na época em que eu trabalhava com engenharia de minas. [/quote]

Engenharia de minas? Conta essa história!

Oi asaudate,

sim, eu trabalhava como desenvolvedor em uma empresa que desenvolvia processos de engenharia de minas. Foi uma experiência maravilhosa, porque ficava nítida a grande dificuldade da nossa área, que é justamente expor o fato de sermos “diferentes” pelas razões que citei acima.

Como eu tinha de lidar com profissionais (algumas das pessoas mais brilhantes que já conheci) cujo trabalho envolvia a construção de bens extremamente sólidos, era muito comum a dificuldade do pessoal em entender esta diferença. Aliás, este era a principal dificuldade do trabalho. Foi muito enriquecedor pra mim e, acredito, para eles também.

Aliás, toda experiência que te obriga a anular o ego é excelente né?

[quote=kicolobo]Oi asaudate,

sim, eu trabalhava como desenvolvedor em uma empresa que desenvolvia processos de engenharia de minas. Foi uma experiência maravilhosa, porque ficava nítida a grande dificuldade da nossa área, que é justamente expor o fato de sermos “diferentes” pelas razões que citei acima.

Como eu tinha de lidar com profissionais (algumas das pessoas mais brilhantes que já conheci) cujo trabalho envolvia a construção de bens extremamente sólidos, era muito comum a dificuldade do pessoal em entender esta diferença. Aliás, este era a principal dificuldade do trabalho. Foi muito enriquecedor pra mim e, acredito, para eles também.

Aliás, toda experiência que te obriga a anular o ego é excelente né?[/quote]

Nossa… deve ter sido realmente “enriquecedor” :?

Curiosidade: o projeto foi entregue no prazo? Usou XGH?

[quote=ViniGodoy]Aliás, você também deveria criar mecanismos para mostrar para chefia o quanto “Go Horse” custa caro.
[/quote]

Isso pra mim, , é o que diferencia um profissional bom de um profissional excelente.

[quote=asaudate][quote=kicolobo]Oi asaudate,

sim, eu trabalhava como desenvolvedor em uma empresa que desenvolvia processos de engenharia de minas. Foi uma experiência maravilhosa, porque ficava nítida a grande dificuldade da nossa área, que é justamente expor o fato de sermos “diferentes” pelas razões que citei acima.

Como eu tinha de lidar com profissionais (algumas das pessoas mais brilhantes que já conheci) cujo trabalho envolvia a construção de bens extremamente sólidos, era muito comum a dificuldade do pessoal em entender esta diferença. Aliás, este era a principal dificuldade do trabalho. Foi muito enriquecedor pra mim e, acredito, para eles também.

Aliás, toda experiência que te obriga a anular o ego é excelente né?[/quote]

Nossa… deve ter sido realmente “enriquecedor” :?

Curiosidade: o projeto foi entregue no prazo? Usou XGH?[/quote]

Ou, ai que tá. Foi REALMENTE enriquecedor (sem qualquer tipo de irônia), porque no processo, as duas partes cresceram muito:

  • Eu compreendi melhor as dificuldades do cliente em entender o nosso oficio
  • O cliente compreendeu melhor o modo como nós trabalhamos

E, pra surpresa de todos, não houve nenhum Go Horse. Houve tentativas, mas eram frustradas por causa do diálogo. Este nem sempre era lá AQUELA maravilha, muitas vezes você precisa pisar em ovos e tal, mas no final das contas, quando rola este tipo de troca todo mundo sai ganhando.

[quote=kicolobo][quote=asaudate][quote=kicolobo]Oi asaudate,

sim, eu trabalhava como desenvolvedor em uma empresa que desenvolvia processos de engenharia de minas. Foi uma experiência maravilhosa, porque ficava nítida a grande dificuldade da nossa área, que é justamente expor o fato de sermos “diferentes” pelas razões que citei acima.

Como eu tinha de lidar com profissionais (algumas das pessoas mais brilhantes que já conheci) cujo trabalho envolvia a construção de bens extremamente sólidos, era muito comum a dificuldade do pessoal em entender esta diferença. Aliás, este era a principal dificuldade do trabalho. Foi muito enriquecedor pra mim e, acredito, para eles também.

Aliás, toda experiência que te obriga a anular o ego é excelente né?[/quote]

Nossa… deve ter sido realmente “enriquecedor” :?

Curiosidade: o projeto foi entregue no prazo? Usou XGH?[/quote]

Ou, ai que tá. Foi REALMENTE enriquecedor (sem qualquer tipo de irônia), porque no processo, as duas partes cresceram muito:

  • Eu compreendi melhor as dificuldades do cliente em entender o nosso oficio
  • O cliente compreendeu melhor o modo como nós trabalhamos

E, pra surpresa de todos, não houve nenhum Go Horse. Houve tentativas, mas eram frustradas por causa do diálogo. Este nem sempre era lá AQUELA maravilha, muitas vezes você precisa pisar em ovos e tal, mas no final das contas, quando rola este tipo de troca todo mundo sai ganhando.[/quote]

Diálogo com o cliente, você quer dizer? Ele pedia pra você fazer XGH?

[quote=asaudate]
Diálogo com o cliente, você quer dizer? Ele pedia pra você fazer XGH?[/quote]

Exatamente. É outra realidade que muitas vezes a gente ignora.
É muito comum a gente pensar: “XGH é coisa de gerente”. Nem sempre. Muitas vezes é decorrente do próprio cliente, que na ansiedade de ver o resultado rápido te força a isto.

Quer ver um exemplo? É muito comum você virar pro cliente e dizer que se for por este caminho vai dar merda, e este achar que o fornecedor está fazendo drama, que o problema não é tão grave assim. Não é raro você ouvir coisas do tipo “tu tá dourando a pílula”.

No final, é aquela questão: você tem de ter jogo de cintura, mostrar que o cara tá errado e ir em frente.

[quote=kicolobo][quote=asaudate]
Diálogo com o cliente, você quer dizer? Ele pedia pra você fazer XGH?[/quote]

Exatamente. É outra realidade que muitas vezes a gente ignora.
É muito comum a gente pensar: “XGH é coisa de gerente”. Nem sempre. Muitas vezes é decorrente do próprio cliente, que na ansiedade de ver o resultado rápido te força a isto.

Quer ver um exemplo? É muito comum você virar pro cliente e dizer que se for por este caminho vai dar merda, e este achar que o fornecedor está fazendo drama, que o problema não é tão grave assim. Não é raro você ouvir coisas do tipo “tu tá dourando a pílula”.

No final, é aquela questão: você tem de ter jogo de cintura, mostrar que o cara tá errado e ir em frente.

[/quote]

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?

hehehe o pior são empresas que se dizem “não adeptas ao XHG”, dizendo que são diferentes e utilizam como argumento para te pagar pouco

oh yeah, smells like (put a company here)

tirando um pouco das piadas, qual a sugestão para acabar com o GoHorse? acabar com as fábricas de javeiros fast-food? exigir literatura básica?

Não devemos simplesmente criticar, mas achar maneiras de melhorar as coisas.

Acho esse tema extremamente complexo, pois muitas vezes há falta um “norte” pra dizer o que é certo ou errado. Você vai ver gente que reclama de XGH sendo que algo de verdade nem chega a ser XGH ou então, só pelo fato de ter uma idéia contrário já é taxado de XGH.

Agora. Temos que reconhecer que “Go Horse” é um problema nosso.

  1. São os desenvolvedores que acabam optando por essa técnica. Você, como membro de um time, não deve fazer isso, e deve orientar seus colegas e não irem pro “go horse” também. Deve mostrar a eles os problemas que as abordagens deles estão gerando, e que eles estão sendo pouco produtivos assim.

  2. O cliente não tem qualquer obrigação de entender o que você faz. Ou vocês fazem curso de engenharia aeronáutica antes de pegar um vôo? Falar claramente pra o cliente e orienta-lo é nosso papel. E, infelizmente, não sabemos falar a lingua da clientela.

  3. O chefe é um cliente. Um cliente interno, mas um cliente mesmo assim. Então, o caso 2 se aplica a ele também. Ele deveria conhecer mais sobre seu trabalho, mas o papel dele é gerencial, não técnico. Você deve aprender o que o seu chefe valoriza e por que ele faz as coisas daquela forma. Deve aprender a argumentar com o vocabulário dele, fornecendo dados que são relevantes para ele. Não adianta falar em UML, design patterns, etc. Você tem que falar em custo, tempo, metas de qualidade. Deve se preocupar em criar indicadores relevantes. Mostrar a economia (de pessoal, de custo, de tempo, mas não de código) que reuso e boas práticas trazem. Só assim se convence chefias.

  4. Você deve aprender a dizer não para seu chefe. É difícil, eu sei. Mas muitas vezes, o chefe espera que o bom profissional saiba quando pisar no freio, e dizer não abre palco para negociar prazos e meios factíveis de fazer o trabalho.

  5. Nem sempre você irá concordar com a empresa que trabalha. Ou seu chefe pode mesmo ser um boçal. Pode ser que ao entender seu chefe, você descubra que a empresa que você trabalha é um lixo, ou que ele é um cara intragável. Nessas horas: troque de empresa.

[quote=asaudate]

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?[/quote]

Neste caso, acabou sendo uma metodologia ágil “acidental”, porque como o cliente estava presente o tempo inteiro (eu estava lá dentro), e havia um consenso a respeito do que devia ser produzido, tinhamos alguns atributos ágeis:

  • Presença forte do product owner
  • Iterações muito curtas

[quote=asaudate]
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… [/quote]

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.

Só para concluir, nao sou a favor do Go Horse, muito pelo contrario. Mas infelizmente eh uma realidade, e o que eh pior, o antidoto pouquissima gente tem. A maioria dos que pensam ter nao tem.

[quote=YvGa][quote=asaudate]
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… [/quote]

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.

[/quote]

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.

É por isso que vivo afirmando que “fazer funcionar” é diferente de “implementar um software corretamente”.

Você pode ter 4 rodas sobre um eixo, e um jegue puxando na frente. E não é porque a carroça anda, que você tem um carro.
E, cuidado, no “Go Horse”, quem é o jegue é você.

[quote=asaudate]

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. [/quote]

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.

Eu também já vi o malefício de “vamos documentar tudo, burocratizar tudo”. Isso geralmente é associado a definir hierarquias entre analistas e programadores, e tornar o ciclo waterfall, e encher a sala de diagramas inúteis.

Entre um ambiente assim e um go-horse, não sei… mas acho que também ficaria no go horse. Pelo menos no go horse todo mundo sabe que está fazendo errado, e você pode tentar mostrar para a chefia que você não tem processo e implementar mudanças…

[quote=YvGa]
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.[/quote]

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.

Bom aqui não tem equipe de teste e o sistemas são baseados em aplicações legadas.(defasadas)
Onde nós mesmos fazemos a especificação baseada em códigos antigos e muitas vezes incompletos.

Onde se da para ter uma noção quase sempre superficial da regra de negócio sobre um domínio que não sabemos ao certo.

Resumindo é tudo na raça,na cara,na coragem e na persistência.(A rotatividade aqui é ± a mesma que de um call center , em seis meses mais da metade da empresa é nova)