O programador fita adesiva

English   |   Código

Fita Adesiva

Tudo começou quando o Joel Spolsky escreveu um artigo em seu blog intitulado The Duct Tape Programmer. E aí a coisa começou a se espalhar, uns gostaram, outros nem tanto. Mas o curioso foi ver a quantidade de blogs que imediatamente levantaram o dedo para dizer como o Joel estava errado, como a comparação era exagerada, como o conceito era falho.

Pelamordedeus! Vamos parar com essa coisa de querermos sempre rotular tudo como certo e errado, poucas coisas na vida são certas e erradas, preto no branco, claro e escuro ou seja lá que comparação você preferir. O segredo é buscar o equilíbrio. E quando falamos em desenvolvimento de software, programação, isso se torna ainda mais verdade. Pouquíssimas coisas estão no terreno do certo e errado, na maioria das vezes, você precisa usar o bom senso (coisa rara hoje em dia) para escolher a forma de trabalho mais apropriada, a tecnologia mais apropriada ou a ferramenta de trabalho mais apropriada.

Assim sendo, ao invés de gastar energia criticando o artigo, vamos pegar a idéia principal e ver como isso pode melhorar a nossa vida, a forma como trabalhamos, para ver se conseguimos fazer melhor o nosso trabalho que é desenvolver software.

Analisando o artigo

No artigo mencionado no início desse post, quando Joel fala sobre o termo "duct tape programmer" ou, numa tradução livre, "programador fita adesiva", faz referência ao livro Coders at Work, que é uma coletânea de entrevistas com programadores experientes e seus respectivos trabalhos.

Nesse livro Joel encontrou a entrevista de Jamie Zawinsky, um dos desenvolvedores do navegador Netscape, e descreveu a Jamie como um "programador fita adesiva". Vejam a definição: > He is the kind of programmer who is hard at work building the future, and making useful things so that people can do > stuff. He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. > And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute. This will > happen while other programmers are still at the starting line arguing over whether to use titanium or some kind of > space-age composite material that Boeing is using in the 787 Dreamliner.

Sim, a idéia principal exposta aqui é simples: o programador fita adesiva está mais interessado em resolver o problema, em entregar o produto, ao invés de se preocupar em adicionar complexidade em cima de complexidade em cima de complexidade (atenção Java, eu estou olhando para você!). > And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”

Sim, para que tenhamos agilidade é necessário aprendermos a dizer "Não!". Não para a complexidade desnecessária, não para funcionalidades que não agregam valor, não para ferramentas que possuem uma curva de aprendizado enorme e que no final agregam pouco ou nenhum valor ao seu trabalho. Foco no principal, foco no que vai resolver o meu problema ou o problema do meu cliente. Esse parágrafo do artigo diz tudo: > Peter asked Zawinski, “Overengineering seems to be a pet peeve of yours.” “Yeah,” he says, “At the end of the day, > ship the fu**ing thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually > be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

Preciso reforçar essa última frase: não estamos aqui para escrever código, estamos aqui para entregar produtos. Sim, é para isso que somos pagos e essa deve ser a nossa principal preocupação, entregar produtos de qualidade para nossos clientes.

Concluindo

É claro que não devemos pegar esse conceito e tratá-lo como verdade absoluta, está longe disso. Repito mais uma vez, assim como tudo na vida, precisamos analisar isso com equilíbrio. Não adianta entregarmos o produto no prazo, sendo que o mesmo está cheio de erros e com a estrutura comprometida.

Da mesma forma como uma fita adesiva nem sempre resolverá o seu problema e talvez seja necessário usar algo que seja mais complicado, porém mais duradouro, no desenvolvimento de software precisamos realmente avaliar quando resolver os nossos problemas com a solução mais simples possível ou então usar algo um pouco ou muito mais complexo mas que nos trará ganhos maiores e mais duradouros no futuro.

Comments powered by Disqus
Share