Eu acho que uma certa pressão em um projeto é boa porque ajuda a manter o foco.
No entanto, se a pressão não for realista, ou se a comunicação entre a gerência e o pessoal técnico não funcionar adequadamente, sim, existe o risco de o agendamento da pressão resultar em má qualidade e / ou atraso na entrega.
Um desenvolvedor experiente saberá que não se espera que ele / ela produza a solução perfeita, mas sim uma solução que seja boa o suficiente . Portanto, a estimativa fornecida por esse desenvolvedor já refletirá sua compreensão do que é bom o suficiente para um projeto em particular.
Existem muitos fatores que influenciam a definição de bom o suficiente.
Por exemplo, quantos meses o projeto dura? Se o projeto durar um ano, você poderá escrever rapidamente um protótipo desse módulo particularmente difícil no início do projeto e terá vários meses para testá-lo e depurá-lo como uma atividade secundária para o desenvolvimento de outros módulos mais rotineiros. (Você pode deixar esse módulo amadurecer por vários meses até que seja bom o suficiente, para que você não precise tentar acertar desde o início.) Acho essa estratégia muito eficaz, mas você precisa de um gerente que confie em você e permita que você mantenha um projeto aberto por meses. Outro gerente (desconfiado) pode pressioná-lo a concluir o módulo o mais rápido possível (não importa se você precisará corrigi-lo mais tarde e se essa abordagem acabará por custar muito mais tempo no total).
Outro exemplo: o projeto é para um produto que terá apenas um release. Depois, você pode tentar fazê-lo rapidamente e contar com extensos testes para garantir que o produto funcione conforme o esperado (rápido e sujo é bom o suficiente ). Por outro lado, se o produto tiver dois ou três lançamentos, dedique algum tempo a projetá-lo, para evitar a reescrita extensa do código para lançamentos posteriores. (Nesse caso, rápido e sujo não é bom o suficiente, porque o tempo total de desenvolvimento nos três lançamentos é maior.)
Resumindo, acho que a má comunicação entre a gerência e o pessoal técnico e a falta de um entendimento comum sobre o que é bom o suficiente para o projeto em questão podem levar a uma pressão de programação excessiva, resultando em má qualidade / atraso na entrega.
Nunca há tempo suficiente para fazê-lo corretamente da primeira vez, mas sempre há tempo suficiente para corrigi-lo mais tarde.