¿Cómo explicar las prioridades de negocio a un programador?

No trataría de dictar su estilo de codificación, déjalo que lo haga de la manera que quiera. Si el rendimiento es un requisito comercial real documentado y él no lo cumple, llámelo.

Si continúa sin cumplir con los requisitos comerciales, entonces no está haciendo su trabajo, comience a darle advertencias verbales oficiales, luego advertencias por escrito y luego déjelo ir si es necesario.

Parece que tienes una prima donna o, peor aún, Michel Angelo, trabajando para ti. ¿Cuánto tiempo lleva en el negocio de la programación? Hago esa pregunta porque hay una gran diferencia entre estar en el negocio de la programación y la programación. Quienes hemos estado en las trincheras durante algún tiempo pueden decirle que la perfección puede ser fea.

Su código puede ser bueno como un libro de texto, pero la realidad es que este código tiene que funcionar y un código que tarda 4 horas en ejecutarse en lugar de 30 segundos: ese código difícilmente puede describirse como funcionando. Hago ingeniería de software, pero desde el lado de DevOps de la casa: si el código no se escala, ese código no es bueno, independientemente de qué tan bien esté escrito y documentado. Y el código resistente y mantenible que funciona mal no es bueno. En lo que a mí respecta, o entiende lo que digo o se va. Tiene la libertad de escribir el código con su propio estilo, pero ese código TIENE que funcionar.

No le digas que vaya en contra de los patrones. Dígale cuál es su requerimiento, asígnele una fecha límite y déle la libertad para averiguar cómo cumplirlo. Dado lo apasionado que es que su código se escriba como un libro de texto, tiene todos los incentivos para cumplir con sus requisitos y mantener su código como un libro de texto posible, y eso no es algo malo.

Como su mánager, tendrás que abusar de él y hacer cumplir la ley. Vas a tener que decirle que él es responsable del desempeño de su código, y vas a tener que asegurarte de que los superiores tienen la autoridad para hacer que esa responsabilidad se mantenga. Le daré un incentivo para presionarlo: como su gerente, USTED será responsable si su código no funciona. Póngalo en el lugar porque si no lo hace, la primera persona a la que irá su alta gerencia será usted.

Dices que eres "técnicamente" su manager. Bueno, o eres su manager o no lo eres. Decídete (*)

Si usted es su gerente, entonces él es responsable ante usted como usted es responsable ante su administración. En cuyo caso, se acabó el tiempo de dar explicaciones que él no escuchará. El requisito no negociable es que el código debe funcionar y él debe cumplir con ese requisito. Eso es todo al respecto.

(*) Me encontré con un problema similar en 1987 con un ingeniero ambiental que no siguió nuestras mejores prácticas establecidas por su servidor. Y dado que mi título era oficialmente igual al suyo, restó importancia a todo lo que dije. Organicé una cita a tres bandas entre él, el mandamás del departamento y yo, en la que expuse en términos explícitos cuáles eran los impactos de no seguir nuestro proceso. El mandamás le ordenó que obedeciera y luego me dijo un par de palabras en privado sobre mi mano dura. No me importó el reproche, lo único que me importaba era que estaba cumpliendo y él ya no perforaba agujeros en el fondo de nuestra nave. La escalada a la alta dirección no fue agradable de contemplar, pero funcionó. Que es todo lo que me importaba.

Como desarrollador sénior, ambos tienen razón. Es encontrar el equilibrio por el que debes trabajar.

En primer lugar, por su parte, sus requisitos deben detallarse claramente. Recomendaría usar el enfoque de desarrollo impulsado por el comportamiento (BDD) . Esto le permite detallar sus requisitos y asegurarse de que el software los cumpla.

Es una buena práctica actual seguir las prácticas de desarrollo basado en pruebas (TDD). En esto, el desarrollador escribe el código "solo lo suficiente" para resolver el problema, escribiendo pruebas fallidas y haciéndolas pasar. Esas definiciones de BDD serían el punto de partida. Se descartarían más pruebas unitarias, pero una vez que todas las pruebas BDD estén en verde, puede estar seguro de que se cumplen los requisitos.

A lo largo de esto, se espera que continúe un diálogo, generalmente al comienzo y al final del desarrollo. Esto asegura que ambas partes entiendan los requisitos, eliminando cualquier ambigüedad. Además, esta conversación podría resaltar la importancia o el valor de la solicitud.

Es importante que el código sea claro y comprensible para el desarrollo y mantenimiento futuros. Sin embargo, se debe establecer un equilibrio entre el pulido constante y la entrega de valor.

Si usted y él no lo han hecho, le sugiero que lea Código limpio: un manual de artesanía de software ágil por Robert C. Martin .

En referencia a su debate sobre ORM, los ORM tienen sus pros y sus contras. Como ha destacado, pueden ser lentos e ineficientes, cuando están mal configurados . Además, escribir SQL en línea puede agregar un acoplamiento adicional entre la base de datos y el código. ¿Por qué no simplemente llamar a los procedimientos almacenados ?

Probablemente haya tantos artículos sobre por qué debería hacerlo como sobre por qué no debería usar un ORM en la web. Sin embargo, una consulta que tarda cuatro horas en ejecutarse, especialmente cuando se puede optimizar a 30 segundos, es inaceptable.

Como reflexión final, ¿es este tu único desarrollador? ¿Quizás se beneficiaría de la programación en pareja con otros? ¿Quizás simplemente no es adecuado para trabajar en su empresa?

En primer lugar, ambos están equivocados. Se equivoca al insistir en que el código se ve bien, y usted se equivoca al insistir en usar un antipatrón. La forma adecuada de desarrollar software se encuentra en algún lugar en medio de sus dos ideologías. Es posible seguir las mejores prácticas y aún tener un código que se puede desarrollar rápidamente, tiene un buen rendimiento y se puede mantener, y aquí es donde ambos deben llegar.

Hay muchas maneras de hacer esto. Su desarrollador parece ser del tipo que ve las "mejores prácticas" y nunca se desvía, incluso cuando las mejores prácticas cambian. La mejor manera de solucionarlo es encontrar una mejor práctica que satisfaga sus necesidades, y luego ambos deben seguirla.

Es importante no quedarse atascado en la terminología o la metodología precisa, y esto parece que puede ser un problema para su desarrollador. Ninguna práctica recomendada es buena si no puede implementarla o si da como resultado un código de bajo rendimiento. En lugar de discutir con su desarrollador, debe tratar de comprender por qué se niega a escribir un código que no se ve bien y luego empujarlo hacia una práctica que le permita escribir un código atractivo y un código de buen rendimiento.

En caso de que no crea que el formato es un problema, simplemente busque en Google la frase "programación de espacio o sangría" y sorpréndase con todo. La forma en que se formatea el código tiene mucho que ver con la capacidad de mantenimiento a largo plazo. Además, echa un vistazo a algunos de estos libros , recomendados por Jeff Atwood. Todos son buenos y lo ayudarán a comprender mejor por qué está tan equivocado como su desarrollador.

En última instancia, debe dejar de competir con el desarrollador. Están en lados opuestos del espectro, y si ambos simplemente dicen "Tengo razón", nunca mejorarán. Debes tratar de entender de dónde viene, y con suerte verá el esfuerzo y luego tratará de entender de dónde vienes. Tal vez si intenta optimizar la consulta de 4 horas utilizando una "mejor práctica" diferente que todavía se ve bien, lo entenderá mejor.

Algunos enlaces a algunas metodologías de desarrollo:

• Manifiesto ágil
• Melé
• Desarrollo rápido de aplicaciones
• Programación extrema

Hay muchos otros. Algunos serán buenos, algunos serán malos. Algunos ya no se usan por una razón. Nuestro trabajo pagó un taller Agile, en el que cubrimos Agile en general y elegimos un subconjunto de esos principios para implementar. Nos ha ayudado de muchas maneras, y también nos ha dificultado en un par. Es mucho mejor que lo que hacíamos antes, pero en nuestro caso el problema estaba relacionado con todo el proceso.

Hemos encontrado que la mayor ayuda fue aprender a enfocarse en el producto mínimo viable. Esto significa que le damos al cliente la mínima funcionalidad para satisfacer sus necesidades al principio y la ampliamos según sea necesario. Esto evita que el software se infle con cosas que el cliente nunca pidió.

Nunca me he encontrado con una persona competente en ningún campo que valore la adherencia rígida a las reglas y formas por encima de los resultados y la función. Si envolverse en la bandera es el primer refugio del sinvergüenza, entonces envolverse en un conjunto de reglas rígidas es el primer refugio del incompetente.

Me preocuparía que esté atrapado con un programador de "Cargo Cult" o "libro de cocina", es decir, uno que no entiende su oficio sino que simplemente imita los ejemplos de los demás.

Tal vez se aferre a los patrones y formatos con tanta tenacidad para disimular que en realidad no comprende los matices de cuándo usar qué patrones y prácticas. Utiliza argumentos morales sobre la integridad personal y profesional que, según afirma, le obligan a escribir código de la "única manera verdadera", para ocultar el hecho de que no conoce otra forma de escribir código.

Creo que esto es bastante claro porque todas las declaraciones reales de " mejores prácticas " siempre vienen con la advertencia " para las siguientes circunstancias o parámetros ". No existe un conjunto universal de "mejores prácticas" que siempre será la opción óptima. para cada proyecto.

En particular, las mejores prácticas pueden variar enormemente entre tiendas pequeñas como la suya e instituciones grandes. En las tiendas más pequeñas, los requisitos principales son la velocidad, la flexibilidad, la ejecución y, sobre todo, el envío. Si eres pequeño y no envías, te mueres. Cuestiones como el formato y el estilo no importan mucho porque las personas que mantienen el código probablemente serán las que lo escribieron. Las tiendas pequeñas hacen más trabajo llave en mano en el que el rendimiento de ajuste manual es un valor agregado importante.

Por el contrario, en grandes instituciones corporativas o gubernamentales, los requisitos principales suelen ser la integración en proyectos más grandes combinados con la capacidad de mantenimiento a largo plazo por parte de personas que no escribieron el código años después. El rendimiento a menudo no es un problema tan grande porque los grandes a menudo pueden arrojar más hardware al problema.

Me parece que su codificador está obsesionado con las "mejores prácticas" para la programación institucional grande en lugar de las mejores prácticas para la programación de pequeñas empresas. La mayoría de los libros e incluso la educación formal en estos días parece centrarse en ese mercado, por lo que si en realidad solo imita lo que ha leído, es posible que no entienda realmente que las "mejores prácticas" cambian con el medio ambiente.

Creo que necesitas ponerlo a prueba para saber exactamente qué tipo de programador es en realidad, es decir, si es un primo uomo arrogante e idiota con habilidades o un incompetente que se esconde detrás de una fachada de perfeccionismo. Pídale que produzca un código optimizado a mano como usted escribió, solo vea si realmente puede hacerlo.

Si él tiene las habilidades, pero simplemente valora la forma sobre la función, entonces usted podría convencerlo de que no existen las "mejores prácticas" universales y definitivamente no existen las "mejores formas" universales.

Pero apuesto a que descubrirás que carece de las habilidades. En el mejor de los casos, es un programador de libros de cocina y no un vaquero hacker que puede trabajar sin estructura ni reglas si tiene que hacerlo (incluso si no le gusta). Apuesto a que tendrás que dejarlo ir.

¿Cómo explicar las prioridades de negocio a un programador?

No, al menos no para este programador que no quiere escucharlo. No es un gerente y, aparentemente, no quiere estar facultado para tomar decisiones o emprender acciones sin dirección para mejorar el negocio.

Quiere entrada en forma de solicitudes de características y quiere proporcionar salida en forma de código perfecto.

Su deseo de capacitarlo para que tome decisiones, o para que se preocupe por el negocio, no es un mal deseo, pero en este caso debe dejar de lado ese deseo y concentrarse en las prioridades del negocio: hacer que este programador sea productivo.

Cuando tiene un sistema que no funciona, puede abrirlo y jugar con las partes internas, o puede jugar con la entrada hasta que produzca la salida correcta.

En este caso, le sugiero que juegue con la entrada al programador, en lugar de intentar cambiar el programador.

Tengo un desacuerdo recurrente con un programador sobre la calidad del código.

Deja de discutir sobre eso.

Corto y dulce:

• No dejes que él dirija la conversación y que se centre en la "calidad del código".
• No le digas que lo está haciendo mal o que está perdiendo el tiempo.
• No crea que está actuando de manera poco profesional, incluso cuando está claro para usted que lo está haciendo.
• Acepte su explicación de "Ese no es mi trabajo" y comuníquele los REQUISITOS .
• Todas las solicitudes de tareas futuras ahora deben hacerse por escrito (el correo electrónico está bien) con una discusión de seguimiento.
• Todas las solicitudes de tareas tienen límites estrictos y objetivos sobre el tiempo que puede dedicar a la tarea y el rendimiento que debe tener la tarea.

Por tanto, la próxima vez que le comuniques una tarea, hazlo de forma similar a la siguiente:

Descripción:

Necesitamos que la función X esté implementada, probada e implementada antes del viernes 3 de junio.

Requisitos:

• Debe incluir un caso de prueba que atrape fuera de los límites y el funcionamiento correcto.
• No debe tardar más de 180 segundos en ejecutarse en la base de datos de producción SOME_DATABASE
• Debe pasar las pruebas LINT/etc para los estándares de codificación de la empresa.

Luego, durante la discusión, averigüe si tiene algún problema con los requisitos. Si lo hace, entonces usted hace la tarea o vuelve a trabajar los requisitos para que se ajusten a sus capacidades. Quítele el trabajo duro y manéjelo usted mismo; debe haber una delimitación clara entre su trabajo y el de él. Cuando falle, no intente "arreglarlo": averigüe por qué no cumplió con sus expectativas y diseñe un requisito que le ayude a comunicarle sus expectativas para la próxima tarea similar.

En este punto, espero que entiendas que tu camino actual de intentar que él cambie para satisfacer tus necesidades no va a funcionar. Debe comprender sus capacidades y luego asignarle solo el trabajo del que es capaz. Si llega a un punto en el que ya no satisface sus necesidades, será mejor que lo despida; si la relación comercial entre sus beneficios y su producción ya no tiene sentido para usted, entonces córtela y busque a alguien más para cumplir con su función. . No necesariamente en ese orden.

En este punto, normalmente hago algunos ruidos conciliadores sobre cómo las personas deberían poder cambiar y mejorar constantemente sus habilidades, pero en este momento solo necesita concentrarse en comprender sus propios requisitos y luego comunicárselos claramente. Una vez que haya descubierto la comunicación , puede pasar a ayudarlo a mejorar sus habilidades para que pueda escribir una consulta ORM que se ejecute a tiempo. Hasta entonces, comuníquese, comuníquese, comuníquese y acepte que hay algunas tareas que simplemente tendrá que hacer usted mismo.

Se trata más de prácticas de código que de prioridades comerciales.

Soy programador y estoy un poco ajustado a mis costumbres, pero este programador está fuera de la red. No entiendo por qué alguien preferiría el estilo a la velocidad. ORM son convenientes pero no eficientes. No es mal estilo usar SQL. No es un mal estilo desnormalizar una base de datos para mejorar el rendimiento. La optimización prematura es una mala práctica de código, pero optimizar los cuellos de botella es una buena práctica de código. Revisaré cualquier consulta que tarde más de 2 segundos.

Mi motivo favorito son los controles personalizados. El negocio me pedirá una mirada muy específica y yo responderé pero el control estándar presenta la información. Los controles estándar son rápidos y probados. Cuando actualizamos, no necesitamos coordinar varias bibliotecas.

¿Por qué un programador querría usar un ORM que tarda 4 horas en ejecutarse? Se necesitarían 4 horas para probar. Si el programador estuviera luchando para pasar a SQL para reducir 4 segundos de una consulta de 8 segundos y la empresa dijera que 8 segundos es lo suficientemente bueno, queremos permanecer en ORM para la mantenibilidad, entonces obtendría ese debate.

¿En cuanto a cómo convencer al programador? Lo llamaría más un problema de prácticas de código que prioridades comerciales. Una empresa no necesita justificar que una búsqueda de 30 segundos es mejor que una búsqueda de 4 horas. Solo hago ORM porque escribir SQL sin procesar es una mala práctica, simplemente no es aceptable. Si el idioma y la plataforma admiten SQL sin procesar, entonces es aceptable. El programador necesita ser puesto en un programa de acción correctiva y RH necesita estar involucrado. Si no eres su jefe, ve con su jefe.

Argumentar a partir de primeros principios.

Ningún cliente o cliente realmente se preocupa por las "mejores prácticas". Pero ciertamente se preocupan por la calidad . Por encima de todo, quieren que su problema se resuelva, y cuanto más rápido, más fácil y más barato, mejor. (También quieren ahorrar tiempo, dinero y esfuerzo a largo plazo, lo cual es una gran parte de la "calidad").

Sí, algunos clientes usan "mejores prácticas" como indicador de calidad, eficiencia, etc. Pero solo porque sus principales intereses son la calidad, la eficiencia, etc.

Así que cualquiera que ofrezca un servicio (incluso un programador que ofrece servicios a una empresa) debe evaluar su trabajo con preguntas como "¿es de alta calidad?", "¿se entrega rápidamente?", "¿hace lo que el cliente quiere?", " ¿Ahorra tiempo/dinero/recursos a largo plazo?"

Estas son preguntas difíciles de responder. Es mucho más fácil responder preguntas como "¿Sigo las convenciones de codificación?", "¿Implemento la especificación correctamente?" y "¿Tengo una descripción de Javadoc para cada método?" Tales preguntas son una manera fácil de evitar las preguntas difíciles. Pero un buen programador hace las preguntas difíciles de su código.

Las mejores prácticas son importantes. Ayudan a crear productos de calidad que ahorran tiempo/dinero/recursos a largo plazo. Son particularmente útiles cuando está tratando de tomar una decisión y tiene poca evidencia sólida sobre qué alternativa es mejor. Pero cuando tiene información clara sobre una alternativa (por ejemplo, tomaría 10 minutos en lugar de 4 horas, con muy pocas posibilidades de crear problemas más adelante), ¡entonces el sentido común triunfa sobre las mejores prácticas!

Si su programador piensa que un fragmento de código es "terrible y nunca debe usarse", pídale que lo justifique desde los primeros principios (en lugar de las mejores prácticas). ¿Tiene un error? ¿Existe el riesgo de que contenga una vulnerabilidad de seguridad? ¿Es probable que añada mucho tiempo al mantenimiento o nuevas funciones en el futuro? ¿Confundirá a otros programadores? ¿Y los problemas con él realmente valen la pena el tiempo dedicado a implementar una alternativa "mejor"? Asegúrate de escuchar lo que dice. Si tiene un argumento fuerte, no dejes que tu ego lo anule.

Una nota sobre la integridad y el hábito

Los buenos hábitos son valiosos. Si sus desarrolladores están constantemente practicando y perfeccionando su capacidad para escribir código claro, limpio y bien documentado, serán más eficientes y estarán menos tentados a ser perezosos y tomar atajos. ¡Esto es excelente para la calidad de su base de código!

Su programador claramente tiene integridad. No intentes matarlo, ¡úsalo! Asígnele tareas donde la calidad sea importante. Por ejemplo, pídale que limpie el código desordenado escrito por otra persona que se está volviendo difícil de mantener. Pídele que implemente la funcionalidad donde sea importante que el código se pueda mantener.

Insiste en que todo su código está escrito al más alto nivel (es decir, que se parece a los ejemplos de los libros de texto de estilos de codificación), independientemente del impacto que esto tenga en la funcionalidad. Yo, por otro lado, creo que es más importante que el código escrito satisfaga las necesidades del negocio, es decir, que funcione de manera eficiente, que no tarde demasiado en desarrollarse y que sea razonablemente mantenible.

Te das cuenta de que ambos tienen el mismo objetivo, ¿verdad?

Las mejores prácticas son tales por una razón. Existen para mantener el código bien organizado y separado para que funcione de manera eficiente, no tarde demasiado en desarrollarse y sea razonablemente fácil de mantener.

Claro, su desarrollador podría beneficiarse de una pizca de pragmatismo o una mejor comprensión de cuándo se pueden romper las reglas de manera segura. Pero también parece que podría beneficiarse de una visión a más largo plazo de cómo la calidad del código base ayuda a sus objetivos comerciales.

Su pregunta es sobre cómo explicar las prioridades comerciales al programador, pero parece que ya lo ha hecho. Lo que no has hecho es escuchar las prioridades comerciales de tu programador. Ustedes dos tendrán que comprometerse. Hay muchas más soluciones al problema que "usar SQL directo" y "usar el ORM". Puede buscar mejorar el rendimiento del ORM. Puede buscar aislar el SQL para que sea menos problemático para el programador.

En resumen, para obtener lo que desea, debe dejar de discutir y comenzar a cooperar.

Para ser honesto, disciplinaría al tipo y lo despediría si fuera necesario. Las respuestas ya publicadas aquí tienen varios puntos buenos con respecto a la flexibilidad en los enfoques de los problemas, por lo que no los repetiré.

Parece que el empleado con el que tiene problemas ya está en el nivel superior o cerca de él, y entiende mucho sobre cómo programar. Sin embargo, ese no es todo su trabajo. Si técnicamente eres su manager, necesita escucharte sin importar si le gusta o no. Obviamente, no hemos observado cómo ustedes dos discuten los problemas, pero debe estar poniéndose bastante tenso. Sí, hay más de una forma de resolver la mayoría de los problemas, y ambos deberían aprender a ser más flexibles, pero varias de las cosas que ha dicho indican que esta persona es un detrimento para la empresa, no un activo.

Ahora se niega a trabajar en esa parte del programa.

Inaceptable e infantil, y también una negativa a cumplir con un deber en su trabajo , que en lo que a mí respecta, es motivo de despido.

pero él simplemente dice "no, no lo es" y continúa escribiendo su código elegante e ineficiente, que a veces tengo que reescribir mal antes de que pueda usarse.

Igual aquí.

Solo puedo imaginar (y espero) que en su frustración haya embellecido un poco, y espero que como su gerente "técnicamente" pueda mantenerse a un nivel más alto y no tener desacuerdos infantiles con esta persona. Sin embargo, si la situación es como usted dice que es, el empleado es inflexible hasta el extremo. Potencialmente, podría usar algo de educación y orientación sobre cómo tratar con personas difíciles pero, al final del día, este empleado se niega rotundamente a mejorar un producto basado en estándares esotéricos. Solo hay una forma en que esto puede afectar a sus clientes, y es de forma deficiente. No importa cuán bueno sea este programador, en algún momento se convertirá en una responsabilidad para la empresa (quizás ya lo sea).

Al final del día, los está empleando para producir un producto que funcione, no un código bonito. Si no pueden hacer eso, entonces no están haciendo su trabajo.

Habiendo dicho mi artículo, trate de recordar que no es blanco y negro, y definitivamente no es usted contra ellos, solo tiene ideas diferentes sobre lo que es correcto. Mis comentarios aquí se basan en el entendimiento de que ha tratado de explicar las prioridades comerciales y a la persona no parece importarle, lo que en mi opinión significa que no encajan bien en su empresa. Tal vez a este tipo le iría bien en un sitio web que enseña las mejores prácticas o algo así.

Es posible que necesite averiguar lo que él considera importante. "Buen estilo" es solo eso, estilo. Debe adaptarse para satisfacer las necesidades comerciales y él debe saberlo. Sin embargo, puede haber un temor subyacente con el que está lidiando y que debe abordarse.

Como caso de estudio, trabajé en un equipo que constantemente producía software a un ritmo más lento de lo que necesitaban los clientes. La gerencia estaba continuamente enojada con nosotros. Teníamos una buena razón para la lentitud. La gerencia había establecido un entorno de desarrollo hostil en el que no se podía cambiar ninguna pieza de código sin un comando explícito de nuestro cliente. Desafortunadamente, teníamos el requisito explícito de mantener este software durante décadas, mientras que pocos o ninguno de nuestros clientes pensaron en más de un mes por adelantado, lo que hizo imposible convencerlos de un ROI a largo plazo. Se nos dio una gran responsabilidad por el software, pero poca o ninguna autoridad para hacer algo al respecto. Nuestro mantra era "El primer prototipo de trabajo que se muestra al cliente será su implementación final". Nunca resolvimos este obstáculo. La gerencia nunca trabajó con nosotros para apoyar el programa de una manera acorde con nuestras responsabilidades (en realidad, se nos ordenó que no tratáramos de resolverlo, porque simplemente mencionar el problema correría el riesgo de continuar con la financiación). En cambio, el programa terminó muriendo porque nadie abordó el fracaso comercial subyacente.

Pasamos mucho tiempo después de esto, como desarrolladores, tratando de averiguar qué salió mal exactamente y qué podríamos hacer la próxima vez para evitarlo. Una de nuestras conclusiones de este ejercicio fue el valor de tener múltiples formas de abordar un problema. ¿Le gusta el estilo ORM, mientras que usted ahorra eones de computación con uno o dos comandos SQL? Haz que ambos puedan existir uno al lado del otro. Muy a menudo, el valor de un enfoque no es obvio para la otra parte hasta mucho después de haberlo terminado. Permita que ambos estilos coexistan en la naturaleza y descubra cuál sobrevive a los rigores de los negocios. Desarrolle un sentido de armonía entre los enfoques en lugar de tratar de dictar un enfoque para gobernarlos a todos. Quizás hace todo su desarrollo primario usando su estilo extremo, pero el producto final requiere la adición de trucos.

Si no acepta esto, entonces en realidad está equivocado. No es la voz de la empresa, es simplemente un empleado. Su voz es parte del todo y no el centro del todo (a menos que lo contrate para ser el centro). Un empleado que no puede flexionar porque mantiene principios que violan las necesidades de la empresa debe ser despedido. Pero por el contrario, los desarrolladores tienen un punto de vista del software que no se puede encontrar en ningún otro lugar. La empresa necesita flexibilizarse cuando el desarrollador señala un problema que es difícil de ver para los demás.

El objetivo es descubrir cómo hacer que los dos puntos de vista coexistan el tiempo suficiente para explorarlos adecuadamente. Sin embargo, eso puede fallar eventualmente si un lado está particularmente atascado en el barro. En ese momento, deberá mantener una conversación cortés explicando que su estilo de codificación no es el centro del mundo, y si se interpone en el camino de los negocios, se le asignarán tareas que le otorgan cada vez menos libertad en los enfoques. se le permite tomar. Alternativamente, es libre de aceptar ceder terreno en cosas como "tamaño del cheque de pago" a cambio de la libertad de hacer su trabajo.

No quería crear otra respuesta que sugiriera un desarrollo iterativo, pero sí quería agregarla al final de mi respuesta. El desarrollo iterativo le da la oportunidad de explorar el "buen estilo" en una iteración y luego hacer que usted aplique los tornillos de mariposa comerciales para convertirlo en un producto útil. Puede que no sepas a priori que una tarea se puede hacer en 30 segundos. Sin embargo, después de la primera iteración, debe tener una idea del tiempo. Este sentido del tiempo debería permitirle proporcionar requisitos de tiempo en la segunda iteración.

Si establece un requisito comercial para que una consulta demore menos de 5 minutos, y él dice que no se puede hacer, quítele educadamente la tarea y hágalo usted mismo. Déjalo jugar con sus pulgares hasta que comience a darse cuenta de que su cheque de pago está en peligro.

La mejor respuesta que he leído sobre este tema proviene de las preguntas frecuentes de C++.

https://isocpp.org/wiki/faq/big-picture#biz-dominates-tech

Puede que no te guste esto, pero la respuesta corta es: "No". (Con la advertencia de que esta respuesta está dirigida a los profesionales, no a los teóricos).

Los diseñadores de software maduros evalúan situaciones en función de criterios comerciales (tiempo, dinero y riesgo) además de criterios técnicos como si algo es o no "buen OO" o "buen diseño de clase". Esto es mucho más difícil ya que involucra cuestiones comerciales (horario, habilidad de las personas, averiguar a dónde quiere ir la empresa para que sepamos dónde diseñar la flexibilidad en el software, la voluntad de tener en cuenta la probabilidad de cambios futuros, cambios que son probable en lugar de meramente teóricamente posible, etc.), además de cuestiones técnicas. Sin embargo, da como resultado decisiones que tienen muchas más probabilidades de generar buenos resultados comerciales.

Como desarrollador, usted tiene la responsabilidad fiduciaria con su empleador de invertir solo en formas que tengan una expectativa razonable de retorno de esa inversión. Si no hace las preguntas comerciales además de las técnicas, tomará decisiones que tendrán consecuencias comerciales aleatorias e impredecibles.

Nos guste o no, lo que eso significa en la práctica es que probablemente sea mejor dejar términos como "buen diseño de clase" y "buen OO" sin definir. De hecho, creo que las definiciones precisas y puramente técnicas de esos términos pueden ser peligrosas y pueden costar dinero a las empresas y, en última instancia, tal vez incluso costarles a las personas sus trabajos. Eso suena extraño, pero hay una muy buena razón: si estos términos se definen en términos técnicos puros y precisos, los desarrolladores bien intencionados tienden a ignorar las consideraciones comerciales en su deseo de cumplir con estas definiciones técnicas puras de "bueno".

Cualquier definición puramente técnica de "bueno", como "buen OO" o "buen diseño" o cualquier otra cosa que pueda evaluarse sin tener en cuenta el cronograma, los objetivos comerciales (para que sepamos dónde invertir), los cambios futuros esperados, la cultura corporativa con con respecto a la voluntad de invertir en el futuro, los niveles de habilidad del equipo que realizará el mantenimiento, etc., es peligroso. Es peligroso porque engaña a los programadores haciéndoles creer que están tomando decisiones "correctas" cuando en realidad podrían estar tomando decisiones que tienen terribles consecuencias. O esas decisiones pueden no tener consecuencias comerciales terribles, pero ese es el punto: cuando ignora las consideraciones comerciales mientras toma decisiones, las consecuencias comerciales serán aleatorias y algo impredecibles. Eso es malo.

Es un hecho simple que las cuestiones comerciales dominan las cuestiones técnicas, y cualquier definición de "bueno" que no reconozca ese hecho es mala.

Considere esta declaración:

• Como programador, la creación de código razonablemente eficiente es parte de su trabajo tanto como ser un tipeador razonablemente rápido es parte del trabajo de un mecanógrafo.

Luego muéstrele un ejemplo de cómo se puede mejorar drásticamente su código.

Si no puede (o no quiere) unir los puntos entre esa declaración y su ejemplo, debe deshacerse de él. Es como tener un representante de atención al cliente que se niega a usar su teléfono porque prefiere enviar correos electrónicos a los clientes.

En realidad, hay dos preguntas separadas: una es que un desarrollador de software (comprensiblemente) quiere crear un código de la más alta calidad, mientras que la empresa quiere que cree un código que ofrezca la mayor funcionalidad posible al mismo tiempo.

Hay un compromiso que se debe tomar: en algún momento, el pulido excesivo del código ya no brinda ninguna ventaja. Por otro lado, si la calidad del código no es lo suficientemente buena, obtendrá un código que produce resultados incorrectos, se bloquea, es demasiado lento o no se puede mantener.

Debe convencer a sus desarrolladores de que no se excedan, y ellos deben convencerlo de que no adherirse a un estándar limitado a veces es costoso a corto plazo y, a menudo, costoso a largo plazo. Por otro lado, ser costoso a largo plazo puede ser aceptable si solo entregando en poco tiempo el negocio sobrevive lo suficiente como para preocuparse por el largo plazo. Si no puede convencer a sus desarrolladores para que produzcan elcantidad de calidad y le cuesta dinero, es posible que deba separarse. (Obviamente, si alguien produce baja calidad en ocho horas, y alguien más produce alta calidad en ocho horas y no se puede lograr que produzca baja calidad en seis horas, usted aún prefiere el segundo desarrollador. O si ese desarrollador está contento con la creación de alta calidad y productivo, y al obligarlo a abandonar la calidad lo vuelves infeliz e improductivo, eso tampoco es bueno).

La otra pregunta: parece que su desarrollador insiste en algún enfoque formal que es ineficiente, en lugar de usar un enfoque informal que es muy eficiente (cuando la ineficiencia es realmente un problema para el negocio). Eso lo veo como un problema serio. Si la empresa tiene un problema que necesita ser resuelto, entonces cualquier técnica que no resuelva el problema no es aceptable, e insistir en tal técnica sabiendo otra diferente que soluciona el problema, eso no me parece aceptable.

Si es necesario, el desarrollador debe sentirse libre de agregar comentarios al código con una diatriba de por qué la técnica que está usando es mucho peor que la otra técnica, pero debe hacerse por eficiencia. (En realidad, podría ser una buena idea escribir las razones en caso de que se le pregunte por qué utilizó este enfoque dentro de dos años). Sin embargo, lo que debe hacerse debe hacerse.

Este es un problema con su actitud, y necesita cambiar.

Sus intenciones parecen lo suficientemente nobles: está tratando de implementar el código que aprendió en la escuela, que aprendió que es seguro e higiénico para el programa, y ​​se apega a las mejores prácticas para la codificación. Este aspecto es algo que quieres de un programador.

Lo que no quiere que sienta es que puede tomar decisiones de alto nivel sobre cómo debería funcionar la aplicación. Es, supongo, un programador junior , y aún no ha aprendido a adaptarse a situaciones especiales, y mucho menos a las complejidades de su propia aplicación.

Si este es un incidente que se repite, le sugiero que hable con él sobre cómo las mejores prácticas, aunque es bueno seguirlas, no siempre son la solución correcta. Recuérdale también que tú eres su jefe y que no tolerarás que rechace tus decisiones o que vaya a tus espaldas a programar 'a su manera'.

Y a nivel individual, su grupo debería revisar el código antes de comprometerse de todos modos, así que aproveche la oportunidad para repasar su código bien formateado pero altamente ineficiente y exponer, paso a paso, por qué es ineficiente.

Si se niega a cambiar, asigna el cambio a otra persona o hazte cargo tú mismo. Desafortunadamente, esto podría ser una señal de que no funciona bien en grupos, y eventualmente tendrás que dejarlo ir, o encontrar un grupo diferente que funcione mejor con su estilo de codificación 'siempre estricto'.

En tu pregunta no hablas de que el código funcione correctamente . Tal vez su programador pasa demasiado tiempo haciendo que el código se vea bonito, pero tal vez está siendo minucioso en su verificación de errores. Un buen código tiene algunos requisitos:

• Debe funcionar una cantidad aceptable del tiempo.
  • Aceptable puede significar al menos el 95 % o nunca menos del 100 %; es su definición
• No debe producir efectos secundarios en otros códigos/sistemas (ver primer punto)
• Debe ser mantenible
  • El código bien formateado es mucho más fácil de mantener que el código mal formateado
• Debe ser entregado en la fecha límite (siempre que sea y recordando que los plazos se pueden reajustar en función de las necesidades del negocio)
• debe ser asequible
• Probablemente muchos otros puntos

Como administrador/representante de la empresa en su conjunto, desea un código de alta calidad, económico y desarrollado rápidamente. Desafortunadamente, la experiencia ha demostrado que solo puedes obtener dos de esos. El código desarrollado rápidamente y de alta calidad es costoso. El código barato y desarrollado rápidamente es de baja calidad. El código barato y de alta calidad requiere mucho tiempo para desarrollarse.

Algunos programadores no comprometerán la calidad (admito que soy uno de ellos) debido a la gran cantidad de tiempo adicional que se requiere para solucionar problemas, corregir errores y reescribir después. No permitiré a sabiendas que se publique un nuevo error.

Una vez trabajé en un proyecto enorme y mal escrito. El código fue heredado de un tercero y tuvimos muy buenos desarrolladores trabajando en él. El negocio seguía pidiendo que fuera mejor y nosotros seguíamos diciendo "Esto es lo mejor que se puede". Eventualmente conseguimos que el código funcionara mejor, pero tomó de 6 meses a un año para que eso sucediera y nunca tuvimos una idea clara de cómo hacer que el código se ejecutara más rápido en ese momento. Cuando dijimos "Esto es lo mejor posible", lo que realmente queríamos decir era "Hemos agotado todas nuestras ideas actuales".

Su programador podría estar en una situación similar. Literalmente está haciendo lo mejor que puede y no puede pensar en mejores formas de hacer las cosas. Probablemente no le guste que le den a la fuerza ciertas ideas y las rechazará automáticamente. Si a él se le ocurre la misma idea de forma independiente, ¡ambos ganan! Ser una empresa pequeña significa que probablemente no tenga muchas oportunidades de compartir ideas con otras personas o recibir ideas de pensamiento lateral de personas que no están tan cerca del proyecto.

Después de haber trabajado en el código de otras personas, puedo decirles que a veces he tenido que pasar media hora reformateando el código antes de poder empezar a entenderlo. El formato del código es esencial para la eficiencia de su programador, aunque se ejecute de manera idéntica.

No intente convencer a su programador de que acepte "código incorrecto". Explique por qué hay múltiples formas de hacer lo mismo y solo porque una es un "buen código" no convierte automáticamente a las otras en "mal código". Tienes que demostrarle que estás de su lado. ¡También quieres un buen código! Pero luego defina qué es un buen código. Si tener un buen desempeño es importante, ¡entonces déle el desafío de hacerlo! Indique claramente el resultado esperado. Por ejemplo, necesitamos ejecutar esta consulta 1000 veces por hora, lo que significa que debe poder ejecutarse al menos una vez cada 3,6 segundos (¡lo que probablemente sea un rendimiento terrible!)

Ha sido contratado para ser un experto técnico, no un experto en negocios. Como tal, sus objetivos profesionales pueden no ser lo que le gustaría que fueran. Debe explicar cómo lo que hace afecta al resto del negocio, al mismo tiempo que comprende cómo el resto del negocio afecta su trabajo. No recomendaría la gestión del rendimiento a menos que esté planeando despedirlo.

También podría investigar la posibilidad de un formateador de código automático. De esa manera, podría concentrarse en la programación y usar una macro o una pequeña utilidad para reformatear el código de la manera que le gusta en menos de un segundo. Con el SQL, estoy de acuerdo con él en que las consultas escritas directamente son malas, pero, por ejemplo, en PHP, puede usar PDO para ejecutar exactamente las mismas consultas con entrada desinfectada. ¡Esta es una buena práctica! Debería haber un compromiso en el que obtienes la velocidad que deseas y él obtiene el "buen código" que desea.

También sugeriría que haga un perfil del código para encontrar los cuellos de botella y convertirlos en una prioridad para la eficiencia. Al final del día, si su bonito código funciona rápidamente (y lo escribe rápidamente), no te importa, ¿verdad? Quiere que vea su punto de vista, así que demuestre que puede ver y valorar su punto de vista. Tendrán que reparar el daño causado a su relación profesional y es importante que ambos confíen el uno en el otro.

Esto puede ser complicado. Depende mucho de lo que su comportamiento está afectando negativamente.

rendimiento del programa

Un buen programador debe comprender la separación de la interfaz y la implementación. Los requisitos son la "interfaz" por así decirlo del proyecto, y un buen diseño

Supongo que usted es al menos parcialmente responsable de los requisitos de este proyecto. Puede crear un requisito para que este script se ejecute en 6 minutos.

Mientras cumpla con los requisitos, no te importa lo que esté haciendo. (Esta es la implementación.)

Puede ayudarlo a ver que, desde el punto de vista de todos los demás (que no pueden ver su código fuente) , su programa es una porquería .

Tiempo de desarrollo

Esto es un poco más complicado. Por un lado, podría hacer tiempo para completar un "requisito" del proyecto, pero estimar el tiempo para completar un proyecto se deja (apropiadamente) a la persona que lo construye.

Este tiene que ver mucho con su desempeño laboral. Debe abordarlo como lo haría con cualquier otro problema relacionado con el desempeño laboral. Esto probablemente signifique una reunión seria, en la que expreses tus preocupaciones sobre su capacidad para terminar el trabajo a tiempo, etc. Aquí no hay soluciones fáciles.

El hecho de que este programador se niegue a trabajar en ese componente es una clara señal para mí de que se trata de una cuestión de responsabilidad del componente.

Desde el punto de vista de su cliente, su optimización es lo correcto: la caja negra que es su programa funciona mejor y su empresa como entidad es responsable de toda la caja.

Dentro de su empresa, las personas individuales son responsables de los componentes individuales, y cada vez que un componente se rompe, la culpa recae en el mantenedor de ese componente.

No se puede desvincular esa responsabilidad del poder de decisión.

Anular la decisión es su prerrogativa como gerente, pero al mismo tiempo asume toda la responsabilidad por la decisión, que incluye un registro en papel que documenta las objeciones de su programador y por qué fueron anuladas, con una copia para todos.

Su programador está prediciendo que esto tendrá consecuencias negativas en el futuro y está tratando de cubrir su trasero inferior.

Dígale que su trabajo NO es escribir programas per se; su trabajo es escribir código que agregue ganancias a la empresa.

Recuérdele Para que sea comercialmente viable como empleado, el código que escribe debe ser comercialmente viable. Si no puede hacer esto, entonces es una responsabilidad comercial para la empresa y será tratado como tal. Usted dice que es una empresa pequeña, por lo que existe la posibilidad de que pueda derribar toda la empresa.

Además, puede explicarle que puede escribir programas por diversión y placer (o para mejorar sus habilidades) en su tiempo libre, y muchos programadores lo hacen. Pero los programas escritos en el tiempo de la empresa deben generar ganancias para la empresa.

Si se niega a cambiar su estilo (posiblemente para hacer que el código sea menos atractivo pero que mejore sustancialmente el rendimiento), pregúntele cómo le gustaría que la empresa le pagara de la misma manera: solo el 10 % de su salario, pero usando un color realmente agradable. cheque impreso. Obra de arte, escrita a mano y firmada a mano por el CEO, puede colgarla en la pared :-)

Sí, las soluciones pragmáticas a veces acumulan deuda técnica -- ( wikipedia ) para brindar VALOR para los negocios.

Negarse a aceptar la deuda técnica es lo mismo que negarse a aceptar la deuda financiera: a veces, la solución válida es pedir dinero prestado para entregar el producto (incluso si más tarde necesita pagar la deuda).

Tener un código menos que idealmente mantenible pero con un mejor rendimiento es similar a pagar un crédito rotativo: permite que la empresa permanezca en el negocio.

Si le toma 10 veces más de su tiempo entregar una solución, solo merece el 10% del salario. Si no logra entregar valor para el negocio, debe ser reemplazado por alguien que sí lo haga. (Estoy seguro de que esto me dará algunos votos a la baja, porque es una droga directa y no un lenguaje cálido y confuso; oh, bueno, la vida es demasiado corta. Y sí, los votos a la baja están llegando a raudales. Es por eso que ya no contribuyo a este foro. ).