21. Las leyes de Bryce

Tal y como el uso de la tecnología va aumentando, disminuyen las habilidades sociales

El 85% del trabajo de desarrollo de todos los sistemas consiste en introducir modificaciones y mejoras

A la vez que la capacidad del hardware incrementa, el software se vuelve más pesado

Olvidar al ser humano durante el diseño del sistema provocará que el ser humano se olvide del sistema en el momento de echarlo a andar

[...]

22. Primer principio de Spaf

Si eres responsable de seguridad pero no tienes autoridad para establecer reglas y castigar sus incumplimientos, tu cargo real en la organización es asumir la culpa cuando ocurra algo grave

23. Ley de Alzheimer de la programación

Si lees un código que escribiste hace más de dos semanas es como si lo vieras por primera vez

24. Ley de Amara

Tendemos a sobreestimar el efecto de la tecnología en el corto plazo y a subestimarla a largo plazo

26. Principio de Liskov

Los subtipos deben ser sustituibles por sus clases bases

25. Ley de Hick

El tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativas

T = blog₂(n + 1)

27. Principio de Hanlon

Nunca le atribuya a la maldad lo que puede ser explicado por la estupidez

28. Ley de Joy

El número de empleados inteligentes en una empresa es una función logarítmica del número de empleados totales

29. Ley de Lister

La gente bajo presión no piensa más rápido

30. La navaja de Occam

En igualdad de condiciones la solución más sencilla es probablemente la correcta

• Global Nerdy: Laws of software development
• Jugando a crear: Leyes del desarrollo de software
• Wikipedia: List of eponymous laws
• sysprog.net: Computer laws
• Haacked: 19 Eponymous Laws Of Software Development

11. Ley de Linus

Dados suficientes ojos, todos los errores son obvios

12. Ley de Reed

La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la red

13. Ley de Moore

La potencia de los ordenadores se duplica cada dos años, reduciendo además su coste

14. Ley de Wirth

El software se ralentiza más deprisa de lo que se acelera el hardware

15. Ley de Zawinski

Todo programa intenta expandirse hasta que pueda leer emails. Aquél que no pueda ser expandido hasta ese punto, será sustituido por otro que sí tenga esa capacidad

16. Las tres Leyes de Clarke

Primera Ley de Clarke

Cuando un anciano y distinguido científico afirma que algo es posible, probablemente está en lo correcto. Cuando afirma que algo es imposible, probablemente está equivocado.

Segunda Ley de Clarke

La única manera de descubrir los límites de lo posible es aventurarse hacia lo imposible.

Tercera Ley de Clarke

Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia.

17. El principio de Dilbert

Las compañías tienden a ascender sistemáticamente a sus empleados menos competentes a cargos directivos para limitar así la cantidad de daño que son capaces de provocar

18. Ley de Gilder

El ancho de banda aumenta a un ritmo tres veces superior a la potencia de los ordenadores

19. Ley de Amdahl

El incremento de velocidad de un programa utilizando múltiples procesadores en computación distribuida está limitada por la fracción secuencial del programa

20. Ley de Myhrvold

El software es un gas; se expande hasta rellenar su contenedor

1. Ley de Postel

Sé conservador en lo que hagas y liberal en lo que aceptes de los demás

2. Ley de Parkinson

El trabajo se extiende siempre hasta rellenar la totalidad del tiempo disponible para completarlo

3. Principio de Pareto

Para muchos fenómenos, el 80% de las consecuencias derivan del 20% de las causas

4. Revelación de Sturgeon

El noventa por ciento de cualquier cosa es basura

5. El principio de Peter

En una jerarquía, todo individuo tiende a subir hasta alcanzar su nivel de incompetencia

6. Ley de Hofstadter

La realización de un trabajo siempre dura más de lo esperado, incluso habiéndose tenido en cuenta la Ley de Hofstadter

7. Ley de Murphy

Si algo puede ir mal, lo hará

8. Ley de Brooks

Incluir trabajadores en un proyecto retrasado hará que éste avance aún más lentamente

9. Ley de Conway

Cualquier software refleja la estructura organizacional de quien lo produjo

10. Principio de Kerckhoffs

En términos de criptografía, un sistema debería ser seguro incluso si todo sobre el mismo se conoce públicamente, salvo una pequeña porción de información

Los “ilities”, cuya traducción a nuestro idioma podría ser algo así como “ilidades”, son atributos que definen aspectos no funcionales y normalmente asociados con requisitos técnicos y cualidades de un sistema o componente software. El nombre viene del sufijo –ilidad, que, como podréis ver a continuación, es común a la práctica totalidad de ellos.

He encontrado en la Wikipedia una interesante (aunque no exhaustiva) relación ilidades, que podemos utilizar a la hora de intentar transmitir las características de un sistema… o simplemente para aparentar ser auténticos expertos en una reunión de trabajo ;-)

1. Accesibilidad, es decir, el hecho ser accesible a muchas personas, con independencia de sus características, dispositivos utilizados, etc.
2. Reportabilidad, capacidad para monitorizar y registrar las acciones del usuario.
3. Exactitud, grado de distancia desde los resultados ofrecidos por un sistema a los valores entendidos como reales.
4. Adaptabilidad, facilidad que presenta un software para ser adaptado a necesidades concretas.
5. Administrabilidad, indica la capacidad de un sistema o componente para ser administrado y gestionado.
6. Asequibilidad, que indica que, atendiendo a su coste, el sistema puede ser adquirido o conseguido por los clientes.
7. Auditabilidad, transparencia frente a sistemas de auditoría.
8. Disponibilidad, grado en el que un sistema está disponible, operativo y funcional.
9. Credibilidad, que es considerado subjetiva y objetivamente como una fuente de información fiable.
10. Conformidad con estándares, grado de cercanía a las prácticas o técnicas aceptadas como estándares.
11. Compatibilidad, que funciona en un escenario determinado, o permite sustituir otros sistemas equivalentes.
12. Componibilidad, capacidad para combinar el software con otros elementos para componer sistemas no previstos inicialmente.
13. Configurabilidad, esto es, que dispone de mecanismos que permiten configurar algunos aspectos de su comportamiento.
14. Corrección, que indica que el software actúa conforme a sus especificaciones.
15. Personalizabilidad, capacidad de un sistema para ser personalizado a las preferencias de sus usuarios.
16. Degradabilidad, capacidad para mantener las funcionalidades básicas en condiciones adversas.
17. Demostrabilidad, aplicable a aquellos sistemas cuyo funcionamiento puede ser demostrado.
18. Dependabilidad, que define la probabilidad de que el sistema complete su misión, dado que estaba disponible en el comienzo de la misma.
19. Desplegabilidad, capacidad de un software para ser desplegado en un escenario.
20. Distribuibilidad, capacidad o facilidad de un componente o sistema para ser distribuido.
21. Durabilidad, mantenimiento de las funciones con el paso del tiempo.
22. Efectividad, o capacidad para lograr el efecto deseado.
23. Eficiencia, capacidad para lograr el efecto deseado con el menor consumo posible de recursos.
24. Evolucionabilidad, grado de facilidad con la que es posible hacer evolucionar un sistema para adaptarse a nuevas condiciones.
25. Extensibilidad, capacidad de un software para ser ampliado con nuevas funciones sin modificar su estructura básica.
26. Fidelidad, que ofrece precisión y confianza en la representación de la realidad.
27. Flexibilidad, que puede adaptarse con facilidad a cambios en el entorno.
28. Instalabilidad, facilidad para ser instalado en un entorno  determinado.
29. Integridad, capacidad para evitar y sobreponerse a errores en la información que maneja.
30. Intercambiabilidad, que indica que un componente puede ser sustituido por otro sin modificar aquellos que lo utilizan.
31. Interoperabilidad, capacidad que tiene un sistema para intercambiar información con otro.
32. Aprendibilidad, es decir, la capacidad que presenta un software para enseñar su propio manejo al usuario.
33. Mantenibilidad, o facilidad con la que se puede corregir, modificar o ampliar un software.
34. Gestionabilidad, facilidad para gestionar la complejidad de un sistema.
35. Movilidad, posibilidad que tiene un sistema de funcionar en distintas ubicaciones geográficas.
36. Modularidad, grado en el que un software está internamente dividido en bloques independientes.
37. Nomadicidad, capacidad de un sistema para adaptarse de forma transparente a una situación de desconexión por cambio de ubicación-
38. Operabilidad, capacidad de un software para funcionar y cumplir su misión.
39. Portabilidad, la facilidad con la que un software puede ser transferido a otro entorno software o hardware.
40. Precisión, nivel de detalle con el que un sistema es capaz de manejar información.
41. Predictibilidad, grado de certeza del comportamiento del sistema ante un escenario determinado.
42. Recuperabilidad, capacidad de un sistema de restablecer un nivel apropiado de servicio y recuperar sus datos en caso de producirse fallos.
43. Fiabilidad, es la habilidad de un software para realizar sus funciones de forma correcta bajo unas condiciones determinadas.
44. Repetibilidad, es la capacidad de generar el mismo resultado si no cambian las condiciones.
45. Reproducibilidad, es el grado de precisión que se obtiene al intentar reproducir un comportamiento del sistema.
46. Responsividad, velocidad con la que un sistema realiza una tarea, por ejemplo responder a la entrada del usuario.
47. Reusabilidad, facilidad con la que un componente o sistema puede ser reutilizado para añadir funcionalidades o características en un nuevo sistema.
48. Robustez, capacidad para continuar la operación aún en el caso de producirse errores inesperados.
49. Seguridad, capacidad de un software para conseguir niveles aceptables de daños a personas, negocios, software, propiedades o entorno.
50. Escalabilidad, facilidad con la que un sistema puede ser adaptado para satisfacer necesidades mayores de carga de trabajo.
51. Uniformidad, grado de presentación como una estructura consistente, aunque el sistema incluya diversas tecnologías.
52. Soportabilidad, que hace referencia a la habilidad del soporte técnico para dar soporte a los productos.
53. Asegurabilidad, capacidad para asegurar distintos niveles de un sistema.
54. Simplicidad, o ausencia de complicaciones y dificultades.
55. Estabilidad, capacidad de un software para funcionar períodos del tiempo sin parar o funcionar incorrectamente.
56. Comprobabilidad, el grado en el que un componente soporta la realización de pruebas para validar su corrección.
57. Oportunidad, es decir, el hecho de estar disponible en el momento en el que debe estarlo.
58. Ubicuidad, capacidad de un software para estar presente en todas partes, en cualquier momento.
59. Comprensibilidad, facilidad con la que un software puede ser comprendido a los distintos niveles.
60. Usabilidad, facilidad con la que un usuario puede utilizar un sistema software para conseguir un objetivo. 

Los términos originales estaban en inglés y algunos no eran fácilmente traducibles, así que en más de una ocasión he tenido que echar mano de la creatividad y patear a la RAE y todos sus integrantes ;-D

Publicado en: Variable not found.

0. Antes de empezar…

• en primer lugar, el propio software Live Writer, más que nada porque necesitamos referenciar algunos de sus ensamblados, y por ir probando el complemento durante el desarrollo.
• en segundo lugar, Visual Studio 2005 o 2008, aunque sea una edición express. Este desarrollo vamos a realizarlo en C#, pero la traducción a Visual Basic .NET sería trivial.

1. Preparación del proyecto

• La primera referencia es al ensamblado que contiene el API de Live Writer, que podéis encontrar en el directorio de instalación de la herramienta. El  archivo a incluir es WindowsLive.Writer.Api.dll .
• La segunda es a System.Windows.Forms. Hay que tener en cuenta que Live Writer es una herramienta de escritorio, y esta referencia es importante para poder interactuar con el mismo.

Otro detalle más que nos va a facilitar las cosas: vamos a indicar a Visual Studio que el resultado de la compilación lo copie en el directorio de plugins de Live Writer. Para ello, lo único que tenemos que hacer es acudir a las propiedades del proyecto, pestaña “eventos de generación” e incluir la siguiente orden en el cuadro “línea de comandos del evento posterior a la generación” (obviamente, modificando la ruta si es necesario):

XCOPY /D /Y /R "$(TargetPath)" "C:\Archivos de Programa\Windows Live\Writer\Plugins\"

2. Escribimos la clase principal

  public class CodeTag: ContentSource
  {
     public override DialogResult CreateContent(IWin32Window dialogOwner, 
                                               ref string content)
    {
      if (string.IsNullOrEmpty(content))
          content = "YourCodeHere";
      
      content = "<code>" + content + "</code> ";
      return DialogResult.OK;
    }
  }

• Si la variable content viene vacía o con valor nulo, es que el complemento ha sido lanzado en modo inserción, es decir, no existía ningún texto seleccionado y por lo tanto lo que se pretende es añadir las etiquetas de código para introducir posteriormente contenido. Como puede observarse en el código, lo que se hace en este caso es insertar las etiquetas <code> con un texto arbitrario para que el usuario lo modifique a su antojo más adelante.
• En caso contrario, si la variable content trae algún contenido, lo que se hace es rodear éste por la apertura y cierre de la etiqueta <code>.

3. Añadimos metadatos

[WriterPlugin("98497c2b-bbfd-4bd1-b343-226f3c9e766b", "Code Tag",
    Description = "Crea etiquetas <code></code> en el contenido",
    PublisherUrl = "http://www.variablenotfound.com")]
[InsertableContentSource("Etiqueta <code>")]
public class CodeTag: ContentSource
{
  [...]
}

• El primer parámetro es un GUID, es decir, un identificador único que debemos generar para el plugin, utilizando este servicio on-line u otras herramientas como la incluida en Visual Studio.
• El segundo parámetro es el nombre del plugin. Es la identificación que aparece en el cuadro de diálogo de configuración de complementos de Live Writer.
• Description permite añadir una descripción textual ampliada del plugin.
• PublisherUrl es una dirección web de referencia al autor. Pura propaganda ;-)

4. Compilamos el proyecto

5. Añadirle un icono al plugin

    [WriterPlugin("98497c2b-bbfd-4bd1-b343-226f3c9e766b", "Code Tag",
        Description = "Crea etiquetas <code></code> en el contenido",
        ImagePath = "CodeTag.bmp",
        PublisherUrl = "http://www.variablenotfound.com")]
    [InsertableContentSource("Etiqueta <code>")]
    public class CodeTag : ContentSource
    {
      [...]
    }

6. O, por si no quieres teclear…

16. El desplome de las Punto-Bomb (2000)

17. El virus del amor (2000)

18. Tratamiento contra el cáncer mortal (2000)

19. EDS frena la ayuda al niño (2004)

20. El final de la trilogía FBI (2005)

Los desastres continúan

• Software Bugs in the Data Reservoir
• History's Worst Software Bugs
• Top 10 IT Disasters of All Time
• Risks Digest: Forum on Risks to the Public in Computers and Related Systems

11. Skynet trae el juicio final (1997)

12. El desorbitado Mars Climate (1998)

13. El estudio del desastre (1999)

14. Pasaportes Británicos a ninguna parte (1999)

15. Y2K (1999)