¿Cómo puedo tratar con los gerentes que se niegan a aceptar el uso de patrones de diseño de ingeniería de software comunes?
Antecedentes
Soy un ingeniero de software y un TDD practicante en mi empresa. Mi gerente también es responsable de la codificación (si es necesario), y de la gestión de sus subordinados ingenieros.
Recientemente tuve algunos debates acalorados con mi gerente sobre el uso de patrones de diseño de software.
El problema
Frecuentemente cuando se me encomienda la implementación de una característica y un código, mi gerente me desafía durante las revisiones de código por mi uso de patrones de diseño de software comunes. Él piensa que es innecesario y que uno debe codificar lo más “sencillo” posible. Puse citas sobre lo sencillo, porque parece que no estamos de acuerdo con el alcance de una “característica”. En muchos casos, la característica no es tan “directa” como piensa mi gerente y requiere el uso de patrones de diseño para separar responsabilidades y minimizar el impacto en la base de código (en su mayoría no probada).
Hay dos casos de uso común Aplicaré patrones de diseño para resolver un problema:
Implementación de nuevas características que requieren cambios en una clase de legado no comprobable
Abordar las incertidumbres mediante la interconexión de las incógnitas
Nos metimos en algunos argumentos debido a reuniones de diseño similares. En una discusión acalorada, incluso me dijeron que “[ha] estado programando durante más de 20 años!”, lo que implica que ni siquiera debería atreverme a cuestionar su autoridad.
Lo que traté de mitigar este problema
Comentarios detallados por escrito sobre algunos componentes no tan obvios sobre por qué los necesitaba y para qué sirven
Demostré pasivamente que mi diseño es mucho más adaptable a los cambios
Un componente que construí tiene un número de fallos significativamente menor que la mayoría de los otros componentes
Anticipé correctamente un cambio en los requisitos, que condujo a un cambio mínimo de código necesario para cumplir con ese requisito
Trató sus preocupaciones por adelantado cuando me desafían explicando mi proceso de pensamiento y razonamiento
Sin embargo, todavía me reprenden por el código de sobreingeniería.
Discutió informalmente esto con mis colegas y les pidió sus opiniones en privado
La mayoría de ellos aprecian mi enfoque bien razonado y uno incluso mencionó que aprendió mucho de mí. A la mayoría de los ingenieros les gusta discutir sus problemas de codificación conmigo, porque normalmente puedo darles consejos útiles o señalarles algo que podrían haber pasado por alto
Realizando presentaciones informales para educar a mis compañeros ingenieros (y al gerente) sobre por qué aplico un patrón de diseño aquí y allá
No quiero parecer arrogante diciendo que mis habilidades de codificación son absolutamente mejores que las de mi gerente, pero realmente me he quedado sin ideas para convencerlo, incluso después de las demostraciones, las explicaciones y los resultados objetivos que se le muestran. Por un lado, me gustaría entregar un código libre de errores, bien probado y diseñado por la unidad. Por otro lado, sigo siendo criticado porque mi diseño no se siente bien y ciertamente ha “complicado” mi código al forzarlo a la forma “aprobada”.
¿Cómo podemos encontrar un punto medio?
Actualización
Como estoy recibiendo muchos comentarios mencionando mi actitud dogmática, incluso demasiado entusiasta para seguir los principios de la ingeniería de software, creo que debo aclarar:
No estoy tratando de ser dogmático ni demasiado entusiasta. Me importa que la gente lea y entienda mi código, tanto si usan/entienden los patrones de diseño como si no. Pedí la opinión de mis colegas durante las revisiones de los códigos si entienden mi código o no. Dijeron que sí y que entienden por qué diseño un componente de esa manera. En una ocasión, mi uso de patrones de diseño ayudó a centralizar la lógica de búsqueda de configuraciones en un lugar en vez de tenerla repartida en docenas de lugares, que tiene que ser cambiada a menudo.
Para ser honesto, estoy bastante decepcionado al ver tantas respuestas con un fuerte estereotipo de “Por qué ustedes los ingenieros no pueden pensar como los gerentes”. Al final del día, todo puede decirse que es sobreingeniería: Por qué marcar los campos como private en lugar de exponerlo todo, por qué probar la unidad si ningún usuario va a ejecutar sólo una unidad, etc.
Mi motivación en el uso del patrón de diseño o de hecho de cualquier ingeniería de software es minimizar el riesgo y llevar valor a la empresa (por ejemplo, reduciendo la propagación innecesaria de la lógica en el código base, para que puedan ser gestionados en un solo lugar).
Lo siento si esto suena como un despotricamiento. Estoy buscando respuestas del tipo “cómo podemos encontrar un punto medio” en lugar de algunas respuestas condescendientes como “los ingenieros se creen inteligentes aplicando patrones de diseño que nadie entiende”.