Ilustração de hartboy
Definir quanto tempo será necessário para finalizar uma tarefa ou o desenvolvimento de um software não é (ou pelo menos não deveria ser) algo trivial. Estimar prazos faz parte do nosso dia-a-dia como programadores.
O que muita gente não se dá conta é que a precisão com que um programador prevê a entrega de tarefas e projetos é um poderoso indicador do quão bom ele é.
Para informar de forma precisa o tempo necessário para a realização de algo em desenvolvimento de software é necessário que o programador possua uma certa experiência no assunto, tenha um bom domínio do negócio, seja rápido e produtivo.
Embora muitos de nós não apreciem essa difícil tarefa, estimar prazos é parte do nosso trabalho. Fazer isso bem pode ser a diferença entre um programador profissional e um amador.
Em um dia normal, estamos estimando prazos o tempo todo. Ao colocar a comida no micro-ondas você deve informar quantos minutos serão necessários para esquenta-la. Se você tem um horário fixo para acordar, deve analisar quantas horas de sono serão suficientes e então decidir quando deve ir para a cama.
O segredo não está no tempo, mas em quão precisa deve ser a sua estimativa. Se seu chefe pergunta que horas você entregará o relatório amanhã, ele quer ter uma ideia se será antes ou depois do almoço. Se ele lhe pergunta quanto tempo será necessário para resolver um bug critico e colocar o sistema de volta em produção ele precisa de uma precisão maior.
A escala de tempo é muito importante ao se estimar prazos. Por exemplo, você pode dizer “O projeto será entregue em 25 dias” ou pode dizer “O projeto será entregue em cerca de 5 semanas”. Embora ambas as frases indiquem o mesmo tempo, o efeito sob cada uma delas pode ser diferente. Ao dar a primeira resposta, seu cliente provavelmente anotará na agenda dele o dia exato em que você entregará o projeto. Por outro lado, a segunda resposta fará com que ele lhe procure a qualquer momento daqui a 4 ou 6 semanas.
O livro The Pragmatic Programmer dá uma importante dica que nos ajuda a escolher a escala de tempo apropriada ao estimar prazos. Veja a tabela:
1-15 dias -> dias
3-8 semanas -> semanas
8-30 semanas -> meses
30 + semanas -> pense bem antes de dar uma estimativa
Qual a vantagem disso? O fato é que quanto maior o tempo, mais difícil é a previsão, exigindo que você seja cada vez mais impreciso. Por exemplo, se sua estimativa é que serão necessários 125 dias para terminar um trabalho, é muito mais seguro dizer que precisará de “cerca de 6 meses” para finaliza-lo.
Todas as estimativas que fazemos são baseadas em nossas experiências passadas. Mas, o que fazer quando é necessário estimar algo que você nunca fez ou que não conhece? A resposta é simples: “não estime”. É melhor pedir para que alguém que já tenha feito algo semelhante lhe dê uma ideia do tempo necessário.
Além de considerar o grau de precisão, também é importante entender qual é o problema antes de começar a chutar um tempo. Quase sempre nossas estimativas dependem de outros fatores para darem certo: “Supondo que não haja trânsito dá para chegar aí em 20 minutos”.
Se possível é muito útil testar alguns aspectos do projeto antes de dizer quanto tempo será necessário para cumpri-lo. Se o sistema precisa ser carregado dentro do Facebook, seria muito bom poder gastar um tempo criando alguma coisa bem simples para esta plataforma afim de analisar o grau de complexidade, isto sem dúvida aumentará a precisão da estimativa.
É muito importante levar em consideração que a equipe, sua produtividade e o ambiente afetam diretamente sua estimativa.
Analisando todos estes fatores, a conclusão é que há apenas uma única resposta correta a se dar quando lhe é pedido para estimar um prazo: “Me dê algum tempo para pensar”. Você sempre terá resultados melhores se retardar a resposta e pensar um pouco mais.
Foto de bookdepository
Eu amo programadores incompetentes. Graças a eles os profissionais de TI não podem reclamar de falta de emprego.
Nos últimos anos o mercado nacional de TI registrou um aumento de 40% no número de novas vagas de trabalho. Há estimativas que revelam que a necessidade de programadores no Brasil ultrapassa 40 mil profissionais por ano.
Afim de resolver esse problema, as empresas tem contratado cada vez mais programadores ruins. Porém nós não temos um problema com a quantidade, mais sim com a qualidade. Apenas um único programador incompetente pode facilmente criar duas novas vagas de emprego por ano.
Contratar mais programadores ruins só aumentará a necessidade por mais deles. Se tivéssemos mais programadores bons (que são facilmente identificados), seria necessário contratar menos e não mais.
Assim, quanto mais programadores ruins no mercado, mais empregos. Vida longa aos programadores incompetentes!
Foto de Decepticreep
Eu tenho uma lista de programadores que merecem o meu respeito. Provavelmente você também deve admirar o trabalho de alguns colegas de profissão. Estranhamente, eu sou obrigado a confessar que vi muito pouco do código de cada um deles.
A maior parte desses programadores ganharam o meu respeito através dos softwares ou livros que escreveram. E não através do seu código.
Um exemplo é Yukihiro Matsumoto. Ele foi o criador da linguagem de programação que utilizo diariamente para realizar o meu trabalho e obviamente está na minha lista de heróis, porém pouquíssimas vezes eu olhei para o código fonte do Ruby, e quando o fiz não teria como identificar se o que estava vendo foi originalmente escrito por Matz ou por algum outro colaborador.
Minha lista está recheada de pessoas que escreveram uma linguagem de programação interessante, um framework útil, uma ferramenta que facilita minha vida ou um bom livro sobre programação. Mas são poucos os que passei a admirar depois de ver algum código que escreveram. Isso me faz pensar…
Na realidade o código que escrevemos tem muito pouco impacto sobre as pessoas. O que realmente interessa é o que fazemos com o código. O que importa é o produto final.
O problema é que a maior parte dos programadores se preocupa demais com o código. Passam horas e mais horas tentando criar o algoritmo perfeito. Porém se esquecem que o melhor código do mundo é inútil se ninguém utilizar o software que o contém.
De forma alguma estou dizendo que devemos jogar tudo para o alto e parar de se importar com a qualidade do código que escrevemos. Porém, tão importante quanto realizar um bom trabalho é fazer com que outras pessoas tomem conhecimento do que você está fazendo. A minha proposta é que aqueles que já são bons programadores hoje, invistam em aperfeiçoar suas habilidades como escritores e palestrantes. Que participem mais ativamente nas comunidades de software e melhorem suas habilidades sociais.
São essas habilidades que vão diferencia-lo dos demais. Não escreva apenas código. Estude, escreva e fale mais sobre código.
Foto de lmw626
É interessante analisar o efeito que uma linguagem de programação tem sobre a mente do programador, principalmente a sua capacidade de influenciar a maneira como enxergamos um problema. A diferença na sintaxe e os recursos disponíveis afetam a forma como pensamos e nos comunicamos, inclusive no mundo real.
O mesmo problema pode ser solucionado de várias formas diferentes, dependendo da linguagem de programação adotada. Certamente a abordagem escolhida para resolver um problema utilizando Ruby não será a mesma se você usar Java.
Outro fator que exerce uma grande influencia sobre a forma como resolvemos os problemas e pensamos é o domínio do aplicativo. Somos tentados a utilizar o mesmo vocabulário do cliente no código. O meu conselho é tirar o máximo de vantagem desse efeito. Pode ser realmente produtivo “falar” a mesma língua que o cliente também dentro do código. Por exemplo, se o cliente explicar uma funcionalidade dessa maneira:
Quando todas as unidade de um produto se esgotarem em uma das lojas, então o sistema deve solicitar mais 10 unidades do mesmo produto para a fábrica.
Seria muito bom se o código produzido fosse algo parecido com isso:
if product.sold_out?
Factory.order 10, product, :to => store
end
É óbvio que não esperamos que o cliente entenda o código e muito menos que ele altere algo por conta própria, mas nós programadores podemos nos beneficiar muito disso.
Não importa se você está escrevendo um código simples como o exemplo acima ou se construiu uma DSL para se aproximar ainda mais da linguagem do cliente. O importante é estreitar a comunicação entre os envolvidos. Assim o seu cérebro estará livre para se concentrar no que realmente interessa: a solução de problemas.
O ano começou muito bem para os leitores deste blog. No finalzinho de 2008, logo após o lançamento do Rails 2.2, eu havia publicado em parceria com o site EnvyCasts, o meu segundo livro em um pacote especial com um screencast produzido por Gregg Pollack e Jason Seifer. No primeiro mês do ano eu disponibilizei a versão em português do livro de graça aqui no site.
Ruby Inside Brasil
Fevereiro foi outro mês muito exitante. Depois de meses de negociação, consegui com a ajuda de Peter Cooper, trazer o famoso site Ruby Inside para o Brasil. A comunidade Ruby nacional ganhou uma excelente fonte de informações sobre tudo o que acontece de novo no mundo sobre Ruby e Rails. Além de traduzir a maior parte dos artigos publicados na versão internacional, também publicamos muitos artigos relevantes para o público de língua portuguesa e distribuímos muitos prêmios durante o ano.
Dois artigos se destacaram no mês de março: Don’t Repeat Yourself e Um pouco mais sobre “Don’t Repeat Yourself”.
Depois de aproximadamente um ano de trabalho duro, finalmente em abril de 2009 finalizamos a tradução do livro “O (comovente) guia de Ruby do Why“. Foi um trabalho colossal realizado por muitos membros da comunidade Ruby brasileira. Também foi neste mês que aconteceu o evento Ruby + Rails no mundo Real 2009, organizado pelo Guru-SP. A galera do Ruby Inside Brasil esteve em peso no evento e realizou uma excelente cobertura. Eu fui um dos palestrantes, com o tema “Só imaturos não testam” (veja o vídeo). E ainda para fechar o mês com chave de ouro, depois de meses de trabalho eu e José Valim finalmente liberamos a versão 3.0 do framework Remarkable, com alguns recursos novos que tornaram o projeto a principal biblioteca de matchers para RSpec.
O (comovente) guia de Ruby do Why
Embora o 14º EDTED tenha acontecido em abril, somente em maio tive acesso ao vídeo da palestra que realizei no evento. O tema desta vez foi “Como Ruby on Rails pode o tornar um programador pior“. Neste mês também tentei iniciar uma série de screencasts sobre curiosidades do Ruby, infelizmente o projeto não foi para frente.
Em junho, ainda empolgado com a gravação de screencasts criei um segundo site com a finalidade de agregar todos os vídeos relacionados a Ruby e Rails, como screencasts e gravações de palestras. O site ainda está no ar, embora eu não tenha dado prosseguimento ao projeto (Se alguém se interessar em tocar o projeto, fale comigo). Também foi neste mês que escrevi o artigo mais lido do ano: “Como motivar um programador“.
Um dos destaques de julho foi o artigo “Não tenho tempo para conquistar meus sonhos“.
Agosto marcou o inicio da temporada de eventos sobre Rails. O primeiro foi o Oxente Rails, um mega evento organizado pelo meu amigo Paulo Fagiani. Infelizmente as gravações das palestras ainda não foram disponibilizadas. Ainda neste mês, escrevi um artigo intitulado “Isto é um bug no Javascript?“, que foi bastante comentado.
Outro importante evento aconteceu em setembro, o Rails for Kids. O tema da minha palestra desta vez foi “Eu odeio OpenSocial“, uma introdução ao tema da palestra que eu iria realizar no Rails Summit. Um artigo que se destacou neste mês foi uma tradução entitulada “Os oito níveis do programador“.
Outubro foi um mês cheio de emoções para mim. Primeiro eu oficializei a minha saída da Surgeworks e o inicio de um novo desafio, atuar como diretor de tecnologia na Amanaiê (SocialSmart), uma startup brasileira. E também foi neste mês que aconteceu o evento mais esperado do ano, o Rails Summit Latin America, organizado pela Locaweb e encabeçado pelo meu amigo Fábio Akita. Este ano tive o privilégio de palestrar mais uma vez neste evento, você pode assistir o vídeo clicando aqui.
Rails Summit Latin America
Novembro e dezembro foram meses de muito trabalho na Amanaiê, onde estou tendo o privilégio de construir um novo framework em Ruby para acelerar o desenvolvimento de aplicativos baseados em OpenSocial. Já temos alguns projetos no ar utilizando a nova tecnologia e estamos muito animados com os resultados.
Enfim, 2009 foi mais um ano de muitas conquistas e muito trabalho. Agora chegou a hora de um merecido descanso. Nos vemos em 2010!
Infelizmente a maioria dos programadores que conheço nunca ouviram falar sobre ortogonalidade no desenvolvimento de software, embora este seja um principio fundamental para se escrever código de qualidade.
Em desenvolvimento de software, o termo ‘ortogonalidade’ passou a significar uma espécie de independência ou dissociação. A ideia é que componentes que conceitualmente não estão relacionados devem ser construídos de forma a não possuírem nenhuma dependência entre si. Adicionar um novo atributo a um objeto do ActiveRecord (na maioria das vezes) não deveria exigir uma alteração na interface com o usuário, por exemplo.
Foto de Voxphoto
Em linguagens orientadas a objetos é muito fácil acrescentar dependências ao código. Em Ruby basta um simples ‘require‘ e seu projeto passa a depender de uma ou várias bibliotecas. Talvez devido a essa simplicidade este tende a se tornar um problema viral, já que nos estimula a estarmos sempre adicionando mais e mais dependências em nossos sistemas.
Queremos projetar componentes auto-suficientes e com um único propósito bem definido. Sistemas não ortogonais são difíceis de alterar. Em projetos onde seus componentes dependem uns dos outros não existem correções pontuais. Uma correção pode levar a um ou mais problemas em outra parte. E isto pode se tornar um ciclo sem fim.
Por outro lado, em sistemas onde os componentes são isolados uns dos outros, desde que você não mude a sua interface pública, você sabe que pode alterar um deles sem se preocupar com os outros.
Os ganhos em produtividade ao colocar em prática este principio são imensos. Uma abordagem ortogonal promove a reutilização. Como seus componentes serão bem específicos e com responsabilidades bem definidas é fácil reaproveitá-los em outros sistemas. Outro fator importante é que por possuírem apenas o código necessário para cumprir uma única tarefa, obviamente estas bibliotecas serão menores e mais simples de serem projetadas, implementadas, testadas e dificilmente precisaremos revisita-las para adicionar novas funcionalidades ou fazer correções.
O fato de serem componentes menores e com menos código também simplifica a criação de testes. E mesmo que um bug passe despercebido ele não será tão critico, pois o tempo de resolução será menor e a chance de o problema se espalhar por todo o sistema são mínimas, o que diminui os riscos.
Vamos considerar como exemplo o desenvolvimento de um e-commerce. O requisito original previa apenas uma interface web simples, mas as exigências foram alteradas para também contemplar uma interface web para telefones celulares e para compras através de uma central telefônica. Em um sistema projetado ortogonalmente, você precisaria alterar apenas os módulos associados com a interface do usuário para lidar com isso. Se o seu sistema foi bem estruturado, você deveria ser capaz de suportar todas essas interfaces com o mesmo código criado inicialmente para realizar as vendas. O paradigma MVC utilizado no Ruby on Rails funciona bem nestas situações.
Testes unitários são uma ótima forma de verificar a ortogonalidade de um componente. Se para realizar o teste é necessário carregar ou acessar uma grande quantidade de outras bibliotecas, então você encontrou um módulo que não está bem dissociado do resto do sistema. Outra forma menos interessante de realizar esta avaliação é ao corrigir bugs. Quando você faz uma alteração, outros problemas surgem misteriosamente? Esta é uma evidência de que seu código não é ortogonal.
Ortogonalidade está intimamente relacionado com o princípio DRY (veja mais aqui e aqui). Enquanto DRY visa minimizar a duplicação dentro de um sistema, com a ortogonalidade você reduz a interdependência entre os componentes do sistema. Utilizar estes dois princípios combinados tornará nossos projetos muito mais flexíveis e fáceis de manter.
Este artigo é descaradamente ‘baseado’ no capítulo de mesmo nome do livro The Pragmatic Programmer.
Muitas reuniões são convocadas apenas para auto-afirmação dos gestores quando poderiam ser evitadas e todos os assuntos resolvidos com um simples e-mail. Não existe nada mais tóxico à produtividade do que uma reunião.
Paul Graham escreveu um artigo intitulado “Maker’s Schedule, Manager’s Schedule” que explica o motivo de nós programadores odiarmos tanto reuniões. Acontece que o nosso cronograma funciona de uma forma diferente que o das outras pessoas. Reuniões nos custam mais caro.
A agenda do gerente segue o modelo tradicional, onde cada dia é dividido em intervalos de um hora. Programar uma reunião é apenas um problema de ordem prática, basta encontrar um intervalo em aberto na sua programação e escrever “reunião”. Quando se gerencia o tempo desta maneira, você pode reservar algumas horas para uma única tarefa se for necessário, mas por padrão você pode mudar o que está fazendo a cada hora.
Mas programadores (e outros profissionais) gerenciam o tempo de outra maneira. Eles geralmente costumam dividir sua agenda em dois períodos: manhã e tarde. Não é possível desenvolver software bem em unidades de uma hora. Isso não é tempo suficiente nem para começar.
É por este motivo que programadores odeiam tanto reuniões, afinal uma única reunião pode acabar com uma tarde inteira de trabalho, dividindo-a em dois pedaços pequenos demais para fazer qualquer coisa importante.
Eu sei que pode soar um pouco sensível demais, mas em alguns casos mesmo uma rápida reunião no meio da tarde pode deixar um programador improdutivo por um dia inteiro. Se eu sei que a tarde será quebrada, então eu sou menos propenso a iniciar algo ambicioso no período da manhã.
Nós entendemos a importância das reuniões. Tudo o que estamos pedindo aos gerentes é que eles entendam os custos.
Programadores são naturalmente introvertidos e não sabem se comunicar. Deve ser por isso que existem tantos programadores ruins. Programar é um exercício de comunicação.
Anos de experiência desenvolvendo software, conhecer muitas linguagens de programação, escrever códigos de qualidade, nada disso tem valor se você não conseguir se comunicar com outras pessoas. De nada vale ter muito conteúdo e guardar isto só para você.
Aqueles que desejam uma carreira bem sucedida como programadores, além possuir um conhecimento técnico acima da média também precisam estar constantemente melhorando suas habilidades de comunicação.
Inevitavelmente passamos horas em reuniões. Precisamos interagir com clientes e entender as suas necessidades. Escrevemos propostas e relatórios. Estamos em uma luta sem fim tentando convencer nossos companheiros e empregadores a adotarem uma nova tecnologia ou prática que tornará nosso trabalho mais produtivo e divertido. E acima de tudo: escrevemos muito código.
O código é uma combinação de signos utilizados para transmitir uma mensagem. Porém a comunicação só se concretizará se o receptor souber decodificar a mensagem. Computadores costumam fazer isto muito bem, mas não estamos escrevendo código apenas para máquinas. Um código mal escrito e cheio de ruído dificultará o trabalho de outros programadores quando houver a necessidade de estudá-lo.
Nosso trabalho se resume a pura e simplesmente comunicar-se, por isso é tão importante fazer isso bem.
Não importa se você está escrevendo um livro/relatório/e-mail ou se preparando para uma reunião, planejamento é tudo. Um dos segredos dos bons comunicadores é saber o que dizer, antes de sair abrindo a boca e despejando pensamentos. Pergunte-se: “Se eu falar desta maneira, será que todos entenderão com clareza a informação que eu estou tentando passar?”. Repita esta pergunta para si mesmo até que esteja convicto disso. Anote estas ideias e planeje como aborda-las.
Comunicação é repassar informações. Para que isto seja possível é vital que todas as pessoas presentes entendam o que você está dizendo. Antes de começar a argumentar sobre as vantagens de se utilizar um banco de dados não relacional no projeto, certifique-se de que todos sabem do que você está falando. Caso contrário, você não estará impressionando ninguém. Estará apenas sendo chato.
Se você está vendendo uma ideia, certifique-se de conhecer cada uma das pessoas envolvidas na negociação e fale somente o que ela precisa ouvir, nem mais nem menos. Talvez você precise convencer o seu gerente, o pessoal de marketing, o usuário final do aplicativo e até outros desenvolvedores. Trate cada grupo de forma individual.
Tão importante quanto dizer a coisa certa, é dizer na hora certa. Pegar seu gerente no corredor, logo após o seu supervisor lhe chamar a atenção por ele ter entregue um aplicativo cheio de bugs é uma excelente oportunidade para convencê-lo a adotar testes automatizados nos próximos projetos. Mas também será uma péssima hora para pedir um upgrade na sua máquina.
Para ser tornar um bom escritor é necessário ler muito, seguindo o mesmo principio se você deseja falar bem é importante escutar. Programadores tem sérios problemas para escutar. Durante uma reunião, assim que o cliente começa a explicar uma funcionalidade do novo aplicativo, a mente do programador abandona a sala e automaticamente já começa a trabalhar no código que precisará ser desenvolvido. Deste momento em diante tudo o que for dito na sala será ignorado. Concentre-se. Se você não escutar o que os outros estão dizendo, como espera ser ouvido?
Lembre-se disso: Não é somente o que você diz, mas também como você diz. A menos que você esteja trabalhando sozinho dentro de uma bolha, você deve ser capaz de se comunicar. E quanto mais eficaz for a sua habilidade de comunicação, mais influente você se tornará.
Foto de James Yeung
Deus ajuda quem cedo madruga. De acordo com este antigo provérbio se você tem o hábito de acordar cedo e trabalhar por horas a fio com muito afinco e dedicação, então você se dará bem na vida. Mas isto também vale para a carreira de um programador? Muita dedicação e trabalho duro são o suficiente para atingir a imortalidade?
Embora exista muita gente esforçada que literalmente dá a sua vida pela empresa em que está trabalhando, não é o trabalho braçal que determinará o seu sucesso. O seu conhecimento e experiência é que são o seu maior patrimônio profissional.
Mas infelizmente nessa área de atuação o nosso conhecimento tem um prazo de validade muito curto. Novas tecnologias, linguagens de programação e metodologias aparecem quase que diariamente e é cada vez mais difícil acompanhar este ritmo. Por outro lado, não acompanhar estas mudanças pode torna-lo obsoleto para o mercado.
Profissionais mais antigos já estão acostumados com isto, só que até pouco tempo atrás a necessidade de se reciclar não exigia tanta velocidade. Quando uma nova tecnologia era lançada, normalmente demorava um tempo até que o primeiro livro fosse publicado e para que outros profissionais e empresas começassem a adota-la.
Agora dado a quantidade crescente de novos artigos, livros, screencasts e blogs na internet, isto tem acontecido cada vez mais rápido. Existem estudos que indicam que a soma da informação do mundo dobra a cada 80 dias. Analisando desta forma, se você permanecer três meses sem se atualizar, já pode se considerar obsoleto.
Pegue como exemplo o Ruby Inside Brasil. Lá são publicados artigos quase que diariamente sobre um único tema: Ruby. Temos uma equipe relativamente grande e muito motivada tentando cobrir as principais noticias relacionadas a esta linguagem de programação e mesmo assim isso algumas vezes tem se tornado uma tarefa árdua dado a grande quantidade de informação gerada em cima deste único tópico.
Assim como o seu conhecimento, o seu valor para uma empresa ou cliente também vai diminuindo com o tempo. Precisamos trabalhar para que isto nunca aconteça. Não existe nada pior do que continuar empregado apenas por ter muito tempo de casa.
Qual é a sua estratégia para se manter atualizado?
Foto de Ernest Descals
Não entendo muito de pintura, mas os amigos que apreciam este tipo de trabalho sempre dizem que uma das coisas mais difíceis sobre pintar é saber quando parar. Entender que o trabalho terminou. Uma pincelada a mais pode arruinar um lindo quadro.
Acredito que o mesmo acontece com software. Programadores profissionais sempre defenderam refatoração, testes, integração contínua e outras práticas que visam deixar nosso código mais limpo e livre de falhas. Mas existe um limite para a aplicação dessas práticas? É possível que a preocupação exagerada com a qualidade do software acabe prejudicando o projeto?
Ferramentas como Flog, Flay e Heckle foram criadas para que pudéssemos estressar nosso código ao limite. Ter um código limpo, sem repetições e com testes bem feitos é essencial para o sucesso de um projeto, sem dúvida nenhuma. Mas o fato é que vivemos em um mundo imperfeito e o sonho de um software livre de bugs é um objetivo impossível de ser alcançado. O tempo, as pessoas e até a nossa amada tecnologia, tudo conspira contra nós. Então quando é a hora de parar e declarar o trabalho como finalizado?
A primeira coisa que precisamos ter em mente é que um projeto de software bem-sucedido não é necessariamente livre de bugs, mas sim um software que atende aos requisitos exigidos pelo seu cliente ou usuário. Isto não quer dizer que você deve jogar tudo para o alto e deixar seu código apodrecer. Mas que você deve considerar o quão importante é a ausência de falhas ou a qualidade do código para o seu cliente.
Se você estiver desenvolvendo um software que controlará algum equipamento médico ou uma aeronave ou estiver trabalhando em uma biblioteca open source que será amplamente utilizada, então você não tem escolha e suas opções serão mais limitadas. Porém, este tipo de projeto é uma exceção. Na maior parte do tempo estaremos trabalhando em produtos comerciais mais simples onde seu cliente terá um cronograma de entrega baseado em promessas feitas a seus superiores e sua empresa certamente terá um fluxo de caixa apertado.
Da mesma forma como seria pouco profissional aceitar prazos impossíveis e deixar testes de lado para terminar um projeto dentro do prazo, também não seria nada profissional ignorar as necessidades do seu cliente/usuário simplesmente para adicionar uma nova funcionalidade ou refatorar o código mais uma vez.
Depois de mais de dez anos trabalhando com software, posso dizer empiricamente que muitos usuários preferem usar um software com algumas arestas soltas do que esperar um ano por uma versão livre de falhas. Muitas vezes é melhor um software ótimo agora do que um software perfeito amanhã.
Ainda há uma outra vantagem nessa abordagem. De acordo com o livro Getting Real: “A coisa mais importante em desenvolvimento de software é motivação. Motivação é localizada—se você não está motivado pelo que está trabalhando neste instante, as chances de que isso não saia tão bom são grandes . Na verdade, isso provavelmente vai ficar ruim”. Ciclos de entregas longos e demorados são assassinos de motivação.
Se você dá algo para seus usuários brincarem no início, as suas reações muitas vezes levarão a uma solução melhor.
Programar é como pintar. Tudo começa com um quadro branco, seguido por um esboço, uma pintura maior e então com o preenchimento dos detalhes. Se seu olhar for critico demais, você não saberá quando parar até que tenha estragado a sua pintura.