Por que as empresas de engenharia de software não contratam apenas desenvolvedores de garagem?

Referência: Dilbert.com

A metáfora do desenvolvedor de garagem pode ser muito mais norte americana do que brasileira ou de outros países, mas a pergunta é válida e nós todos já a ouvimos de formas diferentes no início de projetos de tecnologia da informação:

- Por que vocês, que são profissionais de informática, vão levar 8 meses pra desenvolver esse sisteminha? Eu faço isso em um mês com excel aqui na minha área mesmo?

- Vai custar tudo isso? Com meu excel seria de graça...

Ou a minha forma preferida desta pergunta:

- Oito meses? Meu filho disse que faz isso pra mim em poucas semanas...

Todas estas perguntas são variações da pergunta: por que as empresas de tecnologia não mandam embora todos os seus engenheiros de software, analistas de sistemas, gerentes de projetos, etc, e contratam dois ou três adolescentes trabalhando em casa?

No livro The Mythical Man-Month, Frederick Brooks propõe uma resposta interessante a esta pergunta. O livro reuni uma série de ensaios sobre engenharia de software desenvolvidos ao longo da vida em corporações (ele foi o gerente do projeto do IBM System/360) e acadêmica. Vários dos ensaios são bem interessantes, sendo o melhor o que dá nome ao livro, mas alguns são bem datados e só servem como curiosidade histórica.

O que o Brooks argumenta sobre a questão deste post é que o desenvolvedor de garagem constrói o programa, ainda que bem feito e testado pelo próprio desenvolvedor (teste unitário), enquanto a engenharia de software entrega um produto de sistema, que deve incluir, além do programa inicial:

• O código deve ser generalizável e manutenível;
• Os testes devem ser, além do inicial, o integrado, o de aceitação pelo usuário e o de regressão (no mínimo, além de outros quando aplicáveis), com os scripts e evidências de execução e sucesso;
• Documentação completa e "viva" tanto para o usuário final quanto para a equipe técnica; e
• As interfaces devem estar construídas, testadas e documentadas.

Todas estas atividades e produtos elevarão, tipicamente (número do Brooks) em nove vezes o tempo e custo do programa desenvolvido originalmente, mas deverão trazer uma contraparte em qualidade.

Achei a resposta do Brooks interessante, mas nos leva a pensar se temos entregado todos estes produtos de forma clara e com qualidade, para que o cliente consiga ver o que compõe o tempo e o custo a mais.