PM optando por una configuración demasiado compleja con la que nadie tiene experiencia [cerrado]

Recientemente comencé un proyecto que no parecía demasiado difícil de hacer, el concepto era una aplicación bastante simple que tenía que aceptar información de vez en cuando (tal vez 10 veces al día), e intentar realizar algunas operaciones en ellos y recopilar todos los resultados al final. Esta aplicación obtendría un portal web front-end que los clientes podrían usar para ver los resultados, no exactamente ciencia espacial.

Para esto, inicialmente hice un uso inteligente de las bibliotecas de concurrencia integradas de Python ( ThreadPoolExecutor) y utilicé una biblioteca fácil de usar para el front-end (elegí Flask porque es fácil para principiantes y es relativamente fácil de mantener y probar).

Una vez que estábamos a la mitad del proyecto, el Primer Ministro declaró que teníamos que usar capacidades de cola de mensajes de terceros en lugar de hilos y tuvimos que implementar el equilibrio de carga, lo que finalmente terminó sucediendo fue que finalmente comenzamos a trabajar con Celery, Redis, RabbitMQ, Nginx, uWSGI y un montón de otros grandes servicios de terceros con los que nadie tenía ninguna experiencia real.

Al final, esto condujo a un montón de código de spaghetti, tareas no comprobables (debido a la complejidad de las bibliotecas de terceros, parchear el código ni siquiera funcionó) y un montón de dolores de cabeza porque nadie sabía cuál era el valor agregado de estos servicios .

Antes de decir "Sí, debe usar esos servicios", tenga en cuenta que nadie sabe cómo usarlos ni siquiera sabe lo que hacen además de introducir un código plagado de condiciones de carrera.

¿Qué debo hacer al respecto? En este punto, simplemente sería demasiado costoso volver a lo que teníamos y el PM está decidido a usar estos servicios, a pesar de que el producto final ahora está peor de lo que estaba al principio. ¿Hay algún uso en discutir esto con él? ¿Pido más tiempo? O la dura respuesta, ¿soy demasiado estúpido para mi trabajo?

Una vez que estábamos a la mitad del proyecto, el primer ministro declaró que teníamos que usar capacidades de cola de mensajes de terceros en lugar de hilos y teníamos que implementar el equilibrio de carga

Esto no es lo apropiado para que un primer ministro "declare" unilateralmente. Dos razones:

1. Las decisiones de diseño deben ser tomadas por un recurso técnico y solo en respuesta a los NFR . Por lo tanto, pregúntele amablemente a su PM si hay un nuevo NFR y si podría tener más detalles.

2. Si se introduce un NFR a la mitad del proyecto, probablemente debería hacerse a través de un control de cambios . El control de cambios es muy importante desde una perspectiva de gobernanza; no solo sería un aporte a sus requisitos, sino que también es un aporte importante para los casos de prueba de QA, el manual de implementación y soporte de operaciones, y (aquí está la parte realmente importante) el cronograma del PM . Si el nuevo requisito introduce más trabajo, el equipo de desarrollo debería tener la oportunidad de comunicar nuevas estimaciones de desarrollo, y el primer ministro tendrá que decidir si pueden vivir con la nueva fecha, agregar más recursos o rechazar a la parte interesada que presentó el NFR

Ahora, si realmente hay un NFR de buena fe, y no hay forma de evitarlo, también puede ser apropiado solicitar recursos nuevos o diferentes que estén familiarizados con las tecnologías que se están introduciendo, o solicitar un presupuesto de capacitación para algunos de sus recursos existentes. recursos Entonces también hay un aspecto de costo .

Si habla el idioma del primer ministro (horario y costo), creo que obtendrá más tracción que hablar sobre cómo se sienten los desarrolladores sobre el diseño resultante. Esas cosas tienen un impacto real.

Un primer ministro debería saber mejor que introducir cosas como esta sobre la marcha sin gobernanza, sin controles y sin consenso. Si simplemente no lo entienden, es posible que deba escalar a la gestión de productos o gestión de programas, ya que está poniendo en riesgo la calidad y la programación innecesariamente.

Lo que sería estúpido es dejarse llevar a la muerte .

Lo que estás describiendo es que has perdido la sensación crítica. No hay sentido de control y no hay un camino claro para volver a él.

Lo último que debe hacer es trabajar duro, mantener la cabeza baja y sufrir en silencio hasta que finalmente admitan que el proyecto está condenado.

Lo que debe hacer es pensar mucho sobre lo que tiene todo el derecho de esperar.

Si quieren que uses tecnologías que no entiendes, debes esperar tiempo para aprenderlas. No te avergüences de lo que no sabes. Usa tu ignorancia como un garrote. Cuando exijan que uses algo, pregunta por qué. No aceptes 'porque'. No acepte las "mejores prácticas modernas". No acepte la 'capacidad de escala' sin obtener expectativas reales y comprobables.

Por comprobable quiero decir que TIENEN que decirle cuántas solicitudes por día / hora / minuto quieren que pueda hacer. Deje en claro que tiene la intención de construir algo para ejercer este sistema de acuerdo con esas especificaciones.

De esta manera, puede usar una prueba gratuita de 30 días para demostrar que lo último que quieren es valioso o si es mejor seguir con lo que ya sabe.

Ahora ten en cuenta. No son las herramientas las que introdujeron el código plagado de condiciones de carrera. Ustedes hicieron eso. Debe aprender CÓMO lo hizo para poder deshacer eso.

Y no. No es demasiado costoso volver a lo que tenía. El primer ministro no puede tener lo que quiere simplemente exigiéndolo. Tiene que retroceder hasta que pueda usar efectivamente lo que quiere el PM o demostrar que no es lo que necesita el proyecto.

En serio, simplemente ceder a esto no es profesional y es mortal para el proyecto.

He estado aquí hombre. Más de una vez. Te hace sentir estúpido. Eso no es realmente así. Estás perdido

Habla con el primer ministro. Honestamente. Extiéndelo todo. Demuestra que estás dispuesto a aprender pero no quieres que te lleven a dar un paseo. Nunca jamás diseñe o codifique basado en la fe. Haz que el primer ministro te muestre cómo hacer lo que quieren. No finjas que entiendes cuando no lo haces. No digas que se hará cuando no sea así. Si vas a creer en algo, cree en ti mismo. Tienes que estar dispuesto a decir NO.

Si eso no funciona, pule el currículum porque lo necesitará pronto. De una manera u otra.

Esto realmente debería estar en work.stackexchange.com, porque el problema no es realmente una cuestión de desarrollo de software, sino sobre las relaciones laborales.

Si está seguro de que su enfoque simple habría funcionado y producido un resultado funcional con bastante rapidez, entonces su PM es una fuerza destructiva en su empresa que debería eliminarse. Descubre cómo llevar las noticias al nivel superior a él: que tu equipo tenía una solución simple y funcional que había hecho un buen progreso, y por razones que nadie puede explicar tu PM, te obligó a intentar una solución mucho más compleja, utilizando una multitud de herramientas que nadie conoce, nadie comprende, nadie sabe si son útiles en absoluto, y esa decisión insondable de su PM le causó todos los problemas y hace que el proyecto llegue tarde y no funcione.

Sin conocer el contexto y la estrategia de producto que persigue su gerencia, es difícil responder objetivamente su pregunta.

Aquí algunos argumentos objetivos. Sin embargo, es posible que no sea lo que esperaba:

• " Tenga en cuenta que nadie sabe cómo usar estos productos todavía ".
• El uso exclusivo de herramientas y técnicas perfectamente conocidas garantizará una alta productividad. Pero limitará considerablemente la capacidad de innovar. En algunos mercados, puede ser fatal para su producto. Por ejemplo, hace casi 30 años, propuse usar Windows 3.0 para desarrollar una nueva versión de un producto CAD que tuvo éxito bajo MS-DOS. El gerente de producto objetó que este no era un entorno probado, que sería demasiado complejo y difícil de aprender para el equipo, y de todos modos, que " Windows nunca será un entorno convencional " ... Dejo que adivine el éxito de Su producto 2 años después.
• Todo es cuestión de costos y beneficios. El costo de experimentar versus el beneficio de una escalabilidad y capacidad de implementación asegurada por un tercero que tiene experiencia con grandes instalaciones y gran carga de trabajo.
• Los inconvenientes de agregar una nueva tecnología se pueden suavizar, con la capacitación adecuada o el apoyo / entrenamiento inicial de un consultor experimentado.

En última instancia, la elección económica es responsabilidad de su gerente de producto. Discuta con él los pros y los contras, para asegurarse de que tome una decisión bien informada y no subestime la complejidad añadida. Y si se mantiene en su camino, trate de lograr lo mejor: no tiene nada que perder y, en el peor de los casos, tendrá una nueva tecnología en su CV.

Hay dos enfoques para las bibliotecas de terceros (y otros componentes):

1. Use tantos como sea posible
2. Use la menor cantidad posible

Mi enfoque es (2). Parece que su enfoque también es (2), pero al gerente del proyecto le gusta el enfoque (1).

Hay tres formas de manejar esta situación. O deja que el primer ministro haga lo que quiera, intenta convencerlo de que cambie el enfoque de las bibliotecas de terceros, o vota con los pies y selecciona otro trabajo.

Si desea convencer al primer ministro para que cambie el enfoque, considere estos argumentos:

• Tiempo de aprender. Cada biblioteca externa requiere tiempo para aprender, en cuyo momento un programador competente puede escribir la funcionalidad deseada, especialmente si se eligió una gran biblioteca solo para hacer algo muy simple que podría hacerse en unos pocos cientos de líneas de código.
• Reemplazabilidad.Si tiene una biblioteca externa, ¿cómo se asegura de que si se detiene su desarrollo, puede reemplazarla por otra biblioteca similar? Mi solución es evitar las bibliotecas externas siempre que pueda, y cuando no sea factible, escribo un contenedor simple para abstraer la parte de la interfaz de programación que quiero. Por lo general, la interfaz que quiero es mucho más simple que la interfaz que ofrece la biblioteca. Luego, mi código accede a la biblioteca externa solo a través de este contenedor, lo que facilita los reemplazos. Construir toda su aplicación en algún marco es un gran no-no. Servlets? Sí, han estado aquí durante mucho tiempo y continúan estando aquí en el futuro previsible. Motores de plantilla? Sí, aunque no son exactamente reemplazables (generalmente eliges uno y te quedas con eso), el valor que aportan es enorme, así que seleccione cuidadosamente y tenga en cuenta que al cambiar los motores de plantilla, puede tener dos motores de plantilla en la misma aplicación, pero no puede tener dos marcos en la misma aplicación por lo general. Apache Struts? No, los frameworks se ponen de moda y pasan de moda de manera rápida, y generalmente no puede tener dos frameworks en la misma aplicación.
• Versión infierno. Al seleccionar una biblioteca externa, debe actualizarla para evitar vulnerabilidades de seguridad, y actualizarla puede romper las cosas. Los componentes bien diseñados (como Java JRE) son compatibles con diferentes versiones, pero mi experiencia es que la mayoría de las bibliotecas son basura debido a la imposición de una versión enorme. Además, el componente X puede requerir Z versión 1 y el componente Y puede requerir Z versión 2, y es posible que no pueda vincular Z versión 1 y Z versión 2 en la misma aplicación.
• Vulnerabilidades de seguridad. Al seleccionar una biblioteca externa, aumenta el número de vulnerabilidades de seguridad fácilmente explotables contra su aplicación. Algunos podrían afirmar que el código desarrollado internamente se asemeja a la seguridad a través de la oscuridad, pero nuevamente diría que todavía es una forma de seguridad.
• Problemas de licencia. Cada biblioteca externa impone su propia licencia en partes de su programa. Por ejemplo, las bibliotecas GPL no se pueden usar en programas que no sean GPL, y las bibliotecas LGPL también requieren la distribución del código fuente junto con los archivos binarios, lo que puede requerir cantidades considerables de ancho de banda.
• Hora de inicio de la aplicación. Cada gran biblioteca externa ralentiza el tiempo de inicio de su aplicación. Al escribir una biblioteca simple y sencilla internamente, puede hacer que el tiempo de inicio de su aplicación sea mucho más rápido.
• Huella de memoria. Al tener X que requiere Y que requiere Z que requiere A que requiere B, necesita X + Y + Z + A + B en la memoria al mismo tiempo. Al implementar solo el equivalente de X, llamémoslo X ', internamente, solo necesita X' en la memoria. Y generalmente la huella de memoria de X 'es menor que la huella de memoria de X.
• Riesgo de error. Cuantas más líneas haya en el componente externo, mayor es el riesgo de que se encuentre con un error que será difícil de solucionar debido a la gran cantidad de código que necesita comprender. Si hace la tarea internamente, generalmente lo hace con menos líneas de código (para hacer justo lo que necesita, nada más) y, por lo tanto, un menor riesgo de errores.
• Personalización Si escribo consultas SQL yo mismo, sé cómo se ve la consulta y qué tan bien funciona en un motor de base de datos y un conjunto de índices dados. Si, por otro lado, la consulta SQL está escrita por un componente externo, no sé nada sobre su rendimiento. Solía ​​trabajar en una empresa donde cada página web tardaba varios segundos en llegar. Sospeché que la causa era que la biblioteca de Hibernate que usaban extraía demasiados datos automáticamente de la base de datos cuando todo lo que necesitabas era un elemento y no todos los elementos relacionados con este elemento en particular. Dejé la empresa antes de descubrir la verdadera causa de la lentitud, porque no me gustó el enfoque de utilizar un gran número de bibliotecas existentes.

Tenga cuidado especialmente si una biblioteca se llama a sí misma un marco . Esto significa que la biblioteca requiere que construyas toda tu aplicación sobre sí misma. Generalmente no puede tener dos marcos en la misma aplicación; lucharán entre sí sin coexistir pacíficamente. Biblioteca de utilidad de desarrollo web? Sí, por favor, hay muy pocos de estos. Si alguna vez encuentro una biblioteca mejor que la que uso ahora, puedo usar la biblioteca recién encontrada en un código nuevo mientras continúo usando la biblioteca antigua en el código antiguo. Marco de desarrollo web? Un gran bocinazo NO!

Creo que su PM está apuntando a un sistema difícil de administrar que producirá mucho trabajo de mantenimiento mientras está en funcionamiento, por lo que garantizará sus ingresos.

Personalmente, parece estar atascado con Python, solo olvide Python por un tiempo, no codifique en Python por un año, aprenda cosas nuevas, verá que hay otros lenguajes que pueden hacer lo mismo, y probablemente mejor.

Como han dicho otros, aprenda las herramientas antes de comenzar a codificar con ellas. Quizás sugiera que sería bueno evaluar juntos la pila necesaria, basándose en la investigación de diferentes herramientas que parecen adecuadas para la tarea. O tal vez preguntar cómo se le ocurrió esa lista, podría haber recibido ayuda de alguien que esté actualizado.

Los desarrolladores no deben tener miedo de aprender a usar nuevas bibliotecas, marcos, tecnologías, etc. Esa es una parte central de la descripción del trabajo de un desarrollador, y es perfectamente razonable que alguien sugiera que el equipo trabaje con cosas de terceros que nadie tiene. experiencia o incluso exigir que el equipo lo haga si están en condiciones de tomar decisiones técnicas autorizadas para el equipo.

Sin embargo, no es razonable esperar que pueda utilizar una nueva tecnología (y mucho menos varias tecnologías nuevas a la vez) en tu pila y sigue progresando. Debería haberse programado un tiempo considerable para conocer los entresijos del nuevo enfoque y descubrir un buen diseño para incorporar las nuevas piezas, durante el cual no se esperaría un progreso real en el producto real (de las personas que realizan este trabajo de aprendizaje / diseño , que puede o no ser todo el equipo, aunque si no es así, probablemente deba haber más tiempo programado en el futuro para las personas que aprendieron a transferir conocimientos al resto del equipo). Ese es el costo de hacer este tipo de cambio importante. Aprender nuevas tecnologías es parte del trabajo del desarrollador, pero no es algo que simplemente sucede con un costo de tiempo cero.

Parece que eso no sucedió a partir de la pregunta. Las personas se lanzaron bien al tratar de construir de alguna manera buenas implementaciones sobre tecnologías que ellos mismos no entendían. Por supuesto, el código resultante es terrible.

Tratar de convencer a su PM que la empresa va a necesitar pasar más tiempo en esto. O vendrá en la forma de detenerse ahora, aprender y evaluar las nuevas tecnologías, descubrir un buen diseño y limpiar el desorden de implementación actual. O vendrá en la forma de más tiempo perdido en errores, mantenimiento, desarrollo más costoso, etc.

Es imposible decir si las opciones técnicas descritas en la pregunta (equilibrio de carga, colas de mensajes, etc.) son realmente apropiadas. No creo que "nadie en el equipo tenga experiencia trabajando con esto antes" es una buena razón para descartar absolutamente una decisión, pero sí aumenta el costo a corto plazo de tomar esa decisión (lo que puede alterar el " mejor "decisión para el contexto), y si su PM no está considerando eso y espera que el equipo se vuelva tan productivo de inmediato como lo sería la gente experimentada, entonces debe rechazar esos argumentos; establecerán cronogramas de proyectos poco realistas, lo que no beneficia a nadie.