Si Chuck Norris fuera programador

(39 comentarios)

Según los empleados de Google, que crearon una pequeña página interna para adorarlo, si Chuck Norris fuera programador, se llamaría Jeff Dean, un ingeniero informático especializado en técnicas de optimización que lleva trabajando en Google casi desde su fundación. Estos son algunos de los “hechos de Jeff Dean” que más me han gustado:

[Pulsa para continuar]

La Regla del Boy Scout

(13 comentarios)

A menos que seamos extremadamente cuidadosos la entropía siempre hará que la calidad del software se degrade con el tiempo. Quizás pensemos que tenemos cosas más importantes que hacer que modificar esta clase o esta función y salgamos del paso con un pequeño hack. Es posible que no recordemos muy bien cómo funcionaba el sistema, y que añadamos complejidad innecesaria con nuestros cambios. O que el código nos cause tal sentimiento de repulsión, que no nos importe ejercer un cierto vandalismo casi deliberado contra él.

[Pulsa para continuar]

Principios de diseño: fan-in y fan-out

(18 comentarios)

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.

Ahorra tiempo y dinero con la Ingeniería del Software

(5 comentarios)

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.

Coste Etapa en que se detectó
Requisitos Arquitectura Construcción Pruebas Mantenimiento
Etapa en que se introdujo Requisitos 1 3x 5-10x 10x 10-100x
Arquitectura 1 10x 15x 25-100x
Construcción 1x 10x 10-25x

[Pulsa para continuar]

No hay balas de plata

(7 comentarios)
Bala de plata

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

Captura de requisitos

(11 comentarios)

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

A hombros de gigantes

(15 comentarios)

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 míticos sobre programación que todo desarrollador debería leer

(79 comentarios)

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]

El software y las pirámides

(18 comentarios)

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

Ética profesional

(13 comentarios)

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

Página 1 de 3123