Autor en Google+
Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

15 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
Mostrando entradas con la etiqueta proyectos. Mostrar todas las entradas
Mostrando entradas con la etiqueta proyectos. Mostrar todas las entradas
martes, 2 de febrero de 2016
Ojo a los autobusesMe encanta encontrar definiciones más o menos conocidas de conceptos o ideas que se nos han pasado por la cabeza en algún momento sin saber que otros ya les habían dado forma, porque demuestra que todos los que nos dedicamos a esto tenemos poco más o menos las mismas inquietudes.

En este caso, me ha entusiasmado dar por casualidad con el "bus factor", un término que seguro muchos conocíais pero para mi ha sido un descubrimiento reciente, que básicamente da forma a la pregunta que seguro que todos nos hemos hecho sobre la continuidad de algunos proyectos ante determinados acontecimientos inesperados.

Imaginemos que todo el equipo de desarrollo de un proyecto va caminando por la calle, y un autobús que circulaba cerca pierde el control y les arrolla de forma violenta. ¿A cuántos miembros del equipo tendría que afectar fatalmente este accidente para poner en gran peligro la continuidad del proyecto?

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

martes, 25 de octubre de 2011
The Tao of ProgrammingHace unos días charlaba con un colega sobre aspectos filosóficos del desarrollo de software, y me pareció curioso que no conociera “The Tao of Programming”, todo un clásico de la literatura friki, y lectura indispensable para los que nos dedicamos a esto.

Este libro, escrito en el año 1987 por Geoffrey James, recoge, en un humorístico tono de misticismo oriental, distintas historias y parábolas con geniales mensajes de fondo sobre calidad en la programación, gestión de proyectos y otros temas que siguen siendo válidos veinticinco años después.

Como probablemente habrá más lectores que no lo conozcan, me ha parecido interesante reproducirlo aquí traducido en su totalidad, por supuesto contando previamente con el permiso expreso del Sr. James.

¡Que aproveche!
Warning: Post largo. Muy largo ;-)

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

domingo, 13 de septiembre de 2009

Juan Palacio, en su genial Navegápolis, publicó semanas atrás unos buenos materiales de un Curso de Scrum en los que he podido recordar una historieta que encontré hace tiempo sobre la diferencia entre la implicación y el compromiso en la realización de un proyecto:

La historia de la gallina y el cerdo

Aunque esta metáfora se utiliza en Scrum para agrupar los roles principales distinguiendo entre aquellos que ponen “la carne en el asador” (cerdos), y el resto de afectados y participantes (gallinas), es igualmente aplicable a las actitudes de los componentes de un equipo de trabajo, independientemente de la metodología utilizada.

Publicado en: Variable not found.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

martes, 26 de mayo de 2009

Desde hace unos meses estoy escribiendo las entradas de Variable Not Found desde Windows Live Writer, y la verdad es que estoy encantado con esta herramienta. Pero como nadie es perfecto, me he encontrado con ocasiones en las que tengo que acceder y retocar a mano el código fuente de la página para que el resultado sea el que pretendo.

Me suele ocurrir, por ejemplo, cuando inserto pequeñas porciones de código fuente en mitad de una frase, pues siempre me ha gustado rodear este tipo de textos por las correspondientes etiquetas <code> y </code>. Esto, además de ser un marcado semánticamente más correcto, me permite modificar la forma en que se muestra desde CSS, estableciéndole, por ejemplo, una tipografía de ancho fijo.

Para no tener que hacerlo más a mano, he creado un pequeño plugin para Live Writer que permite seleccionar un texto y envolverlo automáticamente por dichas etiquetas, y he pensado que quizás pueda serle útil a alguien más.

image La criatura se llama “CodeTag”, y la podéis descargar desde el enlace de más abajo. Para instalarla en vuestro Live Writer, simplemente debéis descomprimir el archivo y copiar CodeTag.dll a la carpeta Plugins dentro del directorio donde hayáis instalado la herramienta (en mi caso, la ruta completa es C:\Archivos de programa\Windows Live\Writer\Plugins).

Seguidamente, reiniciáis Live Writer y listo, veréis que en la barra lateral y el menú “insertar” ha aparecido la opción “Etiqueta <code>”, que os permitirá realizar el proceso descrito anteriormente.

En breve publicaré un post describiendo paso a paso cómo se crea un plugin para Live Writer, y veréis lo sencillo que resulta hacer estas pequeñas herramientas de productividad.

Publicado en: Variable not found

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

domingo, 8 de febrero de 2009
HundimientoMe he vuelto a encontrar con el divertido post 101 Ways To Know Your Software Project Is Doomed, donde se enumeran 101 pistas que te ayudarán a saber si tu proyecto está condenado a fracasar estrepitosamente. Tras contactar con Max Pool, el propietario del blog Codesqueeze, me ha permitido muy amablemente publicar aquí una traducción de su post completo.
  1. La dirección ha cambiado el nombre del "procedimiento en cascada" por "cascada ágil".
  2. Se han empezado a contratar consultores para poder echarles las culpas de todo.
  3. El servidor de integración continua retorna el error "Que te jodan. Me largo".
  4. Habéis implementado vuestro propio framework en Ruby que usa archivos de configuración XML.
  5. El miembro del equipo más mayor se refiere a Martin Fowler como "ese gamberro engreído".
  6. Vuestro sistema de control de código fuente consiste en una serie de carpetas en un disco compartido en red.
  7. El tiempo asignado para QA es destinado a preguntarse el por qué de ese desastre.
  8. Todos los requisitos están escritos en una servilleta de papel.
  9. Empiezas a considerar un cambio de empleo para no tener que mantener la aplicación que estás desarrollando.
  10. El responsable de desarrollo web piensa que la X de XHTML viene de "eXtremo".
  11. Las reuniones de todas las iteraciones comienzan por un "¿prefieres las buenas o las malas noticias?".
  12. El equipo todavía considera que su nivel de CMM es una mierda.
  13. El progreso se mide por el número de errores corregidos, y no por funcionalidades o características finalizadas.
  14. La integración continua está haciendo que los empleados nuevos lean el manual del empleado.
  15. Eres amigo del portero.
  16. Al SCRUM master no le importa lo que hicisteis ayer, ni lo que haréis hoy.
  17. Cada hito acaba en un sprint mortal.
  18. Vuestro mejor desarrollador lo único que tiene es su expediente académico brillante.
  19. No entendéis los acrónimos DRY, YAGNI o KISS, pero sí WTF, PHB o FUBAR.
  20. El jefe podría ser sustituido por un script de redirección de emails.
  21. La única certificación de vuestros procesos de construcción de software es la ISO 9001/2000.
  22. El jefe piensa que "métrica" es un tipo de bebida proteínica.
  23. Todos los errores son priorizados como críticos.
  24. Todas las funcionalidades son priorizadas como triviales.
  25. Las estimaciones económicas del proyecto mágicamente coinciden con el presupuesto disponible para el mismo.
  26. Los desarrolladores usan la excusa del código autodocumentado para justificar la ausencia de comentarios.
  27. Vuestro patrón favorito es el god object.
  28. Todavía pensáis que compilar es una forma de testear.
  29. Los desarrolladores todavía utilizan Notepad como entorno de desarrollo.
  30. El gestor del proyecto pasa 7 horas a la semana pidiendo informes de progreso (basado en hechos reales).
  31. No tenéis máquina propia, y no estáis programando por parejas.
  32. Norma del equipo: no hay reuniones hasta las 10:00am, puesto que ayer estuvimos aquí hasta las 2:00am.
  33. En el equipo se piensa que los ORM son una moda.
  34. El equipo piensa que la transición desde VB6 a VB.NET será sencilla.
  35. El gestor piensa que MS Project es la mejor herramienta de gestión de proyectos del mercado.
  36. Tu esposa sólo consigue verte en una webcam.
  37. Ninguno de test unitarios tienen aserciones (asserts).
  38. Vuestro editor de páginas favorito es FrontPage.
  39. Se discute encendidamente sobre si la llave "{" debe escribirse en una nueva línea, pero se es impacial ante el uso de patrones como MVC.
  40. El lema de la compañía es "haz más con menos".
  41. La frase "funciona en mi máquina" se escucha más de una vez al día.
  42. La última conferencia a la que asistió el equipo de desarrollo .NET fue la Apple Worldwide Developers Conference 2000.
  43. Los gestores insiten en registrar toda la actividad, pero nunca usan esa información para tomar decisiones.
  44. Toda la depuración se hace en el servidor en producción.
  45. El jefe no sabe cómo comprobar el email.
  46. El jefe piensa que ser compatible SOX significa no trabajar las noches en las que hay béisbol.
  47. La empresa contrata al senador Ted Stevens para la charla de inicio del proyecto.
  48. El último libro que leíste fue la Biblia de Visual Interdev 6.
  49. El presupuesto general se confunde con tu gasto semanal en Mountain Dew.
  50. El jefe se pasa la hora de la comida llorando en el coche (otro hecho real).
  51. El responsable de desarrollo web define Ajax como un producto de limpieza.
  52. Tu jefe espera que pases los dos próximos días creando una solicitud de compra por un componente de 50$.
  53. El equipo de ventas reduce tus estimaciones porque creen que podéis trabajar más rápidamente.
  54. Requisito - Rank #1 en Google.
  55. Todos los días trabajas hasta medianoche, y tu jefe se va a las 16:30.
  56. A los jefes les encanta decir: "¿por qué se preocupan los desarrolladores? Cobran por horas".
  57. El personal del turno de noche de StarBucks te conoce por tu nombre.
  58. El jefe no pueden entender por qué alguien puede necesitar más de un monitor.
  59. El equipo de desarrollo sólo usa el control de código fuente como sistema de backup por si falla el suministro eléctrico.
  60. Los desarrolladores no son responsables de realizar ninguna prueba.
  61. El equipo no usa SVN porque piensan que los algoritmos de fusión (merge) son pura magia negra.
  62. Tus pizarras no tienen nada escrito (Version One).
  63. El cliente confunde siempre tu gráfico burn-down con un burn-up (lo que queda por hacer con lo que está hecho).
  64. El nombre clave del proyecto pasa a ser "Marcha de la muerte".
  65. Te duele físicamente decir la palabra "sí".
  66. Tus compañeros no refactorizan, sino refuctorizan.
  67. Como recompensa por el tiempo extra, tu jefe compra una nueva cafetera.
  68. El presupuesto de tu proyecto se contabiliza en la empresa como gastos estructurales.
  69. Puedes bloguear desde el trabajo, gracias a que subcontratas porciones del proyecto.
  70. Se crea un comité de control de cambios del proyecto, incluso antes de disponer de la primera versión alfa.
  71. Diariamente consideras romperte los dedos para estar impedido un tiempo.
  72. El hito final de entrega ha sido renombrado simplemente como "hito", igual que el anterior.
  73. La política de puertas abiertas de la dirección sólo se aplica desde las 17:00 hasta las 8:00 horas.
  74. La dirección opina que "por qué comprarlo cuando podemos construirlo".
  75. Traes cerveza a la oficina durante el segundo turno.
  76. Descubrís al director del proyecto consultando una tabla Ouija.
  77. Das información errónea sobre tus compañeros de trabajo para parecer mejor en tu revisión personal.
  78. Las revisiones de código se planifican para una semana antes del lanzamiento del producto.
  79. Sólo existe presupuesto para realizar pruebas "si tenemos tiempo".
  80. El cliente sólo habla sobre los requisitos cuando ya tiene una estimación fija.
  81. Tu jefe no le encuentra la gracia a Dilbert.
  82. Comienzas a notar los faroles del jefe durante un planning poker.
  83. Empiezas a pensar si trabajar dos turnos en Pizza Hut sería una mejor alternativa para tu carrera profesional.
  84. Todos los problemas de rendimiento se solucionan poniendo máquinas más potentes.
  85. El proyecto va a ser lanzado como una versión beta permanente.
  86. Se llevan tu coche del parking por pensar que estaba abandonado.
  87. El jefe de proyecto suele garabatear durante las reuniones de toma de requisitos.
  88. Estás utilizando MOSS 2007.
  89. Tu equipo SCRUM consiste en una única persona.
  90. Tu hoja de control de horas parece un ticket de Powerball.
  91. El desarrollador web piensa que 508 tiene que ver con sus pantalones Levi's.
  92. Piensas que necesitas medicación para la personalidad múltiple porque eres Mort, Elvis, and Einstein al mismo tiempo.
  93. Tu jefe sustituye el asesoramiento profesional de un consultor por una bola mágica.
  94. Sabes exactamente cuántos warnings en compilación provocan que tu IDE genere una excepción de "fuera de memoria".
  95. A estas alturas, todavía no sabes a qué me refiero con el término "IDE".
  96. Has copiado y pegado código desde The Daily WTF.
  97. Los tests unitarios que fallan son eliminados porque, obviamente, están obsoletos.
  98. Eres enviado a una conferencia a aprender, pero te saltas las sesiones para ir a ver si pillas algo.
  99. El personal de QA te apoda "Jefe Off-by-one".
  100. Tenéis el 90% del software completo el 90% del tiempo.
  101. "Oh, oh, casi se me olvida. Ah, voy a necesitar que vengáis también este domingo... gracias".


Post original: 101 Ways To Know Your Software Project Is Doomed
Publicado en: Variable not found

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

miércoles, 27 de febrero de 2008
Bonito plato de spaghettiSabemos que los patrones son plantillas reutilizables que podemos usar para solucionar problemas habituales en el proceso de desarrollo de software. Así, permiten utilizar soluciones fiables y bien conocidas a problemas concretos, aprovechando experiencias previas como base para la consecución de mejores resultados en los nuevos desarrollos.

Pues bien, justo en el lado opuesto se encuentran los antipatrones, que definen situaciones y comportamientos que, según experiencias anteriores, nos conducen al fracaso en proyectos de desarrollo de software, es decir, son soluciones o planteamientos que se han demostrado incorrectos.

Y es ahí donde radica su interés: la observación y conocimiento de los mismos puede evitarnos resultados desastrosos, o actuar como alertas tempranas ante decisiones o dinámicas incorrectas, permitiéndonos prevenir, evitar o recuperarnos de estos problemas.

Al igual que en los patrones, su descripción está relativamente formalizada y suele recoger los siguientes aspectos:
  • nombre del antipatrón, así como su "alias"
  • su tipología: organizacional, de análisis, desarrollo... (veremos esto más tarde)
  • contexto y entorno en el que se aplica
  • descripción del problema concreto
  • síntomas, y consecuencias de la aplicación del antipatrón
  • causas típicas y raíces del problema
  • refactorización a aplicar, es decir, una descripción de cómo podríamos replantear el problema y conseguir una solución positiva.
  • ejemplos y escenarios para su comprensión.
  • soluciones relacionadas con la propuesta.

Por ejemplo, un resumen del clásico antipatrón que reconoceréis muy rápidamente, el llamado spaghetti code:

Nombre:Spaghetti Code
Tipología:Desarrollo
Problema:Existencia de una pieza de código compleja y sin apenas estructura que dificulta enormemente su mantenimiento posterior
Síntomas y consecuencias:
  • Tiempo de mantenimiento excesivo debido a la necesidad de estudio del código
  • Código no reutilizable
  • Aparición del temido "es mejor reescribirlo"
  • Métodos y funciones muy extensas
  • Abuso de variables globales
Causas:
  • Inexperiencia de desarrolladores
  • Reutilización de código de prototipos rápidos
  • Ausencia de diseño previo a la implementación
  • Desarrolladores trabajando en solitario
  • Falta de revisiones de código
Solución positiva:
  • Aplicar refactorización mientras se programa
  • Usar disciplinas de desarrollo específicas, métricas y buenas prácticas
  • Realizar y desarrollar el diseño del sistema antes de implementar

Según según la Wikipedia, los antipatrones se clasifican en los siguientes grupos, atendiendo a las áreas a las que afectan:
  • Antipatrones Organizacionales, que incluyen prácticas nocivas a este nivel, como pueden ser, entre otros:
    • Gestión de champiñones (Mushroom management), o mantener al equipo en la oscuridad, desinformado, y cubierto de porquería.
    • Parálisis en análisis (Analysis paralysis), o quedar inmovilizado debido a un análisis o precaución excesiva, en contraposición a la siguiente:
    • Extinción por intuición (Extint by instinct), llegar a la muerte por adelantarse demasiado y usar la intuición para la toma de decisiones.
  • Antipatrones de Gestión de proyectos, describiendo problemas en la gestión de proyectos, como los célebres:
    • Marcha de la muerte (Death march), que describe el avance de determinados proyectos hacia el fracaso aunque todo el personal, excepto los gerentes, saben que al final se darán el castañazo.
    • Humo y espejos (Smoke and mirrors), o la demostración de funcionalidades o características no implementadas como si fueran reales, lo que siempre he llamado "enseñar cartón piedra".
  • Antipatrones de Gestión de equipos, que recoge problemas relacionados con la relación con y de equipos de trabajo, como:
    • Doble diabólico (traducción libre del término Doppelganger), personas que dependiendo del día pueden ser magníficos colaboradores o auténticos demonios.
    • Gestor ausente (Absentee manager), describiendo situaciones en las que el director está invisible periodos prolongados
  • Antipatrones de Análisis, categoría que engloba antipatrones relacionados con la fase analítica de los proyectos software, entre otros:
    • Retroespecificación (Retro-specification), o lo que viene a ser la realización del análisis una vez implementada la solución.
    • Especificación de servilleta (Napkin specification), también muy socorrida, que consiste en pasar al equipo de desarrollo las especificaciones del producto a crear descritas con muy poco detalle o informalmente.
  • Antipatrones de Diseño, que incluye malas prácticas de diseño de software que dan lugar a aplicaciones y componentes estructuralmente incorrectos:
    • Gran bola de lodo (Big ball of mud), realización de aplicaciones sin estructura reconocible.
    • Factoría de gas (Gas factory), diseños innecesariamente complejos.
    • Botón mágico (Magic Pushbutton), o implementación de funcionalidades directamente en los manejadores de evento (p.e., click) del interfaz.
  • Antipatrones en Orientación a objetos, como una especialización del anterior, describe problemas frecuentes en los diseños creados bajo este paradigma, como:
    • Llamar al super (Call super), obligar a las subclases a llamar a la clase de la que heredan.
    • Singletonitis, abuso del patrón singleton.
    • Orgía de objetos (Object orgy), o encapsulación incorrecta en clases que permite el acceso incontrolado a sus métodos y propiedades internas.
    • Otra jodida capa más (YAFL, Yet another fucking layer), o la inclusión excesiva de capas en un sistema.
  • Antipatrones de Programación, con un gran número de errores frecuentes a evitar, como:
    • Spaghetti code, comentando anteriormente.
    • Ravioli code, que consiste en la existencia de un gran número de objetos desconectados o débilmente acoplados entre sí.
    • Ocultación de errores (Error hiding), o capturar errores antes de que lleguen usuario, mostrando mensajes incomprensibles o simplemente no mostrar nada.
    • Números mágicos (Magic numbers), incluir números inexplicables en el código.
  • Antipatrones Metodológicos, o formas de desarrollar que se han demostrado incorrectas a lo largo del tiempo, como pueden ser:
    • Programación copy & paste, también llamada herencia de editor, consiste en copiar, pegar y modificar, en contraposición a la estritura de software reutilizable.
    • Factor de improbabilidad (Improbability factor), asumir que un error conocido es improbable que ocurra.
    • Optimización prematura (Premature optimization), según algunos la raíz de todos los males, consiste en sacrificar el buen diseño y mantebilidad de un software en benecificio de la eficiencia.
    • Programación por permutación (Programming by permutation), o intentar dar con una solución modificando sucesivamente el código para ver si funciona.
  • Antipatrones de Gestión de configuración, hace referencia a antipatrones relacionados con la gestión de los entornos de desarrollo y explotación del software, como las variantes del infierno de las dependencias (Dependency hell), o problemas de versionado de librerías y componentes:
    • DLL's Hell, el conocido y traumático mundo de las librerías dinámicas en Windows.
    • JAR's Hell, idem, pero relativo a las librerías Java.

Por no hacer el post eterno sólo he recogido unos cuantos, aunque existen cientos de ellos, y con una gran variedad temática: antipatrones para el desarrollo guiado por pruebas (TDD), antipatrones de manejo de excepciones, para el uso de arquitecturas orientadas al servicio (SOA), de rendimiento, de seguridad, centrados en tecnologías (p.e., J2EE antipatterns) o según el tipo de software (sistemas de gestión, tiempo real, videojuegos, etc.).

Y como conclusión personal, decir que me he visto reconocido en multitud de ellos, lo cual significa que muy descaminados no andan. Es más, si hiciera una lista con patrones y otra con los antipatrones que utilizo o he utilizado, la segunda tendría más elementos que la primera... ¿quizás es momento de reflexionar un poco?

Publicado en: http://www.variablenotfound.com/.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

jueves, 6 de diciembre de 2007
Por cortesía de Mergia, ya es posible ver en vivo el sitio web de demostración de NiftyDotNet, el componente que ha supuesto mi primera aportación al mundo del software libre.

NiftyDotNet, para el que no lo conozca, es un componente ASP.Net para las plataformas Mono y Microsoft, que encapsula la librería javascript Nifty Corners Cube para conseguir redondear las esquinas de elementos de una página web de una forma realmente sencilla. Basta con arrastrar los controles sobre un Webform, indicarles los elementos que se verán afectados y listo.

Ejemplo de uso de NiftyDotNet

Publicado en: Variable Not Found.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

lunes, 23 de julio de 2007
El siempre sorprendente Phil Haack nos regaló hace unos días un post sobre leyes relacionadas con el desarrollo de software en su post "19 Eponymous Laws Of Software Development". Del artículo me llamaron la atención dos cosas: primero, ¿qué diantres es un epónimo? y segundo, las leyes objeto del post; algunas eran muy conocidas, otras menos, pero en cualquier caso, son perlas dignas de tener en cuenta.

Un epónimo es el nombre de una persona o lugar que cede su nombre a una época, pueblo, unidad, ley, etc. Son epónimos por ejemplo "Diesel", cedido por Rudolf Diesel, inventor de este tipo de motores, o "Hamburguesa", infame trozo de carne picada cuyo nombre le fue cedido por su lugar de origen. Para los curiosos, en esta dirección encontraréis muchos más epónimos.

Solventada esta primera duda, pasamos a ver las leyes epónimas a las que Phil hace referencia. De las diecinueve originales he seleccionado las que me han resultado más interesantes y cercanas, añadiendo algo de información sobre sus autores, orígenes o curiosidades sobre las mismas. Me tendréis que perdonar por esto, pero voy a partir el post en dos entregas para no hacerlo demasiado largo.

Ley de Postel

Sé conservador en lo que hagas y liberal en lo que aceptes de los demás
Esta frase, de Jonathan Bruce Postel, también llamada Principio de Robustez, es la piedra filosofal del protocolo TCP, y está recogida en la RFC 793, sección 2.10, de septiembre de 1981.

Ley de Parkinson

El trabajo se extiende siempre hasta rellenar la totalidad del tiempo disponible para completarlo
Esta ley fue postulada inicialmente en 1955 por C. Northcote Parkinson en The Economist y más tarde entró a formar parte de su libro, basado principalmente en las experiencias de la administración británica.

Principio de Pareto

Para muchos fenómenos, el 80% de las consecuencias derivan del 20% de las causas
Wilfredo Pareto fue un estudioso de la economía y sociología del siglo XIX, y se fijó que el 80% de las propiedades y riqueza estaban repartidas entre el 20% de la población, enunciando su famoso principio. A partir de ahí, se piensa que esta proporción es cierta en múltiples ocasiones, hasta en el número de bugs en el código fuente de un software, o el tiempo de desarrollo de funcionalidades.

Revelación de Sturgeon

El noventa por ciento de cualquier cosa es una porquería
Theodore Sturgeon era un autor de ciencia ficción americano que escribió esta frase defendiendo a este tipo de literatura de críticos que opinaban que el 90% era basura. Hay un corolario que dice "La revelación de Sturgeon es cierta salvo para la porquería, donde el 100% es porquería".

El principio de Peter

En una jerarquía, todo individuo tiende a subir hasta alcanzar su nivel de incompetencia
Seguro que todos conocéis ejemplos de ello: un fabuloso desarrollador es ascendido a directivo en una empresa, la cual gana un gestor pésimo y pierde un programador excelente. Doble penalización. Lawrence J. Peter, pedagogo de profesión, ya lo enunció en 1968 en el libro El principio de Peter.

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
Esta genial y recursiva Ley creada por el científico, filósofo y académico estadounidense Douglas Hofstadter es absolutamente cierta. Y si no, pensad un poco, ¿cuántas veces habéis estimado un desarrollo, lo habéis incrementado de forma considerable por los imprevistos y aún así os habéis quedado cortos?

Ley de Murphy

Si algo puede ir mal, lo hará
La famosa ley, también enunciada en forma de tostada que recurrentemente cae con la mantequilla hacia abajo, fue dictada por Edward A. Murphy, Jr., mientras trabajaba para la fuerza aérea americana como ingeniero, diseñando un sistema de cohetes experimental. Sería lógico pensar que el experimento acabó en tragedia, pero parece ser que la creación y consideración de esta ley les ayudó a evitar graves desastres en sus pruebas.

Ley de Brook

Incluir trabajadores a un proyecto retrasado hará que vaya aún más lento
Fred Brooks postuló esta ley en su famoso libro The Mythical Man-Month: Essays on Software Engineering como resultado de su experiencia en IBM. Existen variantes y corolarios como "Una señora es capaz de tener un hijo en nueve meses, pero este plazo no puede disminuir por muchas mujeres embarazadas que pongamos a ello". Simplemente genial.

Bueno, ya vale por hoy, pero amenazo con prometo seguir pronto.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons