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

10

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?

professionalism Andy Hunt
fuente
2
Es muy difícil encontrar la pregunta real en la publicación de su blog :) Por favor revise de una manera que enfatice los argumentos técnicos que ambos hacen. Aunque realmente no podemos decirle cómo hablar con una persona que no conocemos, podríamos ayudarlo a abordar la situación desde el punto de vista de los programadores. Parece que hay una buena pregunta sobre la creación de prototipos evolutivos allí, pero no puedo estar seguro ...
Yannis
44
Partes de esto probablemente serían más adecuadas para: area51.stackexchange.com/proposals/30887/professional-matters
Karlson el
3
he doesn't want to use code he hasn't personally written.
Será
44
@AndyBursh I want to know exactly how everything workses un argumento válido cuando se aprende, reinventar la rueda es realmente aceptable. Tal vez, solo tal vez, podrías leer eso como un grito de ayuda y no como terquedad.
Yannis
44
since the project is only a prototype and will never be maintained Últimas palabras finales :) Ojalá tuviera un dólar cada vez que hice esta suposición y descubrí que la impaciencia y la codicia a corto plazo de los superiores decidieron que el prototipo ES el producto ahora.
maple_shaft

Respuestas:

20

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.

Karl Bielefeldt
fuente
3
+1 ya que esto sucede ocasionalmente en el mundo real. He estado en trabajos donde no podía estar de acuerdo con otro desarrollador sobre cuál era el mejor enfoque. Así que ambos elaboramos un POC y luego examinamos los pros y los contras de cada uno. 9 de cada 10 veces terminamos adoptando una solución que era una combinación de los dos POC, y todos aprendieron algo del proceso.
Timothy Baldridge el
1
¡+1 por enseñar sobre Dunning-Kruger! Todo el mundo necesita saberlo ..
Stephen Gross
Bah. Es muy fácil citar a Dunning-Kruger cuando no estás de acuerdo con alguien, demasiado fácil para llamarlo estúpido. Tal vez el compañero de equipo cree que los marcos violan el espíritu de la tarea, tal vez quiera resolver de primera mano los problemas que resuelve un marco, tal vez quiera evitar el debate de CodeIgniter, Cake, Symfony ... Mi primera suposición no fue que El era un idiota.
Corbin marzo
1
@Corbin, Dunning-Kruger no se trata de falta de inteligencia, se trata de inexperiencia. Dos cosas muy diferentes. Estoy de acuerdo en que sus razones podrían ser válidas, pero el OP dijo que esos no eran los argumentos que estaba haciendo. En cambio, "no ve el punto" de usar marcos porque puede escribir algo igual de bueno desde cero en un período de tiempo más corto. Una persona inexperta que sobreestima su propia competencia en comparación con una solución de la que ciertamente no sabe casi nada es un ejemplo de libro de texto de Dunning-Kruger. A esas personas no se les puede "convencer" de algo, se les debe mostrar.
Karl Bielefeldt
7

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.

Péter Török
fuente
Me gusta la idea de una prueba de velocidad para demostrar eso. ¿Qué tipo de pruebas de aceptación podríamos ejecutar? Sin duda sugeriré esto, pero no estoy seguro de que le vaya bien a él (o al grupo) ya que todos tenemos otros plazos para administrar, y dudo que alguien esté particularmente interesado en escribir la especificación o "perder el tiempo" (como Estoy seguro de que se pondría) en esto.
Andy Hunt
1
Ciencia, funciona: xkcd.com/54
StuperUser
5

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.

Tyanna
fuente
No había pensado en cómo esto se refleja en los demás en el grupo, sinceramente. Me aseguraré de señalar eso.
Andy Hunt
1

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).

aufather
fuente