Tentações prejudiciais na programação

Apenas curioso, que tipos de tentações em programação acabaram sendo realmente prejudiciais em seus projetos?

Por exemplo, quando você realmente sente vontade de fazer alguma coisa e acredita que isso beneficiará o projeto, ou então você se engana, acreditando que é, e depois de uma semana percebe que não resolveu nenhum problema real , mas criou novos ou , na melhor das hipóteses, agradou sua fera interior sem impacto visível.

Pessoalmente, acho muito difícil não refatorar códigos incorretos. Eu trabalho com muitos códigos herdados ruins e é preciso respirar fundo para não tocá-lo quando não tenho testes para provar que minha refatoração não quebra nada.

Outro demônio para mim na interface do usuário, eu posso literalmente passar horas mudando o layout da interface do usuário apenas porque gosto de fazê-lo. Às vezes eu digo a mim mesma que estou trabalhando em usabilidade, mas a verdade é que eu amo mover botões.

Quais são seus demônios de programação e como evitá-los?

Generalização prematura é o meu grande bugaboo; em vez de resolver o problema em questão primeiro e esperar até que haja uma necessidade real de resolver o caso geral, eu sempre vou atrás do caso geral e acabo escrevendo uma tonelada de código mais complexo do que precisa ser.

Atualizar:

Veja " Pecado 1 - Generalização prematura " para uma descrição detalhada.

"Voltaremos a isso e corrigiremos mais tarde. Só precisamos trabalhar agora!"

O prazo é muuuuito longe, tenho tempo mais do que suficiente para fazê-lo, então por que não gastar um pouco de tempo navegando na web?

"Este é apenas um código de prova de conceito descartável. Quando eles gostarem, eu realmente o tornarei bom."

1. Refatorando parte do código alguns dias antes do lançamento.
2. Internet: A maior distração de todas.
3. Nova tecnologia : não consigo tirar minhas mãos da nova tecnologia.
4. Otimizar: otimizar, otimizar. .. e mais Otimizar
5. Perfeição : nunca foi satisfeito com o código.
6. TODO: Falta tempo todos, que nunca serão feitos.
7. Estimativa de tempo: muitos PMs não consideram isso como "estimativa". Eles tomam como fato.
8. Promessas: Fazer muitas promessas.

Presa por tentar construir tudo internamente, quando existem estruturas e bibliotecas existentes.

Meus demônios recorrentes: otimização prematura e superengenharia.

E ainda não consigo evitá-los 100% ...

Estimativas excessivamente otimistas

Quando o seu gerente está te encarando, e você sente a sensação de queimar, para dar uma estimativa mais baixa do que seu instinto está lhe dizendo ... não faça isso!

Afinal, seu intestino provavelmente já está muito baixo!

Usar uma tecnologia / ferramenta / linguagem em seu projeto apenas porque você o aprendeu.

Para tentar provar o quão bom você é um desenvolvedor.

Considere o código que você escreveu para ser seu.

Vou apenas fazer uma pausa e olhar para stackoverflow.com;)

A pior tentação:

Bem, acho que um truque / truque / correção sujo não vai doer.

Adivinhe, isso dói. :)

Esquecer que escrever código é o último recurso para resolver um problema .

Característica Creep

Faça um plano, cumpra-o e implante. E depois volte e adicione o que as pessoas estão pedindo.

Eu já vi isso repetidamente. Você se senta, elabora o design e começa a codificar. Os usuários ouvem algumas bobagens confusas sobre a falta de seu recurso favorito e começam a fazer lobby por isso. Seu chefe exige que você o adicione na 11ª hora, comete uma falha na implantação, introduz bugs em todos os lugares e, 3 meses depois, quando todos se acalmarem, você será solicitado a removê-lo, porque ninguém pode descobrir por que você colocou esse recurso retro porcaria em primeiro lugar! Você não poderia dizer que o resto do design tornou inútil?

1. Adicione mais recursos

2. A competição tem esse recurso. Portanto, este é um recurso obrigatório, portanto, mais programação do que analisar estratégia, posicionamento etc.

3. A competição NÃO possui esse recurso. Portanto, esse é um recurso diferenciador, portanto, mais programação do que análise de estratégia, posicionamento etc.

4. Resolvendo um problema de negócios com mais programação. por exemplo, não é possível obter melhores conhecimentos na administração do servidor linux no qual seu site está hospedado, através da programação de mais recursos. Às vezes, você apenas precisa aprender a corrigir o problema, em vez de recodificar tudo em C # .Net

5. Resolvendo um problema de marketing com mais programação. por exemplo, abusando do conceito de vaca roxa de Seth Godin, de que você está indiretamente resolvendo um problema de marketing, programando mais recursos em seu produto para torná-lo uma "vaca roxa". Às vezes, é apenas um monstro mutante.

6. Resolvendo um problema de produtividade com mais programação argumentando consigo mesmo que o tempo gasto escrevendo esse script será economizado em horas no futuro, em vez de realmente programar coisas realmente importantes

7. Planejando codificar, mas ainda não codificando, porque você deseja "acertar"

8. Codificando uma versão suja e prometendo que você "melhorará mais tarde", mas nunca voltou a "melhorar"

9. Não fazendo uma maquete ou um mapa do site porque é "muito problemático". Posso apenas capturar as páginas dos concorrentes para maquetes e desenhar o mapa do site à mão livre "mais tarde", o que nunca é. E então vá direto para a programação da primeira página que visualizo em minha mente.

Confissão: Eu cometi pessoalmente os erros 1, 3, 7, 8. Eu também cometi 2, 4, 5, 6, mas muitas vezes me iludei de mim mesma.

Atualmente, estou corrigindo 9.

EDIT Não percebeu que a pergunta requer que colocássemos soluções.

1) Adicione mais recursos Apenas não faça isso. Trabalhe com seus negócios, marketing, fundadores, consultores etc. e reduza seu aplicativo a apenas uma coisa.

Leia sobre o twitter, o Groupon , etc. sobre como eles simplificam as coisas para apenas uma coisa que levou ao seu sucesso.

Se você acha que só funciona se você deseja criar grandes empresas, pense novamente. Ctrl + F para esta linha "Quanto mais recursos eu adicionar ao software, pior ele vende. (É desnecessário dizer que isso é altamente intuitivo para a maioria dos desenvolvedores de software.)" Neste link

2) A competição tem esse recurso. Portanto, este é um recurso obrigatório

Veja a solução 1

3) A competição NÃO possui esse recurso. Portanto, este é um recurso diferenciador

Veja a solução 1

4) Resolvendo um problema comercial com mais programação.

Se precisar contratar alguém para ensiná-lo, faça uma consulta ou faça isso por você e depois documente como ele o fez, para que você possa fazê-lo da próxima vez. APENAS FAÇA!! Não reescreva o código, não passe no GO, não colete US $ 200.

5) Resolvendo um problema de marketing com mais programação.

Se as pessoas não entendem o que você está vendendo, é um problema de marketing. Volte para a solução 1 e gire.

6) Resolvendo um problema de produtividade com mais programação

Esperar.

Aguarde até sentir que sua produtividade sofreu com um problema específico de produtividade por um período superior a 2 semanas e isso acontecerá razoavelmente por mais 2 semanas.

Agora, avalie a quantidade de tempo gasto para programar um script para resolver esse problema. Lembre-se de fazer sua pior estimativa e multiplicar por 2.

Multiplique sua estimativa pela sua taxa horária.

Agora revise soluções alternativas: terceirize, compre uma solução pronta para uso, não faça nada a respeito, etc.

Escolha a solução mais econômica.

Cumpri-lo.

7) Planejando codificar, mas ainda não codificando, porque você deseja "acertar"

Faça exercício. Você sentirá uma onda de endorfinas que motivarão sua bunda e farão você planejar agir. Eu sei disso porque acabei de fazer supino 5x5 e agachamento 5x5.

8) Codificando uma versão suja e prometendo que você "melhorará mais tarde", mas nunca voltou a "melhorar"

Configure um sistema de arquivos do tickler no GTD. e acompanhar agressivamente. Acompanhe todas as promessas para si e para os outros.

9) Não está fazendo uma maquete ou um mapa do site porque é "muito problemático".

Vá gastar US $ 75 em uma edição para desktop de maquetes balsamiq. Eu sei disso porque eu comprei há 3 semanas. Isso me fez refazer minhas maquetes, porque me sinto como um artista, arquiteto e visionário, tudo em um, mesmo que meu desenho no mundo real seja péssimo. A fonte usada no balsamiq, inconscientemente, lembra que isso é apenas uma maquete, não gravada em pedra que ajuda na RAD.

Fim da edição

Um par de cervejas vai me ajudar a trabalhar melhor e por mais tempo.

"Sim, eu posso refatorar essa bagunça gigantesca de espaguete com 2000 linhas em um dia ..."

"Eu posso passar sem um teste para isso. É muito difícil de testar."

e é irmão do mal,

"Eu preciso fazer um teste para isso, não importa o quão difícil seja escrever ou entender."

Procrastinação e estimativa otimista de tarefas são meus maiores pecados.

Alongamentos, flexões ou flexões (ou qualquer outro exercício físico) para o primeiro e humor pessimista antes de fazer estimativas para o segundo.

"É muito mais ' fácil ' para reimplementar a funcionalidade a partir do zero do que para entender o código existente."

Uma tentação massivamente prejudicial que o projeto em que eu sofri é o 'Efeito da Plataforma Interna'. Essa é uma abordagem que os arquitetos, que há muito se dedicam, estabeleceu em sua infinita sabedoria, que criou um projeto que gera cerca de 20 milhões de dólares por ano, mas custa 60 milhões para atualizar e manter (números aproximados, obviamente, mas essa é a magnitude do problema).

NIH - Não Inventado Aqui

Tenho muita dificuldade em dar uma chance justa às soluções de terceiros. Todos devem ser naturalmente céticos em relação a soluções de terceiros que não foram feitas sob medida para eles, mas eu tenho dificuldade em ser 100% objetivo sobre isso.

A economia de tempo pode ser tão grande que mesmo que 9 em cada 10 vezes a solução de terceiros deve ser evitada, eu preciso ser objetivo o suficiente para perceber o um que irá trabalhar.

Projetar, codificar e / ou testar a unidade com base nos "dados de amostra" fornecidos em vez de analisar uma cópia do banco de dados real do cliente. O prazo era curto e eles continuavam dizendo que chegaria, mas nunca chegou. Quando foi implantada, a explosão foi espetacular. Realmente, quem esperaria que um cliente tivesse três clientes principais.

Nunca mais vou iniciar um projeto até ter uma cópia dos dados reais .

O Não tem que ser uma biblioteca que faz isso em algum lugar síndrome.

intimamente relacionado com

O Plugin Fetish

O perfeccionismo mata; provavelmente a maior razão pela qual os projetos não são bem-sucedidos.

Bem, às vezes a programação me leva à garrafa.

Reescrevendo em vez de refatorar.

Pensando que tem que haver uma maneira melhor de fazer isso. Não vou me contentar com algo que pode ser "bom o suficiente". Estou levando nada menos que perfeição! Geralmente, isso é evitado conversando com outras pessoas que podem ter uma perspectiva diferente sobre um problema ou vendo uma solução de um ângulo diferente.

Automatizando tudo ao ponto, mais tempo é gasto na manutenção das ferramentas do que no trabalho real.

Solução: assim como na otimização de código, primeiro encontre gargalos de produtividade e somente depois que eles forem descobertos, cure-os com uma boa automação .

Quais são seus demônios de programação?

Além do que alguns outros mencionaram.

Priorização : Ignorando o trabalho de alta prioridade em relação ao projeto e trabalhando em outras coisas no projeto primeiro, porque são mais interessantes!

Como você os evita?

Com um pouco mais de autodisciplina. Sério, a auto-disciplina e a auto-motivação para fazer a coisa certa ajudam a evitar a maioria desses "demônios".

Ainda não obtivemos a aprovação do cliente, mas o prazo está próximo. Aqui estão algumas composições preliminares para que você possa começar ...

Mais tarde, depois de concluir a construção do projeto para corresponder às composições ...

Ah, aqui estão as revisões do cliente, eles só querem mudar algumas coisas menores *

(* as principais funcionalidades são totalmente diferentes)

Então você continua refatorando seu código original, com base no modelo defeituoso original, em vez de apenas começar do zero, porque você está sob pressão de um prazo curto e assume que essas foram as últimas revisões.

Eu fico com esse cara o tempo todo. É difícil evitar como desenvolvedor web. Meu melhor conselho é pressionar por mais tempo para que você possa fazer as alterações da maneira correta.