Autor en Google+
Saltar al contenido

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

10 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, ASP.NET Core, MVC, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
domingo, 7 de febrero de 2010
Este post es la tercera y última entrega de la serie 30 Leyes epónimas relacionadas con el desarrollo de software. Puedes encontrar la segunda parte aquí.

Tim Bryce

21. Las leyes de Bryce

Así las llama él, aunque algunas encajarían mejor en una recopilación de frases célebres. Ahí van algunas, aunque pueden encontrarse más de 150 aquí.


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

[...]

Tim Bryce es un controvertido escritor y consultor de gestión de recursos de información (IRM), famoso entre otras cosas por sus aseveraciones sobre el ego, las manías y extrañezas de los desarrolladores, y sus consejos para manejarlos apropiadamente. Aparte de su habilidad para hacer amigos entre los programadores, es sin duda un gran experto en el mundo de las compañías de desarrollo de software, con más de 30 años a sus espaldas en este campo.

Eugene Spafford

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

Eugene Spafford, más conocido como "Spaff", es un reputado experto en seguridad informática y profesor de la Purdue Univertity. Según parece, fue uno de los primeros en escribir un libro sobre virus informáticos en 1989, utilizar el término autopsia software para referirse al análisis de aplicaciones para intentar localizar a sus autores, y un sinfín de aportaciones al mundo de la seguridad en sistemas informáticos.

Además, es tan prolífico creando frases y analogías a la hora de explicar conceptos de informáticos que Mahesh V. Tripunitara, uno de sus estudiantes, mantiene una página donde las recoge: "The Page of Spaf's Analogies".

Aloysius Alzheimer

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
Efectivamente, el psiquiatra y neurólogo alemán Aloysius Alzheimer no enunció esta ley a primeros del siglo pasado, pues estaba muy ocupado estudiando las enfermedades mentales de sus pacientes. Sin embargo, el síntoma de pérdida de memoria tan habitual en ellos propició la utilización de su nombre en esta Ley tan ligada a la escritura de código limpio, documentado y sencillo.

Roy Amara

24. Ley de Amara

Tendemos a sobreestimar el efecto de la tecnología en el corto plazo y a subestimarla a largo plazo
Esta ley, causa de la existencia de problemas debidos a excesos de optimismo o de la formulación de predicciones disparatadas, fue enunciada por Roy Amara, que fue presidente del Instituto para el Futuro, un grupo de investigación sin ánimo de lucro dedicado al análisis de tendencias que ayuden a la toma de decisiones basándose en predicciones sobre el futuro.

Barbara Liskov

26. Principio de Liskov

Los subtipos deben ser sustituibles por sus clases bases
O en otras palabras, que un subtipo no debe modificar el comportamiento esperado de la clase de la que hereda; de esta forma, si el subtipo puede sustituir a su clase base sin causar daños, la herencia será correcta. Citando a Enrique Place en PHPSenior, "No basta con ser hay que comportarse como tal".

Barbara Liskov es profesora del Massachusetts Institute of Technology (MIT) y fue la primera mujer en conseguir el doctorado en informática de Estados Unidos.

Hick no se dejó hacer la foto ;-)

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
Puede sonar a obvio, pero la cuestión es que William Edmund Hick, pionero en psicología experimental y ergonomía, fue capaz de idear, a mediados del siglo pasado, la fórmula que explica por qué tardamos tanto tiempo en responder a un cuadro de diálogo con botones para Aceptar, Cancelar, Reintentar, Ignorar y Omitir:
T = blog2(n + 1)
Cosas de las matemáticas, seguro. :-D

Robert A. Heinlein, uno de los posibles padres del principio de Hanlon

27. Principio de Hanlon

Nunca le atribuya a la maldad lo que puede ser explicado por la estupidez
A pesar de su nombre, no está claro quién definió con tanta claridad su confianza en la capacidad del ser humano. Bill Clarke, Goethe, William James, Napoleón Bonaparte, Richard Feynmann, Einstein, Robert A. Heinlein (cuyo apellido podría haber degenerado en "Hanlon"), o un desconocido Robert J. Hanlon del que no existen demasiadas referencias podrían ser los padres de esta Ley tan utilizada por los hackers para definir situaciones creadas como consecuencia del trabajo de incompetentes sin mala intención.

Bill Joy

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
También formulada como "no importa quien seas, la mayoría de la gente inteligente trabaja para otro", la Ley dictada por Bill Joy ofrece una visión un tanto pesimista (¿realista?) de nosotros mismos y nuestro entorno de trabajo. Pero ojo, que no lo decía cualquiera, que este señor es co-fundador de Sun y, probablemente, estuviera describiendo lo que veía.

Tim Lister

29. Ley de Lister

La gente bajo presión no piensa más rápido
Bonita frase para escribir en un post-it y pegárselo en la frente a alguien a ver si se da por aludido. Y es que efectivamente, la presión y la velocidad de pensamiento no son magnitudes proporcionales, pero es Tim Lister, un consultor, formador y escritor experto en gestión de riesgos en procesos de desarrollo de software, el que lo enunció de esta forma tan tajante y certera.



William of Ockham

30. La navaja de Occam

En igualdad de condiciones la solución más sencilla es probablemente la correcta
En el siglo XIV, Guillermo de Ockham, fraile franciscano y filósofo, postulaba de esta forma el principio de economía, utilizada en disciplinas tan dispares como la teología, informática o lingüística. De hecho, podríamos considerarlo la base de principios como KISS (Keep It Simple, Stupid), o YAGNI (You ain't gonna need it), asociados habitualmente a la programación extrema pero válidos en cualquier tipo de desarrollo.

Una curiosidad, el tercer episodio de la primera temporada de la serie House tenía este título, haciendo referencia a la solución del caso médico propuesto.




Fuentes:

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

2 Comentarios:

Anónimo dijo...

Liskov es mujer !?

Xiuh Blaze dijo...

Yo tengo otra: Cuando un código funciona a la primera es porque algo está mal.