Fan-in (abanico de entrada) es un término utilizado en la Ingeniería del Software para referirse al número de clases que hacen uso de la clase que estamos estudiando. Por otro lado, fan-out (abanico de salida) hace referencia al número de clases que utiliza la clase que estamos estudiando. Estos conceptos, originarios de la electrónica digital, también pueden utilizarse en el resto de niveles del diseño conceptual, para hablar de subsistemas, paquetes o funciones.

Un buen diseño suele tener un fan-in alto, porque eso implica que estamos reutilizando código que de otra forma habría dado lugar a duplicidades en multitud de clases. El fan-in es una medida de reutilización.

Al contrario, un buen diseño cuenta con un fan-out bajo, idealmente de 7±2, que es, según George Miller, uno de los mayores exponentes de la psicología cognitiva, el número máximo de elementos que una persona normal puede almacenar en su memoria a corto plazo. Con un fan-out bajo nos aseguramos de que la clase es lo bastante sencilla para que no nos resulte difícil trabajar con ella. El fan-out es una medida de complejidad, muy relacionado con el Principio de Responsabilidad Única.

Estos últimos días estoy leyendo por enésima vez Code Complete, mi libro preferido sobre desarrollo de software, y el de mucha más gente. A este libro pertenece esta tabla, basada en diversos estudios, que ejemplifica el coste medio de arreglar un error durante el proceso de desarrollo de software según la etapa en que se introdujo y la etapa en que se terminó solucionando.

[Pulsa para continuar]

El folclore y la mitología moderna afirman que la manera más efectiva de acabar con un hombre lobo es utilizando una bala de plata. Esta creencia deriva de ciertos hechos acaecidos en la región francesa de Gévaudan entre 1764 y 1767. En este periodo, una bestia de gran tamaño acabó con la vida de más de 130 campesinos, en su mayoría mujeres y niños, que fueron despedazados brutalmente. Esta supuesta bestia sería abatida finalmente, según los relatos, utilizando balas de plata, obtenida tras fundir varias medallas de la Virgen María.

Actualmente, la frase “bala de plata” se ha convertido en una expresión popular para denotar una solución perfecta a un problema, casi milagrosa, que, además, puede aplicarse en casi cualquier contexto.

Por supuesto, en el mundo del desarrollo de software, sabemos que no existe nada parecido a las balas de plata. De ahí que Fred Brooks acuñara esta famosa frase en su célebre ensayo “No hay bala de plata” (No Silver Bullet) que podéis encontrar en la web de la Universidad de Nottingham, en Barrapunto (español) o en el mítico libro The Mythical Man Month

Si hubiésemos preguntado a los usuarios qué era lo que necesitaban, su respuesta habría sido: “caballos más rápidos”.

– Henry Ford, fundador de la Ford Motor Company

Se dice que las grandes disciplinas científicas son ejemplos de gigantes subidos a los hombros de otros gigantes. También se ha dicho que la industria del software es un ejemplo de enanos subidos a los pies de otros enanos.

– Alan Cooper

10 libros que toda persona que se dedique al desarrollo de software, en cualquiera de sus formas, debería tener en su estantería. También sería conveniente leerlos un par de veces, porque a pesar de que son tremendos como pisapapeles y para nivelar muebles, no es su única utilidad…

[Pulsa para continuar]

La mayor parte del software que se desarrolla hoy en día es similar a las pirámides egipcias: millones de ladrillos apilados uno encima de otro, sin integridad estructural, y construidas a base de fuerza bruta y miles de esclavos.

– Alan Kay

Ningún ingeniero de software con un poco de ética escribiría nunca un procedimiento DestruirBagdad. La ética profesional más básica requeriría escribir un procedimiento DestruirCiudad genérico, al que se le pudiera pasar Bagdad como parámetro.

– Nathaniel S. Borenstein

Si los albañiles construyeran edificios de la misma forma en que los desarrolladores escriben sus programas, el primer pájaro carpintero que hubiera aparecido habría destruido la civilización.

– Gerald Weinberg

Por otro lado, Si los arquitectos tuvieran que trabajar como los programadores…

Hoy en día los usuarios son (somos) mucho más exigentes. No nos conformamos con que un producto satisfaga una necesidad o solucione un problema, sino que tiene que ser amigable y sencillo de utilizar, además de generar una sensación positiva (provocar una respuesta emocional positiva). Y si del primer punto se encarga la ingeniería de la usabilidad, del segundo lo hace el diseño emocional, uno de cuyos mayores exponentes es la Ingeniería Kansei (KES, o Kansei Engineering System).

[Pulsa para continuar]