Segredos do Windows: A Lógica está completamente superestimada
Se encontrar algo confuso com um produto, escolha a opção produtiva sobre como responder.
Raymond Chen
Perguntando sobre a lógica por trás de como algo funciona não resolve nada. Ele pode ter só acabou dessa forma. Qualquer peça de software, do simples ao complexo, engloba inúmeros detalhes de desenvolvimento. Às vezes os detalhes assumem a forma de escolhas arbitrárias.
Considere, por exemplo, um comando que aceita dois parâmetros como nome de usuário e nome de arquivo. Se tiver que passar um nome de usuário inválido e um nome de arquivo inválido, é uma incerteza quanto ao que um será relatado como um erro. Caso o código verificar o nome do usuário em primeiro lugar, então você provavelmente vai ter um erro de "nome de usuário inválido".
Qual é a justificativa para a escolha para verificar o nome de usuário antes do nome do arquivo? Provavelmente há um. É apenas como as coisas aconteceram para ter sido escrito. Ele poderia facilmente ter sido escrito o contrário.
Nós ocasionalmente receberá um pedido de um cliente que observa um determinado comportamento como este. Se eles acham que é confuso ou indesejados, vou perguntar, "Qual é a justificativa para este comportamento?"
Como engenheiros de software, você já compreendem que um determinado comportamento poderia existir para qualquer número de razões. Poderia ser um defeito do código. Poderia ser um descuido de projeto. Poderia ser algo da equipe de engenharia queria fazer diferente, mas não conseguia por razões de tempo, de recursos, de risco ou de prioridade. Também poderia ser uma decisão intencional. Apenas se o comportamento se encaixa nessa última categoria nunca haverá uma razão de ser.
Quando é feito, é feito
Uma vez que um produto tem enviado, qualquer distinção de razão ou lógica é muito irrelevante. O produto se comporta como faz. Você pode pedir alterações no futuro versões, mas a versão atual é um negócio feito. Uma explicação de por que o produto se comporta da maneira que ele faz (se tal explicação ainda existe) não altera o produto ou o seu comportamento. Tudo o que ele pode fazer é acalmar (ou mesmo enfurecer) você. Ele responde a uma pergunta, mas não resolve um problema.
Em muitos casos, há mais do que isso quando um cliente faz a pergunta, "Qual é a justificativa para este comportamento?" Mais frequentemente do que não, ele é realmente apenas abreviação, "corri para algum comportamento que não esperava e isso me frustrou.
Informar que você encontrou um determinado comportamento frustrante é muito mais útil do que simplesmente pedindo a lógica por trás desse comportamento. É ainda mais útil se você descrever a situação que levou a descobrir o comportamento confuso ou indesejado que você frustrado. Esse feedback pode esclarecer uma supervisão de projeto ou chamar a atenção para um defeito de código. Ele mesmo poderia convencer a equipe de engenharia para alterar as suas prioridades para dedicar recursos adicionais para abordar esse problema específico no futuro.
Pedindo a lógica por trás de um problema leva a presunção de que todas as questões devem ser abordadas a menos que haja uma razão importante para fazer o contrário. Que é não apenas como são tomadas as decisões de negócios. Qualquer alteração em um produto já existente precisa equilibrar o risco, benefício, custo e prioridade de fazer a mudança.
Qual é a justificativa para a origem da tela sendo no canto superior esquerdo do monitor? Qual é a justificativa para que não lhe permite escrever \\server\... \otherserver\share? Se a resposta é uma explicação cuidadosamente fundamentada ou algo como: "Porque eu estava sonolento," realmente não importa. Você ainda está enfrentando o problema.
Resposta necessária
É barato e fácil de fazer uma pergunta, mas coloca o fardo da caras educados respostas sobre outras pessoas. E as pessoas tem que adivinhar se a sua pergunta é um pedido de recurso passivo-agressivo ou curiosidade meramente ociosa.
Em ambos os casos, pode levar uma quantidade enorme de tempo e esforço para o problema de pesquisa. Alguém vai ter ao escavar os arquivos e encontrar pessoas familiar com a intenção original do recurso que Lembre-se os resultados dos estudos de usabilidade ou investigações de compatibilidade (que podem ser um grande desafio para os recursos que são vários anos de idade). Isso tudo poderia vir a ser esforço desperdiçado, porque nenhuma informação que é realmente o que você queria em primeiro lugar.
É muito mais clara e útil para explicar o problema que você encontrou e o cenário que levou a ele para que seu pedido para uma mudança de comportamento pode ser melhor compreendido. Caso contrário, seu pedido para uma explicação sobre o processo de pensamento que entrou em um determinado comportamento pode vir transversalmente como uma questão de nitpicky que vai fazer as pessoas saber se vai ser mesmo vale a pena o esforço de responder.
.jpg)
Raymond Chendo Web site, The Old New Thing e identicamente intitulado livro (Addison-Wesley, 2007) tratam Windows histórico, programação Win32 e análise colaborativa de sonho.