Eu posso entender a pressão do cronograma. Você deseja agradar seus usuários, pois eles são a força vital da empresa. No entanto, também é verdade que certas mudanças facilitarão tudo no futuro. Infelizmente, a gerência da minha organização tem uma resistência instintiva a essas mudanças e essa resistência é tão forte que atrapalha as melhorias de longo prazo.

Por exemplo, a Apple lançou recentemente a Contagem automática de referência para programas iOS. Essa é uma grande melhoria em relação às chamadas manuais de retenção / liberação que anteriormente era necessário usar. O código é mais fácil de escrever e mais fácil de manter. É provável que a mudança em si produza algumas falhas. Mas, uma vez resolvidos, o número de falhas estranhas aleatórias provavelmente diminuirá.

Mencionei recentemente ao meu chefe que queria mudar para a contagem automática de referências. Sua resposta foi que ele queria se concentrar em melhorias visíveis. É provável que essa resposta tenha sido motivada pela pressão que ele está recebendo de cima dele - e provavelmente diretamente do CEO.

Existem muitos exemplos semelhantes. O ponto comum é que algo precisa ser corrigido, mas os custos de curto prazo superam os benefícios de curto prazo, onde "curto prazo" é definido como "nas próximas semanas".

Como devo lidar com a situação?

EDIT: Obrigado pelas respostas. Continue vindo. Por ser relevante para minha situação, devo deixar claro que meu gerente e o CEO são ambos programadores - embora o CEO possa já ter esquecido como é isso. Aparentemente, seu lado programador foi dominado por outras pressões.

Você está realmente falando sobre dívida técnica. Talvez uma metáfora ajude seus gerentes. Costumo comparar o efeito da dívida técnica no software com a cozinha em uma cozinha suja. Se a pia, os balcões e o fogão estiverem empilhados com louça suja e houver lixo no chão, leva mais tempo para fazer uma refeição. No entanto, a maneira mais rápida de preparar a próxima refeição é contornar a bagunça. Limpar a cozinha e mantê-la limpa atrasará a próxima refeição, mas melhorará a entrega de todas as refeições subsequentes. E, assim como a pessoa com fome na sala de jantar não pode ver a cozinha bagunçada e não entende por que deseja limpar antes de começar a cozinhar, sua gerência não pode ver a bagunça no código. Você precisa mostrar a bagunça ou mostrar os problemas de qualidade e os atrasos causados ​​pela bagunça.

Talvez você também possa falar sobre tarefas urgentes e tarefas importantes. Quando tarefas importantes não são realizadas, as tarefas urgentes levam mais tempo e custam mais.

Você se deparou com algo que atormenta os programadores em todo lugar em algum momento de suas carreiras: esse código precisa ser refatorado, há problemas de arquitetura por lá, esse módulo está se tornando insustentável etc. Por causa da cultura atual de sua organização, no entanto, você está sendo pressionado a se concentrar no trabalho que gera apenas benefícios diretamente visíveis .

É o clássico Iceberg Secret novamente. O segredo está no fato de que, assim como um iceberg está 90% debaixo d'água, o mesmo ocorre com a maioria de qualquer projeto de desenvolvimento: 90% do trabalho será completamente invisível para o usuário final. Esse código terá um impacto no usuário final, mas a gerência tem dificuldade em entender por que você passou seis horas refatorando as chamadas de manutenção / liberação e referência automática quando Eles não podem ver nenhuma diferença e tudo está funcionando bem.

Aqui estão alguns fatos que você pode levar sobre esse assunto.

• A gerência, a menos que eles próprios sejam programadores , não entenderá o segredo do iceberg.
• Este é um problema de ignorância, não de malícia. O CEO quer um bom produto - ele simplesmente não entende tudo o que entra em um bom produto.
• O CEO (e seu chefe direto) não são estúpidos - estude e prepare alguns fatos e alguns dados concretos sobre por que você deve gastar seu tempo nisso e em outros problemas do Iceberg.

Não se esqueça - você é um homem de empresa (ou mulher). Não é um homem de código. Você está desenvolvendo este produto para uma empresa que tem interesse em seu sucesso ou fracasso - seus projetos e propostas de projetos devem refletir isso. Mostre sua paixão pela empresa e pelo produto, mostre seu conhecimento e prove ao seu chefe e CEO que eles devem confiar em você quando você os encontrar e dizer que algo precisa funcionar. Mostre a eles como isso contribuirá para o resultado final - seja agregando valor ao produto (mais pessoas comprando cópias) ou economizando tempo no caminho (menos clientes irritados quando seu produto falha).

Você não

Eu vejo essa pergunta e todas as perguntas como um beco sem saída. Você não pode "convencer" as pessoas de nada. Se eles ainda não estão cientes de coisas como essa ou estão investigando, é provável que não dêem uma olhada. E nenhuma quantidade de dados os convencerá do contrário. A mudança deve vir de dentro. Você pode levar um cavalo à água, mas não pode fazê-lo beber.

Eu digo que faça as alterações desejadas nas suas próximas estimativas técnicas. Seja como, ei, "precisamos" atualizar para esse novo quadro que a Apple introduziu. Não deixe de não usar o ARC estar no seu roteiro. Não há opções; migrar para o ARC é o único caminho.

Eu já respondi uma pergunta semelhante aqui antes, então isso pode ser considerado uma duplicata. Basicamente, você não receberá aprovação para fazer um "esforço de refatoração". A maneira de tornar o código mais limpo é seguir a regra dos escoteiros: sempre deixe o código mais limpo ao deixá-lo do que quando chegar.

Assim como pagar dívidas reais pode parecer uma tarefa intransponível (ou limpar uma casa bagunçada). O truque é torná-lo melhor, peça por peça, até você começar a ver "ilhas de limpeza". Depois de ter um momento significativo, outros desenvolvedores da equipe começarão a perceber e, eventualmente, contribuir para a tarefa.

Eu sugiro ler o Clean Coder do "tio" Bob Martin. Escrever um bom código faz parte do seu trabalho. Você não pede permissão para fazer o seu trabalho, apenas o faz.

Assim como outras questões dessa natureza, você precisa fornecer números que a gerência entenderá. Números que mostram quanto tempo será economizado com a implementação dessas melhorias, quantos menos "falhas estranhas aleatórias" ocorrerão etc. Convencê-los de que as falhas são visíveis ao usuário final e que tudo o que é feito para evitá-las é bom para os negócios.

Você também pode tentar implementar essas melhorias no seu próprio tempo (ou seja, fora do horário de trabalho) e depois mostrar os benefícios para o gerenciamento posteriormente. Eu faria isso apenas quando estiver claro que a gerência não entende o que você está tentando transmitir e / ou que eles não querem alocar tempo para você tentar.

Boa sorte!

Apresentar um caso de negócios

Há muitas razões pelas quais as recomendações do engenheiro geralmente são ignoradas. A melhor maneira de lidar com quase todos os motivos é o caso comercial do motivo pelo qual isso deve ser feito. A clássica análise de custo / benefício. Isso não apenas cria um argumento convincente, mas também oferece aos seus chefes algo a ser levado para seus superiores.

• Qual é o custo inicial?
• Qual é o custo contínuo?
• Quais são as economias projetadas de dinheiro / tempo e de onde elas vêm?
• Quanto tempo leva para vermos o ROI?

Ao fazer um caso de negócios, você sempre deve fazer backup de seu argumento com dados.

• Quanto tempo o desenvolvimento está gastando atualmente lidando com problemas que isso irá remover ou mitigar?
• Quantas reclamações de usuários você se relaciona com os problemas que isso remove ou atenua?
• Que outros benefícios terá?

Alinhe os números e faça uma equação aproximada, mas simples. Isso custará X e beneficiará a empresa Y.

Nota: Não se surpreenda se for proibitivamente caro implementar uma boa ideia academicamente.

Esse tipo de alteração se enquadra na categoria de refatoração. A abordagem ágil seria que você deveria incorporar o tempo de refatoração AMPLE em cada história que estima e é exatamente por isso. Além dos engenheiros, ninguém vai entender por que você quer fazer isso e tudo bem, não é SEU trabalho determinar como codificar corretamente, é seu.

Portanto, da próxima vez que você tiver um pedaço de trabalho, certifique-se de que essas alterações façam parte dele. Se você estiver fornecendo estimativas, adicione 30% à sua estimativa para refatoração; se você não estiver fornecendo estimativas, faça a refatoração como parte do seu trabalho.

Isso pode torná-lo mais lento - bem, não, esse não é o jeito de encarar, o jeito de encarar é que sua velocidade atual é uma ilusão, essencialmente uma mentira de que você está passando pela corrente, você realmente deve ser um um pouco mais devagar por causa desse trabalho que você sabe que precisa ser feito.

Você provavelmente poderia construir casas mais rapidamente se não usasse concreto como base - e elas pareceriam tão boas para o cliente, mas - bem - Mesmo que o cliente não veja a necessidade da fundação, o construtor precisa de. (Na verdade, esse é um paralelo interessante, porque os construtores nem sempre fazem o que sabem que devem fazer, por isso precisamos aprovar leis para forçá-los a fazê-lo - não existem leis que governem o desenvolvimento de software, mesmo que enfrentemos o mesmo decisões e muitas vezes toma as erradas ...)

Você menciona que é sortudo o suficiente para que seu gerente e CEO sejam ambos programadores. Então, eles provavelmente não entendem o que dívida técnica é.

Você deve lidar com a situação tentando resolvê-la com base em fatos, o que significa que há uma possibilidade real de que você não acabe fazendo as melhorias técnicas que deseja (os fatos podem ser irritantes dessa maneira).

Seu trabalho é garantir que eles entendam os custos e benefícios de quitar qualquer dívida técnica em particular. O trabalho deles é decidir se o melhor uso dos recursos é pagar ou fazer outra coisa.

Assim como pode ser difícil para as pessoas que não estão envolvidas no código ver os benefícios de melhorar o material "oculto", pode ser difícil para os programadores ver os benefícios das alterações visíveis no código quando os benefícios se agregam às áreas da empresa " escondido "dos desenvolvedores.

É bom que sua gerência possa explicar por que os recursos visíveis valem mais o seu tempo do que pagar a dívida técnica, mas, na verdade, não é seu trabalho fazer a determinação de qualquer maneira. Portanto, explicar isso para você não faz muito pelos negócios, exceto para mantê-lo feliz. E de certa forma, insistir que eles fazem isso não é confiar neles para fazer seu trabalho. Se você não gosta quando eles o administram de forma micro, você deve entender.

Portanto, desde que você os mantenha cientes do status de todas as dívidas técnicas e dos custos e benefícios de ignorá-las versus pagá-las, você cumpriu sua tarefa. A menos que você realmente não confie na gerência para fazer a deles, nesse caso, você tem um problema muito maior que seria outra questão a ser resolvida.

Talvez isso não seja uma resposta, mas uma resposta baseada nos erros que cometi. Também um desacordo com algumas das filosofias que li aqui.

• Não caia na crença de que o programador sabe melhor.
• Seja honesto. Re-fatore à medida que avança, mas não minta e preencha estimativas para seus próprios propósitos.
• Você não possui o código. Não realize trabalhos que não sejam aprovados pelo líder.
• Você pode estar certo sobre alguma coisa; você pode estar errado ... mas você deve fazer o que é pago para fazer.

Mas certamente siga os excelentes conselhos dados para melhorar as coisas.

Você obviamente trabalha para um chefe de cabelos pontudos (PHB). Ele não programa mais, se é que alguma vez o fez, e se o fez, provavelmente não foi bom (embora ele goste de usar frases como "correção constante" e "falha de segmentação", para que os rapazes saibam que ele ganhou as rédeas dele. ) - foi assim que ele foi escolhido para a gerência.

O CEO (que praticamente tem um Mohawk) gosta do PHB porque o PHB fornece recursos . A cada sprint, ele orgulhosamente demonstra uma nova caixa de seleção (ligeiramente desalinhada, com um rótulo ambíguo), um ícone brilhante (ainda não funciona em qualquer ambiente, mas com cores de 8 bits sobre a Citrix) e um formulário (que apresenta falhas aleatórias devido às condições da corrida na variante xml sob medida, C, implementou o banco de dados local que ninguém da equipe de desenvolvimento ousa tocar porque foi escrito por uma das lendas da antiga guarda há dez anos e faz TUDO com macros com nomes de 5 letras, se precisavam de 5 letras ou não).

Os programadores que realmente fazem o "trabalho" (você sabe o que acontece, inconvenientemente depois de todo o trabalho real, como desenhar círculos em quadros brancos, gritar e comer Battenburgs em miniatura) sabem que em um sistema são , o trabalho que acabava de levar 10 homens e 10 dias para invadir laboriosamente a selva não mantida, provavelmente equivaleria a um ou dois dias, incluindo o teste. Porém, para obter o sistema de onde é correto, pode levar seis meses de trabalho genuinamente difícil, com pouco em termos de recompensa externa óbvia.

O PHB sabe que em 6 meses, por gancho ou por bandido, ele pode inserir trinta ou quarenta novos recursos no aplicativo que os vendedores (que devem ser mágicos, considerando o que estão realmente vendendo) podem ser usados ​​para tentar novas compras e atualizações .

No entanto, para dar ao PHB suas dívidas: sem essas caixas de seleção e formulários, as vendas podem estagnar ou declinar, um concorrente pode ganhar participação de mercado e isso pode ser pior do que a alternativa.

A conclusão a que cheguei é que a única maneira de sair do atoleiro é trabalhar em uma nova empresa, com algumas pessoas que compartilham sua visão de como o software deve ser feito e depois se apóiam obstinadamente nessa filosofia (eu ainda estou trabalhando para chegar lá!)

Há outro custo oculto não mencionado em outras respostas. Ou seja, bons engenheiros tendem a sair no tipo de ambiente descrito. Eventualmente, qualquer pessoa com a ambição ou capacidade de refatorar deixou a empresa e, em seguida, as coisas serão muito ruins, provavelmente não corrigíveis. Infelizmente, você não pode contar isso ao seu gerente sem parecer arrogante ("Sou um dos seus melhores programadores") e um empurrão insistente ("Vou embora se você não fizer o que eu quero"). No entanto, lembre-se de mencioná-lo em sua entrevista de saída, para garantir que você não tenha status de re-contratação.

Você está certo e errado, é por isso que esses problemas permanecem por muito tempo e criam ressentimentos.

As razões pelas quais estão claramente expostas acima: a gerência pensa em dinheiro; ou ainda mais especificamente: receita. Para eles, algo que tem um custo, mas não tem visibilidade direta para o cliente, não adiciona receita, por isso é um plano ruim.

Sua visão também está certa: será boa para os clientes, mas a longo prazo. Suas ações podem gerar uma receita ainda maior no futuro em comparação com os planos de curto prazo.

Você não é o gerente, não é o responsável direto pela receita (presumo, é claro). Então você está misturando (é o que parece para o gerenciamento) com os problemas deles e não está se concentrando no seu trabalho: expandir ainda mais o software.

Todas as palavras claras e difíceis, mas é assim que a maioria dos problemas surge, devido a erros de comunicação. Vocês dois querem a mesma coisa, mas suas decisões de curto prazo são tomadas de maneira diferente. Tudo porque o desenvolvedor tem uma perspectiva diferente em comparação ao gerente.

Como você resolve esse problema? Você se comunica e se entende muito bem em várias questões. Esse será o foco no envolvimento e satisfação do cliente, provavelmente.

Para resolver esse problema em um método estável e à prova do futuro, concorde com uma coisa: meça o custo da correção de bugs no código antigo. Avalie o tempo necessário para trabalhar com o software antigo e como seria com a nova base de código.

Para provar isso, você pode fazer, por exemplo, uma coisa bem simples: ramifique o software em seu controle de versão. Primeiro faça o que a gerência deseja, então crie esse recurso. Você faz isso, mas o acordo é que você tem tempo para mostrar o caminho diferente. Em seguida, faça o mesmo na nova ramificação, mas primeiro corrija os problemas que deseja eliminar. Então também desenvolva a solução.

Agora você tem a mesma solução, mas totalmente desenvolvido de forma diferente. Crie um caso a partir dele, coloque as soluções próximas, incluindo algumas informações de gerenciamento, como estabilidade, quantidade de código necessária e o próprio código.

Agora, pegue um café e comece a dar uma olhada, sem debater quem está certo, mas qual seria a influência de ambas as direções para a empresa. Isso criará uma reunião que é realmente útil e não uma discussão melhor-pior, porque isso não gerará a atmosfera de que ambos precisarão. Isso não vai melhorar o seu produto.

Se você tiver uma revisão de código, crie um ticket técnico informando que o código deve ser aprimorado usando o ARC e atribua ao gerente.

Convença-o. Explique-lhe alguns pequenos exemplos de aprimoramentos técnicos semelhantes que você fez e seus benefícios para os projetos.

Você precisa vender essas alterações da única maneira que a gerência deseja comprar:

Encontre um recurso voltado para o usuário tão atraente que o gerenciamento apenas precisa dele, mas seria impossível sem algumas melhorias de baixo nível no código.

O trabalho do seu chefe é garantir que a empresa concentre o desenvolvimento no fornecimento do que os clientes consideram um valor agregado. Existem dois fatores que podem alterar essa percepção:

1. Quanto tempo leva para entregar uma solicitação do cliente?
2. Você entrega quando diz que vai?

A maioria prefere que você diga que levará 6 semanas e entregue em 5 do que diga que entregará em 3, mas levará 4.

Ter uma base de código atual que é mais fácil de gerenciar e aprimorar permite fornecer mais rapidamente e aumentar a previsibilidade. Se você está gastando muito tempo com correções de bugs, tem menos recursos disponíveis para adicionar novos recursos. Avalie a quantidade de recursos gastos na correção do código e a precisão das promessas de recursos. Essa é uma maneira de determinar se o seu código atual (de acordo com a filosofia do seu chefe) está custando muito.

Permitam-me contar sobre uma oportunidade de US $ 2 bilhões que quase passou despercebida por causa da inércia da gerência.

Alguns de nós têm o objetivo de ouvir a voz do cliente, ou seja, entender o que ele deseja. Nem sempre é o que ele pede, mas se você está em posição de conversar com seu cliente, acaba tendo um entendimento mútuo do que ele deseja. (Então ele pode explicitamente começar a pedir.)

Dito isto, é importante entender quem deve estar tendo essa conversa com o cliente. Você geralmente tem o pessoal de desenvolvimento de negócios junto com alguns designers principais fazendo isso. Se você tiver alguma concorrência, pode esperar que o cliente também esteja conversando com eles.

Ao mesmo tempo, é importante que os desenvolvedores se mantenham atualizados em seus campos, porque haverá uma competição que irá derrotá-lo se você não estiver.

Em nossa situação, tínhamos um cliente existente e um produto um tanto eficaz com base na tecnologia antiga, e o cliente precisava de atualizações rápidas. O que eles realmente precisavam era de um produto de substituição completo, mas a mentalidade de nossa empresa era que isso imediatamente nos forçaria a uma posição competitiva, enquanto a modificação do produto existente permitia que nosso cliente continuasse conosco, sem a obrigação legal de torná-lo competitivo. Nossa administração pensou que eles possuíam esse mercado. O problema era que eles não conseguiam acompanhar as solicitações de atualização, porque a estrutura do produto existente não era flexível o suficiente para atualizar.

O cliente ficou impaciente e começou a conversar com fontes concorrentes. Perdemos nossa "propriedade" desse mercado e alguns bilhões de dólares em receita. No entanto, uma vez que o mercado nos forçou a uma posição competitiva, a gerência não teve escolha a não ser fechar negócios ou competir. (A maioria dos que foram impedidos acabou sendo demitida.) Competimos e fomos capazes de recapturar os negócios com o fio mais fino.

Eu disse no início que essa oportunidade quase escapou por nossas mãos. Recuperamos o negócio pela receita que mencionei. Se estivéssemos mais preparados para nos adaptar às preocupações do cliente no início, não haveria concorrência real.

O que eu ofereço é o seguinte: sempre tente permanecer na vanguarda em suas capacidades pessoais. Sempre desenvolva um produto que seja flexível e possa ser adaptado rapidamente ao que seu cliente precisa. Se você trabalha demais para uma empresa que não pensa assim, vai murchar e sua motivação pessoal diminui. Eu já vi isso acontecer.

Quando você tiver uma idéia para melhorar seu produto por qualquer motivo, faça a si mesmo as seguintes perguntas: - É isso que acho que o cliente deseja? Posso validar meus pensamentos sobre o desenvolvimento do produto contra a voz do cliente? Minha empresa está em posição de atender às necessidades do cliente? Se sim, como? - Você deve estar em posição de defender com persuasão suas propostas de desenvolvimento de produtos.

A linguagem comum dos negócios em todos os campos e setores é dinheiro. O problema que você está descrevendo não é um problema de programação: é um problema de negócios. Se você deseja obter uma resposta apropriada a uma proposta de negócios, é necessário enquadrá-la no idioma dos negócios. Isso significa que você deve poder apresentar um plano de projeto alternativo, incluindo todos os custos e benefícios.

Você precisa aprender sobre coisas como custos de oportunidade, ROI (retorno do investimento) e NPV (valor presente líquido). Você não precisa de um MBA para fazer isso, mas precisa acessar dados que talvez não estejam disponíveis, como custos de mão de obra, custos indiretos e potencial de receita. Se você puder argumentar claramente que um caminho fornecerá mais valor que outro usando números concretos, receberá toda a atenção do gerenciamento.

Quando eu era um desenvolvedor mais recente de uma equipe muito pequena, fiz muito esse tipo de melhoria no meu tempo livre. Eu gostei; Eu fazia logon e experimentava novas técnicas interessantes enquanto estava sentado na sala com minha esposa à noite. Como me tornei desenvolvedor sênior e gerente de uma equipe maior, meu tempo livre desapareceu. Estávamos trabalhando horas extras apenas para concluir os recursos e as correções críticas. Tornou-se realmente difícil justificar gastar o tempo de alguém nesse trabalho regular de limpeza, mesmo sabendo que todos eram importantes.

Seus chefes não precisam de uma explicação de quão importante é, manter baixos os custos de manutenção, reduzir o custo de crescimento futuro, manter uma equipe de desenvolvimento talentosa engajada etc. Se isso acontecer, você terá grandes problemas. O que eles podem precisar, no entanto, é um plano. Porque, no momento, estou supondo que eles tenham todos os tipos de planos, cronogramas, roteiros, promessas e pressões no lado "adicionar funcionalidade", que estão competindo contra o mero desejo de desejos e solicitações abertas da equipe de desenvolvedores.

Uma coisa que você pode tentar é fazer um plano documentado. Veja se você pode vinculá-lo a liberações ou sair dos critérios para novas funcionalidades. Uma solicitação para "gastar algum tempo refazendo a contagem de referência" pode ser difícil para o seu chefe aprovar, mas agendar um período de cinco dias dentro de quatro semanas daqui a quatro semanas pode ser mais fácil. Basicamente, porém, você vê que novos recursos são planejados e agendados, tente imitar isso ou injetar uma parte "oculta" nele.

Comece pequeno, solicitando 5% de tempo alocado para esse tipo de material e, gradualmente, crie suas próprias prioridades de roteiro de tecnologia e continue justificando o caso de negócios, o ROI, os níveis de risco etc. em cada um deles. Em breve, você terá uma amostra dos desafios de seus chefes, pois encontrará rapidamente muito mais ótimas idéias do que tem tempo para fazer.

Boa sorte!

Eis por que seu pedido de contagem automática de referências está sendo rejeitado:

1. Não é uma melhoria . Uma vez que você tenha algo maior que olá mundo, qualquer mudança estará na direção errada. Nenhuma refatoração mudará o fato de que, se você precisar fazer alterações, sempre estará indo na direção errada. O truque é saber quando suas alterações são significativas o suficiente para que ainda valha o risco de causar novos problemas. Sua gerência disse claramente que, se os usuários finais não podem vê-lo, não vale a pena arriscar.
2. A contagem de referências é um recurso completamente louco. Você viu uma grande empresa famosa implementando algum recurso e imediatamente pensou que precisava do mesmo recurso. Bem, é muito provável que a sua base de código seja completamente diferente da que a apple está usando. Provavelmente, a contagem de referência não vai funcionar, ou é apenas perda de tempo. Você deve encontrar uma maneira diferente que não exija a propagação de primitivas de contagem de referência em todos os lugares do seu código. Provavelmente, seu plano de recontagem requer milhares de modificações na base de código, a maioria dessas alterações não é necessária. Apenas perda de tempo e dinheiro.
3. Você está resolvendo o problema errado. A gerência geralmente sabe que tipo de problemas existem no sistema. Algum problema irrelevante de vazamento de memória que a solução de recontagem está resolvendo não é um deles. Concentre-se em problemas reais e não em alguns problemas imaginários na maneira como os computadores lidam com a memória.
4. Leva muito tempo para implementá-lo. A Apple é uma empresa um pouco maior que a sua equipe insignificante, com poucos programadores e alguns gerentes. Eles podem fazer grandes mudanças apenas pagando o preço. Se são necessários alguns milhões para implementar algo, são amendoins. Se as pequenas empresas tentarem fazer a mesma coisa, ficarão sem dinheiro rapidamente. O desenvolvimento de software já é muito caro; adicionar custos desnecessários não ajudará nem um pouco. Um recurso irrelevante, como o gerenciamento de memória, abrirá as comportas: depois de aprová-lo, metade dos seus programadores deseja que sua própria "melhoria" seja implementada. É uma história sem fim e a empresa poderia estar fazendo algo útil.

Aqui estão algumas etapas que você pode usar para lidar com o problema:

1. Solte o recurso
2. Descubra qual é o verdadeiro problema
3. Comece a fazer algo útil
4. Planeje cuidadosamente como você usa seu tempo
5. Descubra como suas melhorias estão trazendo dinheiro
6. Escolha apenas os recursos que geram mais dinheiro
7. Perceba que o aspecto de programação do desenvolvimento de software é apenas uma pequena parte de todo o sistema - as melhorias nele nunca valerão a pena