Hay varios desarrolladores de talla internacional de los que puedes aprender mucho, que creemos que no tienen la suficiente exposición, sobre todo en America Latina. Es por eso que estamos creando una serie de artículos y videos en la que resaltaremos la trayectoria, forma de pensar, pláticas y cosas que puedes aprender.

Las condiciones para que aparezcan aquí son las siguientes:

  • Amplia experiencia real desarrollando sistemas
  • Que tengan algún logro notable en el desarrollo de sistemas
  • Comparten sus ideas con la comunidad de forma continua
  • No son unos “brilliant jerks”, es decir, no usan su experiencia o inteligencia para humillar o desacreditar a otros, y mucho menos su exposición para promover ideas nocivas.

El objetivo de esta serie es que aprendamos de las personas que han dedicado su vida a esto y construyamos sobre lo que ellos han hecho en vez de reinventar la rueda cada vez.

Nota: El que los mencionemos aquí no implica que todas sus ideas son correctas o que estemos de acuerdo con todo lo que dicen. Conocer diferentes puntos de vista, sumado a tu experiencia en diferentes contextos te ayudará a tener un criterio adaptado a tu realidad.

Ahora sí, vamos a hablar de Kevlin Henney.

Acerca de Kevlin Henney

Kevlin Henney es un consultor, escritor, entrenador y presentador de temas relacionados con sistemas, procesos, las personas y el software. Sus escritos, talleres y consultorías siempre tienen que ver con la forma en que desarrollamos y diseñamos software, además de con los procesos y prácticas que llevan al éxito los proyectos de software complejos.

Ha escrito columnas para múltiples revistas dedicadas al desarrollo de software. Es autor o editor de varios libros que son muy recomendados para arquitectos de software y desarrolladores. Algunos ejemplos son:

Kevlin se ha presentado en casi todas las conferencias importante de desarrollo de software europeas y de hable inglesa. Vive en Bristol, Reino Unido y también disfruta de escribir ficción, puedes encontrar en Amazon sus libros de ficción. Además es muy accesible, si lo buscas en Twitter es muy probable que te conteste: Kevlin Henney en Twitter

Una de las cosas que menciona que más nos gusta es: “Si estás de acuerdo con todo lo qu estoy diciendo, no me estás escuchando.”.

Algunas ideas de Kevlin

“Less code == less bugs”. - Kevlin Henney

De las pláticas y el contenido que hemos consumido de Kevlin, hemos podido derivar algunas de las principales ideas que promueve. Te listamos las tres más importantes y te dejamos descubrir las demás viendo sus charlas o leyendo su contenido.

  1. La arquitectura de software requiere entendimiento completo del dominio. Una de las ideas que Kevlin repite vez tras vez es la importancia de entender y definir el problema que estamos tratando de resolver. Se basa en las ideas de otros autores para reforzar esto. Una de las cosas que Kevlin resalta es que debemos conocer los detalles, para poder implementar software correcto con la arquitectura adecuada.
  2. El diseño y la arquitectura de software son procesos iterativos e incrementales. Es imposible hacer un diseño completamente correcto y sin errores desde la primera vez. Es por eso que esta es una idea que se repite en sus conferencias vez tras vez. La lección para nosotros: debemos diseñar el software con el conocimiento de que siempre habrá algo que mejorar.
  3. El software simple, pequeño y “aburrido” es más fácil de manejar. Haciendo eco de la frase que pusimos al inicio de esta sección, una de las ideas que Kevlin promueve más es la de minimizar la cantidad de código para lograr algo, así como buscar la simplicidad tanto en funciones como de construcción. Esto último es lo que llamamos aburrido: evitar tanto como podamos tecnologías a las que no estamos acostumbrados o demasiado nuevas y que agreguen dependencias innecesarias.

Pláticas

Kevlin tiene decenas de pláticas en YouTube y Vimeo, hablando temas variados, todos relacionados de una forma u otra con el proceso de desarrollo y la calidad del software.

Vamos a mencionar tres de las que nos han parecido las mejores.

Software is Details

Aquí presenta una idea que repite a lo largo de sus presentaciones: la implementación del software requiere un conocimiento lo más profundo y completo que se pueda sobre el problema que se está resolviendo. Da algunos ejemplos en los que se diseñó un sistema sin pensar en los “detalles de implementación” con resultados catastróficos. Mantener la vista en el sistema entero mientras se toman en cuenta los detalles es una señal de un arquitecto de software efectivo.

Old is the new new

En esta plática resalta la importancia de conocer y dominar los principios que habilitan a las nuevas tecnologías y herramientas. Las implementaciones tienen una vida corta mientras que los principios se mantienen inalterados.

It Depends…

Crear software depende del conocimiento que tengamos acerca del dominio que estamos tratando. Nuestro conocimiento tiene límites que no podemos sobrepasar (incertidumbre) y es contra eso con lo que debemos tener cuidado, cosas que no están inmediatamente en nuestra visión.


Tiene muchas más pláticas en conferencias que puedes buscar directamente en YouTube. Cada una de sus pláticas es un conjunto de ideas y referencias que es más de lo que se puede absorber en el tiempo en el que lo presenta, por lo que tal vez tengas que verlas varias veces, pero todo ese bagaje vale la pena. Aquí te dejamos una búsqueda que las agrupa: DevTube.

Preguntas que le hicimos

Además de investigar y aprender sobre las ideas de estos desarrolladores, creamos un cuestionario para hacérselos a todos los desarrolladores de esta serie, para que contesten la que puedan. Contactaremos directamente a cada uno y le haremos llegar las preguntas, con suerte nos contestaran.

Kevlin fue muy accesible y nos contestó casi todas las preguntas, disfruta las respuestas.

¿Cómo fue tu camino de aprendizaje? ¿Cómo te hiciste así de bueno?

No se si soy tan bueno, pero mi camino ha sido una mezcla de interés apasionado experimentación, ignorancia, estudio, ¡y suerte! Me introduje en la programación en la adolescencia pero no se me ocurrió hasta que dejé la universidad que el desarrollo de software podría ser una buena elección de trabajo o carrera.

Mientras trabajaba, fui atraído hacia el mundo de los lenguajes, técnicas, paradigmas, diseño, etc., mientras leía un conjunto aleatorio de artículos que incrementaron mi interés y fascinación. Empecé a tratar de comunicar esas ideas a través de artículos, y a relacionarlas mis experiencias mientras trabajaba con diferentes sistemas y en en diferentes ambientes.

Esto eventualmente me llevó a dar charlas, cursos y visitar compañías, lo cuál amplió mi campo de visión, retó algunas de mis ideas y mejoró mi habilidad para pensar con los pies en la tierra.

¿Cuál ha sido tu peor decisión técnica? ¿Qué restricciones la limitaron?

Escogeré un decisión técnica que está segura en el pasado; un cuarto de siglo en el pasao, para ser precisos. Estaba trabajando en un sistema SCADA en el sector energético. Nuestros sistemas estaban embebidos en subestaciones eléctricas y tenían muy poco ancho de banda (sólo unos pocos miles de bits por segundo). Ayudé a definir un protocolo binario compacto y que no requería mucho ancho de banda. Cuando definimos el protocolo, decidimos específicamente no preocuparnos por la seguridad en el protocolo porque, en ese tiempo, no pensamos que alguien sería lo suficientemente tonto para conectar infraestructura sensible, como la red eléctrica, a una red pública, como el Internet.

¡Resulta que nunca debes subestimar que tan tonta puede ser la gente! Afortunadamente esto fue corregido después con unos cuántos cambios para usar SSL en vez de correr nuestros propios sockets sin protección.

Dicho esto, aunque perdimos una tendencia futura, nos subimos a otras. No sólo corregimos el problema Y2K antes de que la mayoría de las personas siquiera supieran de él; también atendimos el problema del año 2038.1

¿Cuál es el peor consejo que te han dado?

Las pruebas no son responsabilidad del desarrollador.

¿Cuál es el mejor consejo que te han dado?

Piensa en el desarrollo de software como la administración de la complejidad.

¿En tu experiencia, qué tan importante es el lenguaje que seleccionamos para desarrollar nuestro software? ¿Por qué estamos discutiendo aún sobre los lenguajes?

Es importante porque la elección de lenguaje es comúnmente arquitectural. Si no estás seguro de esto, considera el costo y esfuerzo, las herramientas, las habilidades, etc. de lo que tomaría cambiar de lenguaje en una parte o toda tu base de código. Piensa en cuánto de tu sistema se afectaría, como afecctaría al equipo y cómo otros elementos de tu cconjunto de herramientas tecnológicas saldrían afectadas. Y más. Lejos de ser un detalle, la elección es mucho más significativa de lo que muchas personas se dan cuenta.

El lenguaje, en cualquier forma, es una forma de expresarnos. El lenguaje también está asociado con la cultura y la comunidad. Por eso peleamos acerca de él. Aunque muchos desarrolladores podrían pensar que están debatiendo racionalmente acerca de su lenguaje y sus méritos técnicos, pero típicamente esto no sucede. Debajo de la apariencia técnica de estas discusiones hay algo más humano y menos racional, algo más social y personal. Y por eso es por lo que continuamos discutiendo sobre los lenguajes.

Claro, hay diferencias técnicas y puntos objetivos que se pueden argumentar, pero la verdad es que esto no es el centro de las discusiones.

¿Cuál es la discusión técnica más improductiva que has tenido?

¡Probablemente sobre un lenguaje de programación!

¿Qué podrías recomendar a los programadores jovenes que aún estén buscando su camino?

Observa la historia de la programación, la arquitectura de software, las metodologías de desarrollo, etcétera. El desarrollo de software tiene una historia y la mayoría de las ideas profundas puede ser hayada ahí. La mayoría de las tendencias y elecciones actuales se entienden mejor al entender el pasado, en vez de sólo mirar el presente. El desarrollo de software es más conservador de lo que podrías apreciar, y las nuevas ideas raramente son originales.

¿Qué ideas debemos superar como comunidad de IT para mejorar?

La idea de que el desarrollo de software es una actividad estríctamente neutral y técnica que no necesita considerar a la gente. La manera en que desarrollamos software y en la que es usado tiene implicaciones éticas. Necesitamos reconocer de mejor manera el espectro de personas que pueden y crean software y las responsabilidad que tienen para con las personas qeu usan el software. El software cambia al mundo; no podemos hacer eso y decir que la manera en que el mundo cambia no es nuestra responsabilidad.

¿Cuál es el futuro de la programación para los siguientes diez años, en tu opinión? ¿Qué deberíamos aprender para mantenernos productivos?

Los próximos diez van a ser muy parecidos a los diez anteriores. Va a haber nuevos frameworks, nuevas plataformas, nuevos lenguajes de programación, junto con los respectivos cambios en las habilidades. Algunas personas se emocionarán con las nuevas ideas que no son tan nuevas. Algunas personas personas predecirán la desaparición de los programadores y el software tal como lo conocemos. Lo que es más probable que pase es que el número de programadores va a seguir aumentando y el desarrollo de software va a seguir evolucionando, mayoritariamente en la línea que lleva ahora. El mundo continuará siendo cada vez mas dependiente de los desarrolladores de software.

Recursos

Para aprender más de las ideas qeu Kevlin enseña, puedes investigar más de él y su trabajo aquí:

Conclusión

Todos los desarrolladores de diferentes niveles podemos aprender mucho de las ideas que Kevlin se ha dedicado a enseñar, mientras lo hace de una manera entretenida, profunda y que va puliendo con el tiempo. Es importante escuchar a personas con experiencia para pode desarrollar el criterio propio y las habilidades y formas de pensar para ser efectivos.

  1. El fin del UNIX Timestamp o Y2k38. (Nota de tracucción) 

Comentar