Hace unos años, trabajé para una pequeña empresa que llegó tan lejos al desarrollo de marcos internos que dedicaron a su desarrollador más experimentado y a su arquitecto a desarrollar un marco MVC personalizado y ORM desde cero. Estas dos cosas eran ortogonales a su producto principal. Desafortunadamente, el soporte para este enfoque basado en el marco provino de la parte superior y retrasó la entrega del software generador de ingresos, y los marcos producidos fueron notablemente inferiores a las alternativas estándar, lo que agravó los retrasos. La compañía se quemó rápidamente en efectivo y, finalmente, todos fueron despedidos.
Un empleador posterior cometió un error similar: obtuvieron un desarrollador altamente calificado técnicamente, un perfeccionista, con una sólida base en los patrones de diseño de la empresa para diseñar excesivamente una solución de consultoría para uno de sus clientes, a sabiendas tomando una pérdida, con la esperanza de que La solución podría adaptarse y extenderse a otros clientes. El proyecto se excedió significativamente. Pero ningún otro cliente potencial mordió. Un error estratégico chapado en oro que cuesta una pequeña fortuna.
En ambos casos hubo un grado significativo de ingeniería excesiva. En ambos casos, la empresa y la dirección del proyecto eran personas con antecedentes de dominio o análisis, en lugar de tener experiencia en programación. En ambos casos, los arquitectos de software crearon soluciones demasiado complejas para rascarse la picazón y mejorar sus currículums, con cierta complicidad de la gestión no técnica. En ambos casos, los arquitectos no tenían interés en mantener bajos los costos (aparte del riesgo de perder sus trabajos si las empresas se declaraban en quiebra, lo cual no era un gran riesgo, considerando su alta empleabilidad).
Mi experiencia sugiere que no es una trampa poco común para que caigan las tiendas de desarrollo.
¿Hay lugar en los proyectos de software para un rol técnico interno o externo formal de confrontación (un "Surveyor de cantidad") para usar una analogía de construcción que puede llamar o evitar el exceso de ingeniería innecesaria? ¿Quién es el más adecuado para desempeñar este papel?