Y ya se dieron cuenta de esto los padres de la informática, aquellos pioneros que hace cincuenta años andaban sentando las bases sobre las que se sustentan las tecnologías, herramientas y lenguajes que utilizamos hoy.
La programación sin ego, o egoless programming, es una forma de programar basada en el aprendizaje continuo y colaboración entre personas, dejando de lado los aspectos puramente personales y comportamientos ególatras que podemos tener algunas veces. La idea fue acuñada por Jerry Weinberg en su libro The Psychology of Computer Programming, publicado publicado en 1971.
En este libro aparecieron por primera vez los Diez Mandamientos del Egoless Programming, que creo que deberían ser unas normas de lectura y aplicación obligatoria en nuestra profesión.
Los Diez Mandamientos del egoless programming
1. Entiende y acepta que cometerás errores.La cuestión es encontrarlos pronto, antes de que lleguen a producción. Afortunadamente, salvo para los pocos que desarrollan software de guiado de misiles, los fallos tienen raramente consecuencias fatales en nuestra industria, así que podemos, y deberíamos, aprender, reírnos, y seguir adelante.
2. Tú no eres tu código.
Recuerda que el objetivo de una revisión es encontrar problemas, y se encontrarán problemas. No te lo tomes personalmente cuando un error tuyo se descubra.
3. No importa cuánto “karate” sepas, siempre alguien sabrá más.
Esa persona puede enseñarte algunos movimientos nuevos si se lo pides. Busca y acepta información de otros, especialmente cuando piensas que no es necesario.
4. No reescribas código sin consultarlo antes.
Hay una fina línea de separación entre “corregir código” y “reescribir código”. Conoce la diferencia y realiza los cambios en el marco de una revisión de código, y no actuando como un justiciero solitario.
5. Trata a los que saben menos que tú con respeto, educación y paciencia.
La gente no técnica que trata con desarrolladores de forma frecuente casi siempre tienen la opinión de que en el mejor de los casos somos divas, y en el peor, llorones. No refuerces este estereotipo con ira e impaciencia.
6. La única constante en el mundo es el cambio.
Permanece abierto a ello y acéptalo con una sonrisa. Mira cada cambio a tus requisitos, plataforma o herramientas como un reto, no como un inconveniente contra el que hay que luchar.
7. La única autoridad real deriva del conocimiento, no de la posición.
El conocimiento genera autoridad, y la autoridad engendra respeto. Así que si quieres ser respetado en un entorno egoless, cultiva el conocimiento.
8. Lucha por lo que crees, pero acepta la derrota con deportividad.
Entiende que a veces tus ideas serán ignoradas. Incluso si resulta que estabas en lo cierto, no seas vengativo o digas “te lo dije” más de un par de veces, ni hagas de tu difunta idea una mártir o un grito de guerra.
9. No seas “ese tío de la habitación”.
No seas ese tío programando en una oficina oscura que emerge sólo para comprar coca-cola. Ese tío está fuera de la vista, del tacto, fuera de control y no tiene cabida en un entorno abierto y colaborativo.
10. Critica el código y no a la gente.
Sé amable con el desarrollador pero no con el código. Haz comentarios relacionados con los estándares locales, especificaciones de la aplicación, incrementos de rendimiento, etc.
Publicado en Variable not found.
Publicado por José M. Aguilar a las 9:05 a. m.
Etiquetas: buenas prácticas, leyes
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í.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.
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
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".
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 vezEfectivamente, 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.
24. Ley de Amara
Tendemos a sobreestimar el efecto de la tecnología en el corto plazo y a subestimarla a largo plazoEsta 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.
26. Principio de Liskov
Los subtipos deben ser sustituibles por sus clases basesO 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.
25. Ley de Hick
El tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativasPuede 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
27. Principio de Hanlon
Nunca le atribuya a la maldad lo que puede ser explicado por la estupidezA 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.
28. Ley de Joy
El número de empleados inteligentes en una empresa es una función logarítmica del número de empleados totalesTambié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.
29. Ley de Lister
La gente bajo presión no piensa más rápidoBonita 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.
30. La navaja de Occam
En igualdad de condiciones la solución más sencilla es probablemente la correctaEn 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:
- 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
Publicado en: Variable not found.
Publicado por José M. Aguilar a las 11:24 p. m.
Etiquetas: buenas prácticas, curiosidades, epónimos, frases célebres, leyes, software
11. Ley de Linus
Dados suficientes ojos, todos los errores son obviosPues sí, Linus Torvalds, uno de los más famosos artífices de Linux tal y como es conocido hoy en día, no sólo desarrollaba software, también emitía este tipo de aseveraciones en las que exponía las ventajas del modelo de desarrollo cooperativo y abierto frente al propietario; otros simplemente ven esta teoría como una barbaridad desde el punto de vista de la seguridad y mantenimiento de los sistemas.
Aunque la frase fue cosa de Linus, fue Eric S. Raymond, un hacker a la antigua usanza, el que la popularizó y le dio el nombre de su creador.
12. Ley de Reed
La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la redDavid P. Reed, científico americano, enunció esto que parece obvio en los tiempos actuales dado el tamaño y utilización de este tipo de redes. En esta entrada de la wikipedia podéis encontrar una introducción del soporte teórico en el que se basa, que explica en esencia la facilidad con la que crece el número de subgrupos posibles entre usuarios en relación al número de usuarios o de pares.
13. Ley de Moore
La potencia de los ordenadores se duplica cada dos años, reduciendo además su costeRepetida hasta la saciedad en revistas de cacharreo, y constatada desde hace décadas, fue promulgada por Gordon Earl Moore, quien por cierto es co-fundador de Intel, fijaos si lo tenía claro el muchacho, en 1965 (!). No sé si entonces utilizó la bola de cristal, era una declaración de intenciones, o simplemente es un genio, pero desde luego su ley es una referencia de la medida del avance en los ordenadores y demás dispositivos basados en tecnología similar, y un objetivo mínimo a cumplir.
14. Ley de Wirth
El software se ralentiza más deprisa de lo que se acelera el hardwareBrillante la frase de Niklaus Wirth, que allá por el año 1995, aún sin conocer Windows Vista, observó su entorno y predijo la situación actual: cada vez el software es más lento y pesado, a pesar de que según la Ley de Moore tendría que ser al contrario. Este señor, una eminencia, es conocido sobre todo por haber dirigido la creación de los lenguajes Pascal, Modula y algunos otros menos difundidos.
¿Será coincidencia que en ese mismo año, 1995, fue el lanzamiento oficial de Java? ;-P
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 capacidadLo que más me ha llamado la atención de Jamie Zawinski aparte de su metafórica ley que critica el crecimiento, a veces sin sentido, del software, es su página web personal. No os la perdáis, pues es bastante indicativa del tipo de individuo de que se trata, todo un friki, padre entre otros de una versión de Netscape, Grendel, Netscape Mail & News, Lucid Emacs, etc. También es curioso que es propietario de un club nocturno en San Francisco, este sí que sabe ;-)
16. Las tres Leyes de Clarke
El conocido científico y escritor británico Sir Arthur Charles Clarke enunció estas tres leyes porque, según comentaba,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.
"si tres leyes fueron suficientes para Newton, modestamente decido parar aquí".
Arthur C. Clarke fue autor de un gran número de libros, relatos y obras de divulgación, destacando su novela y participación en el guión de 2001: Una odisea en el espacio.
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 provocarEste complemento perfecto para el Principio de Peter fue observado por Scott Adams, autor de Dilbert, una popular tira cómica sobre el mundo de la empresa que se publica en 1200 periódicos de todo el mundo.
Scott Adams es considerado uno de los 50 pensadores más influyentes en el mundo de la empresa, incluso por encima de personajes como Steve Jobs o Al Gore. Se trata, además, de un epónimo curioso en cuanto a que su nombre no proviene directamente de su autor, sino de la obra de su autor.
18. Ley de Gilder
El ancho de banda aumenta a un ritmo tres veces superior a la potencia de los ordenadoresPues sí, cualquiera lo hubiera dicho hace unos años... pero la verdad es que hoy en día la velocidad en las conexiones a la red son increíbles. Y por suerte, sin subir proporcionalmente el coste ;-)
George Gilder es un controvertido escritor e intelectual americano, entusiasta de la tecnología e internet, que en la actualidad dirige el Gilder Technology Report, un sitio exclusivo de información de ámbito económico y tecnológico. Según comentan, "sus hijos no estudian español, sino C++" (visto en Wikiquote).
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
Esta ley, de gran aplicación en el cálculo de rendimiento de sistemas cuando uno de sus componentes es mejorado o en contextos de procesamiento en paralelo, fue enunciada por Gene Myron Amdahl en 1967, en sus tiempos como trabajador de IBM Corporation, que abandonó varias veces por disconformidad con el escaso trato humano en esta empresa, muy encorsetada y llena de burocracia.
Según demuestra matemáticamente, llegados a un punto el rendimiento de un sistema no está relacionado con el número de procesadores instalados, sino con la eficiencia de los algoritmos empleados.
20. Ley de Myhrvold
El software es un gas; se expande hasta rellenar su contenedorClaro, esto explica por qué da igual la potencia y capacidad del ordenador que tengamos: nuestro software lo llenará como si se tratara de un globo, hasta ponerlo a reventar.
Y lo dijo ni más ni menos que Nathan Myhrvold, ex-director de tecnología de Microsoft y fundador de Intellectual Ventures, una empresa dedicada crear y patentar, pero curiosamente no a poner en explotación, inventos para sectores como el software, semiconductores, redes, lásers, biotecnología y otros dispositivos.
Continuar en 30 Leyes épónimas relacionadas con el desarrollo de software (y III).
Publicado en: Variable not found
Publicado por José M. Aguilar a las 11:22 p. m.
Etiquetas: buenas prácticas, curiosidades, epónimos, frases célebres, leyes, software
Hace unos años, el gran Phil Haack posteó sobre leyes epónimas relacionadas con el desarrollo de software en "19 Eponymous Laws Of Software Development", y seleccioné las que me resultaron más interesantes en un par de posts.
Ahora los he vuelto a maquetar y les he añadido un nuevo conjunto de leyes muy interesantes para todos los que nos dedicamos al mundo del desarrollo de software, y muchas de ellas incluso aplicables a otros ámbitos.
1. Ley de Postel
Sé conservador en lo que hagas y liberal en lo que aceptes de los demásEsta 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.
2. Ley de Parkinson
El trabajo se extiende siempre hasta rellenar la totalidad del tiempo disponible para completarloEsta 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.
3. Principio de Pareto
Para muchos fenómenos, el 80% de las consecuencias derivan del 20% de las causasVilfredo 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.
4. Revelación de Sturgeon
El noventa por ciento de cualquier cosa es basuraTheodore 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 una porquería.
Hay un corolario que dice
"La revelación de Sturgeon es cierta salvo para la basura, donde el 100% es basura".
5. El principio de Peter
En una jerarquía, todo individuo tiende a subir hasta alcanzar su nivel de incompetenciaSeguro 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.
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 HofstadterEsta 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 plazos en un desarrollo, lo habéis incrementado de forma considerable por los imprevistos y aún así os habéis quedado cortos?
7. 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.
8. Ley de Brooks
Incluir trabajadores en un proyecto retrasado hará que éste avance aún más lentamenteFred 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.
9. Ley de Conway
Cualquier software refleja la estructura organizacional de quien lo produjoA pesar de que suena a guasa, la ley de Melvin Conway no puede ser más cierta. Una empresa con tres grupos de desarrollo tenderá a generar software distribuido en tres subsistemas, reflejo fiel de las relaciones entre los grupos participantes. Y por cierto, extrapolando un poco... ¿habéis pensado alguna vez que el software que se hace en vuestra empresa es un desastre? ¿creéis que con esta ley podríais obtener alguna conclusión? ;-D
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ónEs increíble que Auguste Kerckhoffs lingüista y criptógrafo alemán, enunciara en el siglo XIX este principio, base de todos los sistemas de criptografía de clave pública actuales.
Publicado en: http://www.variablenotfound.com/.
Publicado por José M. Aguilar a las 11:20 p. m.
Etiquetas: buenas prácticas, curiosidades, epónimos, frases célebres, leyes, software
Ley de Conway
Cualquier software refleja la estructura organizacional de quien lo produjoA pesar de que suena a guasa, la ley de Melvin Conway no puede ser más cierta. Una empresa con tres grupos de desarrollo tenderá a generar software distribuido en tres subsistemas, reflejo fiel de las relaciones entre los grupos participantes. Y por cierto, ¿habéis pensado alguna vez que el software que se hace en vuestra empresa es un desastre? ¿creéis que con esta ley podríais obtener alguna conclusión? ;-D
Principio de Kerchkhoff
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ónEs increíble que Auguste Kerckhoffs critógrafo alemán, enunciara en el siglo XIX este principio, base de todos los sistemas de criptografía de clave pública actuales.
Ley de Linus
Dados suficientes ojos, todos los errores son obviosPues sí, Linus Torvalds, uno de los más famosos artífices de Linux tal y como es conocido hoy en día, no sólo desarrollaba software, también emitía este tipo de aseveraciones. Aunque la frase fue cosa de Linus, fue Eric S. Raymond, un hacker a la antigua usanza, el que la popularizó y le dio el nombre de su creador.
Ley de Reed
La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la redDavid P. Reed, científico americano, enunció esto que parece obvio en los tiempos actuales dado el tamaño y utilización de este tipo de redes. En esta entrada de la wikipedia podéis encontrar una introducción del soporte teórico en el que se basa.
Ley de Moore
La potencia de los ordenadores se duplica cada dos años, reduciendo además su costeRepetida hasta la saciedad en revistas de cacharreo, y constatada desde hace décadas, fue promulgada por Gordon Earl Moore quien, por cierto, es co-fundador de Intel, fijaos si lo tenía claro el muchacho, en 1965 (!). No sé si entonces utilizó la bola de cristal o es simplemente un genio, pero desde luego su ley es una referencia de la medida del avance en los ordenadores y demás dispositivos basados en tecnología similar, y un objetivo mínimo a cumplir.
Ley de Wirth
El software se ralentiza más deprisa de lo que se acelera el hardwareBrillante la frase de Niklaus Wirth, que allá por el año 1995, aún sin conocer Windows Vista, observó su entorno y predijo la situación actual: cada vez el software es más lento y pesado, a pesar de que según la Ley de Moore tendría que ser al contrario. Este señor, una eminencia, es conocido sobre todo por haber dirigido la creación de los lenguajes Pascal, Modula y algunos otros menos difundidos.
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 capacidadLo que más me ha llamado la atención de Jamie Zawinski aparte de su metafórica ley, es su página web personal. No os la perdáis, pues es bastante indicativa del tipo de individuo de que se trata, todo un friki. También es curioso que es propietario de un club nocturno en San Francisco, este sí que sabe.
Enlaces relacionados: leyes epónimas relacionadas con el desarrollo de software (I)
Publicado por José M. Aguilar a las 10:36 p. m.
Etiquetas: curiosidades, epónimos, leyes, productividad, programación