¿Cómo puedo convencer a un miembro del equipo para que use un marco web? [cerrado]

La pregunta es esta y el detalle sigue: ¿hay algo que pueda decir / mencionar, como programador, para llevarlo a mi lado?

Me encantaría escuchar argumentos válidos para ambas partes en este caso, pero sobre todo sugerencias sobre cómo hablar con él.

Mi situación es esta: estoy trabajando en un proyecto de equipo en mi carrera, construyendo un sitio web de tamaño medio como prototipo para la universidad. Todos se consideran iguales en el grupo y no hay un líder designado, por lo que la respuesta a este problema no puede ser "rango de atracción".

Todos son iguales, sin embargo, existe una gran brecha en el conocimiento entre los miembros. El miembro del equipo en cuestión y yo somos desarrolladores capaces, aunque no tiene experiencia en la industria. Los otros tres miembros son menos capaces, y dos han optado por abandonar el desarrollo por completo. Los tres se han negado a comentar sobre la situación debido a la falta de conocimiento.

Como grupo, estamos decidiendo qué tecnologías usar en la implementación del sitio web; específicamente, si usar un framework PHP (Code Igniter) o no.

Estoy argumentando a favor, citando:

1. No reinventar la rueda
2. Base de código bien escrita y probada para trabajar desde
3. Ponerse en marcha (la fecha límite está más cerca de lo que nos gustaría)
4. Velocidad de desarrollo
5. Patrones de diseño sólidos y sostenibles y buenas prácticas.

Está argumentando a favor de trabajar de la manera que solía hacerlo:

• Escribir funciones personalizadas y únicas en un archivo de "biblioteca" como cuando las necesita
  • Funciones para acceder a los datos y representar esos datos en la página, obtener / configurar hacia y desde la sesión y obtener / publicar datos, etc.
• Tener 1 archivo por página (lo que resulta en la no separación de preocupaciones entre control, presentación y datos)

Sus razones contra el uso del marco de trabajo se basan principalmente en que él no puede ver el punto: ya puede hacer todas esas cosas. El marco no cambia eso, solo lo hace más difícil porque tiene que aprender el marco; no quiere usar código que no ha escrito personalmente.

También ha dicho que "no importa la calidad de la base del código, ya que el proyecto es solo un prototipo y nunca se mantendrá". Para mí, eso no es excusa para escribir código que no se puede mantener.

Puedo ver por qué él hace esos argumentos, pero tengo problemas con su "falta de preocupación por la mantenibilidad" y su "desprecio por el buen diseño", o incluso la separación de las preocupaciones. Sin embargo, sospecho que nunca ha estudiado patrones de diseño, por lo que no sé cuán efectivo sería demostrar que su método podría ser imposible de mantener.

Quiero comenzar este proyecto, pero no quiero hacerlo sin tener en cuenta todo lo que he aprendido a lo largo de los años. Como dije antes, no hay posibilidad de subir de rango aquí, ni otros miembros del equipo están dispuestos a participar. ¿Debería retroceder y hacer las cosas a su manera? ¿Es demasiado terco e inexperto para saberlo mejor? ¿O estoy siendo el terco aquí?

TL; DR Un miembro del equipo inexperto es terco, ¿cómo puedo convencerlo?

No vas a poder convencerlo. Se llama el efecto Dunning-Kruger . Es demasiado ignorante para saber lo que no sabe y tiene demasiado miedo de perder lo que él llama una ventaja.

Cuando no puede llegar a un consenso, debe alcanzar un compromiso. Tal vez pueda dividir el trabajo para que su necesidad de aprender el marco sea mínima. Tal vez tenga algún tipo de "diseño" en el que cada uno lo haga a su manera durante un par de semanas y luego el equipo vote cuál es el mejor. Tal vez pueda involucrar a su profesor patrocinador o a quien sea que sea el cliente para resolver el empate.

Un argumento a su favor es la reutilización del conocimiento. Todos los miembros del equipo que aprendan un marco bien conocido y ampliamente utilizado (como CodeIgniter) podrán reutilizar sus conocimientos en el próximo proyecto. Mientras que el conocimiento de una "biblioteca" al azar no es reutilizable. Esto puede resonar bien con los otros miembros del equipo, ya que probablemente prefieran obtener un conocimiento útil y reutilizable sobre este proyecto.

Otro argumento podría ser una medición concreta de los costos de desarrollo / mantenimiento. Me imagino que un desarrollador bien versado en CodeIgniter puede desarrollarse más rápido que tu colega escribiendo todas esas funciones propietarias. Esto podría demostrarse haciendo que tanto usted como él construyan una página web idéntica, usted con CodeIgniter, él en su propio camino, y mida los tiempos hasta su finalización. Luego haga un conjunto de modificaciones / extensiones a las páginas, nuevamente midiendo el tiempo hasta su finalización. Por supuesto, la especificación debe ser preparada por alguien independiente de ambos, para luchar en terreno neutral.

Otro, como mencionó, es la calidad del código. Una vez que las páginas web estén listas, ejecute el mismo conjunto de pruebas de aceptación en cada una y compare la densidad de errores.

Por supuesto, cuando está bajo presión de tiempo, puede que no haya posibilidad de detenerse y hacer tales mediciones. Entonces, probablemente desee una resolución rápida a este dilema. Intenta convencer a los otros miembros del equipo (por ejemplo, haciendo que lean las próximas respuestas a tu publicación aquí :-), para aumentar la presión del grupo sobre él. Al final, si realmente no puede convencerse, es posible que desee dividir el proyecto en dos partes, una para él e, idealmente, una para el resto del equipo, utilizando CodeIgniter. Concéntrate en hacer tu propia parte lo mejor que puedas y deja que haga lo que quiera. Los resultados probablemente hablarán por sí mismos.

Siento que necesitas involucrar a los otros 3 compañeros de equipo. Ambos necesitan presentarles sus argumentos y explicarles cosas para que entiendan. Al final del día, también tendrán que trabajar con esta base de código. Y si todos son iguales, entonces deberían tener algo que decir sobre lo que desean trabajar.

Creo que un buen enfoque sería que cada uno de ustedes describa los beneficios de sus respectivas soluciones y muestre a los demás miembros del equipo por qué creen que es la mejor manera de hacerlo. Entonces déjelos decidir. Hay 3 de ellos, por lo que será el desempate.

Una cosa que querrá señalar es que si este es su proyecto Sr. y los otros miembros del equipo no tienen otra experiencia, este proyecto debe reflejar el trabajo que pueden hacer a los posibles empleadores. Si lo haces bien, puede ser un buen tema de conversación en una entrevista. Sé que les pido a los nuevos graduados que describan su proyecto principal y cómo fue diseñado y desarrollado.

Si siguen el enfoque del otro tipo, tendrás que aguantarlo. Pero no pierdas la esperanza. Cree un buen diseño para que el caos que está escribiendo no afecte todo. Si tiene tiempo, limpie el código y refactorice algunas de sus cosas y muéstrele que no tiene que reinventar la rueda cada vez.

Siento que la universidad es como una caja de arena. La mayoría de las cosas que haces allí no se usan en la implementación. Por lo tanto, le brinda mucha más libertad para experimentar y salir de su zona de confort. Explore cosas nuevas porque fallar no tendrá demasiado impacto. También en su situación, los miembros de su equipo tienen la ventaja adicional de tener a alguien con conocimientos previos que los ayuda.

En cuanto al otro miembro experimentado del equipo, no necesitaba haber ido a la universidad si no quería aprender nada nuevo. Esta es una buena oportunidad para aprender algo nuevo y agregarlo a su caja de herramientas.

Y para los miembros del equipo sin experiencia, sus posibilidades de ser empleados / mejor empleados aumentarán con un marco como CodeIgniter en su currículum (en realidad, el conocimiento para justificar eso en su currículum).