A lição de hoje chega aos senhores por cortesia do seu Departamento de Transporte local:
O DOT de Utah está gastando US$ 6 milhões em um estudo de viabilidade para uma ponte sobre um lago. Enquanto isso, o DOT não tem dinheiro suficiente para instalar câmeras de vídeo com informações ao viajante em passagens perigosas nas montanhas e desfiladeiros para ajudar os motoristas a fazer escolhas seguras ao dirigir. Esses US$ 6 milhões poderiam facilmente ter pago pelas câmeras, deixando ainda dinheiro para uma análise razoável da viabilidade de uma ponte.
No Estado de Washington, o dinheiro orçado para um projeto de drenagem ficou preso em estudos. Enquanto isso, as recentes enchentes arrasaram várias cidades pequenas, com danos da ordem de dezenas de milhões, destruindo a vida de muitas pessoas. E US$ 16 milhões estão sendo gastos em um estudo de conversão de trilhos ferroviários. Esse dinheiro seria suficiente para construir um novo cruzamento de autoestrada e aliviar milhões em atrasos de congestionamento e melhorar a segurança hoje.
John Taber, o autor do artigo, está profissionalmente envolvido exatamente nesses tipos de estudos. Sua opinião?
Caramba, eu ganho a vida com estudos de transporte e até eu estou dizendo que há muito estudo e pouca construção.
É uma viagem conceitual fácil a partir de construindo pontes para a construção de software. Em software, alguns desenvolvedores fixam residência no planeta arquitetura, um lugar de outro mundo onde o software é eternamente planejado e discutido, mas nunca realmente construído. Ter discussões intermináveis sobre software em uma sala de conferência ou lista de discussão parece um trabalho útil… mas será que é? Até que tenha produzido um artefato funcional para o resto do mundo experimentar, o senhor realmente feito alguma coisa?
Uma de minhas citações favoritas sobre esse assunto vem do Christopher Baus.
Software não se trata de metodologias, linguagens ou mesmo sistemas operacionais. Trata-se de aplicativos que funcionam. Na Adobe, eu teria aprendido a arte de criar aplicativos enormes que geram milhões de dólares em receita. É claro que o PostScript não era o aplicativo mais atraente e foi escrito em C da velha guarda, mas realizava uma tarefa importante e útil da qual milhares (se não milhões) de pessoas dependiam para realizar seu trabalho. Dificilmente poderia haver um lugar melhor para aprender as habilidades de criação de aplicativos comerciais, independentemente das ferramentas empregadas na época. Aprendi uma lição importante na ObjectSpace. Um diagrama UML não pode empurrar 500 páginas por minuto em um RIP.
Há dois tipos de pessoas nesse setor. Os que falam e os que fazem. A ObjectSpace era uma empresa de faladores. A Adobe é uma empresa de realizadores. A Adobe obteve uma receita de US$ 430 milhões no último trimestre. A ObjectSpace está falida há muito tempo.
Portanto, é isso que o senhor deve se perguntar: o senhor é um fazedor ou um falador? O ideal é que o senhor seja um pouco dos dois, como já disse várias vezes aqui. Certamente há valor em alguns discussão e planejamento na sua equipe. Mas se o senhor tiver que escolher um ou outro, tente errar o lado que produz código útil e funcional:
A melhor maneira de iniciar um projeto de código aberto é com código. Código funcional. Trabalhe em casa nos fins de semana, talvez consiga a ajuda de alguns amigos e não torne o projeto público até que tenha algo para mostrar às pessoas que faça algo interessante e que outras pessoas possam usar para construir coisas mais interessantes em cima dele. O senhor precisa disso por vários motivos diferentes: estabelece a boa-fé do colaborador original na meritocracia do código aberto, abrevia todos os tipos de debates prejudiciais sobre estilos de codificação e arquitetura que podem interromper um projeto antes de ele começar, e assim por diante.
O código de trabalho atrai pessoas que querem codificar. Documentos de design atraem pessoas que querem falar sobre codificação.
Há um limite superior definido para o valor da discussão e do planejamento puros e teóricos em software. O truque é saber quando o senhor atingiu esse limite e como canalizar esse esforço para a produção de ativos de código reais em vez de deixá-lo se dissipar em um sopro inofensivo de ar quente.