O Hacker

Um hacker, segundo a RFC 1392, é uma pessoa que possui grande conhecimento sobre o funcionamento de sistemas de computadores. Em outras palavras, é aquele (ou aquela) que sabe o que está fazendo quando o assunto é programação.

O termo foi cunhado em 1960, quando aqueles que desenvolviam sistemas passavam dias trancafiados em laboratórios sem comunicação alguma com o mundo externo ou com outros colegas. Em algumas semanas, ou meses, concluiam sozinhos o desenvolvimento de alguma ferramenta sensacional ou inútil.

Os Processos

Apesar de existir um certo nível de comunicação entre a comunidade de hackers (a colaboração em sistemas open-source é um exemplo), sua fama de anti-sociais persistia. A indústria via um grande potencial técnico nos hackers mas, ao mesmo tempo, um grande gap no quesito comunicação e organização perante o mercado.

Inspirados nos processos fabris de linhas de produção, foram criados processos semelhantes de gerenciamento e desenvolvimento de software. Acreditava-se ser a melhor forma de domar os pedreiros de programas de computador.

Com processos meticulosamente definidos e documentados, a idéia era que qualquer pessoa com o mínimo de conhecimento em sua área pudesse seguir um manual e produzir software conforme o esperado. Do ponto de vista dos profundos conhecedores dos processos, os que trabalhavam para fazer o programa funcionar passaram a ser chamados de recursos. Um recurso é, teoricamente, algo altamente previsível, como uma conexão com o banco de dados ou um stream para um arquivo do filesystem e que deveria funcionar exatamente durante o horário comercial - e as vezes até mais.

Epic Fail

Trinta anos e trilhões de dólares depois, conclui-se que a fórmula

hackers + processos

não resulta em software funcionando nem em clientes satisfeitos. Os famosos processos dificilmente são instanciados de forma correta, suportando mudanças do mercado ou a alta rotatividade dos “recursos”.

Tentar domar os hackers através da criação de processos com canais formais de comunicação não funcionou. As barreiras criadas pelos processos entre “quem quer” (stakeholders) e “quem faz” (hackers) provaram-se extremamente prejudiciais a todos os envolvidos.

E se os hackers evoluíssem suas habilidades sociais a ponto de serem os responsáveis pela criação de seus próprios canais de comunicação ?

Nova Fórmula

Quanto mais tempo um programador passar codificando, mais fluência ele terá em sua linguagem de escolha e maior familiaridade com sua API. Interrupções como listas de e-mail, IRC, amigos, prática de esportes, festas e namoradas apenas servem para tirar o tempo que ele poderia estar codificando ou estudando. Isto é fato. Mas vimos que hackers não foram muito bem sucedidos no desenvolvimento de software para o mundo dos negócios, mesmo quando controlados por processos de big vendors.

Alguém que venha a tornar-se um excelente hacker mas sem habilidades sociais será um péssimo desenvolvedor.

hacker + comunicação = developer

Um bom developer, por sua vez, possui não só um conhecimento técnico acima da média, mas também habilidades sociais que possibilitem sua comunicação com as pessoas. Ele precisa comunicar-se com o restante do seu time, com seus clientes e com outras áreas de sua empresa.

“In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback” - Eric Evans (Domain Driven Design)

Os processos - desta vez mais ágeis - utilizados por sua equipe visam facilitar a comunicação. Os conhecedores destes processos não controlam, mas facilitam, e tentam livrar a equipe dos impedimentos que ameaçam o andamento do projeto.

Participação na comunidade, seja ela open-source ou específica de suas plataformas e ferramentas também é vital. Nenhum processo ou ferramenta é “the one to rule them all”. A troca de experiências da comunidade através de eventos, listas de e-mail, workshops e etc,  evita que erros sejam repetidos e divulga novos caminhos que foram traçados com sucesso e que podem servir de guia para outros.

A idéia de um hacker que recebe algumas ordens e depois programa, sozinho e incomunicável em uma sala por algums dias até sair com um programa “simplesmente funcionando” já provou ser um fracasso para problemas em domínios que não os já entendidos por ele. Não é assim que se faz software passível a expansão, manutenção e que satisfaça as reais necessidades do cliente.