Realmente estás hablando de deuda técnica . Tal vez una metáfora ayudaría a sus gerentes. A menudo comparo el efecto de la deuda técnica en el software para cocinar en una cocina sucia. Si el fregadero, los mostradores y la estufa están llenos de platos sucios y hay basura en el piso, se necesita más tiempo para hacer una comida. Sin embargo, la forma más rápida de preparar la próxima comida es evitar el desorden. Limpiar la cocina y mantenerla limpia retrasará la próxima comida, pero mejorará la entrega de todas las comidas subsiguientes. Y así como la persona hambrienta en el comedor no puede ver la cocina desordenada y no entiende por qué quiere limpiar antes de comenzar a cocinar, su gerencia no puede ver el desorden en el código. Debe mostrarles el desorden o mostrar los problemas de calidad y los retrasos causados por el desorden.

Quizás también podría hablar sobre tareas urgentes y tareas importantes. Cuando no se realizan tareas importantes, las tareas urgentes toman más tiempo y cuestan más.

Ha tropezado con algo que afecta a los programadores en todas partes en algún momento de sus carreras: este código debe ser refactorizado, hay problemas de arquitectura allí, este módulo se está volviendo inalcanzable, etc. Porque de la cultura actual de su organización, sin embargo, está siendo empujado a centrarse en el trabajo que solo produce beneficios directamente visibles .

Es el clásico Iceberg Secret de nuevo. El secreto tiene que ver con el hecho de que al igual que un iceberg está 90% debajo del agua, la mayoría de los proyectos de desarrollo : el 90% del trabajo será completamente invisible para el usuario final. . Ese código tendrá un impacto en el usuario final, pero la administración tiene problemas para pensar por qué pasó seis horas refactorizando las llamadas de mantenimiento / liberación y de referencia automática cuando no pueden ver ninguna diferencia y todo está Trabajando bien, bien.

Aquí hay algunos datos que puede llevar con usted sobre este tema.

• La administración, a menos que ellos mismos sean programadores , no van a entender el Secreto de Iceberg.
• Este es un problema de ignorancia, no de malicia. El CEO quiere un buen producto, simplemente no entiende todo lo que implica un buen producto.
• El CEO (y su jefe directo) no son estúpidos: estudie y prepare algunos datos y algunos datos concretos sobre por qué debería dedicar tiempo a esto y otros problemas relacionados con los icebergs.

No lo olvides, eres un hombre de compañía (o mujer). No un hombre código. Está desarrollando este producto para una empresa que tiene un gran interés en su éxito o fracaso: sus proyectos y propuestas de proyectos deben reflejar esto. Muestre su pasión por la compañía y el producto, demuestre su conocimiento y demuestre a su jefe y director general que deben confiar en usted cuando acuda a ellos y decir que algo necesita trabajo. Muéstrales cómo contribuirá a los resultados finales, ya sea agregando valor al producto (más gente comprando copias) o ahorrando tiempo en el futuro (menos clientes enojados cuando tu producto falla).

No lo haces.

Veo esta pregunta y todas las preguntas parecen un callejón sin salida. No puedes "convencer" a la gente de nada. Si aún no son conscientes de cosas como estas o las están investigando, es probable que no den la vuelta. Y ninguna cantidad de datos los convencerá de lo contrario. El cambio debe venir desde dentro. Puedes llevar un caballo al agua pero no puedes hacerle beber.

Digo que los cambios deseados se conviertan en tus próximas estimaciones técnicas. Sea como, hey, "tenemos que" actualizar a este nuevo marco que Apple introdujo. No permita que el uso de ARC esté en su hoja de ruta. No hay opciones; la migración a ARC es la única manera.

He respondido una pregunta similar aquí antes, por lo que esto podría considerarse un duplicado. Básicamente, no vas a obtener la aprobación para hacer un "esfuerzo de refactorización". La forma de hacer que el código sea más limpio es seguir la regla de boy scout: siempre deje el código más limpio cuando lo deje que cuando llegó.

Al igual que pagar una deuda real puede parecer una tarea insuperable (o limpiar una casa desordenada). El truco es hacerlo mejor pieza por pieza hasta que empieces a ver "islas de limpieza". Una vez que tenga un impulso significativo, otros desarrolladores en el equipo comenzarán a darse cuenta y eventualmente contribuirán a la tarea.

Le sugiero que lea Clean Coder del "tío" Bob Martin. Escribir un buen código es parte de tu trabajo. No pides permiso para hacer tu trabajo, simplemente lo haces.

Al igual que con otras preguntas de esta naturaleza, debe proporcionar números que la administración entienda. Los números que muestran cuánto tiempo se ahorrará al implementar estas mejoras, cuántos menos "choques extraños aleatorios" se producirán, etc. Convénzalos de que los choques son visibles para el usuario final y que todo lo que se haga para evitarlos es bueno para el negocio.

También puede intentar implementar estas mejoras en su propio tiempo (es decir, fuera del horario laboral) y luego mostrar los beneficios a la administración. Solo haría esto cuando esté claro que la administración no entiende lo que intenta transmitir y / o que no quieren asignar tiempo para que usted incluso lo intente.

¡Buena suerte!

Presente un caso de negocios

Hay muchas razones por las que las recomendaciones de los ingenieros a menudo se ignoran. La mejor manera de lidiar con casi todas las razones es presentar el caso comercial de por qué debería hacerse. El clásico análisis costo / beneficio. Esto no solo constituye un argumento convincente, sino que también les brinda a sus jefes algo para llevar a sus superiores.

• ¿Cuál es el costo inicial?
• ¿Cuál es el costo continuo?
• ¿Cuáles son los ahorros de dinero / tiempo proyectados y de dónde vienen?
• ¿Cuánto tiempo pasará antes de que veamos el ROI?

Al hacer un caso de negocios, siempre debe hacer una copia de seguridad de su argumento con datos.

• ¿Cuánto tiempo está gastando actualmente el desarrollo para resolver problemas que esto eliminará o mitigará?
• ¿Cuántas quejas de los usuarios se relacionan con los problemas que esto eliminará o mitigará?
• ¿Qué otros beneficios tendrá?

Alinea los números y haz que sea una ecuación aproximada pero simple. Le costará a X hacer y beneficiará a la empresa Y.

Nota: No se sorprenda si es prohibitivamente costoso implementar una idea académicamente buena.

Este tipo de cambio cae dentro de la categoría de refactorización. El enfoque ágil sería que deberías incorporar AMPLIO tiempo de refactorización en cada historia que estimas y esto es exactamente por qué. Aparte de los ingenieros, nadie va a entender por qué quieres hacer esto y está bien, no es su trabajo determinar cómo codificar correctamente, es tuyo.

Así que la próxima vez que tenga mucho trabajo por hacer, asegúrese de que estos cambios sean parte de él. Si está proporcionando estimaciones, asegúrese de agregar un 30% a su estimación para refactorización, si no está proporcionando estimaciones, simplemente haga la refactorización como parte de su trabajo.

Puede hacerte más lento - bueno, no, esa no es la forma de verlo, la forma de verlo es que tu velocidad actual es una ilusión, esencialmente una mentira de que estás pasando la cadena, en realidad debería ser un poco más lento debido a este trabajo que usted sabe que se debe hacer.

Probablemente podría construir casas más rápidamente si no usara el concreto como base, y se verían igual de bien para el cliente, pero bueno, incluso si el cliente no ve la necesidad de la base , el constructor lo necesita. (Este es en realidad un paralelo interesante porque resulta que los constructores no siempre hacen lo que saben que deberían hacer, por lo que debemos aprobar leyes para obligarlos a hacerlo. No hay leyes que rijan el desarrollo de software, aunque nos enfrentamos a lo mismo. decisiones y muchas veces las equivocadas ...)

Usted menciona que es lo suficientemente afortunado de que su gerente y su CEO sean programadores. Por lo tanto, probablemente sí entienden qué es la deuda técnica.

Debes manejar la situación al tratar de resolverla en base a los hechos, lo que significa que existe una posibilidad real de que no termine haciendo las mejoras técnicas que deseas (los hechos pueden ser molestos de esa manera).

Su trabajo es asegurarse de que entiendan los costos y beneficios de pagar cualquier deuda técnica particular en la que incurra. Su trabajo es decidir si el mejor uso de los recursos es pagarlo o hacer otra cosa.

Así como puede ser difícil para las personas que no están involucradas con el código ver los beneficios de mejorar las cosas "ocultas", puede ser difícil para los programadores ver los beneficios de los cambios de código visibles cuando los beneficios se acumulan en áreas del negocio algo "oculto" de los desarrolladores.

Es bueno si su administración puede explicarle por qué las características visibles valen más su tiempo que pagar la deuda técnica, pero en realidad, no es su trabajo tomar la decisión de todos modos. Por lo tanto, explicárselo a usted no hace mucho por el negocio, excepto mantenerlo contento. Y, en cierto modo, insistir en que lo hagan no es confiar en que hagan su trabajo. Si no te gusta cuando te administran en micro, debes entenderlo.

Entonces, mientras los mantengas al tanto del estado de todas las deudas técnicas y los costos y beneficios de ignorarlos en lugar de pagarlos, has hecho tu trabajo. A menos que realmente no confíe en la administración para hacer la suya, en cuyo caso tiene un problema mucho más grande que sería otra cuestión que abordar.

Tal vez esto no sea una respuesta, sino una respuesta basada en errores que he cometido. También un desacuerdo con algunas de las filosofías que he leído aquí.

• No se oponga a la creencia de que el programador sabe mejor.
• Sé honesto. Re-factor a medida que avanza, pero no mienta ni rellene las estimaciones para sus propios fines.
• No eres dueño del código. No realice trabajos que no estén aprobados por el líder.
• Podrías tener razón en algo; podría estar equivocado ... pero debe hacer lo que le pagan por hacer.

Pero ciertamente siga los excelentes consejos dados para mejorar las cosas.

Obviamente, trabajas para un jefe de pelo puntiagudo (PHB). Él no programa más, si es que lo hace, y si lo hizo, probablemente no fue realmente bueno (a pesar de que le gusta escribir frases como "const. Corrección" y "falla de segmentación" para que los muchachos sepan que se ha ganado la raya). ) - así es como se destacó para la gestión.

Al CEO (que prácticamente tiene un Mohawk) le gusta el PHB porque el PHB ofrece características . Cada sprint muestra con orgullo una nueva casilla de verificación (un poco desalineada, con una etiqueta ambigua), un ícono brillante (que aún no funciona en ningún entorno pero el color de 8 bits sobre Citrix) y una forma (que tiene bloqueos aleatorios debido a las condiciones de la carrera) en la variante xml a medida, la C basada en la base de datos implementó que nadie en el equipo de desarrollo se atrevería a tocar porque fue escrito por una de las antiguas leyendas de los desarrolladores hace 10 años y TODO lo hace con macros con 5 nombres de letras, ya sea que necesiten 5 letras no).

Los programadores que realmente hacen el "bit de trabajo" (usted sabe lo que sucede, inconvenientemente después de todo el trabajo real como dibujar círculos en pizarras blancas, gritar y comer Battenburgs en miniatura está listo) saben que en una sensata el trabajo que tomó 10 días 10 días para arrancar laboriosamente la jungla no mantenida, probablemente equivaldría a uno o dos días, incluida la prueba. Pero obtener el sistema de donde está para estar sano podría llevar 6 meses de trabajo realmente duro, con poca recompensa externa obvia.

El PHB sabe que en 6 meses, por gancho o por ladrón, puede obtener treinta o cuarenta nuevas características en la aplicación que los vendedores (que deben ser magos dado lo que realmente están vendiendo ) se puede utilizar para tentar a nuevas compras y actualizaciones.

Sin embargo, para otorgarle al PHB sus cuotas: sin esas casillas de verificación y formularios, las ventas pueden estancarse o disminuir, un competidor puede ganar cuota de mercado, y eso podría ser peor que la alternativa.

La conclusión a la que he llegado es que la única manera de salir del atolladero es trabajar en una nueva empresa, con algunas personas que compartan su visión de cómo se debe hacer el software y que luego sigan atentamente a eso. filosofía (todavía estoy trabajando para llegar allí)

Hay otro costo oculto que no se menciona en otras respuestas. Es decir, que los buenos ingenieros tienden a dejar en el tipo de ambiente descrito. Eventualmente, cualquier persona con la ambición o la capacidad de refactorizar abandonará la empresa, y entonces las cosas estarán muy mal, probablemente no se podrán arreglar. Desafortunadamente, no puede decirle esto a su gerente sin parecer arrogante ("Soy uno de sus mejores programadores") y un imbécil agresivo ("Me marcharé si no hace lo que quiero"). Sin embargo, recuerde mencionarlo en su entrevista de salida para asegurarse de que no se le vuelva a contratar.

Ambos están en lo correcto y en lo incorrecto, es por eso que esos problemas se mantienen durante mucho tiempo y crean sentimientos duros.

Las razones por las que se indican claramente arriba: la gerencia piensa en dinero; O incluso más específicamente: los ingresos. Para ellos, algo que tiene un costo pero no tiene visibilidad directa para el cliente no agrega ingresos, por lo que es un mal plan.

Su visión también es correcta: será buena para los clientes, pero a largo plazo. Sus acciones podrían generar un ingreso aún mayor en el futuro en comparación con los planes a corto plazo.

Usted no es el administrador, usted no es el responsable directo de los ingresos (supongo que por supuesto). Así que estás confundiendo (así es como se siente la administración) con sus problemas y no te estás enfocando en tu trabajo: expandiendo aún más el software.

Todas las palabras claras y difíciles, pero así es como surgen la mayoría de los problemas, errores de comunicación. Ambos quieren lo mismo, pero sus decisiones a corto plazo se toman de manera diferente. Todo porque el desarrollador tiene una perspectiva diferente en comparación con el administrador.

¿Cómo resuelves este problema? Se comunican y se entienden bastante bien en una serie de cuestiones. Ese será el enfoque más probable en el compromiso y la satisfacción del cliente.

Para resolver este problema en un método de prueba estable y con futuro, acuerde algo: mida el costo de la corrección de errores en el código antiguo. Mida el tiempo que lleva, además, trabajar con el software antiguo y cómo sería con el nuevo código base.

Para demostrar esto, puedes hacer, por ejemplo, algo muy simple: ramifica el software en tus versiones. Primero haz lo que la administración quiere, así que crea esa característica. Haces esto pero el acuerdo es que tienes tiempo para mostrar la manera diferente. Luego haga lo mismo en la nueva división, pero primero corrija los problemas que desea eliminar. Luego también desarrolla la solución.

Ahora tienes la misma solución pero totalmente desarrollada de manera diferente. Cree un caso a partir de él, ponga las soluciones una al lado de la otra, incluida información de administración como la estabilidad, la cantidad de código necesaria y el código en sí.

Ahora tome un café y comience a echar un vistazo, sin debatir quién tiene la razón, sino cuál sería la influencia de ambas direcciones para la empresa. Eso creará una reunión que es realmente útil y no una discusión peor, porque no generará la atmósfera que ambos necesitarán. Eso no mejorará tu producto.

Si tiene una revisión de código, cree un ticket técnico que indique que el código debe mejorarse mediante el uso de ARC y asignarlo al administrador.

Convencerlo. Explícale algunos ejemplos de mejoras técnicas similares que hiciste y sus beneficios para los proyectos.

Debe vender esos cambios de la única forma en que la administración está dispuesta a comprar:

Encuentre una función orientada al usuario tan convincente que la administración solo tenga que tenerla, pero sería imposible hacerlo sin algunas mejoras de bajo nivel en el código.

Es el trabajo de su jefe asegurarse de que la empresa se centre en el desarrollo para entregar lo que los clientes perciben como valor agregado. Hay dos factores que pueden alterar esta percepción:

1. ¿Cuánto tiempo demora la entrega de una solicitud de cliente?
2. ¿Usted entrega cuando dice que lo hará?

La mayoría preferiría que usted dijera que tomará 6 semanas y entregará en 5 que decir que entregará en 3 pero que tomará 4.

Tener una base de código actual que es más fácil de administrar y mejorar le permite entregar más rápido y aumentar la previsibilidad. Si está gastando demasiado tiempo en la corrección de errores, tiene menos recursos disponibles para agregar nuevas funciones. Evalúe la cantidad de recursos gastados en corregir el código y la precisión con la que cuenta en las promesas de funciones. Esta es una forma de determinar si su código actual (según la filosofía de su jefe) está costando demasiado.

Permítame contarle sobre una oportunidad de $ 2 mil millones que casi se nos escapó por la inercia de la administración.

Algunos de nosotros tenemos un punto de escuchar la voz del cliente, es decir, entender lo que quiere. No siempre es lo que pide, pero si está en condiciones de conversar con su cliente, finalmente llega a un entendimiento mutuo de lo que él quiere. (Entonces él puede comenzar a pedirlo explícitamente.)

Dicho esto, es importante entender quién debe tener esa conversación con el cliente. Por lo general, tiene a su gente de desarrollo comercial junto con algunos diseñadores principales que hacen esto. Si tiene alguna competencia, puede esperar que el cliente también tenga esta conversación con ellos.

Al mismo tiempo, es importante que los desarrolladores se mantengan actualizados en sus campos, porque habrá una competencia que lo superará si usted no lo está.

En nuestra situación, teníamos un cliente existente y un producto algo efectivo basado en tecnología antigua, y el cliente necesitaba actualizaciones rápidas. Lo que realmente necesitaban era un producto de reemplazo completo, pero la mentalidad de nuestra empresa era que esto nos obligaría inmediatamente a una posición competitiva, mientras que la modificación del producto existente permitía a nuestro cliente continuar con nosotros sin que se nos exigiera legalmente que lo hiciera competitivo. Nuestra gerencia pensó que eran dueños de este mercado. El problema era que no podían mantenerse al día con las solicitudes de actualización, porque la estructura del producto existente no era lo suficientemente flexible como para actualizar.

El cliente se impacientó y comenzó a tener conversaciones con fuentes competidoras. Perdimos nuestra "propiedad" de ese mercado y un par de miles de millones de dólares en ingresos. Sin embargo, una vez que el mercado nos obligó a una posición competitiva, la administración no tuvo más remedio que cerrar el negocio o competir. (La mayoría de los que eran obstáculos finalmente fueron despedidos). Compitimos y pudimos recuperar el negocio por el hilo más delgado.

Al principio dije que esta oportunidad casi se nos escapaba. Recuperamos el negocio, por los ingresos que mencioné. Si hubiéramos estado más preparados para adaptarnos a las inquietudes del cliente al principio, no habría habido ninguna competencia real.

Lo que estoy ofreciendo es lo siguiente: siempre intente mantenerse a la vanguardia en sus capacidades personales. Siempre desarrolle un producto que sea flexible y que pueda adaptarse rápidamente a lo que su cliente necesita. Si trabajas demasiado tiempo para una empresa que no piensa así, te marchitarás y tu motivación personal disminuirá. Lo he visto suceder.

Cuando tenga una idea para mejorar su producto por cualquier motivo, hágase estas preguntas: ¿Es esto lo que el cliente quiere? ¿Puedo validar mis pensamientos sobre el desarrollo del producto contra la voz del cliente? ¿Está mi empresa en condiciones de atender las necesidades del cliente? ¿Si es así, cómo? - Entonces debería estar en condiciones de presentar un caso convincente con respecto a sus propuestas de desarrollo de productos.

El lenguaje común de los negocios en todos los campos e industrias es el dinero. El problema que está describiendo no es un problema de programación: es un problema comercial. Si desea obtener una respuesta adecuada a una propuesta de negocios, debe enmarcarla en el idioma de los negocios. Esto significa que debe poder presentar un plan de proyecto alternativo que incluya todos los costos y beneficios.

Necesita aprender sobre cosas como los costos de oportunidad, el ROI (retorno de la inversión) y el NPV (valor actual neto). No necesita un MBA para hacer esto, pero sí necesita acceso a datos que pueden no estar disponibles para usted, como los costos de mano de obra, los gastos generales y el potencial de ingresos. Si puede presentar un argumento claro de que una ruta proporcionará más valor que otra utilizando números reales, recibirá la atención completa de la administración.

Cuando era un desarrollador más nuevo en un equipo muy pequeño, realicé muchas mejoras de este tipo en mi tiempo libre. Me gustó mucho; Me conectaría y probaría nuevas técnicas interesantes mientras estaba sentada en la sala con mi esposa por la noche. Cuando llegué a ser un desarrollador más senior y luego gerente de un equipo más grande, mi tiempo libre desapareció. Estábamos trabajando horas extras solo para hacer las funciones y correcciones críticas. Se hizo realmente difícil justificar el gasto de tiempo de cualquiera en ese trabajo de limpieza regular, a pesar de que todos sabíamos lo importante que era.

Sus jefes no necesitan una explicación de lo importante que es, mantener bajos los costos de mantenimiento, reducir el costo de crecimiento futuro, mantener un equipo de desarrollo talentoso involucrado, etc. Si lo hacen, tiene grandes problemas. Lo que podrían necesitar, sin embargo, es un plan. Porque ahora mismo supongo que tienen todo tipo de planes, cronogramas, planes de trabajo, promesas y presión en el lado de "agregar funcionalidad", que compiten contra meras ilusiones y solicitudes abiertas del equipo de desarrolladores.

Una cosa que podrías intentar es hacer un plan documentado. Vea si puede vincularlo a las versiones, o para salir de los criterios para una nueva funcionalidad. Una solicitud para "dedicar un tiempo a rehacer el conteo de referencias" puede ser difícil de aprobar para su jefe, pero programar un período de tiempo de 5 días en 4 semanas a partir de ahora podría ser más fácil. Básicamente, sin embargo, usted ve que las nuevas funciones están planificadas y programadas, intente imitar eso, o inyecte una porción "debajo del capó" en él.

Comience poco a poco solicitando un 5% de tiempo asignado a ese tipo de cosas, y luego aumente gradualmente sus propias prioridades de la hoja de ruta tecnológica, y continúe conectándose para justificar el caso de negocios, el ROI, los niveles de riesgo, etc. en cada uno de ellos . Muy pronto incluso podrá conocer los desafíos de sus jefes, ya que encontrará rápidamente muchas más ideas geniales de las que tiene tiempo de hacer.

¡Buena suerte!

Este es el motivo por el que se rechaza su solicitud de conteo automático de referencias:

1. No es una mejora . Una vez que tienes algo más grande que hola mundo, cualquier cambio va en la dirección equivocada. Ninguna cantidad de refactorización cambiará el hecho de que si necesita hacer cambios, siempre va en la dirección equivocada. El truco es saber cuándo sus cambios son lo suficientemente significativos como para que aún valga la pena el riesgo de causar nuevos problemas. Su gerencia ha dicho claramente que si los usuarios finales no pueden verlo, no vale la pena correr el riesgo.
2. El recuento de referencias es una función completamente loca. Viste a una gran empresa existente que implementa alguna función e inmediatamente pensó que necesitas la misma función. Bueno, es muy probable que su base de código sea completamente diferente de lo que usa la manzana. Probablemente el conteo de referencias no va a funcionar, o simplemente es una pérdida de tiempo. Debe encontrar una forma diferente que no requiera distribuir primitivas de conteo de referencias en todo el código. Probablemente su plan de refcounting requiera miles de modificaciones en el código base, la mayoría de esos cambios no son necesarios. Solo una pérdida de tiempo y dinero.
3. Está resolviendo el problema incorrecto. La administración generalmente sabe qué tipo de problemas hay en el sistema. Algunos de los problemas irrelevantes de pérdida de memoria que la solución de refcounting está resolviendo no son uno de ellos. Concéntrese en problemas reales y no en algunos problemas imaginarios sobre cómo las computadoras manejan la memoria.
4. Lleva demasiado tiempo implementarlo Apple es una compañía un poco más grande que su equipo insignificante con pocos programadores y algunos gerentes. Pueden hacer grandes cambios con solo pagar el precio. Si se necesitan pocos millones para implementar algo, son cacahuetes. Si las pequeñas empresas intentan hacer lo mismo, se quedarán sin dinero rápidamente. El desarrollo de software ya es muy caro; Agregar costos innecesarios no va a ayudar en nada. Una característica irrelevante, como la administración de la memoria, será abrir las compuertas: después de que la aprueben, la mitad de los programadores quieren que se implemente su propia "mejora". Es una historia interminable y la compañía podría estar haciendo algo útil en su lugar.

Aquí hay algunos pasos que puede usar para manejar el problema:

1. Soltar la función
2. Averigua cuál es el problema real
3. Comienza a hacer algo útil
4. Planee cuidadosamente cómo usa su tiempo
5. Averigüe cómo sus mejoras están aportando dinero
6. Elija solo las funciones que aportan la mayor cantidad de dinero
7. Tenga en cuenta que el aspecto de programación del desarrollo de software es solo una pequeña parte de todo el sistema: las mejoras nunca valdrán la pena.