Punto de complejidad sin retorno. ¿Cómo llamas a eso?

13

Como desarrollador de software, una de mis tareas principales es mantener la complejidad bajo control.

Sin embargo, en algunos proyectos, hay un momento en que el nivel de complejidad crece tan alto que alcanza algún tipo de punto de "no retorno". Pasado este momento, nunca podrá devolver el proyecto a un nivel aceptable de complejidad en menos tiempo del que necesitaría reescribir todo desde cero.

¿Este momento en particular tiene un nombre en el dialecto de los programadores (algo similar a la ley de Godwin para trolls)?

--editar--

Lo siento si no estoy claro. No creo que este "momento" tenga un nombre oficial, o sea una métrica seria. Estaba pensando en algo en el espíritu del "pico de Ballmer" en xkcd .

terminology Thibault J
fuente
1
Veo una controversia en su definición del punto en cuestión: ... en menos tiempo necesitaría reescribir todo desde cero , lo que implica que aquellos que van a reescribir el proyecto son lo suficientemente buenos, o al menos mejores que aquellos que creó el desastre en primer lugar;)
mojuba 05 de
1
Creo que una razón por la que no hay un nombre acordado es que depende de quién esté mirando el código. Lo que parece irremediablemente complejo o imposible de mantener para un desarrollador puede parecer bastante razonable para otro. En casos severos, simplemente compilo en una DLL con un prefijo "ms" y digo que vino de Microsoft.
Kevin Hsu
1
Quizás esto
sirva

Respuestas:

20

Es más una cuestión de mantenibilidad que de complejidad.

El fenómeno se llama "deuda técnica", y una vez que alcanza un nivel crítico, el proyecto está en camino a la bancarrota.

¿Es eso lo que querías decir?


fuente
Gracias por tu respuesta Soy consciente del concepto de "departamento técnico". Cada proyecto tiene algún tipo de deuda técnica. Lo que quiero decir es: ¿cómo calificas el momento en que esta deuda se vuelve tan alta que preferirías tirar el proyecto a la basura y comenzar de nuevo?
Thibault J
3
Me gusta su término 'bancarrota técnica'. Sugiere que, al igual que en una bancarrota real, debe observar cuidadosamente qué partes son recuperables y cuáles deben dejarse atrás. Y tal vez una reestructuración de la deuda es todo lo que realmente se necesita :)
Jaap
2
@Thibault J: No creo que haya un término específico para ese momento. Se trata más de darse cuenta de si todavía estás feliz antes de ese momento o tristemente pasaste de allí.
1
@ Developer Art: ... dándome cuenta de si todavía estás feliz antes de ese momento o lamentablemente pasaste de largo , creo que esa es la clave para dar una buena definición del punto: un proyecto que ha ido más allá del punto es algo que ningún ingeniero haría hacerse cargo voluntariamente.
mojuba 05 de
3
Iré por el término de "bancarrota técnica", me gusta. Y también usaré tu definición.
Thibault J
16

El "punto de exceso de complejidad" se conoce en inglés como:

OH DIOS MÍO QUE ES ESTA MIERDA.

El problema es que esto puede aplicarse a algo que es realmente simple, pero se implementa de una manera tan horrible que tiene la misma reacción.

Así que distinguir algo muy complejo de algo muy horrible puede ser difícil.

SIN EMBARGO: Lo que en realidad tiende a suceder a todo el software es un proceso como este:

Paso 1: Tener una buena especificación, hacer un buen diseño, implementar cosas buenas. Todo el mundo está feliz.

Al final del paso 1: los desarrolladores se felicitan por la maravillosa elegancia de su diseño y se van felices pensando "Tengo un maravilloso legado aquí para que otros agreguen cosas en el futuro, será maravilloso y el mundo será un mejor lugar."

Paso 2: Se realizan algunos cambios, se agregan cosas, se incluyen nuevas funciones. La arquitectura y la estructura del Paso 1 hicieron de este un proceso bastante sencillo. [Pero vaya, el "factor cruft" solo aumentó un poco.]

Al final del paso 2: los desarrolladores se felicitan por la maravillosa elegancia de su diseño, y se van contentos pensando "Gee, soy tan inteligente de haber tenido en cuenta todo eso en el Paso 1. Esto fue tan bien. Tengo un maravilloso legado aquí para que otros agreguen cosas en el futuro, será maravilloso y el mundo será un lugar mejor ".

Paso 3: se realizan más cambios, se agregan más cosas, se agregan más funciones nuevas, se cambian muchas cosas y se escuchan los comentarios de los usuarios.

Al final del paso 3: los desarrolladores se felicitan a sí mismos por la maravillosa elegancia de su diseño y se van bastante felices pensando "Gee, esta arquitectura es bastante buena para permitir tantos cambios que se insertan fácilmente. Pero estoy un poco infeliz sobre X e Y y Z. Ahora podrían limpiarse un poco. ¡Pero! ¡Ah! ¡Soy tan inteligente de haber hecho todos esos ajustes en el Paso 1. Esto fue tan bien. Tengo un maravilloso legado aquí para otros para agregar cosas en el futuro, será maravilloso y el mundo será un lugar mejor ".

Paso 4: al igual que el paso 3. Excepto:

Al final del paso 4: los desarrolladores piensan: "Esto es tan bueno que se está poniendo feo para mantener. Realmente necesita algunos cambios serios. Realmente no me gusta trabajar en esto. Necesita una refactorización. Me pregunto qué hará el jefe dirá cuando le diga que necesita 6 semanas y que no habrá nada para que los usuarios vean al final de esto ... pero tendré otros 5 años de delicioso alcance de modificación futura al hacer esto ... hmmm ... "Es hora de ir al pub a tomar una cerveza".

Paso 5: se deben realizar muchos cambios.

Y DURANTE el paso 5, los desarrolladores se dicen unos a otros: "Este código apesta. ¿Quién escribió esto? Deberían ser fusilados. Es horrible. Tenemos que volver a escribirlo".

El paso 5 es fatal. Aquí es donde el factor cruft se ha vuelto tan malo que el código no puede tener solo algunos cambios más, sino que debe tener algunos GRANDES cambios.

El problema en el Paso 5 es el deseo de tirarlo y comenzar de nuevo. La razón por la que esto es fatal es "El factor Netscape". Ve a google it. Las empresas MUEREN en este punto, porque comenzar de nuevo significa que comienzas con aproximadamente un 50% de suposiciones en lugar de hechos, 150% de entusiasmo en lugar de conocimiento, 200% de arrogancia en lugar de humildad ("¡Esos tipos eran tan estúpidos!"). Y presentas un montón de nuevos errores.

Lo mejor que puedes hacer es refactorizar. Cambia poco a poco. Si la arquitectura se está cansando un poco, arréglala. Añadir, ampliar, mejorar. Gradualmente. En cada paso del camino, prueba, prueba y prueba un poco más. Cambios incrementales como este significan que 10 años después el código actual y el original son como el hacha del abuelo ("tenía 10 cabezas nuevas y 3 manijas nuevas pero sigue siendo el hacha del abuelo"). En otras palabras, no queda mucho en común. Pero te moviste de lo viejo a lo nuevo de forma gradual y cuidadosa. Esto reduce el riesgo, y para los clientes, reduce el factor cabreado.

rápidamente_ahora
fuente
Apuesto a que obtendrás más votos si acortas tus pasos.
Codismo
Tengo que agregar que la mayoría de las empresas no presupuestan para esto, por lo que la refactorización siempre es demasiado poco y demasiado tarde. Gestionar la creciente entropía de los sistemas es establecer que, desde el día 1, se asigne un presupuesto (10% -20%) de cada trabajo para la limpieza. No es un presupuesto de corrección de errores. El gasto presupuestario lo decide la ingeniería, no la administración, el marketing o las ventas. Solo se usa para factorizar la entropía creada por el desarrollo, y el gasto se reduce a medida que el producto se acerca al final de su vida útil.
mattnz
Convenido. La gerencia siempre quiere recortar ese tipo de cosas. A veces puede salirse con la suya ocultándola (agregue aproximadamente un 20% a la estimación de desarrollo para hacer cualquier cosa, y cuando sea necesario refactorizar, HÁGALO).
rapid_now
1
Hay un punto en el que realmente no puedes refactorizar. Si tiene varias aplicaciones comerciales dispares que dependen de la misma interfaz o base de datos pésima, no puede arreglar muy bien las cosas subyacentes sin romper todas las otras aplicaciones que dependen de la base de mierda. En este punto, realmente estás jodido.
John Cromartie
2

Estoy de acuerdo en que el momento es difícil de reconocer y puede evitarse mediante procesos adecuados. Sin embargo, la pregunta era sobre cómo llamarlo. En la economía real, existe el concepto de "rendimientos decrecientes": el punto en el que el aumento de los insumos para un recurso en un proceso disminuye su beneficio general por unidad. Esto ciertamente se aplica a la codificación, e incluso cosas buenas como la abstracción, la reutilización, etc. tienen tal punto de rendimientos decrecientes. El término general específico de programación es "sobreingeniería". Para alguien que es propenso a hacer esto, me gusta el término de Joel " astronauta de la arquitectura ".

Kilian Foth
fuente
1

Con demasiada frecuencia, se descarta un buen código bajo la falsa impresión de que el nuevo equipo con nuevas herramientas puede hacerlo más barato, más rápido y con mayor confiabilidad, solo para descubrir que

  • La complejidad está en los requisitos de indocumento
  • Las nuevas herramientas son más difíciles de usar que el sitio web flash prometido
  • El nuevo equipo no está tan 'caliente' como pensaban que estaban

Posiblemente el tiempo que ha descrito llega con algunas bases de código (solía pensar que sí). Nunca experimenté personalmente un caso de código antiguo que causara que un proyecto se arruinara, o reescribí el código para guardar un proyecto.

No incluyo en estos casos donde las métricas se han utilizado para identificar módulos o diseños problemáticos específicos, que luego fueron eliminados y reemplazados.

Mattnz
fuente
Bueno, he visto un proyecto tan jodido que su presupuesto de mantenimiento era tres o cuatro veces el presupuesto de desarrollo inicial. De todos modos, el término que estoy buscando no es algo "oficial" y serio, sino más bien algo como el "pico de Ballmer" en xkcd. Lo siento si no estoy muy claro.
Thibault J
Pero, ¿cómo se puso tan jodido? Si se debe a requisitos complejos, mala administración, sobre ingenieros optimistas, ¿por qué una reescritura lo solucionaría?
Mattnz
¿Porque el equipo que lo reescribe no es lo mismo que el que lo escribió al principio?
Thibault J
1

El verdadero problema con este "momento" teórico es que solo se reconoce después del hecho. A menos que sus colegas sean psicópatas, cada compromiso en la base de código se realiza con la creencia de que es una mejora en esa base de código. Solo mirando hacia atrás en el desorden resultante, puedes ver que has pasado ese "momento".

Pero me gusta que podamos darle un nombre. "Caballeros", podría decir, atrayendo a sus colegas desarrolladores a su alrededor, "Hemos cruzado el Malesibility Hellespont. Envíe un mensaje de texto a su esposa y hágale saber que no la verá por un tiempo".

Dan Ray
fuente
"Cada compromiso en la base de código se realiza con la creencia de que es una mejora en esa base de código". Parece que nunca trabajamos en las mismas compañías :)
Thibault J
@ThibaultJ - ¿Quizás tus colegas han sido psicópatas?
Dan Ray
@Thibault J: Creo que cada confirmación se realiza con la creencia de que es una mejora en esa base de código. La creencia a veces es pobremente investigada e infundada, por supuesto.
David Thornley
En mi último trabajo, no creo que haya ningún compromiso de mantenimiento que alguien haya hecho con la creencia de que fue una mejora en la base de código.
Bobby Tables
A veces, los requisitos de un proyecto pueden cambiar lo suficiente como para forzar el reemplazo con un nuevo diseño, pero puede ser necesario hacer cambios a la versión anterior. Si la mayoría de los usuarios anteriores de la versión anterior usarán el nuevo sistema y ya no necesitarán el anterior, puede ser perfectamente razonable producir una versión que cumpla con los requisitos de aquellos pocos para quienes el nuevo sistema no es adecuado, incluso si fuera hacer que el sistema sea menos utilizable para las personas que ya no lo necesitan de todos modos.
supercat
-1

No sé si hay un nombre, pero si no lo hay, propondría llamarlo "punto de fusión"

DPD
fuente
O pedir prestado otro término nuclear: masa crítica.
John Cromartie
-2

Esta no es una pregunta muy interesante.

De hecho es trivial.

Es tan trivial que hemos desarrollado numerosas formas de hacer frente.

  1. Metodologías en cascada. Mucha gente pasa mucho tiempo revisando requisitos y diseñando documentos para asegurarse de que se gestione la complejidad.

  2. Metodologías ágiles. Menos personas pasan menos tiempo discutiendo lo que es inmediatamente aplicable para resolver el problema de alguien y lanzarles software. La complejidad se gestiona porque todos se centran en obtener algo lanzado.

La única vez que alguien lucha con la "complejidad" es por no seguir la metodología y administrar su tiempo adecuadamente.

  • No hay supervisión detallada en una metodología de cascada. No están obligados a revisar los productos de trabajo intermedio según los requisitos, la arquitectura, el diseño de alto nivel o las revisiones detalladas del diseño.

  • Sin fecha límite de sprint o prioridades de caso de uso adecuado en una metodología ágil. No están enfocados en hacer que algo sea lanzado al usuario lo más rápido posible.

La complejidad debe limitarse estableciendo metas.

Luchar con la complejidad significa que los objetivos no se establecen o no se recompensan adecuadamente.

No hay un "punto de inflexión". Si la gestión de la complejidad es de alguna manera un problema, algo ya está mal organizacionalmente.

S.Lott
fuente
1
No veo el punto Es muy poco probable que un proyecto bien ejecutado llegue al punto de no retorno, pero no todos los proyectos están bien ejecutados. Algunos proyectos mal ejecutados tendrán éxito de todos modos, y el resto fracasará por varias razones, a veces llegando al punto de complejidad sin retorno y a veces no.
David Thornley
@David Thornley: Ese es mi punto. El "punto de complejidad sin retorno" no existe. Es simplemente una mala gestión. No hay necesidad de un nombre sofisticado o una regla. La complejidad es solo un síntoma de un mal manejo. Realmente no muy interesante.
S.Lott
@ S.Lott: Creo que existe, aunque no en proyectos bien administrados. Hay una horda de proyectos mal gestionados, y algunos de ellos entrarán en el horizonte de eventos de complejidad y otros no. Realmente no creo que sea útil agrupar todas las malas gestiones.
David Thornley
@David Thornley: Creo que es muy difícil separar la mala gestión (lo que lleva a una complejidad horrible) de la mala gestión (lo que lleva a que todos renuncien). No puedo ver una manera de saber si un proyecto se volverá demasiado complejo o si se retrasará o simplemente será incompetente.
S.Lott
@ S.Lott: Sin embargo, existe una distinción entre un proyecto donde todos abandonan o sufren un colapso de salud importante y un proyecto donde la complejidad se vuelve demasiado. Hay diferentes formas de fallar, y puede ser interesante o incluso útil clasificarlas.
David Thornley
-2

Existen métodos para visualizar y monitorear el riesgo de aumentar la complejidad de los proyectos (grandes) y el código. Cuando se aplican razonablemente con suerte, no se necesita un nuevo nombre para el punto de no retorno. (Hay un MOOC relacionado en openHPI: https://open.hpi.de/courses/softwareanalytics2015/ )

La complejidad estructural es un problema de diseño general, no solo para el diseño de software en grandes equipos. La visualización es el primer paso en la gestión de la complejidad estructural. Las matrices y los gráficos dirigidos también se pueden usar para este propósito.

Algunos métodos para reducir la complejidad estructural son http://www.buch.de/shop/home/suche/?fq=3540878890 :

  • modularización
  • evitar bucles de retroalimentación
  • triangulación

Además, existe el concepto de diseño axiomático: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ Con este concepto se pueden evitar problemas de fiabilidad debido a la complejidad innecesaria.

Por lo tanto, hay un montón de métodos disponibles. Al final, siempre se trata de la decisión de pensar en ellos porque un proyecto se vuelve lo suficientemente grande.

Eddi
fuente
Esto no responde la pregunta.
Hulk