Saltar al contenido

Blog técnico | Ampliando nuestro horizonte

Trabajamos en una industria única. Aunque hay restricciones reales sobre lo que es computablemente posible (P probablemente no es igual a NP, después de todo), los sistemas más complicados que construimos raramente se acercan a esos límites. Y aunque tanto la memoria como la eficiencia de la CPU son importantes, la disponibilidad y el costo de los recursos de computación en la nube empujan constantemente los límites de lo que era posible. Más que cualquier otra cosa en la tierra, la computación se acerca al mítico mundo de la “post-escasez”.

Sin embargo, incluso en ese mundo, el trabajo que hacemos sigue siendo difícil. Resulta que construir castillos internamente consistentes desde el aire es difícil, precisamente porque son tan efímeros. Nuestro trabajo más importante es manejar la complejidad, pero nuestros sistemas son tan complejos que podemos pasar años trabajando en ellos y aún así no entenderlo todo. Nos enfrentamos a un problema que ningún poeta ha tenido que abordar – nuestras creaciones tienen que trabajar .

Blog técnico | Ampliando nuestro horizonte
Blog técnico | Ampliando nuestro horizonte

Este conflicto es la razón por la que el aprendizaje es tan importante para el campo del software. Las cosas cambian tan rápido, y los sistemas son tan complejos, que es imposible alcanzar un estado en el que realmente lo sepas todo. Por eso, en , nos preocupamos más por cómo aprendes que por lo que sabes. Todo lo que sabes es algo que fue útil en algún momento, pero eso no significa que sea útil hoy en día. De hecho, el contexto es tan importante que es probable que nunca más trabajes en un sistema lo suficientemente cercano al que trabajaste ayer como para que el conocimiento que tienes hoy sea suficiente. Afortunadamente, vivimos en la era de la información, y las herramientas para aprender están a nuestro alcance. De hecho, el mayor reto al que nos enfrentamos es el de la concentración, porque hay mucha más información disponible de la que cualquier persona puede esperar examinar, y mucho menos comprender.

Dada la riqueza de la información disponible, no es sorprendente que la mayoría de la gente elija especializarse. Después de todo, la programación es un esfuerzo relativamente nuevo, con limitaciones que son muy diferentes de otras industrias. Los desafíos técnicos que enfrentamos cambian tan rápidamente que incluso el intento de mantener el ritmo puede a menudo sentirse abrumador. Sin embargo, frente a esa complejidad técnica, a veces olvidamos que el aspecto humano del desarrollo de software puede ser aún más desafiante. Afortunadamente, podemos comprender mejor cómo otras disciplinas han superado desafíos similares. De hecho, esos conocimientos han llevado a varias de las ideas más revolucionarias en nuestro campo.

Esos conocimientos son también la razón por la que abogo por que todos los desarrolladores pasen algún tiempo aprendiendo cosas que parecen, a primera vista, no estar relacionadas con el campo del software en absoluto. Para convencerles de la importancia de ese tipo de aprendizaje, primero les recordaré los orígenes de algunas de nuestras técnicas más importantes. Luego, para probar que este tipo de aprendizaje no es sólo algo para tipos de torres de marfil, discutiré lo que aprendí mientras veía un documental sobre el diseño del Ford Mustang. Requiere esfuerzo, pero estoy convencido de que la única manera de ver más lejos es que cada uno de nosotros amplíe sus horizontes.

Arquitectura (el tipo de construcción)

En la década de 1970, un pequeño grupo de arquitectos se dio cuenta de que veían características similares en una variedad de comunidades diferentes. Se esforzaron por comprender los problemas que estos rasgos estaban resolviendo, y llegaron a una lista de 253 “patrones”: combinando una simple declaración del problema a resolver con una solución simplificada que fue diseñada para ser adaptada a las condiciones locales. El libro que publicaron, A Pattern Language, sigue siendo uno de los libros más vendidos sobre arquitectura, cuatro décadas después de su lanzamiento.

Veinte años después, un grupo de desarrolladores de software que habían leído el libro de Alexander notaron una repetición similar en el código que escribieron. Decidieron que la catalogación de estos patrones de software proporcionaría una manera de discutir estas características, así como ayudar a los desarrolladores a reconocer cuando estaban tratando con un problema común. Pronto escribieron un libro (Design Patterns) que se convertiría en uno de los libros más leídos y discutidos en la programación orientada a objetos.

Curiosamente, en algún momento los desarrolladores de software olvidaron una de las lecciones más importantes de “Un Lenguaje de Patrones”: que cada comunidad es diferente, y mientras que los patrones proporcionan un lenguaje útil para discutir problemas y soluciones, las cosas funcionan mejor cuando se permite a la comunidad crear una solución única. Con demasiada frecuencia, la implementación de los patrones en exactamente de la manera especificada en el libro Gang of Four se convirtió en una marca de software “bien diseñado”. La rigidez y el formalismo resultantes era algo que Christopher Alexander estaba trabajando específicamente en contra de , porque había visto los problemas que causaba. Si más desarrolladores de software hubiesen aprendido de él, podríamos tener menos “singletons” innecesarios.

Fabricación

En los años 70 y 80, Japón provocó una revolución en la fabricación. La sabiduría tradicional sostenía que la fabricación era un proceso “rápido, barato o bueno; elige dos”. De repente, sin embargo, los productos japoneses estaban compitiendo en los tres frentes. A la cabeza estaba Toyota, cuyo sistema de gestión, el Sistema de Producción Toyota (TPS), se hizo famoso en todo el mundo por su impacto positivo en la empresa. Los fabricantes establecidos se quedaron luchando para tratar de mantenerse al día, y comenzó el movimiento de fabricación Lean.

A primera vista, hay pocas similitudes entre la fabricación, donde el objetivo es producir exactamente la misma cosa una y otra vez, y el desarrollo de software, donde (idealmente) nunca se escribe el mismo código dos veces. Sin embargo, cuando Mary Poppendieck pasó de la fabricación a la gestión de software, descubrió que muchos de los problemas que habían existido en la fabricación antes de Lean también aparecían en los proyectos de software. El software se desarrollaba sin bucles de retroalimentación, los gerentes asumían que podían sacrificar la calidad para ganar velocidad, y un enfoque en el rendimiento local en lugar de en el valor entregado a través del sistema eran casi idénticos a los problemas con los que Mary había lidiado primero en el mundo de la manufactura.

Aquí en , también hemos usado Lean como una forma de ayudarnos a entregar valor más rápido. Una de las primeras cosas que hice después de empezar aquí fue ver Compitiendo en base a la velocidad. Es una fantástica introducción a muchos de los porqués detrás de las técnicas que nos han permitido movernos rápido. Recomiendo encarecidamente tomarse una hora para verlo todo.

Diseño de coches

Recientemente, descubrí un documental en Netflix sobre el rediseño del Ford Mustang en 2015. Incluía entrevistas tanto con el equipo que diseñó el Mustang 2015, como con algunos de los miembros supervivientes del equipo detrás del Mustang original de 1965. Mientras lo veía, me sorprendió cómo muchos de los problemas que describían parecían reflejarse en mi propia experiencia trabajando en… Es cierto que nunca he tenido que preocuparme de cómo la resonancia armónica de un escape puede crear un traqueteo en un tablero de mandos, o de cuánto un aumento de 10 centavos en la lista de materiales impactará en los resultados de mi empresa. Y sin embargo, mientras trabajábamos para construir un sistema distribuido, rápidamente quedó claro que tendríamos que construir todo el sistema para observar cómo interactuarían las piezas entre sí, y más de una vez he descubierto que los cambios aparentemente pequeños pueden tener un gran impacto cuando se complican con suficiente tráfico.

Aún más interesante para mí fueron los problemas de la gente que ambos equipos describieron. La historia del equipo del Mustang de 1965, tal y como se cuenta aquí, es la historia de un pequeño equipo que utiliza sus limitaciones para mejorar su creatividad. Siguiendo los pasos del desastroso Edsel, Ford estaba comprensiblemente preocupado de que otro gran fracaso hundiera la compañía. Esto significó que cuando Henry Ford II dio luz verde al programa, le dio sólo la mitad del presupuesto habitual. Además, debido a que el mercado objetivo del Mustang eran los jóvenes baby boomers, el precio era una gran preocupación. Para superar estas limitaciones, el equipo decidió construir un coche basado en el Ford Fairlane existente, utilizando las cadenas de suministro y la experiencia existentes. El resultado fue un éxito arrollador, superando su objetivo de ventas de un año en sólo tres meses, y vendiendo un récord de 318.000 en su primer año modelo.

A menudo he visto resultados similares por tener restricciones en… El año en que me uní se nos ofreció la oportunidad de aumentar enormemente nuestra asociación con Microsoft, ofreciendo más cursos a los suscriptores de MSDN que nunca antes. En el momento en que se firmó el acuerdo, teníamos una cuestión de semanas antes de que el acuerdo estuviera disponible, y todo nuestro departamento en ese momento tenía menos de 20 desarrolladores. La claridad que nos proporcionaron nuestras limitaciones nos ayudó a diseñar herramientas de forma que nos permitieran lanzarnos a tiempo, prácticamente sin problemas.

La importancia de las tensiones creativas ha sido una de las lecciones más difíciles de aprender. Es tan fácil olvidar que hay un valor real desde puntos de vista opuestos. Dave Perizack se refería al reto de desarrollar un coche que sea a la vez bonito y que funcione bien, pero tensiones similares están por todas partes en nuestra industria. A medida que sigo aprendiendo, cuando cualquiera de los dos lados en estas importantes tensiones deja de luchar, todo empeora. Y así, he descubierto que tengo dos trabajos importantes cuando represento el desarrollo en una discusión con otros grupos con prioridades conflictivas. El primero es abogar como mejor posible por la excelencia técnica y la innovación que aporto. El segundo es asegurarse de que todos los demás en la sala están abogando por sus prioridades tan fuertemente como yo estoy abogando por las mías. Hacer ambas cosas al mismo tiempo es una de mis responsabilidades más difíciles, pero los resultados hablan por sí mismos.

Conclusión

Espero que la importancia de continuar aprendiendo sea obvia para cualquiera que esté remotamente interesado en la industria del software. Los cambios y mejoras técnicas suceden a un ritmo notable en estos días, y sin la dedicación al aprendizaje constante de nuevas tecnologías y técnicas, nos fallaremos a nosotros mismos y a nuestros clientes. En muchos casos, nuestros desafíos técnicos no tienen precedentes, por lo que el aprendizaje introspectivo es tan comprensible como importante. Por favor, no tome esto como una excusa para dejar de aprender cosas técnicas.

Y sin embargo, algunos de los problemas más complicados y difíciles de resolver que encontramos tienen más que ver con interacciones interpersonales que con 1 y 0. Cuando nos enfrentamos a estos desafíos, podemos encontrar inspiración y guía en la experiencia de personas en campos que tienen poco en común con nuestra experiencia técnica. Creo firmemente que muchos de los importantes avances que veremos en los próximos años estarán influenciados por personas que aprenden de cosas que, a primera vista, no tienen nada que ver con la programación informática. Espero que se unan a mí para pasar al menos parte de su tiempo tratando de encontrarlas.

Categorías: cultureTags: mejora continua, lean