Complejidad

He recibido tanto comentarios en mi bitácora como en persona sobre mi – crítica – opinión sobre el concepto “Menos es más”. Por lo tanto, creo que debo extenderme algo más en mis razonamientos.

Hay sin duda aplicaciones, muy sofisticadas, de los que el 80% de los usuarios utilizan sólo un 20% de la funcionalidad. O porcentajes parecidos. Por lo que para las pocas cosas que se utilizan se complica demasiado su uso. Además, el software se llena de errores. Y de ahí nace el concepto.

Un caso paradigmático de esto es el famoso editor de ecuaciones de Microsoft Word. ¿Cuantos habéis utilizado ese editor? Yo, algunas veces, pero muy pocas. Antes era parte del software, ahora es un add-in, o add-on, o complemento, o como se llame.

Siguiendo con el ejemplo: ¿alguien se imagina un tratamiento de textos que no permita cambiar el tipo de letra, la justificación, la corrección ortográfica o la creación automática de índices? Yo no.

Sin embargo, a veces echo de menos un micro-editor en el que pueda fijar qué estilos y cuándo se pueden utilizar, en el que el formato, aspecto y estructura estén previamente determinados y en el que los usuarios no hagan mas que “rellenar” lo que les toca.

Odio que alguien pueda escribir en Comic Sans negrita, color naranja sobre fondo amarillo…

En resumen, lo único que intento decir es que:

Menos es menos pero, a veces, es mejor.

Alejandro André

Tags: Complejidad

Extraido de W3 Schools:

Cliente: Quiero descargarme el Internet ¿necesito un disco duro más grande?

Respuesta: Descarga el Intenet aquí.

Tags: Curiosidades

Parece que esta bitácora va de leyes, así que ahí va otra:

No hables con desconocidos

Esta regla fue formulada en la Northeastern University en 1987 por Ian Holland. Y la explica magistralmente el blog Refactoring.

Es una regla comúnmente aceptada de buen Diseño, que se basa en el mínimo conocimiento del modelo de objetos, de modo que se reduzca el número y complejidad de las interrelaciones.

Aplicado la ley de Demeter a objetos, tendríamos que una operación de un objeto sólo tendría que utilizar:

• Las operaciones propias del objeto.

• Los objetos que tenga asociados o sean atributos del objeto.

• Los objetos que recibe como parámetro la operación.

• Los objetos que cree la operación.

Tags: Metodología, Programación

Ya lo dice Martin Fowler en su artículo sobre La Nueva Metodología: Ágil no es para todo el mundo. No hay reglas predeterminadas que nos ayuden a determinar claramente cuando utilizar una metodología Ágil o, por el contrario, una metodología clásica.

En cualquier caso, ahí van unas ideas:

Dedicación del cliente.

Difícilmente podemos aplicar una metodología ágil si no contamos con la adecuada involucración del cliente. En ese caso es mejor tomar requisitos muy concienzudamente al principio.

Tamaño del proyecto.

El tamaño no es una limitación en si misma, pero a mayor tamaño más complicado es implantar una metodología Ágil.

Estabilidad de los requerimientos.

Cuando los requerimientos cambian, una metodología Ágil puede ayudar a adaptarse a ellos. Para requisitos estables, quiza una metodología clásica ayude a evitar el re-trabajo.

Criticidad.

Yo personalmente no utilizaría una metodología Ágil para diseñar y construir un sistema del que dependan vidas humanas: los sistemas de navegación de un avión, por ejemplo.

Experiencia.

Esto es obvio. No uses metodologías Ágiles con equipos sin experiencia. Estas metodologías se basan en la capacidad y madurez de los miembros del equipo.

Apetencia.

Otra obviedad. Si no te apetece usarlas, pues no las uses.

Tags: Metodología, Programación

Me he permitido copiar y traducir un pequeño fragmento del libro “Implementing and Integrating Product Data Management and Software Configuration Management” de Ivica Crnkovic, Ulf Asklund y Annita Persson Dahlqvist

Transformar [dividir] un problema grande en muchos problemas pequeños, normalmente implica que las relaciones entre las partes se hacen complejas. Las relaciones entre componentes pueden ser tan complejas que se haga casi imposible manejarlas.

Es otra forma de expresar la Ley de Tesler.

En el fondo refuerza la idea de que la complejidad de un sistema no desaparece por el método de dividirlo en subsistemas más simples. Es decir, la complejidad no se “destruye”, sino que se traslada de los componentes a las relaciones entre ellos.

Por cierto, interesante libro…

Tags: Complejidad