Puedo entender la presión del horario. Desea complacer a sus usuarios, ya que son el alma de la empresa. Sin embargo, también es cierto que ciertos cambios harán que todo sea más fácil en el futuro. Desafortunadamente, la gerencia de mi organización tiene una resistencia instintiva a tales cambios y esta resistencia es tan fuerte que se interpone en el camino de las mejoras a largo plazo.

Por ejemplo, Apple presentó recientemente el Conteo automático de referencias para programas iOS. Esta es una mejora importante sobre las llamadas manuales de retención / liberación que antes tenía que usar. El código es más fácil de escribir y más fácil de mantener. El cambio en sí es probable que produzca algunos bloqueos. Pero una vez que se resuelvan, es probable que disminuya la cantidad de accidentes extraños al azar.

Recientemente le mencioné a mi jefe que quería cambiar al conteo automático de referencias. Su respuesta fue que quería concentrarse en mejoras visibles. Es probable que esta respuesta haya sido impulsada a su vez por la presión que está recibiendo por encima de él, y probablemente directamente del CEO.

Hay muchos ejemplos similares. El hilo común es que hay que arreglar algo, pero los costos a corto plazo de la solución son mayores que los beneficios a corto plazo, donde "corto plazo" se define como "dentro de las próximas semanas".

¿Cómo debo manejar la situación?

EDITAR: Gracias por las respuestas. Sigue viniendo. Debido a que es relevante para mi situación, debo dejar en claro que mi gerente y el CEO son programadores, aunque el CEO ya puede haber olvidado cómo es esto. Aparentemente, sus lados programadores han sido abrumados por otras presiones.

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 software con 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, tomará más tiempo preparar la comida. Sin embargo, la forma más rápida de preparar la próxima comida es evitar el desastre. Limpiar la cocina y mantenerla limpia retrasará la próxima comida, pero mejorará la entrega de todas las comidas posteriores. 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 tardan más y cuestan más.

Te has topado 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 arquitectónicos allí, este módulo se está volviendo imposible de mantener, etc. Debido a la cultura actual de su organización, sin embargo, se le está presionando para centrarse en un 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 así como un iceberg está 90% bajo el agua, también lo es 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 entender por qué pasó seis horas refactorizando las llamadas de mantenimiento / liberación y referencia automática cuando no pueden ver ninguna diferencia y todo funciona bien.

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

• La gerencia, a menos que sean programadores , no comprenderá 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 hechos y algunos datos concretos de por qué debería dedicar tiempo a este y otros problemas de Iceberg.

No olvides que eres un hombre (o mujer) de la compañía. No es un hombre de código. Está desarrollando este producto para una empresa que tiene un interés personal en su éxito o fracaso; sus proyectos y propuestas de proyectos deberían reflejar esto. Muestre su pasión por la empresa y el producto, demuestre su conocimiento y demuestre a su jefe y CEO que deben confiar en usted cuando se acerque a ellos y diga que Algo necesita trabajo. Muéstreles cómo contribuirá al resultado final, ya sea agregando valor al producto (más personas comprando copias) o ahorrando tiempo en el futuro (menos clientes enojados cuando su producto falla).

Usted no

Veo esta pregunta y todas las preguntas como un callejón sin salida. No se puede "convencer" a la gente de nada. Si aún no están al tanto de cosas como esta o lo están investigando, lo más probable es que no den una vuelta. Y ninguna cantidad de datos los convencerá de lo contrario. El cambio debe venir de adentro. Puedes llevar un caballo al agua pero no puedes obligarlo a beber.

Digo que hornee los cambios deseados en sus próximas estimaciones técnicas. Oye, oye, "tenemos que" actualizar a este nuevo marco que Apple presentó. No permita que no use ARC en su hoja de ruta. No hay opciones migrar a ARC es la única forma.

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 en que hace que el código sea más limpio es seguir la regla del 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 empiece a ver "islas de limpieza". Una vez que tenga un impulso significativo, otros desarrolladores del equipo comenzarán a darse cuenta y eventualmente contribuirán a la tarea.

Sugeriría leer el 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 gerencia entienda. Números que muestran cuánto tiempo se ahorrará al implementar estas mejoras, cuántos menos "accidentes extraños aleatorios" ocurrirán, etc. Convénzalos de que los accidentes son visibles para el usuario final y que todo lo que se haga para evitarlos es bueno para los negocios.

También podría intentar implementar estas mejoras en su propio tiempo (es decir, fuera de las horas de trabajo) y luego mostrar los beneficios a la gerencia después. Solo haría esto cuando esté claro que la gerencia no comprende lo que está tratando de transmitir y / o que no quiere asignarle tiempo para que incluso lo intente.

¡Buena suerte!

Presentar 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 de costo / beneficio. Esto no solo es un argumento convincente, sino que también le da a tus jefes algo para llevar a sus superiores.

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

Al hacer un caso de negocios, siempre debe respaldar su argumento con datos.

• ¿Cuánto tiempo pasa el desarrollo actualmente tratando con 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 una ecuación aproximada pero simple. Le costará a X hacerlo y beneficiará a la empresa Y.

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

Este tipo de cambio cae en la categoría de refactorización. El enfoque ágil sería que debería incorporar un tiempo de refactorización AMPLIO en cada historia que estima 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.

Por lo tanto, la próxima vez que tenga mucho trabajo por hacer, asegúrese de que estos cambios sean parte de ello. Si proporciona estimaciones, asegúrese de agregar un 30% a su estimación para la refactorización, si no proporciona estimaciones, simplemente realice la refactorización como parte de su trabajo.

Puede hacerlo más lento, bueno, no, esa no es la forma de verlo, la forma de verlo es que su velocidad actual es una ilusión, esencialmente una mentira que está pasando por la cadena, en realidad debería ser un un poco más lento debido a este trabajo que sabes que hay que hacer.

Probablemente podría construir casas más rápidamente si no usara el concreto como base, y se vería tan bien para el cliente pero, bueno, incluso si el cliente no ve la necesidad de la base, el constructor necesita. (Esto es en realidad un paralelo interesante porque resulta que los constructores no siempre hacen lo que saben que deben hacer, por lo que debemos aprobar leyes para obligarlos a hacerlo; no existen tales leyes que rijan el desarrollo de software a pesar de que enfrentamos lo mismo decisiones y a menudo toman las equivocadas ...)

Usted menciona que tiene la suerte de que su gerente y CEO sean ambos programadores. Por lo que probablemente no entienden lo que es la deuda técnica.

Debe manejar la situación tratando de resolverla en función de los hechos, lo que significa que existe una posibilidad real de que no termine haciendo las mejoras técnicas que desea (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 visibles del código cuando los beneficios se acumulan en áreas del negocio " oculto "de los desarrolladores.

Es bueno si su gerencia 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 determinación de todos modos. Así que explicártelo no hace mucho por el negocio, excepto mantenerte feliz. Y en cierto modo, insistir en que lo hagan no es confiar en que hagan su trabajo. Si no te gusta cuando te microgestionan, entonces debes entenderlo.

Por lo tanto, siempre y cuando los mantenga al tanto del estado de todas las deudas técnicas y los costos y beneficios de ignorarlas en lugar de pagarlas, habrá hecho su trabajo. A menos que realmente no confíe en la administración para hacer lo suyo, en cuyo caso tiene un problema mucho mayor que sería otra cuestión que abordar.

Quizás esta no sea una respuesta, sino una respuesta basada en los errores que he cometido. También un desacuerdo con algunas de las filosofías que leí aquí.

• No caigas en la creencia de que el programador sabe mejor.
• Se honesto. Vuelva a factorizar a medida que avanza, pero no mienta y anote las estimaciones para sus propios fines.
• No eres dueño del código. No emprendas trabajos que no estén aprobados por el líder.
• Podrías tener razón sobre algo; podrías estar equivocado ... pero debes hacer lo que te pagan por hacer.

Pero sin duda, siga los excelentes consejos dados para mejorar las cosas.

Obviamente trabajas para un jefe de pelo puntiagudo (PHB). Ya no programa más, si es que lo hizo, y si lo hizo, probablemente no fue realmente bueno (aunque le gusta incluir frases como "corrección constante" y "falla de segmentación" para que los chicos sepan que se ha ganado la fama) ) - así es como se destacó para la administració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 (ligeramente 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, C implementó una base de datos local que nadie en el equipo de desarrollo se atrevió a tocar porque fue escrita por una de las antiguas leyendas de desarrollo de la guardia hace 10 años y hace TODO con macros con nombres de 5 letras, ya sea que necesiten 5 letras o no).

Los programadores que realmente hacen el "bit de trabajo" (ya sabes ese bit que sucede, inconvenientemente después de todo el trabajo real como dibujar círculos en pizarras blancas, gritar y comer Battenburgs en miniatura está hecho) saben que en un sistema cuerdo el trabajo que acaba de tomar 10 hombres 10 días para salir laboriosamente de la jungla sin mantenimiento, probablemente equivaldría a uno o dos días hombre, incluidas las pruebas. Pero obtener el sistema de donde está sano puede llevar 6 meses de trabajo realmente duro, con pocas recompensas externas obvias.

El PHB sabe que en 6 meses, por las buenas o por las malas, puede obtener treinta o cuarenta nuevas funciones en la aplicación que los vendedores (que deben ser magos dado lo que realmente están vendiendo) pueden usar para tentar nuevas compras y actualizaciones .

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

La conclusión a la que he llegado es que la única forma de salir del atolladero es trabajar en una nueva empresa, con algunas personas que comparten su visión de cómo se debe hacer el software y luego se adhieren a esa filosofía (yo ¡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 abandonar el tipo de entorno descrito. Eventualmente, cualquier persona con la ambición o la capacidad de refactorizar ha dejado la compañía, y entonces las cosas estarán muy mal, probablemente sin solución. Desafortunadamente, no puede decirle a su gerente esto sin parecer arrogante ("Soy uno de sus mejores programadores") y un imbécil agresivo ("Me iré 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 tienen razón y ambos están equivocados, es por eso que esos problemas permanecen por mucho tiempo y crean sentimientos duros.

Las razones por las cuales están claramente establecidas anteriormente: la gerencia piensa en el dinero; o incluso más específicamente: 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 pueden generar ingresos aún mayores en el futuro en comparación con los planes a corto plazo.

No eres el administrador, no eres el responsable directo de los ingresos (supongo, por supuesto). Por lo tanto, se está mezclando (así es como se siente para la administración) con sus problemas y no se está concentrando en su trabajo: expandir aún más el software.

Todas palabras duras y claras, pero así es como surgen la mayoría de los problemas, por 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 gerente.

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

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

Para probar esto, podría hacer, por ejemplo, esta cosa bastante simple: bifurcar el software en su versión. Primero haga lo que la gerencia quiere, así que cree esa característica. Haces esto, pero el acuerdo es que tienes tiempo para mostrar la manera diferente. Luego, haga lo mismo en la nueva sucursal, pero primero solucione los problemas que desea eliminar. Entonces también desarrolle la solución.

Ahora tiene la misma solución pero totalmente desarrollada de manera diferente. Cree un caso a partir de él, coloque las soluciones una al lado de la otra, incluida cierta información de gestió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 mejor-peor porque eso no generará la atmósfera que ambos necesitarán. Eso no mejorará su producto.

Si tiene una revisión de código, cree un ticket técnico que indique que el código debe mejorarse utilizando ARC y asígnelo al gerente.

Convencerlo. Explíquele algunos pequeños ejemplos de mejoras técnicas similares que usted hizo y sus beneficios para los proyectos.

Debe vender esos cambios de la única manera que la gerencia está dispuesta a comprar:

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

El trabajo de su jefe es 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 lleva entregar una solicitud de un cliente?
2. ¿Entregas cuando dices que lo harás?

La mayoría preferiría que diga que tomará 6 semanas y entregará en 5 en lugar de decir que entregará en 3, pero tome 4.

Tener una base de código actual que sea más fácil de administrar y mejorar le permite entregar más rápido y aumentar la previsibilidad. Si dedica demasiado tiempo a la corrección de errores, tiene menos recursos disponibles para agregar nuevas funciones. Evalúe la cantidad de recursos gastados en arreglar el código y qué tan preciso es en las promesas de características. 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ó de las manos debido a la inercia administrativa.

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

Dicho esto, es importante entender quién debería tener esa conversación con el cliente. En general, tiene a su gente de desarrollo de negocios junto con algunos diseñadores principales haciendo 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 al día en sus campos, porque habrá competencia que lo superará si no lo hace.

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 compañía era que esto nos obligaría inmediatamente a una posición competitiva, mientras que la modificación del producto existente permitió a nuestro cliente continuar con nosotros sin la obligación legal de hacerlo 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 gerencia no tuvo más remedio que cerrar el negocio o competir. (La mayoría de los que fueron bloqueados eventualmente fueron despedidos). Competimos y pudimos recuperar el negocio con el hilo más fino.

Al principio dije que esta oportunidad casi se nos escapó de las manos. 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 una competencia real.

La conclusión que estoy ofreciendo es esta: siempre trate de mantenerse a la vanguardia en sus capacidades personales. Desarrolle siempre un producto que sea flexible y que pueda adaptarse rápidamente a lo que su cliente necesita. Si trabaja demasiado para una compañía que no piensa así, se marchitará y su motivación personal disminuirá. Lo he visto suceder.

Cuando tenga una idea para mejorar su producto por cualquier razón, hágase estas preguntas: - ¿Es esto lo que creo que quiere el cliente? ¿Puedo validar mis pensamientos sobre el desarrollo del producto contra la voz del cliente? ¿Mi empresa está en condiciones de atender las necesidades del cliente? ¿Si es así, cómo? - Entonces debería estar en posición 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 de negocios. Si desea obtener una respuesta adecuada a una propuesta comercial, 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.

Debe aprender cosas como los costos de oportunidad, el ROI (retorno de la inversión) y el VPN (valor presente 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 costos generales y el potencial de ingresos. Si puede hacer un argumento claro de que una ruta proporcionará más valor que otra utilizando números fijos, obtendrá la atención total de la administración.

Cuando era un desarrollador nuevo en un equipo muy pequeño, hice muchas de estas mejoras en mi tiempo libre. Me gustó mucho; Me conectaba y probaba nuevas técnicas interesantes mientras estaba sentado en la sala de estar con mi esposa por la noche. Cuando llegué a ser un desarrollador senior y luego gerente de un equipo más grande, mi tiempo libre desapareció. Trabajábamos horas extra solo para obtener las características y las soluciones críticas. Se hizo realmente difícil justificar pasar el tiempo de alguien 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 del crecimiento futuro, mantener comprometido a un equipo de desarrollo talentoso, etc. Si lo hacen, tiene grandes problemas. Lo que podrían necesitar, sin embargo, es un plan. Porque en este momento supongo que tienen todo tipo de planes, horarios, hojas de ruta, promesas y presiones en el lado de "agregar funcionalidad", que compiten contra las meras ilusiones y las solicitudes abiertas del equipo de desarrolladores.

Una cosa que podría intentar es hacer un plan documentado. Vea si puede vincularlo a versiones o salir de los criterios para una nueva funcionalidad. Una solicitud de "pasar un tiempo rehaciendo el recuento de referencias" puede ser difícil de aprobar para su jefe, pero programar un bloque de tiempo de 5 días dentro de 4 semanas podría ser más fácil. Básicamente, sin embargo, verá que las nuevas características están planificadas y programadas, intente imitarlo o inyecte una parte "oculta" en él.

Comience con poco, pidiendo un 5% de tiempo asignado a ese tipo de cosas, y luego construya gradualmente sus propias prioridades de hoja de ruta de tecnología, y continúe enchufándose para justificar el caso comercial, el ROI, los niveles de riesgo, etc. en cada uno de ellos. Muy pronto, incluso podrá probar los desafíos de sus jefes, ya que rápidamente encontrará muchas más ideas geniales de las que tiene tiempo para hacer.

¡Buena suerte!

He aquí por qué se rechaza su solicitud de recuento automático de referencias:

1. No es una mejora . Una vez que tenga algo más grande que Hello World, cualquier cambio irá en la dirección equivocada. Ninguna cantidad de refactorización cambiará el hecho de que si necesita hacer cambios, siempre irá en la dirección equivocada. El truco es saber cuándo sus cambios son lo suficientemente significativos como para que 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 el riesgo.
2. El conteo de referencias es una característica completamente loca. Viste a alguna gran compañía famosa existente implementar alguna característica, e inmediatamente pensaste que necesitabas la misma característica. Bueno, es muy probable que su base de código sea completamente diferente de lo que Apple está usando. Probablemente el conteo de referencias no va a funcionar, o es solo una pérdida de tiempo. Debería encontrar una forma diferente que no requiera difundir primitivas de conteo de referencias en todas partes de su código. Probablemente su plan de recuento requiera miles de modificaciones en la base de código, la mayoría de esos cambios no son necesarios. Solo una pérdida de tiempo y dinero.
3. Estás resolviendo el problema equivocado. La gerencia generalmente sabe qué tipo de problemas hay en el sistema. Algún problema de pérdida de memoria irrelevante que la solución de recuento está resolviendo no es uno de ellos. Concéntrese en problemas reales y no en algunos problemas imaginarios sobre cómo las computadoras manejan la memoria.
4. Implementarlo lleva demasiado tiempo. Apple es una compañía un poco más grande que su equipo insignificante con pocos programadores y algunos gerentes. Pueden hacer grandes cambios simplemente pagando 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 costoso; agregar costos innecesarios no va a ayudar un poco. Una característica irrelevante, como la administración de memoria, abrirá las compuertas: después de que lo aprueben, la mitad de sus 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. Suelta la función
2. Descubre cuál es el verdadero problema
3. Comienza a hacer algo útil
4. Planifique cuidadosamente cómo usa su tiempo
5. Descubra cómo sus mejoras aportan 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.