Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Nola Editores
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Spanisch
Los que no conocen la Historia están condenados a repetirla, pero en el caso de la tecnología, tampoco entenderán el futuro que está llegando. La Informática ha transformado por completo nuestra sociedad en apenas 50 años y se ha convertido en una disciplina transversal y, a día de hoy, imprescindible. Los que no sepan trabajar con ordenadores serán los analfabetos del futuro. Sin embargo, a pesar de su enorme importancia, sus fundamentos y su historia suelen ser completamente ignorados por el público general e incluso por los propios informáticos. Este libro presenta una selección de textos relacionados con la Historia de la Informática, redactados para que cualquiera pueda entenderlos y disfrutarlos. Una ventana al poder transformador de la tecnología y una guía para adivinar a dónde nos lleva. El algoritmo que cambió el mundo habla de sus ilustres protagonistas, de sus motivaciones y, en resumen, de por qué la realidad digital es tal y como la conocemos hoy día. Si somos capaces de comprender el origen de nuestras herramientas electrónicas actuales, seremos capaces de reconocer las nuevas formas en las que nos relacionaremos con ellas mañana. Para Douglas Engelbart, el inventor del ratón, la tecnología era solo un medio para conseguir un fin: ayudar a la Humanidad a colaborar y progresar. La responsabilidad y el propósito de estas páginas es difundir y preservar su legado.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 325
Veröffentlichungsjahr: 2025
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
DAVID BONILLA
EL ALGORITMO QUE CAMBIÓ EL MUNDO
Y otras historias informáticas
© de la presente edición, Nola editores
© David Bonilla, 2024
Maquetación: Ostraca Servicios editoriales
Diseño de cubierta e ilustraciones de interior: Hugo Tobío
Primera edición: noviembre de 2024
Nola Editores
Apdo. de Correos 7065
c/Palos de la Frontera, 6-10
28012 Madrid (España)
<www.nolaeditores.com>
Nola Editores es un sello editorial perteneciente a Proyectos de Difusión de Contenido, S.L.
<www.prodiko.es>
Cualquier forma de reproducción, distribución, comunicación pública o transformación de esta obra puede ser realizada con la autorización de sus titulares, salvo excepción prevista por la ley. Diríjase a CEDRO (Centro Español de Derechos Reprográficos) si necesita fotocopiar o escanear algún fragmento de esta obra (www.conlicencia.com; 91-7021970/93-2720445).
ISBN: 978-84-18164-52-1
Depósito Legal: M-24.154-2024
A Cris y Hugo, por empujarme para que este libro saliera a la luz.
A Alejandro, por atreverse a editarlo.
A Bea, Yeray y Jero, por ayudarme a que cada texto saliera con muchas menos faltas de ortografía.
Y —sobre todo— a todos los suscriptores de la Bonilista, que me han llevado en volandas durante más de trece años.
Muchas gracias.
Índice
Nota del Editor
Prólogo
Años 50 y 60
1. El Test de Turing
2. La Ley De Gordon
3. Revisando la Ley de Conway
Cómo sobrevivir a la Ley de Conway
Conway y el trabajo remoto
4. La madre de todas las demos
Años 70
5. 50 años de SQL
6. La historia del lenguaje C
El lenguaje de programación que lo cambió todo
7. Un día para la historia
Tal día como hoy, 3 de abril, 3 dispositivos cambiaron nuestra vida para siempre
8. El algoritmo que cambió el mundo
La historia de la fórmula matemática que consiguió eliminar la distancia entre nosotros y nuestros seres queridos
9. El cubo de Ernö
10. La hoja de cálculo que lo cambió todo
Años 80
11. Sinclair
12. La historia de Sun Microsystems, 1.ª parte: Network is the Computer
13. Juegos de guerra
Hace cuarenta años se estrenó la película que más vocaciones ha despertado en la historia de la informática
14. Las Stevenotes
El trabajo —y la estrategia— detrás de las presentaciones de Steve Jobs
15. El juego de Alexey
Go West
Big in Japan
Trololó
Ground Theme
Happy? End
Epílogo
16. El legado de Lord Sugar
El nacimiento del 464
Corrigiendo un sesgo de cuarenta años
El verdadero legado de Sugar
17. El fontanero bigotudo
World 1-1: el fracaso que se convirtió en éxito
World 1-2: el título que salvó la industria de los videojuegos
World 1-3: de personaje a símbolo
18. La historia del GIF
19. El año en que los videojuegos cambiaron para siempre
20. El día del cuanto
21. Los granjeros que decidieron hacer videojuegos
El château
Rayman
Tormenta Roja
La OPA
1. Apuesta por los océanos azules
2. Captura de toda la cadena de valor
3. Adquieren talento por tierra, mar y aire
4. Mantienen la relación con sus antiguos empleados
Años 90
22. El juego de mi vida
23. El código de Masahiro
24. El software más usado (y más ignorado) de tu ordenador
Tomándonos la diversión (muy) en serio
El punto de no retorno
La consola de Bill
Epílogo
WWW: Wild wild west
De la petición a la sesión
El caso de uso que Montulli nunca imaginó
Un mundo post-cookies
27. La librería que cambió el mundo
El trato al empleo no cualificado
Los impuestos
Las patentes
Algo debe cambiar, pero no solo Amazon
Epílogo: Work hard. Have fun. Make history
28. La Vida de Bob
29. La historia de Sun Microsystems, 2.ª parte: Write Once. Run Everywhere
30. La Muerte de Flash
El próximo 31 de diciembre nos dejará una de las tecnologías que ayudaron a definir la red tal y como ahora la conocemos
31. Cinco lecciones que aprender de la historia de Hotmail
1. La integración en una compañía de una empresa o tecnología adquirida siempre es un reto y, también, una oportunidad
2. El éxito en los negocios tiene que ver con la capacidad, el esfuerzo y —sobre todo— la suerte y la oportunidad
3. Uno de los peores errores que puedes cometer es enamorarte de tu marca o producto en lugar de hacerlo de tu equipo y de tus usuarios
4. El marketing con mejor retorno de inversión es el viral. Si consigues que funcione, claro está
5. Todos tenemos sesgos y, por supuesto, algunos están directamente relacionados con la tecnología
32 😃
En 2022, los emojis cumplen veinticinco años. Esta es la historia detrás de la primera lingua franca digital
33. El proyecto de software peor gestionado de la historia
Epílogo
Años 2000
34. El año en el que el mundo no se acabó
35. Veinte años de Linkedin
36. Quince años de Facebook
37. La mejor tostadora del mundo
38. El pívot
YouTube
39. El cumpleaños de Aaron
40. El Legado de Barnes
41. El firmware que puede ganar una guerra
42. Hecatombe Madison
43. Super Pumped
44. Bienvenidos al futuro
45. Chinese democracy
46. El héroe
47. Guacamaya
48. Hay una persona en astorga de la que depende la marcha de la economía mundial
49. Silicon Valley Bank Crack
El principio del fin
La tormenta perfecta
El pánico
¿Y ahora qué?
¿Te podría haber pasado esto a ti?
¿Y por qué a mí debería importarme?
50. Epílogo: La generación de Poincaré
Landmarks
Front Matter
Copyright Page
Dedication
Notice
Prologue
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Chapter
Table of Contents
Back Matter
Nota del Editor
Este libro está compuesto de una serie de textos que vieron originariamente la luz en el entorno digital. Aunque la lógica de maquetación de la versión en papel es diferente, ya que contamos con las notas a pie de página, hemos optado por conservar los subrayados de aquellos textos que venían hipervinculados a una dirección electrónica por una cuestión de estilo.
Prólogo
No leo periódicos, ni escucho pódcast1, ni frecuento YouTube. La última serie que vi fue Alf. No tengo Netflix. Y —por supuesto— no enciendo el televisor, ese sofisticado vertedero donde un camión volquete descarga en alta definición todas las taras y miserias de nuestro tiempo. Tampoco leo libros de autores contemporáneos, pues los clásicos me bastan. Estoy en las redes sociales, sí, pero en un personal modo de solo escritura: no leo a nadie, no sigo a nadie; tan solo comparto ahí algunos pensamientos y las improvisadas escalas de mi viaje.
En las congestionadas autopistas de la información, yo he elegido caminar por el arcén. Solo desde el silencio, desde el vacío, consigo pensar con claridad en este loco mundo orlado de pantallas: pantallas en el metro, pantallas en el ascensor, pantallas en el bolsillo. Vivimos la era de la sobrecarga cognitiva, del horror vacui digital. Somos una sociedad colectivamente enganchada a los contenidos, yonqui de la última hora. Seleccionamos cuidadosamente los alimentos que nutren nuestro cuerpo, pero inyectamos casi cualquier cosa en nuestra mente. Nunca hubo tanto que leer, ver, escuchar. Y, aun así, nunca se abarcó tanto y se apretó tan poco.
Mi grito de Munch a esta pandemia de la infoxicación es la reclusión ascética. Dar la espalda a esta posmodernidad que confunde lo importante con lo urgente, que cincela nuestra visión del mundo a golpes de algoritmo. He erigido unas anchas murallas para aislarme de la realidad en ciernes y todo su ruido. Para ir y venir de mis soledades con mis propios pensamientos.
De vez en cuando permito que algo trascienda estas barricadas mías. Alguna alhaja que celosamente selecciono y traigo a mi remanso. La lista de correo de David Bonilla —la Bonilista— es una de estas deliciosas excepciones. Una historia interesante que aterriza con delicadeza en mi buzón cada domingo, espejo de otro tiempo, ya remoto, en que llegaban al buzón cartas de amistades distantes.
Cada mensaje dominical es una reflexión que David hilvana casi con artesanía. Textos que son la infrecuente intersección de dos territorios singulares. De un lado, los temas de tecnología y negocios digitales que están moldeando nuestro mundo. De otro, la reposada reflexión de David, cargada de experiencia y sentido común. Y, entre ambas tierras, qué inusual puente: la agradable constatación de que un ingeniero también puede escribir, y escribir muy bien.
Conocí a David casi por accidente. Pronto me sedujeron la pasión que imprime a sus retos, su capacidad para comunicar y una rara ambidestreza en los dos hemisferios cerebrales: la habilidad analítica y la visión humanista. (¡Qué necesaria esta última en este tiempo de máquinas y algoritmos en los altares!) Las cincuenta historias de este volumen, tan a fuego lento cocinadas, son un perfecto compendio de esta manera de ser. Y las cuidadas ilustraciones de Hugo Tobío, el mejor celofán para unas reflexiones que hacen reflexionar.
Tomados de uno en uno, cada capítulo de esta obra es un ojo de buey por el que asomarse a una cumbre de la historia de la informática. Pero el libro que tienes entre los dedos, estimado lector, es mucho más que la suma de sus partes. Porque el conjunto es, sobre todo, un original paseo por una cordillera de la disciplina que ha partido en dos la historia de la humanidad.
Desde la aurora misma de esta nueva ciencia hasta nuestros días, página a página David saca a pasear su curiosidad. Lo hace con el rigor, el sentido común y el lenguaje desenfadado que torna este recorrido asequible por igual a técnicos veteranos y a entusiastas ajenos a la escena tecnológica.
El lector despierto disfrutará de estos cincuenta capítulos que hacen pensar. Tanto como los he disfrutado yo, como los hemos disfrutado muchos en el buzón cada domingo. Estoy seguro de ello.
Jaime Gómez-Obregón
1 El plural adaptado al español es invariable.
AÑOS 50 y 60
1. El Test de Turing
20 de mayo de 2018
El «Test de Turing» fue concebido por el informático Alan Turing en 1950 como un medio de describir el punto en la evolución de la inteligencia artificial en la que esta empieza a ser indistinguible de una persona.
La semana pasada, Google mostró al mundo por primera vez Duplex —un sistema de inteligencia artificial, para completar tareas interactuando con seres humanos mediante llamadas telefónicas1— que ha hecho que tengamos que replantearnos de nuevo la vigencia del Test de Turing. ¿Ha llegado ya el momento en el que no podremos saber si estamos hablando con una máquina o con un ser vivo?
Lo fascinante del Test, en cualquier caso, son sus implicaciones éticas y morales. Porque, en realidad, lo único que pretendía Turing es responder una simple pregunta que aparece en la primera línea de las 28 páginas del artículo académico en el que lo dio a conocer: ¿pueden pensar las máquinas?
Como el concepto de pensamiento es muy abstracto, lo tradicional hubiera sido empezar el artículo con una definición del término. Sin embargo, Turing utilizó una aproximación distinta: un juego en el que solo se expondrían las capacidades intelectuales de los participantes, ocultando las físicas. El Juego de la Imitación.
El jugador A es un máquina y el B una persona. El jugador C no tiene contacto visual con ninguno de los otros jugadores y solo puede comunicarse con ellos por medio de notas escritas. Al hacerles preguntas, intentará determinar cuál de los dos es la máquina y cuál la persona. Si no puede, la máquina habrá pasado el Test de Turing.
La capacidad del Test de Turing para determinar si una máquina puede pensar o no siempre ha generado una gran controversia y cuenta con tantos seguidores como detractores. Puede que Duplex pasara el test, pero ¿eso le convertiría en un ser inteligente? ¿En un ser capaz de gestionar objetivos y dilucidar por sí solo las tareas necesarias para alcanzarlos? Y en el caso de que tuviera inteligencia, ¿deberíamos dotarle también de algún tipo de ética?
Las Tres Leyes de la robótica, planteadas por Isaac Asimov en 1942, parecían darnos un sólido armazón moral sobre el que construir una inteligencia artificial:
Un robot no hará daño a un ser humano, ni permitirá con su inacción que sufra daño.Un robot debe cumplir las órdenes dadas por los seres humanos, a excepción de aquellas que entrasen en conflicto con la primera ley.Un robot debe proteger su propia existencia en la medida en que esta protección no entre en conflicto con la primera o con la segunda ley.Sin embargo, las eternas pulsiones para conjugar el bien común y el individual —en las que la Humanidad lleva sumida desde su origen— hicieron que ese armazón saltara por los aires. El propio Asimov creó una Ley Cero a la que debían supeditarse las otras tres: «Un robot no hará daño a la Humanidad o, por inacción, permitir que esta sufra daño».
Una inteligencia artificial que siguiera las Tres Leyes de la robótica de forma estricta no habría podido asesinar a Hitler al comienzo de la Segunda Guerra Mundial, aunque hubiera tenido ocasión de hacerlo. La pregunta que tenemos que hacernos es: ¿Queremos crear máquinas que sean capaces de hacerlo?
El problema es que un ser humano es algo concreto y, por el contrario, la Humanidad un concepto abstracto. Al intentar llegar a un consenso sobre el mismo, dejamos de debatir sobre la ética que querríamos implementar en el código máquina para empezar a hablar de nosotros mismos.
No parece casualidad que Turing publicara un test que genera más preguntas que respuestas en una revista académica de filosofía, en vez de en una de computación o matemáticas. Tampoco que en la Universidad de Oxford —una de las mayores potencias a nivel mundial en el campo de la Inteligencia Artificial— se ofrezca la licenciatura híbrida de Informática y Filosofía2.
Pero hace tiempo que la Inteligencia Artificial y el Machine Learning abandonaron el campo de lo puramente teórico para convertirse en una realidad y, por tanto, su alcance e implicaciones deberían ser comprendidos y debatidos por la opinión pública. Da tanto miedo el plan de China para convertirse en la superpotencia mundial de Inteligencia Artificial en 20303 como la inexistencia de una mínima estrategia al respecto en nuestro país. Como dice Andrés Torrubia, «la inteligencia artificial ha pasado a ser una cuestión de Estado».
En 1950, Turing formuló su Test como una hipótesis. Hoy, la pregunta no es si alguna vez una máquina será capaz de superarlo sino cuándo lo hará. Lo que hagamos en ese momento nos definirá no solo como sociedad sino, también, como especie. Más nos vale empezar a preparar las respuestas.
1<https://www.youtube.com/watch?v=WPzu6W2rWNs>.
2<https://www.cs.ox.ac.uk/admissions/undergraduate/courses/cs_philosophy.html>.
3<https://www.fhi.ox.ac.uk/wp-content/uploads/Deciphering_Chinas_AI-Dream.pdf>.
2. La Ley De Gordon
2 de abril de 2023
La semana pasada, Gordon Moore murió a los noventa y cuatro años en su casa de Hawái, rodeado de su mujer Betty —con quien llevaba setenta y tres años casado—, sus hijos Kenneth y Steven y sus cuatro nietos.
Moore es mundialmente conocido porque, en 1965, escribió un artículo para la revista Electronics1 en el que predecía —entre otras cosas— que el número de componentes de un chip se duplicaría cada año, lo que suponía pasar de 60 a 60.000 en apenas una década. El cálculo resultó ser ridículamente preciso y, en 1971, Carver Mead empezó a usar la expresión «Ley de Moore» para referirse al mismo. Había nacido una leyenda.
Pero Gordon fue mucho más que esa Ley y su historia es ni más ni menos que la historia de Silicon Valley.
En 1956, el físico William Shockley —que había ganado el Nobel, junto a John Bardeen y Walter Brattain, por sus descubrimientos en el campo de los semiconductores y el diseño del transistor— fundó un laboratorio en Mountain View, California, para el que intentó reclutar a algunos de sus antiguos compañeros en Bell Labs. La mayoría rehusaron la oferta porque casi todas las empresas y profesionales relacionados con los semiconductores estaban en la costa este de Estados Unidos, no en ese recóndito lugar a las afueras de San José.
Porque Shockley no eligió ese emplazamiento porque estuviera rodeado de algunas de las mejores universidades técnicas del mundo o porque allí hubiera un ecosistema de emprendimiento tecnológico, sino porque quería vivir cerca de su anciana madre. Si la mamá de William hubiera vivido en Monforte en vez de en Palo Alto, a lo mejor la Ribeira Sacra se conocería hoy como la Ribeira do Silicio.
Pero Shockley tenía tanto de buen hijo como de mal jefe y ocho de sus mejores ingenieros —a los que se denominó despectivamente, los ocho traidores2— abandonaron su compañía para fundar Fairchild Semiconductor, que pronto se convirtió en el líder de la industria. Uno de ellos era Gordon Moore.
Para entender el impacto de los ocho traidores en la creación de Silicon Valley, debemos tener en cuenta que, en 2014, de las 130 compañías del área de la bahía de San Francisco que cotizaban en bolsa, el 70% tenían un vínculo directo con los antiguos fundadores o empleados de Fairchild —desde AMD a Apple, pasando por Google u Oracle— conocidas como fairchildren3.
Sin embargo, la más famosa es otra. En 1968, Gordon y su compañero Robert Noyce abandonaron Fairchild para fundar NM Electronics que, un año después, se convirtió en… Intel. Moore dirigió la compañía durante más de treinta años, en los que consiguió hacer realidad su ley y cumplir su visión: que todos pudiéramos tener un ordenador en casa y un «dispositivo portátil para poder comunicarnos».
Gracias por todo Gordon.
1 <https://hasler.ece.gatech.edu/Published_papers/Technology_overview/gordon_moore_1965_article.pdf>.
2 <https://en.wikipedia.org/wiki/Traitorous_eight>.
3 <https://computerhistory.org/blog/fairchild-and-the-fairchildren/>.
3. Revisando la Ley de Conway
13 de agosto de 2023
En 1967, el informático Melvin Conway llegó a la conclusión de que «las organizaciones están abocadas a producir diseños que se estructuran de la misma forma que se estructura la comunicación en dicha organización».
Vamos, básicamente, que —por ejemplo— si una empresa tecnológica se estructura en equipos autónomos que se coordinan entre sí, es más que probable que acaben desarrollando un software modular. Si, por el contrario, se organiza como un único gran equipo con grupos especializados para la parte de frontend y de backend, lo más normal es que cada una de esas capas se desarrolle de forma independiente y acaben integrándose con mejor o peor fortuna.
Lo que ha llegado a ser conocido como «la Ley de Conway» es uno de los axiomas más importantes de la industria informática, pero —también— de los más desconocidos y, sobre todo, malinterpretados. Porque, aunque Conway habla de «estructuras de comunicación», solemos quedarnos únicamente con la parte de estructuras y pasar por alto la parte de comunicación.
La confusión puede venir en parte porque en el Nuevo Diccionario para Hackers1 —una obra seminal de la cultura informática— se simplificó la Ley como «la organización del software y del equipo que lo produce serán congruentes», pero también porque —frecuentemente— los programadores minusvaloramos la importancia de la comunicación en el desarrollo de software.
El principio de «software funcionando antes que documentación completa» —introducido por el Manifiesto Ágil2 y que fue mal traducido como «documentación extensiva»— ha confundido a mucha gente. Hasta el punto de creer que lo más importante es aporrear teclas hasta que algo «funcione», antes que entender, consensuar y explicar cómo se debe hacerlo y por qué.
Y cuando hablamos de «comunicación», solemos acotarla a nuestra interacción con proveedores o clientes, no a la transmisión de información y toma de decisiones entre los actores más relevantes de nuestro proceso productivo: los miembros de nuestro equipo. La última vez que comprobé cuánto invertía una empresa —la mía— en comunicación externa e interna, la proporción era de 8 a 1.
Otro problema de la Ley de Conway es que no se puede demostrar. De hecho, el Harvard Business Review rechazó el artículo que la contenía con el argumento de que Conway no presentaba ninguna evidencia que probara su tesis. Así que, finalmente, las cuatro páginas de ¿Cómo inventan los comités?3 se publicaron en el número de abril de 1968 de la revista Datamation.
Pero Conway no sugiere causalidad, sino correlación. No da por hecho que una empresa produce productos o servicios de una determinada manera por sus procesos de comunicación interna, sino que entre unos y otros hay una correspondencia.
En 1997, un interesante estudio de Nigel Bevan sobre problemas de usabilidad en el diseño de webs4 concluyó que «a menudo, las organizaciones producen sitios web con un contenido y estructura que reflejan más las preocupaciones internas que las necesidades de sus usuarios».
En 2008, después del fracaso que supuso Windows Vista, Microsoft financió una investigación de la Universidad de Maryland que demostró la influencia de la estructura de una organización en la calidad del software que produce5. Usando el proceso de desarrollo de Vista como caso de estudio, concluyó que «la complejidad de la estructura organizativa de una empresa predice de forma estadísticamente significativa la tendencia al fallo de la misma».
Finalmente, no deja de ser paradójico que —en 2012, cuarenta y cinco años después de rechazar el artículo original de Conway— Harvard publicara un texto sobre la dualidad entre la arquitectura de un producto y la organización que lo desarrolla6, en el que se constatan las evidencias sobre «el impacto de las decisiones de diseño organizacional en la estructura técnica de los productos que estas organizaciones desarrollan posteriormente».
Pero más allá de sesudos estudios y complejas investigaciones, hay algo dentro de nosotros —nuestro «test de tripas»— que nos dice que Conway tenía razón.
Que si una empresa crea dos equipos —uno para iOS y otro para dispositivos Android—, aunque en teoría desarrollen la misma aplicación, la similitud de las dos versiones tendrá una relación directa con la comunicación que exista entre un grupo y otro. Que si los bugs y problemas reportados por los usuarios se comunican de forma efectiva y constructiva al equipo de desarrollo, este tendrá aún más cuidado en la calidad del código que lleva a producción.
Cómo sobrevivir a la Ley de Conway
Un buen primer paso para aplicar la Ley de Conway para nuestro propio beneficio sería dejar de ignorarla. El segundo —como apunta Martin Fowler— podría ser no luchar contra la misma.
El simple hecho de tener dos equipos en distintos pisos del mismo edificio ya impacta significativamente en la comunicación entre los mismos. Aún más si trabajan en distintas oficinas o poblaciones alejadas. En vez de continuar obviándolo, podemos asumirlo.
En el ejemplo que menciona Fowler7, la responsable técnica de un equipo que tenía que diseñar la arquitectura de un nuevo proyecto que iban a desarrollar 6 equipos diferentes en distintas ciudades por todo el mundo, decidió que iba a tener 6 subsistemas. Aún no sabía que iba a hacer cada uno, pero sí que iban a ser 6.
Otra opción, más extrema, es modelar la estructura de tu equipo y sus procesos de comunicación para que se adapten al tipo de productos o servicios que quieras desarrollar, lo que se conoce como Maniobra Inversa de Conway. Algo más fácil de decir que de hacer.
Conway y el trabajo remoto
Igual de estúpido que circunscribir la Ley de Conway a la industria informática sería pensar que solo aplica a las empresas que desarrollan un producto propio en vez de proporcionar un servicio a terceros, que las obligue a adaptarse a la estructura y procesos de sus clientes.
En realidad, siempre existe un núcleo organizativo y unos procesos de comunicación propios —parte de eso que, a veces, se llama «cultura»— que permanecen, independientemente de con quien se trabaje.
Da igual si nuestros clientes usan Scrum o Kaban. Si en nuestra empresa se comunica con total transparencia toda la información relacionada con el proyecto o la gestión de la cuenta, es muy probable que nuestro equipo encuentre nuevas oportunidades para aportar valor. Da igual si se organizan en equipos autónomos o en departamentos horizontales, si todos nuestros empleados saben lo que hacen sus compañeros y se comparten tanto los éxitos como las dificultades, es muy probable que nuestro grupo encuentre la forma de colaborar entre sí.
También sería bastante torpe usar el evidente impacto que tiene la ubicación para la comunicación cara a cara como argumento en contra del trabajo remoto. Precisamente, una de las ventajas del remoto es que permite que todos se comuniquen online en igualdad de condiciones, independientemente de su ubicación. Solo tenemos que asegurarnos de que esas condiciones sean las mejores posibles.
Por el contrario, el remoto exige definir de forma explícita esos procesos de comunicación que tendrán una correlación directa con el trabajo que desarrollemos, según Conway, en vez de improvisarlos o asumir su diseño de forma implícita. Y, en el caso de que quisiéramos hacer una Maniobra Inversa de Conway, una organización completamente remota será mucho más adaptable que una distribuida en diferentes espacios físicos.
En cualquier caso, da igual que trabajemos de forma remota o presencial, desarrollando un producto o prestando servicios. Lo que Conway nos enseña a todos es que una de las mejores inversiones que una empresa puede hacer es asegurarse de que su comunicación interna se alinea con su misión y propósito. En 2023, la mayoría sigue viéndola como poco más que un gasto y un trámite molesto.
1 <https://www.gutenberg.org/files/3008/3008-h/3008-h.htm#ConwaysLaw>.
2 <https://agilemanifesto.org/>.
3 <https://www.melconway.com/Home/pdf/committees.pdf>.
4 <https://assets.publishing.service.gov.uk/media/57a08da640f0b652dd001abc/Usability-issues-in-website-design.pdf>.
5 <https://www.semanticscholar.org/paper/The-influence-of-organizational-structure-on-Nagappan-Murphy/cc52bfc42571c3caa33f1348cc814ce168639837>.
6 <https://dash.harvard.edu/bitstream/handle/1/34403525/maccormack%2Cbaldwin%2Crusnak_exploring-the-duality.pdf>.
7 <https://martinfowler.com/bliki/ConwaysLaw.html>.
4. La madre de todas las demos
24 de marzo de 2019
La evolución suele producirse a través de pequeños pasos a lo largo del tiempo pero, de vez en cuando, se produce un enorme e inexplicable salto. También en la tecnología. El 9 de diciembre de 1968, una presentación de noventa minutos transformó por completo la visión que el mundo tenía de los ordenadores. «La madre de todas las demos» es las pirámides de Keops, Kefren y Micerino de la Informática. Hoy no podemos explicarnos cómo lograron completarla con los medios con los que entonces contaban.
Douglas Engelbart hizo la chaladura de inventar el ratón, los hiper-enlaces, la videoconferencia, el trabajo colaborativo e interactivo con el ordenador, el copy & paste, el drag & drop, los interfaces gráficos basados en ventanas, los dispositivos de entrada basados en gestos, el procesador de textos y el primer control de versiones; y mostrarlo todo DE GOLPE ante una anonadada audiencia en una conferencia que fue en sí un milagro técnico1 y costó más de 1 millón de dólares.
Sin embargo, la intrahistoria detrás de la demo de Engelbart es tan interesante como lo que mostró en el escenario.
En 1948 Engelbart consiguió completar sus estudios de Ingeniería Eléctrica, después de volver de la Segunda Guerra Mundial. Sus objetivos vitales no eran especialmente ambiciosos —casarse con su novia de toda la vida, conseguir un buen trabajo y disfrutar de una existencia confortable y sencilla—, pero en 1951 tuvo una revelación, una epifanía. Calculó que a su carrera profesional le quedaban 5 millones de minutos de trabajo y llegó a la conclusión de que quería emplear ese tiempo en contribuir al progreso de la Humanidad construyendo las herramientas necesarias para lograrlo.
No era un farol. Dejó su trabajo y volvió a estudiar. En 1953 consiguió el master en Ingeniería Eléctrica en Berkeley y en 1955 el doctorado. En 1957 consigue un puesto en el Stanford Research Institute (SRI), donde realiza diversas labores e invierte dos años en un nuevo campo de estudio: cómo potenciar el intelecto humano, desde el lenguaje hasta las estrategias organizativas. Finalmente, en 1962 publica el ensayo «Augmenting Human Intellect: A Conceptual Framework»2.
La propuesta de Engelbart llegó a Bob Taylor, director de la Agencia para Proyectos de Investigación Avanzada (arpa, por sus siglas en inglés). La misión de ARPA era financiar proyectos de investigación, por arriesgados o extraños que parecieran, para intentar que la Administración estadounidense no volviera a verse sorprendida y superada por los logros científicos de la Unión Soviética, como le pasó con el lanzamiento del Sputnik. A Taylor le encantó la idea de usar los ordenadores con una aproximación completamente distinta a la empleada hasta ese momento —aumentar la producción intelectual humana en vez de intentar sustituirla— y decidió financiar la visión de Engelbart, que monta un equipo de trabajo compuesto por estudiantes y jóvenes doctorados, con el que intentar convertirla en realidad.
A principios de 1968, Engelbart y Taylor hablaron sobre la posibilidad de hacer una demostración de todo lo que habían construido en la próxima Joint Computer Conference, que se celebraría a finales de año. El primero argumenta que hacerla costaría una fortuna. Tendrían que establecer una conexión entre San Francisco —donde se celebraría la conferencia— y Menlo Park, donde estaba el mainframe que ejecutaba el software del proyecto, a más de 45 kilómetros de distancia. El segundo le anima a hacerla y le asegura que la financiación no será ningún problema, pero le pide que no escatime recursos y construya una infraestructura redundante para asegurarse de que todo funcione.
Para lograrlo, el equipo de Engelbart tuvo que conseguir un Eidophor3 con el que proyectar la salida de vídeo del ordenador, mezclada con la imagen en vivo de Doug y su equipo, en una pantalla de casi 7 metros de alto y cinco y medio de ancho. Para transmitir la imagen de vídeo entre el laboratorio y la sala de conferencias se usaron dos enlaces de microondas: dos transmisores en el techo del edificio del SRI, un repetidor en Woodside —en medio de las montañas— montado en un camión y dos receptores en el techo del Civic Auditorium.
Para transmitir los datos —las pulsaciones de teclas y los movimientos de ratón que hacía Engelbart en el escenario— hasta el SDS 9404 en Menlo Park, tuvieron que construir 2 módems artesanales que operaban a 1.200 baudios —1,2 Kbits/segundo, alta velocidad en 1968 y hasta bastantes años después— que eran unidireccionales, así que, necesitaban uno para subir datos al servidor y otro para recibirlos. Toda esa infraestructura permitía que Douglas interactuara con el ordenador en vivo desde el escenario, usando una sencilla consola, en una época en la que estas máquinas pesaban toneladas y ejecutaban programas de forma desasistida. Los asistentes, sencillamente, no podían creer lo que estaban viendo.
arpa acabó gastándose 175.000 dólares de la época —alrededor de 1,2 millones de hoy en dia, teniendo en cuenta la inflación— en la preparación de la demo, la pregunta es ¿por qué?
Por dos motivos principalmente. Primero, por poner en valor al grupo de Engelbart y sus logros. Antes de la demostración, una parte significativa de la comunidad informática pensaba que Douglas era «un chiflado». En una época en la que la mayoría de los informáticos no entendían por qué un operador debía interactuar con máquinas destinadas a procesar información y devolver un resultado, la visión de Engelbart de crear ordenadores que no requirieran a sus usuarios saber lenguajes de programación parecía una excentricidad.
Segundo, porque el Zeitgeist del momento, la posición de la opinión pública respecto a la informática era bastante negativa. Los ordenadores eran vistos como máquinas inaccesibles, custodiadas en lo más profundo de grandes corporaciones, agencias gubernamentales y laboratorios universitarios y utilizadas por estos para estudiar y explotar a la población cuando no directamente aniquilarla, realizando complejos cálculos balísticos que calentaban la Guerra Fría. En ese contexto, cuando los ordenadores eran cualquier cosa menos personales, Engelbart proponía: «Si tuvieras en tu oficina un ordenador disponible para ti todo el día, reaccionando instantáneamente a cualquier tarea que hicieras con él, ¿cuánto valor podrías obtener?». El mayor logro de Doug no fue enseñarnos cómo podría ser el software o el hardware, sino mostrarnos qué deberíamos hacer con él.
Durante la demo, se podía escuchar el vuelo de una mosca. Cuando esta acabó, la audiencia estalló en una atronadora ovación. Engelbart acababa de cambiar la Informática para siempre. Sin embargo, para Douglas la tecnología era solo un medio para conseguir un fin: ayudar a la Humanidad a colaborar y progresar. Nuestra responsabilidad es preservar su legado.
1 <https://www.youtube.com/watch?v=yJDv-zdhzMY>.
2 <http://dougengelbart.org/content/view/138>.
3 <https://en.wikipedia.org/wiki/Eidophor>.
4 <https://en.wikipedia.org/wiki/SDS_940>.
AÑOS 70
5. 50 años de SQL
8 de septiembre de 2024
SQL es una de las tecnologías más relevantes del mundo. Es el principal lenguaje con el que se almacena, consulta y modifica la información que sustenta a gobiernos y grandes corporaciones. Sin embargo, la historia detrás del mismo es bastante desconocida, no ya por el público general sino por los propios informáticos.
Desde mediados de los años sesenta, Edgar Frank «Ted» Codd —empleado de IBM— trabajaba en el diseño y conceptualización de diferentes sistemas de organización de datos. En junio de 1970 publicó el artículo «Un modelo relacional de datos para grandes bancos de datos compartidos»1 en la revista de la Asociación de Maquinaria Computacional.
Codd propuso un sistema basado en el algebra relacional que era mucho más sencillo y efectivo que las arquitecturas jerárquicas y de red que se usaban en la época. Sin embargo, IBM no mostró especial interés en su propuesta porque se estaba hinchando a ganar dinero con IMS/DB, la base de datos jerárquica que estaba comercializando.
Ted no se quedó de brazos cruzados, sino que se jugó el puesto al empezar a evangelizar las ventajas de su modelo —por iniciativa propia— entre los clientes de la multinacional, que empezaron a presionar a IBM para que lo implementara.
En vez de despedirlo, la compañía decidió trasladarlo a su laboratorio de investigación de San José, donde le permiten seguir desarrollando su modelo relacional y empieza a trabajar en Alpha, un lenguaje que lo implemente.
En 1972 Codd dio un simposio interno al que acudieron Ray Boyce y Don Chambelin, dos jóvenes graduados recién contratados por IBM para que experimentaran con el novedoso concepto de «datos persistentes», información almacenada de tal manera que sobreviva a la ejecución de un programa, incluso después de que el sistema o la aplicación se apague o reinicie.
Para Boyce y Chambelin la exposición al modelo relacional de Codd fue una especie de revelación y empezaron a diseñar su propia implementación del mismo, un lenguaje al que llaman SQUARE o «Specifying Queries in A Relational Environment».
No eran los únicos. El artículo de Codd había despertado mucho interés y, en la universidad de Berkeley, otro equipo estaba trabajando en Ingres; un proyecto similar —del que derivaría la base de datos open source Postgres o «post Ingres»— que contaba con su propio lenguaje de consultas, llamado QUEL.
Con buen criterio, IBM consideró una estupidez que dos grupos de trabajo estuvieran desarrollando el mismo proyecto en paralelo y, en 1973, también traslada a Boyce y Chambelin al laboratorio de San José. Sin embargo, estos tenían sus propios planes.
En vez de seguir trabajando en SQUARE —que usaba una estructura anidada difícil de transcribir con un teclado— o el Alpha de Codd, que consideraban «demasiado matemático» y complejo, decidieron implementar un nuevo lenguaje «tan sencillo que pudiera ser usado por cualquier oficinista». Como IBM no creía demasiado en el potencial comercial de las ideas de Codd, les permitieron tomar el control del proyecto y matar Alpha.
Como juego de palabras con la «competencia» de QUEL, deciden llamarlo SEQUEL. Lo diseñan como un lenguaje completamente declarativo —describe la información que se está buscando, no la lógica para encontrarlo— en vez de procedural. Para conseguirlo, se suman al proyecto Patricia Selinger, que desarrollaría un optimizador para hacer las consultas más eficientes; y Raymond Lorie, que inventó un compilador que guardaba esa lógica de búsqueda para poder usarla de nuevo.
En 1974, aproximadamente un mes después de presentar SEQUEL por primera vez en una conferencia técnica, Ray Boyce murió repentinamente a causa de un aneurisma cerebral. Tenía veintiséis años y una hija de apenas diez meses.
Tras la prematura muerte de Ray, SEQUEL continuó evolucionando como parte del proyecto System R, la iniciativa de IBM para crear una primera base de datos relacional comercial. Se instaló experimentalmente en tres clientes y, a partir de la experiencia recopilada con esos primeros usuarios, en 1976 publicaron un diseño más completo.
En 1977, se eliminaron las vocales del nombre porque «SEQUEL» era una marca registrada de la compañía aeronáutica Hawker Siddeley. Nacía SQL, que empezó a usarse como acrónimo de «Structured Query Language».
IBM seguía sin tener ninguna prisa por dar el salto a las bases de datos relacionales. Su lentitud permitió que, en 1979, un joven programador y emprendedor copiara el lenguaje a partir de la documentación técnica publicada y comercializara la primera base de datos relacional del mundo que implementaba SQL. Su nombre era Larry Ellison y llamó a su base de datos Oracle.
Presionada por la competencia, finalmente IBM lanzó SQL/DS en 1981 y DB2 en 1983, pero nunca volvió a recuperar el liderazgo en el mercado de bases de datos relacionales.
SQL supuso tal impacto en la gestión de la materia prima más cara y peligrosa del mundo —la información— que, en 1986, la ANSI (American National Standards Institute) lo adoptó como estándar para lenguajes de consulta en bases de datos relacionales. Al año siguiente, la ISO (International Organization for Standardization) también lo aprobó como estándar internacional.
A lo largo de los años, el estándar ha evolucionado para adaptarse a nuevas tecnologías y necesidades; pero, en esencia, sigue siendo la misma propuesta recogida en las catorce páginas escritas por Chamberlin y Boyce2.
Michael Stonebraker, uno de los creadores de QUEL y principal damnificado por el éxito de SQL, no solo no guarda ningún rencor al lenguaje, sino que cree que la industria se ha beneficiado por esa estandarización. En una entrevista para The Register
