Sistemas engessados
Sistemas engessados são uma das piores pragas de TI. Custam rios de dinheiros para os clientes.
Às vezes construir um sistema engessado (hardcoded) é bem rapidinho e funciona na hora. Mas ai acontece que aquela regrazinha de validação de um campo mudou. Por exemplo agora pode aceitar números e letras e não apenas letras.
Ai você pensa: Beleza, vamos apenas reconfigurar esta regra de validação. Mas é neste ponto que os sistemas engessados cobram seu preço.
Fazer qualquer alteração envolve mexer em código e por isso tem custos mais altos porque tem analise de impacto, desenvolvimento, testes e validações. E tudo isso com os enormes riscos de mexer em código de péssima qualidade (sistemas engessados geralmente têm péssimo código).
Por outro lado querer fazer um sistema super ultra mega flexível custa caro e demora. E nem sempre este custo pode ser justificável. Vi muito disso em arquitetura J2EE de alguns anos atrás que queriam ser super flexíveis, que os tornavam extremamente complexos e em 90% das vezes esta flexibilidade não era necessária.
Então qual o caminho?
O do bem senso. Apenas não tente engessar seu sistema. Se tiver alguma coisa que pode ser configurado em runtime, deixe esta configuração em runtime. Nunca, mas nunca mesmo coloque magic number ou magix strings em código. Nem mesmo com constantes ou #defines.
E o pior é que tem fornecedores, que por pura mesquinharia, engessa o código a fim de manter o cliente em sua mão.
Sinais de mudança
Você sabe que alguma coisa mudou na sua carreira de desenvolvedor quando seu desktop tem 256Mb (e isto não é problema), suas principais ferramentas de trabalho são o Outlook e o Excel e você faz esta compra.