¿Lucha contra la deuda técnica como el "desarrollador más bajo"?

Digamos que trabajas para una empresa y lo que haces es desarrollar software para ellos. No tienes idea del panorama general o tal vez leve. Lo que sí tiene son tareas asignadas a través del sistema de seguimiento de problemas. Se le asignan tareas, las hace funcionar de la manera en que la tarea las describe, las envía de regreso. Como agregar 2 enteros:

function add(a,b){return a + b;}

Pero más adelante, a medida que avanza el proyecto, observa que a medida que se addvuelve más complejo, se da cuenta de que debería haber necesitado algún tipo de arquitectura, más que una función que agrega parámetros y devuelve un valor. Sin embargo, no lo sabías. En primer lugar, todo lo que necesitaban era así de simple add. No esperaba que agregar se volviera tan complejo.

El proyecto avanza con más funciones, que no esperaba tener en primer lugar. Y al final, sigues acumulando hacks y capa tras capa de funciones para evitar romper / reescribir el código existente.

¿Cómo manejas estas situaciones? ¿Cómo se combate la deuda técnica como "el desarrollador más bajo"?

Aclaración:

• Eres el "implementador", el más bajo en la jerarquía.

• Usted ve el problema, pero no tiene nada que decir al respecto.

• No estoy cuantificando la deuda técnica ni buscando herramientas.

• En cuanto al tercer "duplicado"

  • Refactorización y reescritura: está bloqueado para sus tareas. No se le paga por hacer más.
  • Descripción general de la arquitectura: conoce el sistema general, pero no tiene idea de la arquitectura.
  • Congelación de código: no es su llamada. No eres gerencia.
  • Modularización: ninguna idea de arquitectura. Los módulos cambian a medida que cambian los requisitos.
  • Pruebas automatizadas: no existe ninguna.

Cada vez que note algo así, ingrese un nuevo ticket en su sistema de seguimiento de problemas.

Acostúmbrese a usar el rastreador de problemas como una herramienta principal para comunicar cosas como esa, porque a partir de ahí, será fácil elegir, evaluar y priorizar para sus colegas / líderes / gerentes / responsables que sean responsables de rastrear los problemas en su proyecto .

Use la herramienta adecuada para el trabajo. Lo hago siempre y fuertemente recomiendo que hagan lo mismo.

Como ejemplo, aquí hay un ticket que creé hace aproximadamente un mes. Al completar una función particular, descubrí que el código se volvió mucho más complicado de lo que era antes, pero no puedo solucionarlo dentro del plazo establecido para la implementación de la función.

(Los nombres de las características, tickets y código utilizados en el rastreador real están oscurecidos, pero el texto se copia tal cual).

Resumen: simplifique el diseño que involucraParticularPieceOfCode

Descripción:
En el curso de la implementación según TICKET-12345, el código que involucra el uso de ParticularPieceOfCodeun poco de complicación se convirtió en algo difícil de leer, comprender y mantener (vea el fragmento de código de ejemplo a continuación).

Encuentre una manera de simplificarlo.

Puede encontrar un ejemplo de código que sería deseable rediseñar en ClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW mi consejo se aplica independientemente de qué "nivel" eres.

Lo he estado usando en su nivel actual ("más bajo") y lo estoy usando ahora que mi nivel está bastante lejos de "más bajo" y tengo un "decir" satisfactorio como lo llama, y ​​lo voy a usar siempre pase lo que pase.

Solo piense en ello, sin nivel, no importa cuánta autoridad tenga, simplemente no puede haber una mejor manera.

Si "dices" oye, tenemos un problema , es solo un ruido de aire. E incluso si su jefe / líder está de acuerdo y dice que tiene razón, tenemos un problema , esto no cambia nada: es solo una sacudida de aire una vez más, y no puede ser otra cosa.

• ^{Puede pensar que escribir su opinión (por ejemplo, en un correo electrónico) sería mejor, pero si lo piensa, realmente no lo es. Si su proyecto tiene una actividad sustancial de correo, lo que se escribió se perderá y se olvidará por mucho tiempo un mes después.}

Use la herramienta adecuada para el trabajo. Para el trabajo que describe, el rastreador de problemas es exactamente la herramienta correcta.

Nota el problema, lo ingresa en el sistema diseñado para rastrearlos y se encarga del resto, de la mejor manera posible, simplemente porque fue diseñado para eso :

paquete de software que administra y mantiene listas de problemas , según lo necesite una organización ... de uso común ... para crear, actualizar y resolver problemas informados por los clientes, o incluso problemas informados por otros empleados de esa organización ... Un seguimiento de problemas el sistema es similar a un " rastreador de errores " y, a menudo, una compañía de software venderá ambos, y algunos rastreadores de errores pueden usarse como un sistema de seguimiento de problemas, y viceversa. El uso constante de un sistema de seguimiento de problemas o fallas se considera una de las "características distintivas de un buen equipo de software" ¹ ...

Cualquier otro medio que desee elegir para comunicarse, tener un ticket en el rastreador solo lo hará más fácil para usted.

Incluso si prefieres sacudir el aire , decir "Me gustaría discutir TICKET-54321 ..." es un punto de partida más sólido que "Escucha, me gustaría hablar sobre algún código que traté hace un tiempo ... "Y puede pasar con seguridad las referencias al ticket por correo: incluso si el correo se pierde, el problema seguirá ahí en el rastreador, con todos los detalles que deseaba contar.

Lo que me hace sentir mal por su escenario es exactamente lo que escribió en el título y varias veces en el texto de la pregunta:

Eres el desarrollador más bajo de la cadena

¿Por qué es tan importante ese punto? Bueno, antes que nada, y desde un punto de vista puramente técnico, ciertamente tienes razón. Usted es contratado como lo que llama un "implementador" de las cosas, una abeja obrera que actúa según los comandos dados.

Pero incluso si usted es el desarrollador más bajo en cuanto a rango, esto aún no es del todo correcto. La clave aquí es darse cuenta de que solo te estás percibiendo a ti mismo como el desarrollador más bajo. ¿Alguna vez has tratado de superar esa autopercepción y realmente asumir la responsabilidad de algo ?

¡Tomar! No esperes, hasta que alguien te haga responsable.

• Usted ve el problema, pero no tiene nada que decir al respecto.
• No estoy cuantificando la deuda técnica ni buscando herramientas.
• Estás encerrado en tus tareas. No se le paga por hacer más.
• No es tu llamada. No eres gerencia.

Por lo general, es todo lo contrario: se le paga más y se respeta más su opinión, una vez que demuestra que vale la pena . Es "hacer antes tener", no al revés.

Lo que espero de las personas dentro de mi equipo es exactamente eso: un sentido de responsabilidad por el proyecto o producto que estamos tratando de construir y por todos los procesos relacionados con ese esfuerzo. Cada vez que alguien en mi equipo me impresiona asumiendo la responsabilidad, por ejemplo, proponiendo mejoras o incluso mejor para comenzar a mejorar las cosas por su cuenta, estas son las personas que serán promovidas.

Para decirlo de otra manera: nadie promueve las abejas obreras, las personas esperan pasivamente que se les asignen tareas, sin siquiera el más mínimo destello de iniciativa " porque no se les paga ", y finalmente se quejan de que nunca tuvieron la oportunidad.

Por supuesto, todo esto nuevamente depende de la cultura de su empresa, con lo que Joel se relaciona en las "Dos historias" vinculadas por Arthur. Si los gerentes de la compañía son realmente tan estúpidos como para impedir que su propia gente progrese, entonces la tasa de fluctuación probablemente ya sea muy alta y puede ser hora de sacar conclusiones de eso. Pero si ese no es el caso, el verdadero problema podría estar dentro de usted.

Eres un profesional Su empleador lo contrató para ser profesional. Por lo tanto, trate sus inquietudes de la misma manera en que desearía que los profesionales que contrata para tratar sus opiniones profesionales . En particular, espera que otros profesionales realicen las optimizaciones y correcciones necesarias en el camino, siempre que esas optimizaciones no aumenten inesperadamente el costo.

Por ejemplo, suponga que lleva su automóvil a un mecánico para que le reemplace una lámpara. El mecánico nota cuatro cosas:

1. El cable que conduce a la lámpara está deshilachado y peligroso. Pero, se puede recortar sin aumentar notablemente el costo. Es de esperar que se tome unos minutos para cortar el cable, posiblemente sin siquiera notarlo.
2. Un perno está suelto. No tiene ninguna relación, simplemente lo vio. Son 20 segundos de su tiempo para tomar el controlador necesario y apretarlo; entonces, esperarías que lo haga.
3. El chasis de la lámpara está agrietado, lo que hará que la lámpara vibre. Es costoso reemplazarlo. Y no es esencial. Por lo tanto, lo llama para preguntar al respecto; si dice "no", le recomienda por escrito el resumen de su visita.
4. Hay una buena cantidad de líquido de frenos debajo del automóvil. Debería, e incluso puede ser requerido como profesional, evitar que use el automóvil hasta que permita que alguien repare la fuga.

Cada uno de estos escenarios, y estoy seguro de que otros, tienen paralelos en el desarrollo de software, especialmente si te consideras un profesional de cualquier nivel . Como profesional, con muy pocas excepciones, su trabajo es alcanzar el objetivo final de mejorar el producto de una manera particular de acuerdo con su comprensión profesional .

1. Si la solución es trivial, ya sea que no esté relacionada o no, realice la solución.
2. Si la solución no es trivial e innecesaria, haga una recomendación formal utilizando cualquier mecanismo formal de comunicación / seguimiento de problemas que haya acordado.
3. Si se puede argumentar que la solución es necesaria para llevar a cabo la tarea principal, pero que inesperadamente aumentará el costo, comunique el cambio de alcance.
4. Si el problema identificado representa una seria amenaza para el éxito del proyecto, aclare eso. Formalmente. Si existen preocupaciones éticas para permitir que el problema no se solucione (como en los sistemas de salud, emergencia o transporte), insista en abordar el problema antes de que se envíe el producto (notifique a los medios de comunicación o a las autoridades si es éticamente necesario).

Usted hace esto de la misma manera que un empleado de una oficina de abogados lucha contra el comportamiento poco ético, un trabajador de comida rápida lucha contra el comportamiento antihigiénico, o un oficial de seguridad de estacionamiento lucha contra la corrupción policial.

1. Se un buen ejemplo. En la medida de lo posible, produzca código limpio y sensible. Cuando tenga la opción, elija la que satisfaga sus requisitos con menos inconvenientes. (Tenga en cuenta que la deuda técnica no es diferente a la deuda hipotecaria, solo tenerla no es necesariamente algo malo).
2. Comunica tus inquietudes . Debe tener a alguien, ya sea un líder de equipo o un cliente o arquitecto, que tenga la responsabilidad real de administrar la deuda técnica y asignar los recursos de su empresa. Cuando vea algo que cree que es malo, comuníqueles su preocupación. Póngalo por escrito (es decir, un correo electrónico) si no está seguro de que entenderán, responderán y darán crédito por sus comentarios.
3. No te estreses. La deuda técnica rara vez causa el fracaso laboral de una empresa. Mientras haya comunicado sus inquietudes y esté haciendo su trabajo, los problemas de arquitectura, como la deuda técnica, literalmente no son su problema. Sí, pueden afectarlo, pero no son más su preocupación que la reelección de un alguacil es la preocupación de un oficial de policía menor.

En el ejemplo que proporcionó, con una addfunción que ha sufrido un deslizamiento completo de las características, tómese unos minutos y redacte el esquema de lo que lo mejoraría. Envíe eso a quien necesite aprobación para implementarlo y continúe.

Suponiendo que su empresa sea administrada por personas extremadamente competentes y estructurada correctamente, su inquietud se dirigirá al diseñador de sistemas adecuado para que tome una decisión o se le dará margen para implementar su sugerencia. Como desarrollador junior, me preocuparía más aprender cómo funciona su empresa que la deuda técnica, y si conoce el primero, cómo manejar el último debería ser obvio.

Nunca he oído hablar de una organización que no quería que participaran sus empleados. Dices que solo te pagan por hacer las tareas. Dudo sinceramente que tenga las tareas correctas en mente. Porque te pagan por escribir un buen software.

Toma esta responsabilidad. Di no a agregar funciones si no puedes soportar la base. Asesora al cliente con tu experiencia. Pise los frenos ahora, antes de que sea demasiado tarde y tenga que tirar todo el proyecto, porque ya no será mantenible.