Estive lendo este genioso livro, que fala sobre o impacto da metodologia Getting Real (Caindo na Real, traduzindo) que descreve os métodos de produção utilizada pela equipe da 37signals, empresa responsável por iniciativas como o Ruby on Rails e Writeboard, entre outros.
Os autores falam, de forma incisiva, que alcançaram altos índices de produtividade na construção de softwares para web pulando todas as etapas que representam a realidade (como wireframes, documentos de especificação, gráficos etc.) e partindo direto para o que é a realidade.
A metodologia prega a filosofia do menos, a 37signals defende que os softwares devem iniciar enxutos, que a equipe deve ser pequena e ágil, que o código deve ser o mais simples possível e que tudo deve ser lançado logo e aprimorado sempre.
Bem, vou citar aqui alguns trechos importantes, mas recomendo claro, a boa leitura do mesmo, se você identificou com a metodologia.
Como Escrever Software Vigoroso
Escrita vigorosa é concisa. Uma sentença não deve conter palavras desnecessárias, um parágrafo não deve conter sentenças desnecessárias, pela mesma razão que desenhar não deve ter linhas desnecessárias e uma máquina não deve ter partes desnecessárias. Isso requer não que o escritor torne todas as sentenças curtas ou evite todos os detalhes e trate os assuntos apenas em ítens, mas sim que cada palavra fale.
—De “Os Elementos de Estilo” de William Strunk Jr.
Faça menos que sua competição
O senso comum diz que para vencer seus competidores, você precisa estar um passo a frente. Se eles possuem quatro funcionalidades, você precisa de cinco (ou 15, ou 25). Se eles gastam X, você precisa gastar XX. Se eles têm 20, você precisa 30.
Este tipo de estratégia, a Guerra Fria de estar um passo a frente, leva a uma briga sem fim. Trabalhar assim é caro, defensivo e paranóico. Empresas defensivas e paranóicas não pensam para frente, eles pensam apenas no passado. Elas não lideram, elas seguem.
Se você quer construir uma empresa que segue, este livro não é para você.
Construa software para você mesmo
Uma grande maneira de escrever software é começar resolvendo seus próprios problemas. Você será o público-alvo e saberá o que é importante e o que não é. Isso lhe dá um bom adiantamento na entrega de um produto fora de série.
Dois caminhos
[Jake Walker começou uma companhia com dinheiro de investidores (Disclive) e um sem (The Show). Aqui ele discute as diferenças entre os dois caminhos.]
A raíz de todos os problemas não foi conseguir dinheiro, mas tudo que veio junto com ele. As expectativas são simplesmente mais altas. As pessoas começam tomando salários e a motivação é para construir e depois vender, ou encontrar outra maneira para os investidores iniciais terem seu dinheiro de volta. No caso da primeira empresa, simplesmente começamos a agir como se fôssemos muito maiores do que realmente éramos – sem necessidade …
[Com The Show] percebemos que poderíamos entregar um produto muito melhor com menos custo, apenas com mais tempo. E apostamos com um pouco de nosso próprio dinheiro que as pessoas iriam esperar por mais qualidade em vez de velocidade. Mas a empresa se manteve (e provavelmente continuará sendo) uma operação pequena. E desde esse primeiro projeto, estamos totalmente auto-financiados. Com apenas um pouco de criatividade de nossos fornecedores, nunca mais realmente precisamos colocar muito de nosso próprio dinheiro na operação. E a expectativa não era de crescer e vender, mas de crescer por crescer e continuar se beneficiando disso financeiramente.
—Um comentário de Signal vs. Noise
Desenhe a interface antes de começar a programar
Muitos aplicativos começam com a mentalidade de programar primeiro. Isso é uma má idéia. Programação é o componente mais pesado de construir em um aplicativo, significando ser o mais caro e mais difícil de mudar. Ao invés disso, comece desenhando primeiro.
Até a próxima.
