La longevidad de las soluciones provisionales

La longevidad de las soluciones provisionales
Autor: Klaus Marquardt

¿Por qué creamos soluciones provisionales?

Típicamente hay algún problema inmediato que resolver. Puede ser provisional para el equipo de desarrollo, algunas herramientas que llenan un vacío en la cadena de herramientas. Puede ser externo, visible al usuario final, como un solución que aborda la funcionalidad faltante.

En muchos sistemas y equipos encontrarás algún software que está algo desintegrado del sistema, que es considerado un borrador para ser cambiado en algún momento, que no sigue el estándar y las guías que dan forma al resto del código. Inevitablemente oirás a desarrolladores quejándose sobre esto. Las razones para su creación son muchas y variadas, pero la clave para el éxito de una solución provisional es simple: es útil.

Las soluciones interinas, sin embargo, adquieren inercia (o momentum, dependiendo de tu punto de vista) debido a que están ahí, útiles y ampliamente aceptadas, no hay necesidad inmediata para hacer algo más. Sin embargo, cuando la parte interesada tiene que decidir qué acción agrega más valor, habrá muchos cosas que ranqueen más algo que la instalación apropiada de una solución provisional. ¿Por qué? Porque está ahí, funciona y es aceptada. El único lado malo perceptible es que no sigue los estándares seleccionados y directrices elegidas, excepto en un pequeño nicho del mercado, esto no es considerado como una fuerza significativa.

Así que la solución provisional se mantiene en su lugar. Por siempre.

Y si un problema surge con esa solución provisional, es poco probable que se provea una actualización que esté en línea con la calidad de producción aceptable. ¿Qué hacer? Una rápida actualización en esa solución provisional a menudo hace el trabajo. Y será más común que sea bien recibida. Exhibe las mismas fortalezas que la solución provisional inicial… Sólo está más actualizada.

¿Es esto un problema?

La respuesta depende de tu proyecto, y de su interés personal en las normas del código de producción. Cuando los sistemas contienen muchas soluciones provisionales, su entropía o complejidad interna crece y su mantenibilidad disminuye. Sin embargo, quizás de inicio nuestra pregunta sea la equivocada. Recuerda que estamos hablando sobre una solución. Podría no ser tu solución preferida –es poco probable que sea la solución preferida de alguien–, pero es débil la motivación para rehacer esta solución.

¿Qué podríamos hacer si vemos un problema??

  1. Evitar crear una solución provisional en primer lugar.
  2. Cambiar las fuerzas que influencian la decisión del Administrador de Proyecto.
  3. Dejarlo como está.

Vamos a examinar estas opciones más de cerca.

  1. Eludir no funciona en la mayoría de los casos. Hay un problema a resolver y los estándares pasan a ser muy restrictivos. Puedes gastar energía para cambiar los estándares. Una honorable aunque tediosa tarea… y ese cambio no será efectivo a tiempo para el problema actual.
  2. Las fuerzas están arraigadas en la cultura del proyecto, la cuál se resiste a cambios voluntarios. Podría tener éxito en proyectos pequeños –especialmente si sólo eres tú– y acabas de limpiar el desorden sin preguntar antes. También podría tener éxito si el proyecto es tan confuso que se ha estancado visiblemente y tomarse algún tiempo para la limpieza suele ser aceptado.
  3. El estatus quo automáticamente aplica si la opción no lo hace.

Crearás muchas soluciones, algunas serán provisionales, muchas serán útiles. La mejor manera de superar las soluciones provisionales es hacerlas superfluas, proveer una más elegante y útil solución. Podrías recibir la serenidad de aceptar las cosas que no puedes cambiar, coraje para cambiar las cosas que puedes y sabiduría para saber la diferencia.

Leer contribución original

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *