Desculpe dizer isso, mas

Você não vai querer ouvir isso, mas ele não está completamente errado .

If you are doing work for hire for external companies as a consultant, and they are willing to accept the most slapped together thing you can do and don't complain, and are willing to come back over and over again for you to do more work, your boss is 100% correct when it comes to maximizing profits for your company.

Depois, há YAGNI : se os projetos forem projetos únicos que não custarão nada para você manter ou re-escrever e todo esse tempo em manutenção e reescrita é faturável, fazer isso direito pela primeira vez está realmente custando ainda mais dinheiro. Então, seu chefe está 100% correto novamente.

Se seus clientes não reclamarem sobre custos e falta de qualidade, a qualidade não estará em questão para deixar seus clientes satisfeitos. Parece que os clientes estão satisfeitos com a porcaria, então vender mais porcaria não é uma decisão difícil.

Qualquer coisa que você faça acima e além do que o cliente está feliz é um esforço desperdiçado em todas as partes: elas não vão gostar. Seu chefe está 100% correto novamente.

Lembre-se de que a qualidade está nos olhos de quem vê. Se atende às necessidades dos clientes, eles não se importam com a fita adesiva e os cabides que fazem com que funcione.

O que você valoriza tem pouco ou nenhum valor direto para seus clientes, já que eles não se importam como o software faz o que faz, apenas faz o que eles querem na maioria das vezes.

Cada software eventualmente degenera da entropia para uma Big Ball of Mud . Aplicativos de GUI, especialmente aqueles para Windows, escreveram em algum tipo de entropia de VB mais rápido por causa da cultura do conjunto de ferramentas.

Se isso faz você se sentir melhor, você está começando um pouco mais perto da entropia máxima do que as outras pessoas.

Pessoalmente, eu nunca estabeleceria um precedente com resultados de qualidade tão baixa, mas, novamente, eu não iria para a corrida até o nível inferior de clientes que sua empresa aparentemente está tentando atender.

A sua gerência decidiu que estes são os clientes que eles querem ter e não há necessidade de tentar vender o cliente em softwares mais caros e de alta qualidade, se eles estiverem bem com as coisas.

Você não vai conseguir que a gerência mude, apenas seus clientes farão isso. Você pode conseguir clientes melhores ou conseguir um emprego melhor.

Soa como meu trabalho antigo

Isso costumava acontecer o tempo todo no meu antigo emprego. Eu concordo que as vendas impulsionam tudo. O gerente da loja (Conjunto de Habilidades: 80% de Vendas, 20% Gráficos) estava constantemente atendendo aos recursos que os clientes queriam. Um trabalho de 20 horas seria vendido a um preço de 10 horas porque o cliente não estava disposto a pagar mais ou (eu costumo pensar) que o gerente de vendas não enfatizou o suficiente O valor que o cliente estava ficando.

O gerente de vendas costumava exibir os recursos e widgets de clientes em potencial que criamos para diferentes clientes. E é claro que ele iria subestimar esse recurso para o novo cliente em potencial porque nós realmente não precisávamos recodificar a coisa ... tudo que precisávamos fazer era copiar e colar o código de um site diferente e plop neste site. Nós já o construímos.

Depois de várias sessões de "por que você não consegue fazer isso mais rápido ... você já fez isso para o cliente x". e "Demorou apenas 10 horas para o cliente e como é necessário 16 horas para o cliente z".

Perguntamos ao vendedor qual era o objetivo? Ele disse para vender o maior número possível desses itens pelo preço mais barato que pudermos.

Nós dissemos a ele que somos uma loja de qualidade e fazemos um trabalho de qualidade. Dissemos a ele que, ao baixar o preço, ele realmente estava diluindo o valor do nosso trabalho e, ao fazê-lo, o cliente voltava para nós para novos recursos que não tinham sido desenvolvidos anteriormente (ou seja, a opção de copiar e colar do site x wasn lá, eles iriam empurrar de volta os preços e o gerente de vendas cederia sob a pressão.

Decidimos avaliar nossos widgets com um preço premium como é. Qualquer modificação seria extra. Convencemos a administração de que, se tivéssemos tempo para desenvolver esses widgets para que pudéssemos retirá-los de nossa " Biblioteca de códigos " em vez de outros sites, poderíamos criá-los de maneira mais genérica. -los em um site existente em 2 horas e são pagos por 10 horas.

Ele começou a vendê-los "como estão" com cobranças premium por modificações e nós conseguimos jogá-los e fazê-los trabalhar em duas horas. Também começamos a adicionar esses widgets a " nosso site " e paramos de usar outros sites de clientes como ferramentas de vendas. Nós só usaríamos outros websites de clientes para mostrar como o widget poderia ser personalizado " por uma pequena taxa " para agir como este ou aquele.

Para provar nosso conceito, nós (os desenvolvedores) ficamos atrasados depois do trabalho algumas noites para construir um widget genérico e o colocamos em nossa biblioteca de códigos. A vida ficou melhor. As discussões mudaram de por que está demorando tanto para ... " Ei, você pode revender esse widget x x cliente? Se sim, quais recursos você quer que adicionemos ao modelo básico para ajudá-lo vendê-lo. "

Eu vi empresas fazerem isso. Eles acabam com clientes irritados. Os clientes têm o hábito de voltar e pedir novos recursos assim que o aplicativo começa a ganhar dinheiro ou está integrado ao fluxo de negócios. Em breve você terá que dizer a esses clientes que você não pode adicionar novos recursos à bagunça que criou, porque você não pode mais lidar com a base de códigos. Ou vai demorar muito mais tempo.

Os clientes (mesmo em uma situação competitiva entre si) tendem a falar. Seja diretamente, por funcionários que mudam de empresa ou por reuniões aleatórias em eventos típicos de sua linha de negócios (conferências, exposições). Você logo encontrará dificuldades para adquirir novos clientes se sua empresa tiver uma má reputação.

Além disso: A codificação de baixa qualidade funciona somente (se for possível) se você limitar sua empresa a projetos muito pequenos. Qualquer coisa maior ou mais complexa perderá tempo (e isso por dinheiro) instantaneamente, mesmo dentro do primeiro ciclo de vida do projeto, simplesmente gastando mais tempo de depuração do que o estimado.

Ensine-o sobre dívida técnica

O que você tem que fazer é fazê-lo perceber as conseqüências das escolhas que ele faz. Rápido e sujo pode ser bom, às vezes, porque você pode fazer as coisas mais rapidamente, mas tem consequências a longo prazo.

Se, por exemplo, o projeto nunca teve a intenção de ter uma grande base de código, a rapidez e a sujeira podem ser a maneira perfeitamente correta de lidar com esse projeto.

Ward Cunningham surgiu com a brilhante metáfora "Dívida Técnica". Assim como você pode tomar um empréstimo no banco para conseguir algo mais rápido (em vez de economizar), você tem que pagar mais a longo prazo porque você tem que pagar juros. Isso pode ser uma coisa boa, se o valor de obter sua "coisa" mais rápido supera o custo de juros.

Soluções rápidas e sujas são como empréstimos no banco. E, novamente, se o valor de obter um recurso anterior supera o custo de limpeza depois, o empréstimo pode ser a abordagem correta.

Mas se você pegar mais e mais empréstimos no banco, então no final você paga todas as suas receitas em juros. Apenas o mesmo com dívida técnica. Se você fez muitas soluções rápidas e sujas, sua dívida técnica será tão alta que seu progresso será interrompido.

Eu vi isso acontecer. Em um projeto em que trabalhei, a dívida técnica era tão severa que não tivemos nenhum progresso por 3 meses, apenas tentando consertar bugs, que introduziam novos bugs, etc.

Se você puder fazê-lo entender completamente o conceito de dívida técnica, ele deve ser capaz de tomar as decisões corretas (boa sorte, é um durão). Observe que a solução correta ocasionalmente também significa rápida e suja.

Uma última coisa que você pode apontar é que os desenvolvedores são mais produtivos se estiverem altamente motivados;)

O custo da manutenção costuma ser muito maior, e geralmente a maior parte do custo, de um software.

Se você programar rápido e sujo, a manutenção será mais difícil e o custo também.

Se você construir todo o seu software de maneira rápida e suja, será ruim e seus clientes notarão. A longo prazo, se seus produtos continuarem a ser ruins e com erros, você os perderá. Os clientes vão querer pagar ao seu concorrente um pouco mais por um produto de boa qualidade do que sofrer seus erros.

Seu chefe não entende isso?

Em todos os casos, com exceção do mais raro, você não pode convencer alguém que é insanamente míope que mais é quase sempre melhor em nossa profissão. Desculpe, mas essa é a verdade; pessoas de visão curta vão sacrificar tudo no caminho para colher os benefícios agora e quase sempre sofrerão no final.

Às vezes, a solução correta é para mudar de posição para um local em que as pessoas sejam inteligentes o suficiente para entender os benefícios da qualidade e não sejam míopes.

Observação: essa resposta usa uma estratégia de comunicação empresarial que tenta usar a razão para garantir que todos estejam conseguindo o que desejam. Se o problema é simplesmente que fazer engenharia de baixa qualidade está minando sua vontade de viver ou que seu chefe é um motorista de escravos e parece não haver um fim à vista, pode ser que na verdade seja hora de uma mudança de cenário.

Você não está falando a língua do seu chefe. Parte do seu trabalho é dar informações ao seu chefe para que ele possa tomar decisões, e você precisa mudar sua estratégia de dar informações. Você está falando em linguagem de engenharia, e o que ele precisa ouvir é risco, custo, investimento e retorno. Você também precisa ser um pouco defensivo e ter certeza de que há um bom registro do que você o informa de.

Existem duas partes para isso:

O primeiro é a comunicação da sua estimativa e da ideia de que não é uma meta ou um plano. Eu poderia escrever volumes aqui, mas seria basicamente uma cópia de tudo na " Estimativa de Software: Desmistificando a Arte Negra de McConnell ", um livro para o qual você deve correr, não andar, até a sua livraria. Tenha cuidado para distinguir entre estimativas, metas e compromissos, e certifique-se de fazer uma estimativa real antes de se comprometer com alguma coisa!

O segundo é a comunicação dos riscos reais que o seu chefe estaria interessado. Simplificando, isso significa que você precisa dizer ao seu chefe que a implementação que poderia ser concluída em 1,5 dias atenderá aos requisitos básicos, mas aumentar significativamente o risco de que futuras mudanças e recursos exigirão muito mais tempo do que o necessário. Se ele perguntar por que, use a analogia da construção de casas: se o seu software é uma casa, cada mudança é uma nova peça de mobília, e cada característica é um novo andar. Se você não tem uma base strong e não reforma / recondiciona um pouco toda vez que faz alguma coisa, eventualmente estará na situação em que a grande remodelação será necessária apenas para suportar o peso e o tamanho de um novo tratamento de janela, e toda a casa terá que ser reconstruída se eles quiserem suportar quatro novos andares e um deck.

Isso coloca a bola de volta na quadra do seu chefe - você deu a ele informações, e ele precisa decidir. Ele precisará pensar se haverá ou não mudanças futuras e se ele quer ou não ignorar essa possibilidade. A partir daí, se for decidido que a rapidez e a baixa qualidade são o caminho a seguir, certifique-se de que você (com tato) alerta os lembretes sobre essa decisão em praticamente todas as comunicações e documentações possíveis. Envie um e-mail de acompanhamento que confirme a decisão e os riscos que você comunicou, comprometendo-a a escrever. Anote sobre a estratégia de engenharia e os riscos em suas especificações.

Quando chega o dia em que o cliente quer uma piscina instalada no 50º andar, e você vê que os últimos 20 andares foram construídos com paus e areia, certifique-se de que a grande estimativa de gordura que você produz seja tecnicamente justificável e prepare-se para lançar a trilha de papel das faturas de baixa oferta para ilustrar por que isso vai custar tanto.

Se você realmente fez todos esses argumentos e ele ainda os os afasta, então é seu dever como profissional elevar essa preocupação para uma instância mais alta. Sim, isso significa passar por cima da cabeça dele. A razão para isso é simplesmente que seu chefe é um perigo para a empresa.

Minha experiência com esses caras é que eles eventualmente levarão sua organização ao fracasso ou pelo menos à mediocridade. Seu produto vai sugar e seus clientes vão te deixar.

Para o registro: estou assumindo que o negócio principal da organização é o desenvolvimento de software e o produto é importante e não algo descartável.

Seu chefe pode estar certo. Eu posso pensar em cenários onde esse tipo de codificação é suficiente. Digamos que você escreva scripts descartáveis para algum tipo de análise de dados ou sites dinky onde você pode olhar algumas páginas e ter uma idéia do que está acontecendo. Esses tipos de coisas não precisam ser superimplementados, pois é improvável que sejam mantidos. Se isso é o que os clientes querem, então é isso que os clientes vão conseguir.

Agora, também pode ser que o seu chefe esteja equivocado e os clientes não apreciem produtos que funcionem mal. Este é mais frequentemente o caso.

Também pode ser uma opção para encontrar algum tipo de mídia feliz. O principal é que, se algo não está funcionando, precisa mudar. Claramente, seu chefe não está satisfeito com a forma como o processo de desenvolvimento está afetando os negócios. O tempo de entrada no mercado é tão importante quanto a qualidade do produto. O que você precisa fazer é argumentar que sua equipe pode produzir um produto de qualidade em um período de tempo que não destrua a comercialização do produto. Se os princípios de engenharia forem usados corretamente, isso não deve destruir a produtividade de uma equipe. Se alguma coisa, usando boas práticas deve acelerar o processo de desenvolvimento e aumentar a qualidade.

Sim, podemos invadir isso juntos hoje.

Se fizermos isso dessa maneira, haverá mais bugs do que a média e será um sério retrocesso no desenvolvimento futuro. Hackear isso juntos é realmente algo que podemos fazer uma ou duas vezes. Pense nisso como um arranha-céu, podemos ter uma boa fundação, e temos 10 andares que são muito legais também, se você quiser, podemos rapidamente juntar algumas barracas e caixas no 11º andar, talvez até construir um 12º andar de tendas e caixas, mas você está ferrado por ir além disso. Temos que tirar todo mundo desses dois andares, montá-los, re-treinar tudo e construir tudo de novo só para chegar ao 13º andar.

Se tentarmos construir um décimo terceiro andar de caixas e tendas, poderíamos desmoronar três andares a qualquer hora aleatória, e levaria meses apenas para obter os blocos de jenga e o duplo super-colado nos pontos certos.

Isso é aceitável para você?

W. Edwards Deming é mais conhecido por seu trabalho na reconstrução da manufatura japonesa após a Segunda Guerra Mundial. Muitas vezes esquecido é o fato de que seu trabalho é, na verdade, mais sobre administração do que sobre manufatura. De fato, uma seção importante de seu livro Out of the Crisis é sobre como melhorar a qualidade nas organizações de serviços. Seus exemplos de organizações de serviços incluem software, bancos, seguros e igrejas.

Deming argumenta - com muitas evidências do mundo real para comprovar - que o aumento da qualidade aumenta o lucro.

Você pode analisar o desenvolvimento de software como um processo de negócios. Como a manufatura, produz produtos intencionais, não intencionais, diretos e indiretos.

Produtos diretos intencionais de fabricação e programação incluem torneiras e código-fonte. Produtos indiretos intencionais incluem dívida e renda.

Produtos não intencionais dos processos de fabricação incluem torneiras que apresentam defeitos de fabricação, incêndios acidentais, ferimentos, alta rotatividade de funcionários e roubo de funcionários. Produtos não intencionais de processos de programação incluem bugs, dificuldades de manutenção, dificuldades de escalabilidade, problemas de segurança, alta rotatividade de pessoal e roubo de funcionários.

Cada um desses "produtos" está sujeito a variação, análise estatística e melhoria de processos.

No seu caso, você provavelmente precisará enumerar e quantificar os produtos não intencionais de seus processos de desenvolvimento de software e gerenciamento de projetos.

Deming é uma das principais razões pelas quais o Japão é uma potência mundial na manufatura. O Prêmio Deming é nomeado após ele.

Isso pode parecer óbvio, mas acho que você precisa encontrar uma via secundária. Não desista de sua atitude de chefe fora de mão. Sua opinião sobre isso é provavelmente tão estranha para ele quanto a dele é para você.

Qualquer extremo não é, obviamente, bom para ninguém, então tente e negocie um meio-termo.

Eu não acho que seja possível. Diferentes empresas têm diferentes culturas e se a cultura de sua empresa atual (rápida e suja) não combina com você, então eu acho que você deve seguir em frente. Algumas outras empresas têm uma opinião contrária e você trabalha com pessoas que pensam da mesma maneira que você.

Eu realmente não quero entrar na discussão que tipo de cultura é melhor (veja os outros posts se você estiver interessado), tudo o que estou dizendo é que será benéfico para a sua saúde mental se você trabalhar em uma empresa com a mesma abordagem.

Eu passei por todas as perguntas e vi que ninguém entrou na perspectiva da segurança ...

Sim, outros mencionaram o tempo de depuração, mas neste caso, a depuração só é feita no nível de 'ei, finalmente funciona'

Nos meus projetos (pequenos e / ou grandes), mantenho um alto nível de atenção às explorações e possíveis falhas de segurança.

Levar isso em consideração e testá-los requer uma quantidade considerável de tempo, mas pelo menos dessa forma eles não estarão me acusando por não fazer o melhor que pude quando algo de ruim acontecer.

Eu aposto que quando você estiver indo rápido e sujo, esqueça de limpar algumas variáveis, esqueça de fazer alguns controles nas funções e, assim, tornar seu projeto um bom ponto de partida para hackers.

Quando meu chefe pergunta por que algo me levou tanto tempo, mostro a ele todas as verificações de segurança e função que construí para evitar coisas como injeção, inclusão, loops infinitos e até mesmo as medidas de segurança para quando algo é hackeado causa dano mínimo

Fazer coisas rápidas e sujas pode atrasá-lo antes mesmo do almoço. Muitas vezes, ele começa a doer mesmo antes de você estar completo o suficiente para tentar aceitá-lo por um cliente.

Talvez você possa tentar a metáfora da dívida técnica, o ônus dos pagamentos de juros será maior do que a renda depois de algum ponto.

Orientar para uma reescrita também é uma oportunidade para os seus clientes experimentarem uma empresa de desenvolvimento diferente (se quisermos começar do zero, eles podem também).

Se você não tem empregadores alternativos em sua área, pode haver mais do que muitos clientes para se desgastar também. Então, basicamente, seu chefe pode continuar fazendo o que ele está fazendo, nenhuma competição que faça melhor. Talvez comece seu próprio negócio? ; -)

Alternativamente, você poderia simplesmente dizer a ele que você sempre faz as coisas "rápidas e sujas" e apenas faz as suas próprias coisas.

Jogue matemática nele. Infelizmente, não tenho os livros à mão para fornecer citações (espero que alguém possa me ajudar), mas um ou ambos do Programador Pragmático e do Código Completo 2 têm uma seção que faz referência a estudos que mostram o impacto do custo de fazer as coisas 'n' maneira suja, versus tendo tempo para consertá-lo mais tarde. Outros pôsteres forneceram muitos argumentos, mas dependendo do comportamento do seu chefe, ele pode responder muito melhor ao apoio de estudos existentes. Ele pode pensar que você está apenas tentando economizar tempo e aliviar sua própria carga de trabalho. Mostrar a ele que é um fato aceito pela indústria, em vez de apenas sua opinião, pode ser o ingresso.

Estou de alguma forma em situação semelhante a você. Eu trabalho para uma empresa de serviços, então escrevo um aplicativo personalizado para diferentes clientes. As pessoas encarregadas de entregar o aplicativo (como gerentes de projeto, executivos de projetos, etc.) realmente não se importam com a qualidade do código (embora digam que sim), tudo o que importam é entregar o material a tempo para maximizar o lucro. Sempre me pedem para escrever recursos dentro de um curto período de tempo.

Uma técnica que usei para manter a qualidade do código enquanto cumpria o prazo é a refatoração contínua. Se eu for solicitado a escrever o recurso A em 1 dia, o que na verdade levará de 3 a 5 dias para escrever com alta qualidade, eu apenas farei o caminho rápido e sujo e entregarei. Mas enquanto faço a maneira rápida e suja, mantenho anotações sobre a área que podem / devem ser melhoradas. Então, mais tarde, no ciclo de desenvolvimento, encontrarei pedaços de fragmentos de tempo aqui e ali para refatorar meu código no recurso A.

No começo, foi uma experiência dolorosa refatorar meu código rápido e sujo; Lembro de alguns casos em que reescrevi quase completamente um recurso durante a refatoração. Mas à medida que faço mais e mais refatoração, meu código rápido e sujo começou a ficar menos sujo. Comecei a desenvolver um melhor senso natural de design modular, para que os códigos que escrevo se tornassem cada vez mais modulares, mesmo se eu estivesse no modo rápido e sujo.

Não é errado pensar que a qualidade do código não importa, porque para muitas pessoas isso realmente não importa. Como você realmente se preocupa com a qualidade do design do circuito dentro da sua TV SONY, desde que ele exiba uma boa imagem HD e funcione bem por 5 a 10 anos?

Como desenvolvedor, você deve se preocupar com a qualidade do código, porque sabe o benefício disso. É improvável que seu chefe mude de ideia sobre a qualidade do código, a menos que ele experimente algumas novidades onde a qualidade do código economiza seu dia ou quando ele vê pessoalmente a correlação entre lucro e qualidade do código.

Só por causa da falta de conhecimento do seu chefe na qualidade do código, não significa que você deve comprometer a qualidade do código (no entanto, ainda é uma boa idéia manter o canal de comunicação aberto com o seu chefe sobre a qualidade do código). Esforce-se para encontrar o ponto de equilíbrio entre a qualidade do código e o cronograma de desenvolvimento. Você não pode escrever um código de boa qualidade para a programação atual, não significa que você não possa melhorar a qualidade nas programações futuras, certo?

Eu tenho um strong sentimento de que não há nada que você possa dizer neste caso. Mas alguns pontos eu traria:

Corrigir problemas demora mais

Quando você copia e cola o código todo o lugar, quando você encontrar um bug nesse código, levará mais tempo para ser corrigido e levará mais tempo para ser testado. Assim, você estará desperdiçando horas extras na fase de suporte (como eu estou supondo que você não tem uma fase de testes integrada com uma mentalidade de 'saia da porta') .

Adicionar um novo recurso demora mais

Adicionar um novo recurso ao código espaguete leva muito mais tempo. E como é uma tarefa de copiar e colar, você precisa ajustar o código em muitos lugares. Isso, por sua vez, criará bugs ou funcionalidades inesperadas em vários lugares. Assim, você terá que perder horas extras na fase de suporte.

Elementos de interface do usuário e terminologia para novos clientes são mais longos

A empresa na qual estou trabalhando agora é que o cliente da web começou a copiar e colar a bagunça do código de espaguete. Antes de começar, demorou duas semanas para descascar o cliente da Web para um novo cliente.

Depois de algumas longas noites, agora leva uma tarde. Eu ainda estou trabalhando e aprimorando para que leve menos tempo.

Se o seu patrão deseja tornar um produto que é fácil de vender para diferentes clientes, ele precisa investir tempo para garantir que você não perca tempo com o produto quando estiver vendendo novos recursos.

Vai ser difícil, mas você precisa fazer com que seu chefe entenda que, a menos que você passe algum tempo agora para garantir que seja feito corretamente, você perderá muito mais horas no futuro com bugs, e isso realmente levará mais tempo para você Prepare o produto para um novo cliente no futuro.

Tudo o que ele gosta é a linha de fundo, então você precisa fazê-lo entender que codificar dessa maneira não vai ajudar e só vai atrapalhá-lo.

A melhor resposta possível seria da abordagem Agile:

lançamento antecipado, lançamento frequentemente

Lançamento antecipado é bom para sua empresa porque você começa a receber o pagamento antecipado. O primeiro ponto de liberação é quando o produto tem funcionalidade suficiente para que possa ser usado pelo menos em algum aspecto. Por isso, adiciona o valor da empresa do cliente. É por isso que é inteligente desenvolver módulo por módulo.

O lançamento com frequência é bom para o seu cliente, pois eles conseguirão o que precisam . Eu intencionalmente não escrevi querer, porque o resultado final freqüentemente difere da ideia no início.

Se nada mais, isso satisfará mais os seus clientes, pois eles se sentirão mais envolvidos e você estará interagindo passo a passo com o seu produto.

Uma coisa que descobri foi que uma base de código limpa pode suportar uma pele de sujeira sem muita dificuldade. Se você tem um CMS principal que você personaliza para pessoas diferentes, quaisquer problemas no núcleo irão assombrá-lo. Mas um plugin específico do cliente mal testado e mal-feito pode passar sem muitos problemas.

No seu caso, parece que você não construiu o núcleo limpo, então você está muito ferrada. Ainda assim, você deve preferir pedir tempo para melhorar sua base de código principal, o que deve beneficiar seus clientes existentes e acelerar o desenvolvimento futuro.

Diga a ele que ele pode economizar dinheiro. Roger Pressman escreveu que você gasta 20% do seu dinheiro construindo o software e 80% mantendo-o.

Se você precisa criar rapidamente para não perder um contrato, faça isso, mas em um ramo alternativo. Depois disso, faça de novo da maneira certa.

Eu quero resumir.

• Se o código for mantido por muito tempo, a qualidade do código é um problema.
• Para o código de prototipagem, não é um grande problema. Normalmente as pessoas jogam fora tal código.
• A qualidade do código escrito por um programador é alcançada através da prática. Como a maneira como temos experiência, vamos conseguir uma boa velocidade vs. Relação de qualidade. Eu vi programadores que costumavam perguntar: "Dê-me 3 dias para atualizar com o padrão de codificação". Isso é uma merda completa. Por que eles estão tomando cuidado ao escrever o código em si? Uma vez que o teste é feito, e indo para atualizações padrão pode levar a problemas.
• Mesmo que não projetemos oficialmente algo, teremos algum tipo de design em mente antes de escrever o código. Nestas situações, a qualidade depende de pensamentos do desenvolvedor.
• Os gerentes são notórios quanto a cronogramas, esforço e orçamento. Se você puder fazer algo em um determinado limite, concorde com isso. Caso contrário, diga a ele o que você pode fazer dentro do período dado. Ou dê sugestões sobre as pessoas que podem contribuir bem para o problema específico

Como obter o melhor dos dois mundos? Use fábricas de software. Gaste seu poder cerebral em criar ferramentas que podem fazer o que pode ser repetido. Por exemplo, dê uma olhada no Ruby on Rails ou, se você for um .NET, veja ASP.NET MVC combinado com um pacote nuget chamado MVCScaffolding . Eu estou atualmente cavando nesta ferramenta e personalizando-a para gerar o que eu preciso para o meu fluxo de trabalho. A criação de um site CRUD simples e baseado em banco de dados é um controlador Scaffold fácil. Agora posso gastar meu tempo personalizando a interface do usuário e refinando a lógica de negócios que direciona o aplicativo.

Como mencionei, você pode personalizar a ferramenta (por exemplo, alterei o modelo de controlador padrão para usar meus utilitários IRepository / IUnitOfWork internos, o que me permite alternar facilmente entre os datastores EF e InMemory para teste). Na maior parte, a maior parte do meu desenvolvimento é gasto refinando o modelo de objeto para suportar os cenários de uso de negócios.

Eu apresentaria seu chefe ao LulzSec. Eles podem implorar para diferir que a qualidade do código em aplicativos da web não importa ...

LIE : Quando o seu patrão pergunta o quão rápido para "rápido e sujo" - diga a ele "que foi a estimativa rápida e suja".

Muitas das respostas neste tópico são baseadas em raciocínio. A última falha nessa abordagem é que você está conversando com um homem de negócios .

Quem está lucrando? O que este processo está fazendo para sua carreira de longo prazo? Isso desvaloriza o trabalho e, finalmente, o valor de sua habilidade. Mesmo se você for um empreiteiro de curto prazo, pense no efeito de longo prazo na indústria de reduzir o custo de um trabalho razoável.

Por todos os meios, corte sua roupa de acordo com o seu pano - mas "rápido e sujo" não é uma opção. Se o cliente solicitar um recurso, esse recurso leva um nível básico de tempo para ser concluído em um padrão razoável . Não forneça horários para nada menos que uma implementação razoável.