¿Desarrollar una función con el único propósito de eliminarla? [cerrado]

Se llama un pato , de una leyenda que supuestamente proviene de Battle Chess de Interplay:

  

Esto comenzó como una pieza de la tradición corporativa de Interplay. Era bien sabido que los productores (una posición en la industria del juego, aproximadamente equivalente a PM) tuvieron que hacer un cambio en todo lo que se hizo. El supuesto era que, inconscientemente, sentían que, si no lo hacían, no estaban agregando valor.

     

El artista que estaba trabajando en las animaciones de reina para Battle Chess estaba al tanto de esta tendencia y se le ocurrió una solución innovadora. Hizo las animaciones para la reina de la manera que creía que sería mejor, con una adición: le dio a la reina un pato mascota. Animó a este pato a través de todas las animaciones de la reina, lo hizo revolotear en las esquinas. También tuvo mucho cuidado de asegurarse de que nunca se superpusiera a la animación "real".

     

Finalmente, llegó el momento de que el productor revisara el conjunto de animación para la reina. El productor se sentó y miró todas las animaciones. Cuando terminaron, se volvió hacia el artista y dijo: "Eso se ve muy bien. Solo una cosa: deshacerse del pato ”.

Simplemente lo veo como una gestión que valida su propio propósito en un proyecto extendiendo el trabajo programado el mayor tiempo posible o creando un trabajo ocupado sin sentido para mantener a la gente ocupada o trabajando.

He visto esto personalmente en cinco tipos diferentes:

• Proyectos gubernamentales: muchas veces, si el proyecto de un gerente se ejecuta en un presupuesto bajo o en un tiempo limitado, entonces resultará malo para él / ella en el futuro. Pueden recibir elogios por un buen trabajo, pero corren el riesgo de que su presupuesto se reduzca el próximo año si no pueden justificarlo. Debido a la forma en que funciona el presupuesto en el gobierno, esta es la razón por la que los proyectos gubernamentales pretenden utilizar la mayor cantidad posible de su presupuesto asignado.

• Un administrador posiblemente obsoleto que tiene un gran equipo y responsabilidad por el software que es relativamente fácil de mantener o escribir. El peligro es real en el mundo corporativo de que cuando intentan arrojar un peso muerto, buscarán a los gerentes medios con la menor responsabilidad real y se mudarán de allí. Sienten que, al sobreestimar y crear un alcance innecesario, protegen sus posiciones.

• Algunas compañías de software son básicamente clubes de Good Ol 'Boy, donde tienen un software simple o heredado que encierra un mercado lucrativo pero nicho. Por lo general, el dinero es relativamente fácil, las ambiciones son relativamente bajas y todos los gerentes son mejores amigos que intentan validar el propósito de los demás mientras se llevan a casa grandes cheques de pago. El espacio para el avance es imposible en tales compañías a menos que esté conectado. A menudo, intentarán validar su propia importancia mediante la creación de un trabajo ocupado sin sentido en un problema ya bien resuelto.

• Algunos lenguajes de contrato requieren lanzamientos regulares y mejoras continuas en el software. Para un problema bien resuelto, encontrar características únicas y nuevas puede ser difícil o imposible. A menudo se asignará trabajo ocupado, tal vez para agregar algo y luego eliminarlo en la próxima versión.

• El gerente está legítimamente preocupado por mantener al equipo unido, ya sea por culpa o simplemente tratando de ser amable. Intentará validar el propósito de su propio equipo para mantenerlos empleados debajo de él.

En algunos proyectos en los que he trabajado, los hemos llamado "cobertizos para bicicletas" como un guiño al término bike arrojar el problema . Este término proviene de un pasaje del libro Ley de Parkinson , que describe que las plantas de energía nuclear son tan complicadas que los malhechores tendrían miedo de tocar cualquier cosa, pero un cobertizo para bicicletas es tan simple que todos tienen que temblar y jugar. Es para dar la apariencia de "gestionar" las cosas.

Mi jefe lo llamó la "estrategia de la fuente". Diseñó una nueva ala de computadora para una universidad con una fuente masiva en el frente. El ala fue aprobada pero sin la fuente, exactamente como estaba previsto.

Eso fue hace 50 años, así que esto no es nada nuevo.