Empezamos una aventura...

... parafraseando libremente a Ernest Shackleton:
Se buscan profesionales para peligroso viaje.
Amistades en huida. Frío penetrante.
Largos meses de completa soledad.
Constante peligro. Dudoso regreso a la vida sano y salvo.
En caso de éxito, honor y reconocimiento
.
¿Te atreves a cambiar el statu quo del sector de las Tecnologías de la Información?
Empieza comentando y opinando. Sin tí nosotros no tenemos sentido.


La tira diaria de Dilbert 20/09/2011

dilbert.com

Nuestra estrategia consiste en aumentar la cuota de mercado.

Estoy confundido. Pasé todo el año anterior tratando de disminuir la cuota de mercado. ¿Fue que un esfuerzo inútil?

No se preocupe. Wally me dijo que tiene un buen sentido del humor.

No estoy seguro.

miércoles, 16 de junio de 2010

15 Leyes epónimas para el Desarrollo de Software


Traducción libre, reducida e interpretada de
http://haacked.com/archive/2007/07/17/the-eponymous-laws-of-software-development.aspx
Una forma segura de ser recordado es asociar una ley o principio al nombre de una persona muerta (una persona viva valdría igualmente, pero produce menos hilaridad).

Un epónimo es algo cuyo nombre hace referencia al nombre de una persona (algunas veces hace referencia a quien inventó algo, pero esa regla no es de fiar). Puedes encontrar en Wikipedia una lista de leyes o principios que se conocen con el nombre de una persona.


1. Ley de Postel

Sea conservador en lo que envía, liberal en lo que acepta.

Jon Postel lo proponía originalmente como un principio para realizar implementaciones robustas de TCP. Este principio también ha sido consagrado por HTML lo que muchos atribuyen como la causa de su éxito o de su fracaso, dependiendo de a quién se le pregunte.
En el actual entorno de fuerte carga política, la ley de Postel es un agrutinador.

2. Ley de Parkinson

También conocida como la ley de la burocracia; esta ley establece que:

Cualquier trabajo se expande hasta llenar todo el tiempo disponible para su realización.

3. Principio de Pareto

También conocido como la regla 80-20, el Principio de Pareto establece:
Para muchos fenómenos, el 80% de las consecuencias se derivan de un 20% de las causas.
Este principio se encuentra detrás de la dolorosa verdad de que el 80% de los errores en el código se encuentran en el 20% del propio código. Del mismo modo, el 80% del trabajo realizado en una empresa se realiza por un 20% de la plantilla. El problema es que no siempre los que ponen los sueldos tienen una idea clara de quien es parte de ese 20%.

4. Revelación de Sturgeon

La revelación no tiene nada que ver con ninguna experiencia religiosa (Iglesias hijo dixit), como uno podría creer. Por el contrario, señala que:
El noventa por ciento de cualquier aplicación software es CRUD Creation / Retrieval / Update / Deletion (Alta / Baja / Modificación / Lectura).
Me han dicho que en EE.UU. existen clínicas especializadas en tratar el síndrome CRUD. Sus pacientes, principalmente, estuvieron programando para consultoras de renombre.

5. El Principio de Peter

Una de las leyes más deprimente de esta lista, si resulta que tienes experiencias (negativas) de primera mano por haber trabajado con directores incompetentes.
En cualquier estructura jerárquica, todo empleado tiende a ascender hasta su máximo nivel de incompetencia.
Basta con leer Dilbert (o ver la serie The Office) para obtener algunos ejemplos “reales” de esto.

6. Ley de Hofstadter

Esta es una ley recursiva; dice:
Una tarea siempre lleva más tiempo del esperado, incluso si se tiene en cuenta la Ley de Hofstadter.

7. Ley de Murphy

La que todos conocemos y amamos.
Si algo puede salir mal, saldrá mal.
La consecuencia en desarrollo de software seria leer algo (y aplicarlo) sobre programación defensiva.

8. Ley de Brook

También conocida como Ley del Bombero Pirómano (aquel que echaba gasolina al fuego pretendiendo apagarlo)
Añadir personal a un proyecto retrasado lo retrasará aún más.
Mi corolario favorito a esta ley es el siguiente:
El periodo de gestación de un niño es de nueve meses, no importando el número de mujeres a las que se les asigne esta tarea.

9. Ley de Conway

Esta ley establece:
Cualquier pieza de software refleja la estructura organizativa que lo produjo.
Dicho de otra manera: si usted tiene cuatro equipos de trabajo realizando un compilador, obtendrá un compilador de 4 pasos.
¿Cuántos equipos están involucrados en el software que está construyendo?

10. Principio de Kerchkhoff

En criptografía, un sistema debe ser seguro incluso si todo el sistema, a excepción de una pequeña pieza de información - la clave - es de conocimiento público.
Y así Kerchkhoff se posiciona claramente contra la Seguridad por oscuridad. Este es el principio fundamental de la criptografía de clave pública.

11. Ley de Linus
Creada en honor de Linus Torvalds, el creador de LINUX, esta ley establece:
Con suficientes ojos, todos los errores son superficiales.
Donde almacene los globos oculares dependerá de usted.

12. Ley de Reed
La utilidad de las grandes redes, en particular las redes sociales, crece exponencialmente con el tamaño de la red.
Es imprescindible que se la repita en voz alta cada vez que invite a cualquier desconocido para que sea su amigo en FaceBook…

13. Ley de Metcalfe
En la teoría de redes, el valor de un sistema crece cuadráticamente en relación al número de usuarios del mismo.
Me pregunto si Reed y Metcalfe hacían ejercicios de barra fija en los mismos pubs.

14. La Ley de Moore
Probablemente la ley más famosa de la Informática; esta ley establece:
La potencia de los ordenadores, por unidad de coste, se duplica cada 24 meses.
La versión más popular y conocida de la ley de Moore dice:
El número de transistores en un circuito integrado se duplicará cada 18 meses.
Y, desde que se declaró esta ley, hemos estado trabajando para cumplirla...

15. Ley de Zawinski
Esta ley responde al crecimiento desordenado del software:
Cualquier programa tiende a expandirse hasta que es capaz de leer el correo. Los programas que no lo consiguen se sustituyen por otros que si lo logran.
He oído que la próxima versión de calc.exe va a incluir la capacidad de leer el correo electrónico. Una formulación más moderna de esta ley sustituye correo electrónico por RSS.

1 comentario:

Arturo dijo...

Tremendamente cierta, la ley de Conway. Una interesante manifestación de cómo se comporta nuestra especie primate ante el trabajo en equipo, especialmente en el desarrollo de software. Mi corolario a esta ley es muy simple y evidente: Los buenos equipos hacen buen Software.