Confidencial de Windows: Los motivos son algo altamente sobrevalorado
Si se encuentra con algo confuso en un producto, tome la opción productiva como respuesta.
Raymond Chen
Pregunta sobre el fundamento de cómo algo funciona no resuelve nada. Podría haber acaba de terminar de esa forma. Cualquier pieza de software, desde el simple al complejo, abarca innumerables detalles del desarrollo. A veces esos detalles adoptan la forma de decisiones arbitrarias.
Consideremos, por ejemplo, un comando que acepta dos parámetros como nombre de usuario y nombre de archivo. Si un nombre de usuario no válido y un nombre de archivo no válido, es un complemento en cuanto a que uno se declara como un error. Si el código pasa a comprobar primero el nombre de usuario, entonces probablemente obtendrá un error "nombre de usuario no válido".
¿Cuál es la justificación de la elección comprobar el nombre de usuario delante del nombre de archivo? Probablemente hay uno. Es simplemente cómo sucedieron cosas han sido escritas. Se podría fácilmente haber escrito al revés.
De vez en cuando recibo de una solicitud de un cliente que observa un cierto comportamiento como este. Si les resulta confuso o no deseados, voy a preguntar, "¿Cuál es la razón de este comportamiento?"
Como ingenieros de software, ya que entienden que un comportamiento particular puede existir cualquier número de razones. Podría ser un defecto de código. Podría ser una supervisión de diseño. Podría ser algo que el equipo de ingeniería quería hacer de manera diferente, pero no podía por razones de tiempo, recursos, riesgo o prioridad. También podría ser una decisión intencional. Sólo si el comportamiento cae en esa última categoría habrá una justificación.
Cuando se hace, se hace
Una vez que haya enviado un producto, es en gran medida irrelevante cualquier distinción de razón o justificación. El producto se comporta como lo hace. Puede solicitar cambios en el futuro las versiones, pero la versión actual es un hecho. Una explicación de por qué el producto comporta de la manera que lo hace (si existe tal explicación) no cambia el producto o su comportamiento. Lo único que puede hacer es apaciguar (o incluso enfurecer). Responde a una pregunta, pero no resolver un problema.
En muchos casos, hay más que cuando un cliente hace la pregunta, "¿Cuál es la razón de este comportamiento?" Más frecuente, es realmente justo taquigrafía para, "me encontré con algunos comportamientos que no esperaba y me frustrado".
Indicando que encontrado un comportamiento particular frustrante es mucho más útil que simplemente pidiendo la razón de ese comportamiento. Es más útil si describe la situación que llevó a descubrir el comportamiento confuso o no deseado que le frustró. Esa información podría aclarar una supervisión de diseño o llamar la atención sobre un defecto de código. Incluso podría convencer al equipo de ingeniería para modificar sus prioridades para dedicar recursos adicionales para abordar este problema en particular en el futuro.
Pidiendo la lógica detrás de un problema lleva a la presunción de que cada cuestión debe ser dirigida a menos que haya una razón importante para hacer otra cosa. Es no sólo cómo se toman las decisiones de negocio. Cualquier cambio a un producto existente necesita equilibrar el riesgo, beneficio, costo y prioridad de hacer el cambio.
¿Cuál es la justificación para el origen de la pantalla está en la esquina superior izquierda del monitor? ¿Cuál es la razón de que no pueda escribir \\server\... ¿\otherserver\share? Si la respuesta es una explicación razonada cuidadosamente o algo así, "Porque estaba soñoliento," realmente no importa. Todavía experimenta su problema.
Requerida respuesta
Es barato y fácil de hacer una pregunta, pero pone la carga de respuestas Cortés caras en otras personas. Y esas personas tienen que adivinar si tu pregunta es una solicitud de función pasiva agresiva o simplemente ociosa curiosidad.
En cualquier caso, puede tomar una cantidad enorme de tiempo y esfuerzo a la investigación del problema. Alguien tendrá que cavar en los archivos y encontrar a personas familiarizadas con la intención original de la función que recuerdan los resultados de los estudios de usabilidad o investigaciones de compatibilidad (que pueden ser todo un reto para las funciones que tienen varios años). Esto podría todos resultan para ser esfuerzo inútil porque ninguna de esa información es realmente lo que quería en primer lugar.
Es mucho más clara y útil para explicar el problema encontrado y el escenario que hizo que, por lo que su solicitud para un cambio de comportamiento puede ser mejor entendido. De lo contrario, su solicitud para una explicación del proceso de pensamiento que entró en un comportamiento particular puede venir a través como una cuestión de nitpicky que hará que la gente se preguntan si será incluso vale la pena el esfuerzo de responder.
.jpg)
Raymond Chendel sitio Web, la cosa nueva e idénticamente titulado libro (Addison-Wesley, 2007) historia de Windows, programación de Win32 y análisis de sueño originario de la multitud.