Esta es la segunda parte de la entreista a James Coplien. La parte 1 puedes encontrarla aquí
4 – Ha pasado mucho tiempo desde la introducción de patrones en el mundo del software. ¿Qué otros pasos debería dar la comunidad de patrones?
He estado muy triste viendo a la comunidad de desarrollo de patrones estos últimos veinte años. Hemos perdido los ideales que construyeron la base de la literatura software que capturaban las prácticas cotidianas importantes. Eso son los patrones. Esa era la visión. Y la visión se ha perdido.
¿Qué pasó? Creo que el objetivo era demasiado ambicioso y que la segunda generación de escritores sobre patrones nunca alcanzó el nivel de conocimiento necesario para comprender de qué trataba todo esto. El software es un área intelectual enorme, y rara vez se formó una masa crítica de personas alrededor de cualquier área de software comprometidos con la literatura. Hubo algunas excepciones interesantes. Ward Cunningham creó originalmente Wikis para apoyar la forma en la que se escriben los patrones. Levantó la cultura Wiki entorno a los patrones a los patrones y ha disfrutado de un éxito sin límites en la Wikipedia y otros medios de Wiki. Incluso la Wiki, como medio, no le ha funcionado tan bien en el software.
Actualmente estoy trabajando como “pastor” en la próxima conferencia de patrones – la vigésima cita anual. El “pastor” trabaja junto con los autores (llamados ovejas) desafiando y guiándoles para hacer sus patrones excelentes. Durante nuestro diálogo sobre su trabajo, mi oveja me dio una explicación sobre como los patrones de IT eran diferentes de los patrones de Alexander, y aunque entendió mi consejo de seguir la corriente de Alexander, quiso escribir “IT patterns”. No creo que ninguno de los siete que estuvimos en aquella postura hace más de 20 años desarrollara una visión de cómo la visión de Alexander encajara bien en lo que hicimos en el software, habría creído posible que la comunidad nunca tuviera un miembro con esa perspectiva. Sin embargo, apuesto a que lo contrario es cierto. Yo estaba en PLoP 2012. Richard Gabriel y yo éramos las únicas personas fundadoras allí. Aparte de él, no podía encontrar a alguien que realmente entendiera la visión de Alexander. (Por cierto, ¡tengo mis ovejas de vuelta en el camino! Eso es difícil y es digno de elogio por el trabajo que lleva)
El problema en el software, creo, es que está dominado por «nerds». Demasiados «nerds» encuentran su orgullo en los detalles en vez de en la gran obra. Es por eso por lo que los «nerds» valoran la inteligencia por encima del trabajo duro. (Dile a un «nerd» que es vago y se desanimará un poco; dile que no es lo suficientemente listo para resolver un problema y le romperás el corazón) Se convierte en algo crucial demostrar la inteligencia en el lugar de trabajo: salarios, promociones y status dependen de ello. La inteligencia va a menudo de la mano de una predisposición a poner por encima el intelecto sobre los sentimientos.
Es el comienzo para la especialización. La especialización es menos importante en un mundo altamente conectado de lo que era en el mundo industrial, y si tengo que encontrar la manera de hacer X, a menudo me encuentro la respuesta en la web en lugar de invertir el tiempo en una institución que «me enseña cómo hacer X. »
De hecho es difícil construir una comunidad de gente capaz y que esté dispuesta a construir una base de literatura con valor, de aplicación general y que se impulse por una base de colaboradores afines. Los nerds rara vez encuentran energía para este tipo de trabajos. En teoría, esta combinación conduce a patrones en dos direcciones. Por un lado son colecciones fragmentadas de detalles que, por carecer de un lenguaje, no logran ser patrones. Por otro lado, los generalistas que están en el lado social pero que, en este mundo altamente conectado, se separan de los actos diarios de empujar con las manos la cálida tierra del desarrollo o luchar contra las fuerzas de la naturaleza para poner la estructura. Ese grupo produce colecciones que a menudo son lugares comunes y, aunque a veces constituyen un buen consejo, carecen de la estructura morfológica coherente necesaria para ser patrones. Y la teoría parece confirmarse en la práctica.
Lo más cercano que tenemos a una historia de éxito en la comunidad del software han sido las obras de la comunidad HCI, que publicaron un aluvión de buenos patrones hace muchos años. Encontraron el punto ideal entre lo aplicable y el conocimiento antiguo y lo plasmaron en pequeñas piezas de literatura. Es un mundo muy geométrico, la coherencia morfológica era algo natural para ellos. Anders Toxboe, Ian Graham, y Jenifer Tidwell son mis héroes y heroínas en este campo, y Jan Borchers también ayudó a popularizarles.
Los patrones organizacionales son el otro ejemplo de éxito. Han demostrado un alto valor (de uso limitado) por derecho propio, pero también se han convertido en uno de los motores más poderosos de cambio que tenemos en el software actual: Scrum. (Ten en cuenta que los patrones simplemente capturan la práctica madura en lugar de inventar, por lo que es una tontería decir que la gente de los patrones inventó Scrum. También es absurdo decir que la gente de Scrum “inventó” Scrum, pero voy a dejar esta pregunta para ellos.) Lo que ambos, patrones organizativos y Scrum hicieron fue combinar, racionalizar y dar a conocer las ideas eternas de cómo las personas son efectivos en el mundo del trabajo.
He estado diciendo durante años que la comunidad debe subdividirse en las actuales conferencias de patrones: comunidades, pájaros con plumas que van juntos a crear literatura que la gente clamará por leer. La gente de HCI hizo su propia voluntad. La gente de Scrum PLoP lo hizo primero para conseguir centrarse en algo y en segundo lugar como una forma de aislarnos de la cultura de patrones generales.
Si la cultura de patrones puede generar más de estos esfuerzos puede empezar a estar verdaderamente viva. Hoy en día es una comunidad maravillosa, brillante, con gente que se apoya mutuamente, que todavía tienen que darse cuenta de que los patrones tratan de encontrar maneras para ayudar a la sociedad comprometida a crecer. Scrum, por supuesto, trata de lo mismo.
Hay algunas buenas noticias. Los medios electrónicos han creado canales de información ubicua, y la investigación muestra que los canales no han disminuido el consumo de los libros de la sociedad. Por el contrario: la comodidad de la publicación electrónica ha causado que crezca (http://www.gallup.com/poll/16582/about-half-americans-reading-book.aspx). Así que si podemos crear una buena literatura de patrones, hay bastante probabilidad de que vaya a leerse. (Constrúyelo y ellos vendrán). La mala noticia es que los tweets que llegan, las nuevas alertas y los emails han hecho que la vida conectada sea la norma, y el enfoque requerido para escribir de forma reflexiva, contribuir de forma colectiva al archivo literario, es cada vez más difícil de encontrar (http://www.theatlantic.com/magazine/archive/2008/07/is-google-making-us-stupid/306868/).
También dentro de las buenas noticias está que la comunidad de patrones está formada por una buen y preocupado conjunto de seres humanos. Ellos quieren hacer las cosas bien. Ahora es cuestión de usar esa pasión para volver a dar forma a la inteligencia y a las visiones utópicas en algo disciplinado, basada en comunidades. Este es el trabajo duro – el más duro que he visto en el que la mayoría de la comunidad de patrones está dispuesta a invertir. Por supuesto, hay siempre algunos individuos que destacan, y estoy animado por todo el mundo en la comunidad PLoP de Scrum. Tenemos nuestras frustraciones por nuestras diferencias, pero las diferencias nos están enriqueciendo mucho.
Hay un lugar donde tengo la esperanza de que los patrones puedan todavía florecer y ese es Japón. Los patrones tienen unas fuertes raíces japonesas. La primera vez que conocí a Christopher Alexander le pregunté si había alguna conexión entre “The Timeless Way of Building” y “The Chinese classic” de Tao Te Ching. Respondió: “Por supuesto, ¿no es obvio?”. Muchas de esas ideas Taoistas se han embebido en la cultura japonesa. Estamos en un punto cambiante en la sociedad japonesa, moviéndose desde una generación que todavía recuerda en sus propias carnes esas ideas profundas a una generación donde se sentirán perdidos. El patrón de lenguaje más bonito que he visto – y el más potente al ser aplicado – fue escrito por Masanari Motohashi-san.
Desde el principio, había una distancia saludable entre la comunidad de patrones y la academia. El valor del patrón de conocimiento maduro y la belleza entra en conflicto con los valores académicos de novedad y excelencia técnica. Las dos comunidades han crecido juntas de una forma en la que siento que se ha obtenido lo peor de las dos. Apostaría a que se ha publicado más información errónea por los académicos que por otros sectores del reino de patrones juntos.
Realmente animo a los estudiantes a no sentirse embaucados por las publicaciones sobre patrones durante sus años académicos. Los patrones son escritos en comunidad y basados en décadas de reflexión sobre prácticas en el mundo real. Pocos estudiantes pueden decir que están involucrados en la comunidad de patrones y todavía menos cuentan con canas en su cabeza. Para aquellos que estén interesados en aprender la teoría, te recomiendo bucear en la literatura la teoría del diseño de la década de 1980: Christopher Alexander, John Thackara, Nigel Cross, y otros de la época, que fueron algunos de los primeros en comprender los retos de los sistemas complejos. Pasando a los libros de Alexander. Me llevó más de una década de estudio conseguir entender la esencia de ellos. Hay que empezar alguna vez, y no hay mejor momento que el presente.
5 – Por otra parte, ¿cuáles son sus tres libros favoritos que todos los profesionales de software debe leer? (Por supuesto, además de los suyos 🙂 )
Es fácil.
“The Toyota Way”, por Liker.
“Zen and the art of Motorcycle Maintenance”, por Pirsig.
“Design after Modernism”, editado por John Thackara.
Por supuesto, se aprende muy poco de los libros. Se trata de estar en los workshops (donde se involucra y crece el conocimiento) y en el diálogo cara a cara. Hacer cosas es la mejor manera de hacer algo. Los libros son buenos, pero la cosa más importante no es algo que encontrará en algún libro. Eso es probablemente el peor servicio que la religión – incluyendo la particularmente perniciosa religión llamada academia – que ha hecho a la sociedad moderna, elevar la palabra impresa a ese nivel. Tal vez debería añadir «El nombre de la rosa» de Eco a la lista.
6 – ¿Alguna recomendación para los jóvenes ingenieros de software?
Me gustaría reiterar que se deben aprovechar las oportunidades que tienen a principios de su carrera – y especialmente en la universidad – de ampliar sus horizontes. Aunque los ingenieros odian escuchar esta verdad, la ingeniería de software es muy poco de software y casi nada de ingeniería (http://www.computer.org/portal/web/buildyourcareer/Agile-Careers/-/blogs/it-s- no-engineering-jim). Lo que necesitan aprender de esos dos temas, lo adquirirán de forma natural en el trabajo.
Disfruta del ambiente de aprendizaje dando un paseo por el lado salvaje. Estudia psicología y sociología, o historia del arte, y toma todos esos caminos de aprendizajes de culturas fuera de la propia. Esas son las joyas que iluminarán el camino a través de los temas importantes de su carrera. El «software» y la «ingeniería» (bits) son para los problemas simples. Si se encuentran interesados sólo en la resolución de problemas sencillos, los jóvenes ingenieros deberían tal vez encontrar otra vocación.
Construir grandes cosas y hacer grandes cosas es mucho más sobre entender agilidad y patrones que entender principios académicos. Entender la agilidad, o entender patrones, tiene mucho más que ver con el enamoramiento, o con la construcción de algo que da paz interior, de lo que es cualquier cosa que encontrará siempre en un libro, escuchará en una conferencia, o aprenderá de la lectura de una entrevista.
Estoy preparando una serie de lecturas – una por cada semana del año – orientado a ingenieros. Esta serie aparece actualmente como el blog de IEEE, y me gustaría invitar a sus jóvenes ingenieros escoger un título que se les antoje y empezar a leer allí. He tratado de captar algunas de las ideas más profundas que he recogido a lo largo de los años y presentarlos de una manera casual. Los escritos son un sistema encubierto de la ética, basada en la idea de que no se trata de tener un trabajo, pero en el juego sin fin llamaron a una carrera de ingeniería. Lo puedes encontrar en:
http://www.computer.org/portal/web/buildyourcareer/Agile-Careers
7 – ¿Has estado alguna vez en España? ¿Te veremos pronto por España?
No, “pero me gusta la música…” [En referencia a la popular canción de Elvis Presley] Me gustaría (realmente me encantaría) ir a España y tal vez ayudar a formar algunas comunidades allí. Es difícil para mí organizar algo desde fuera del país, pero si alguien está dispuesto a trabajar conmigo para organizar algún evento o involucrarme en algún evento, me encantaría saberlo.
Gracias por la entrevista y esperamos vernos pronto en España, o en cualquier lugar.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Pingback: Bitacoras.com