Innovar para sobrevivir

O cómo actúan las fuerzas que degradan los márgenes de beneficios de tu producto y qué debes hacer para mantenerlos.

Las empresas sacan productos a mercado para ganarse la vida. Pero una vez lo haces, las oportunidades de mantener las ventas/beneficios en el tiempo con el mismo producto son cada vez menores.

Por un lado, en el mercado la oferta de productos similares de menor precior y/o mayor funcionalidad aumenta con el tiempo. Para protegerte, es sensato sacar nuevas versiones que aporten algo nuevo y permitan mantener los márgenes, bien sea consiguiendo nuevos clientes o con la actualización de los actuales a la nueva versión del producto. En esa carrera, llega un punto donde la demanda se resiente: los clientes ya tienen el producto que hace casi todo lo que necesitan, ¿y para qué van a cambiar a una nueva versión con los costes que eso tiene? Por lo que te ves empujado a integrar un número mayor de funcionalidades que van dirigidas a un menor número de usuarios. Si no lo haces bien, es muy fácil acabar con un producto tan lleno de cosas que es imposible que nadie esté contento y hacer la misma tarea les llevará a todos más tiempo. En ocasiones lo mejor es saber decir no:

Por otro lado, los costes de producir algo que la gente desee comprar aumentan con el tiempo: tu productividad y eficiencia se ven mermadas por adaptaciones del producto a cambios tecnológicos propios o del ecosistema, la complejidad derivada del crecimiento y los compromisos que has tomado con el tiempo. En ocasiones, necesitarás hacer cambios profundos que afectarán a tu base instalada de usuarios, a las que quizás no les interesa el cambio que propones por lo que no actualizarán a la nueva versión o, peor todavía, hablarán mal de tu producto. Esta fuerza no visible te empuja a ser más conservador con lo que haces, con el consecuente coste de oportunidad.

2015-08-18 15.17.20En definitiva, el tiempo y las iteraciones meten presión en tu producto. Una nueva versión o funcionalidad no significa simplemente incluir un icono más en el menú o crear una nueva función en el código. La complejidad aumenta con cada añadido y si no la controlas, tu atractivo en el mercado y tu capacidad de reacción serán cada vez menores.

El corre que te pillo de la industria del software

La historia de la mayoría de empresas de software se podría resumir de esa manera: como un corre que te pillo en el que se puede estar un tiempo indeterminado, con las amenazas constantes de que el mercado llegue a su punto de saturación o tu producto se quede desfasado.

Las compañías están programadas para crear nuevas versiones del producto, pero no nuevos productos. Microsoft, luego de tener el monopolio de los sistemas operativos erró al calcular el impacto que tendría internet con consecuencias en su negocio que duran hasta hoy, siendo Google y Apple los grandes beneficiados. ArcGIS, hace una década el producto cuasi-monopolista del mercado de sistemas de información geográfica, ha visto cómo le crecen los enanos con el inicio de siglo: productos de software libre que lo sustituyen para gran parte de las tareas y compañías como CartoDB o MapBox que han sabido leer mejor en un primer momento las oportunidades de internet para el sector SIG. Casi la totalidad de los productos que ha sacado Adobe después de Illustrator han sido resultado de adquisiciones de otras compañías. Y así un largo etc.

genesis-adobe-products

Particularmente con la emergencia de internet y el empuje del software libre, el sector ha sufrido movimientos profundos durante los últimos años, y uno de los patrones que vemos emerger es que las compañías se están moviendo mayoritariamente a un modelo de negocio basado en subscripciones. Un modelo de subscripciones permite reducir el time to market a la vez que los usuarios pagan por las actualizaciones, que no están garantizadas en un modelo de licencia.

Lo cierto es que crear nuevos productos no es sencillo. Sobre todo cuando las fuerzas que degradan tus márgenes son, en un análisis cortoplacista, tan lógicas y apetecibles que es fácil dejarse llevar por ellas: «añade esta funcionalidad, que así firmamos el contrato con este nuevo cliente», «haz un apaño aquí con el código, total es más rápido y funciona lo mismo», etc. En ocasiones, seguro que traen algún beneficio inmediato a corto plazo. Para las empresas que no tenemos un talonario que usar cuando se esté muriendo la gallina de los huevos de oro, esto es un peligro evidente. A falta de talonario, nos toca agudizar el ingenio. Para sobrevivir debemos ser más cuidadosas que las grandes, ampliar miras y aprender a reinventarnos con el tiempo. Vivir arrebatados por el cambio.

Análisis orientado a la tarea

«If I’d asked people what they wanted, they would have asked for a better horse»

— Henry Ford

Una de las cosas que uno hace cuando participa en una empresa es preparar ofertas para clientes. En ocasiones, la tarea es sencilla porque el dominio o el problema es muy acotado o ya has hecho cosas similares anteriormente. En otras, sin embargo, es necesario aterrizar una marabunta de ideas inconexas, deseos más allá de la realidad o que el usuario no sabe lo que quiere (simplemente necesita resolver un problema).

De un problema a una solución

Hace años, participé en un proyecto donde el cliente tenía un problema: para compartir información de un proceso de la empresa, los usuarios participantes tenían en su ordenador una jerarquía de carpetas propia, con distintos documentos cada uno que ligaban mediante un código compartido (que tenía, sin embargo, matices para cada usuario). Cuando necesitaban alguna información concreta, se enviaban e-mails entre ellos para preguntar quién tenía un documento específico.

Esto era un horror además de poco efectivo. Nos pidieron opinión para diseñar un sistema centralizado para compartir información: la idea inicial era construir un FTP que enviase mails automáticamente cuando alguien añadía un documento a una u otra carpeta, según una jerarquía que estaba siendo definida. Luego de algunas vueltas y no pocas conversaciones llegamos a algo diferente a lo que pedían inicialmente. ¿Por qué no crear un sistema de gestión de expedientes que se integre con otras herramientas que ya tenéis? No un FTP más organizado o e-mails automáticos. No un caballo más rápido, sino un coche.

La diferencia puede parecer sutil, pero conceptualmente es un salto importantísimo: las conversaciones con el cliente pasaron de pivotar sobre los nombres de las carpetas que debería tener el FTP centralizado a centrarse en cómo hacían las cosas, los fundamentos de sus procesos internos. En este caso, el resultado fue que no hicimos nada de lo que inicialmente se había pensado (FTP centralizado, envío de mails, etc) y, sin embargo, el proyecto es ahora fundamental en su día a día.

Análisis orientado a tarea

¿Qué es lo que nos llevó a determinar que existía una mejor solución? Creo que simplemente poner la mirada en cómo trabajaban y escuchar, no sólo dejar que el sonido entrase en las orejas. A partir de ahí, pensar un proceso para compartir información sobre la base de cómo hacían ellos las tareas y orientar la construcción de herramientas al soporte de ese proceso.

En ese momento no fuimos conscientes de que estábamos haciendo análisis orientado a la tarea. Supongo que llegamos a esa idea simplemente por ponerlos en la piel de los usuarios, por dedicarle un poco de cariño al proyecto. Desde luego no conocíamos «Understanding the job» de Christensen:

Ni todavía habíamos llegado a Ryan Singer y sus interfaces orientadas a la tarea, aunque poco después empezamos a escuchar lo que estaba diciendo este chico:job

El análisis de la tarea en diseño de interacción

A lo largo de mi carrera, creo que esta técnica ha sido uno de los aprendizajes que más impacto ha tenido en cómo enfoco mi trabajo y en las soluciones que propongo.

Es en este marco en que el estudio de las ideas de Bill Verplank cobran muchísima relevancia. Se me hace ahora más claro cómo encaja el análisis orientado a la tarea en el marco general y las distintas fases del proceso creativo, los outputs que debemos esperar de cada una de ellas.

IxDesign_Matrix

Su librito sobre diseño de interacción ha resultado fabuloso como integrador de muchos conceptos que tenía sueltos. Entre otras cosas, me ha permitido clarificar también dónde encaja la metáfora de mapa VS ruta, que es un buen heurístico para ayudarte a pensar cómo el usuario va a interactuar con el producto.

La verdad es que sienta muy bien dedicar un tiempo a reflexionar sobre lo que uno hace y pararse a estudiar cómo lo hacen otros. Ayuda a clarificar ideas y eliminar lo superficial. Es como dedicar un tiempo a afilar el hacha antes de empezar a cortar árboles. Eres más productivo con un hacha afilada y te cuesta menos esfuerzo. Supongo que es también ahora, cuando uno pasa a ser consciente de cómo hace las cosas, en que empieza lo divertido. ¡Abróchense los cinturones!

Una crítica a la arquitectura Spring clásica

He estado leyendo el artículo Understanding Spring Web Application Architecture: The Classic Way.

Creo que es un buen artículo porque explicita algo que no mucha gente hace en esta clase de cosas: cómo se distribuye la lógica del dominio en la  arquitectura que propone. En este caso, la divide entre servicios, objetos entity, objetos value, etc … y aunque no lo haya puesto de manera explícita, es habitual que, en el mundo real, la lógica del dominio llegue a los controladores de las vistas. Precisamente ésa es la principal crítica que se le puede hacer: propone un modelo del dominio anémico, lo que supone problemas de testeabilidad y comprensión de las reglas del dominio, dos de las actividades que me parecen más fundamentales en el desarrollo de software. No es un problema menor.

Sin embargo, hay otra crítica que se le puede hacer a estos sistemas. Con un impacto igualmente importante, pero quizás más sutil y difícil de ver: tienen un mayor riesgo de quedarse obsoletos. Este tipo de sistemas tienden a ser usados (por su propia manera de ser) como un todo: usas desde el ORM que empaqueta hasta su sistema de directivas HTML/JS (que, obviamente, tiene sutilezas que lo hace distinto a HTML y JS). Suele ser complejo integrar cosas diferentes a las que te propone el framework. Esto hace que seas vulnerable en áreas donde exista gran volatilidad o innovación. Por ejemplo: hoy en día, es inmensa la innovación que se está dando en las interfaces con HTML y JS, tanto por la consolidación de nuevos estándares –HTML5, ECMAScript6– como por la propia dinámica de la industria que ha apostado fuerte por estas tecnologías en los últimos años. Por lo tanto, si usas un sistema de plantillas propio del framework que sea un sucedáneo de HTML y JS, estás invirtiendo en un conocimiento/tecnología específico que en breve tiene grandes posibilidades de quedarse obsoleto.

Hasta aquí la crítica. Me parece importante entender también el atractivo que tienen este tipo de sistemas todo-en-uno. Desde luego que son atractivos al inicio, ya que venden que puedes construir una aplicación en un par de días sin programar ni pensar sobre cómo hacerla. Probablemente sí puedas hacer alguna cosa muy rápido. Me imagino que las primeras semanas pueden ser un camino de rosas. Pero lo que veo en el mundo real es que, a medida que inviertes tiempo en un framework todo-en-uno, los riesgos de encontrarse con sus límites y quedarte bloqueado son altísimos: costes altos de mantenimiento por falta de integración de tests, semanas de desarrollo para hacer lo que parece una pequeña mejora porque supone revisar la lógica en varios lugares e implementar la nueva petición en otras tantas capas, interfaces que no son tan atractivas como las de los competidores, etc.

Para mí, estos son unos riesgos no menores que no asumiría a no ser que los pros fuesen espectacularmente altos. Y habitualmente no lo son. Es muy fácil dejarse llevar y no darse cuenta de estas sutilezas, pero es igualmente peligroso, porque entonces serán los clientes los que te pidan más de lo que puedes dar a un precio competitivo o directamente contraten a otra compañía que se lo pueda ofrecer. Por eso me parece que la selección tecnológica no es meramente una cosa técnica, sino que tiene un impacto muy alto en el futuro de los productos que tu empresa puede ofrecer y conviene tener en cuenta tu contexto y no tomársela a la ligera.

Diseño y testeabilidad

Todo programador que lleve un tiempo en esto, ha vivido debates sobre «arquitecturas» o «patrones de diseño». Dentro de la serie que he iniciado para hablar de desarrollo de software en una PYME, creo que estos debates tienen un encaje fundamental porque una vez seleccionas tecnología tienes que darle forma de alguna manera. Y esa manera es el «diseño» o «arquitectura» de tu producto.

El «buen diseño»

Lo primero que conviene recordar es que la reducción de los tiempos de producción y mayor calidad de producto es el camino de una PYME para ofrecer el máximo valor posible al cliente. En el mercado, eso te pone en una situación favorable con respecto a tu competencia. Definiremos, pues, como «buen diseño», aquel que se pone al servicio de la producción, que permite aumentar la calidad y reducir los tiempos de desarrollo.

Podemos continuar y definirlo como flexible y mantenible, bello y que hace sentirse orgulloso al que lo crea, etc. Pero el problema no es tanto definirlo, sobre lo que existe mucha literatura, sino cómo se llega a él y cómo se mantiene a lo largo del tiempo. Porque tenemos que reconocer que no es fácil y que existen varios problemas. Para empezar, no existe un diseño universal válido sino que hay tantos como contextos, que las personas, además, insisten en tener diferentes opiniones sobre qué es un «buen diseño» y que ambas cosas se reflejan en el código – lo que fácilmente puede convertir tu producto en una torre de babel ininteligible si no se construye una visión común. Tenemos, además, estructuras de comunicación disfuncionales que provocan diseños sub-óptimos, deuda técnica y requisitos cambiantes que introducen variantes a lo largo del tiempo, rotación de personas en los equipos y distintos niveles de experiencia que dificulta la transmisión de ideas, etc. Es decir, el software, su diseño, se ve afectado por las fuerzas humanas y organizacionales. ¿Cómo podemos ponerlo a salvo? ¿Cómo asegurarnos de que las fuerzas están en equilibrio y el diseño sirve a nuestros objetivos?

Necesitamos salvaguardas que nos permitan calibrar qué es un «buen diseño» y controlar su degradación a lo largo del tiempo, herramientas que nos ayuden a caminar hacia a él y nos orienten.

Los tests como salvaguardas

Michael Feathers, en su libro «Working effectively with legacy code» desarrolla la idea de cómo trabajar con software que está degradado. Cómo, partiendo de código degradado, se puede conseguir un «buen diseño» a partir de las restricciones habituales en el día a día (tiempos limitados, código con altas dependencias, etc). Es un libro por ello interesantísimo porque te cuenta ciertas maneras de cómo llegar a ese buen diseño. Y su principal herramienta son los tests:

«When you start to try pull out individual classes for unit testing, often you have to break a lot of dependencies. Interestingly enough, you often have a lot of work to do, regardless of how “good” the design is. Pulling classes out of existing projects for testing really changes your idea of what “good” is with regard to design. It also leads you to think of software in a completely different way.»

Empatizo por completo con su visión. Sobre los tests hay poco que decir: tener o no tener, that’s the question. Porque tenerlos afecta a la producción a varios niveles:

  • El primer efecto y más obvio es que, tenerlos, reduce los tiempos más inciertos y difíciles de estimar en proyectos de software: el testeo manual que hay que hacer en cada versión y el bugfixing. En gran medida, estos tiempos son los que suelen determinar que un proyecto sea o no rentable.
  • Otro efecto un poco más indirecto es que, para desarrollar software testeable, necesitamos dividirlo en trocitos, evitar y romper las dependencias. Es decir, estamos en la dirección de desarrollar software reutilizable, reducir la complejidad.
  • Quizás un poco más sutiles sean los efectos a nivel personal, pero no menos importantes. Por un lado, aportan seguridad y confianza en tu trabajo a posteriori ya que tienes algo objetivo y automático que te dice que funciona. Pero es que además, durante el proceso, tener feedback continuo te ayuda a enfocar tu trabajo y a mantener tu moral alta a base de pequeñas victorias cotidianas. Y la moral, en tareas creativas, es un factor clave en la productividad.

Conclusiones

Tests y diseño van de la mano. Una vez has sentido sus efectos, tu visión cambia. Aprendes que un buen diseño es un diseño testeable. Porque eso es lo que te va a permitir reducir tiempos de producción y aumentar la calidad de lo que ofreces, ganarte la vida desarrollando software de un modo sostenible, que, al final, es de lo que va todo esto.

Inversión y amortización en la selección tecnológica

Dependiendo del día y la hora, actúo como programador, dueño o CTO en una PYME. A lo largo de estos años, me he encontrado en varias ocasiones ante la situación de tener que seleccionar tecnología para un proyecto, compaginando los diferentes roles y perspectivas.

Poco a poco, he ido desarrollando «una intuición», una personalidad propia sobre la dirección que nos interesa a la hora de valorar las opciones tecnológicas. La selección tecnológica en una PYME es un proceso que va más allá de lo técnico, tiene componentes sociales, y también económicos. Estos últimos son los que quiero explorar con esta nueva serie con unos cuantos amigos. Se habla demasiado de los beneficios intrínsecos y universales a cada tecnología particular y muy poco de todo lo demás, que posiblemente tenga más influencia en el tipo de relaciones que una PYME puede generar con su entorno.

Inversión y amortización, lo nuevo y lo viejo

Durante la ejecución de un proyecto, van emergiendo ideas que permitirían reducir tiempos o abrir nuevas oportunidades de negocio a medida que el aprendizaje se consolida. Algunas de ellas tienen sentido y unos costes que te permiten ponerlas en marcha de inmediato; otras, requieren más tiempo o maduración. Aunque suelo ser muy comunicativo con estos aspectos (la comunicación es el oxígeno de una compañía con responsabilidades distribuidas como la nuestra) no es hasta que toca pensar un proyecto nuevo en que bajo esas ideas a la práctica y me pregunto: ¿qué es lo más efectivo que podemos hacer en este proyecto para mejorar nuestros procesos y productos? ¿hacia dónde se están moviendo las necesidades de nuestro mercado? ¿necesitamos cambiar algo drásticamente? Este proceso de evaluación continua requiere mantenerse actualizado y es muy necesario para que el cambio no te pille desprevenido, para evitar ahogarse si el mercado en que navegas naufraga:

«When heavily invested in a technology, you live in a memetic bubble, which also serves as an echo chamber. Bubbles created by vendors are particularly dangerous because you never hear honest appraisals from within the bubble. But the biggest danger of Bubble Living comes when it starts collapsing, which you never notice from the inside until it’s too late

En ese proceso de re-evaluación, hay ocasiones en que toca apostar por algo nuevo y soy consciente de lo que eso supone: estamos ante una inversión. Decidimos invertir porque la posibilidad de beneficios pesa más que los costes y riesgos. La promesa puede ser que nos ayudará a acceder a nuevos mercados, fortalecerá nuestra posición frente a la competencia o reducirá nuestros tiempos y costes de producción, entre otras (aunque éstas son las más habituales que me encontrado por el momento). No puedo negar que, como humano y programador, mi pasión por aprender cosas nuevas y «hacer las cosas bien» influye también en mis decisiones.

Sin embargo, noto que, con los años, mi impulso por asignarle a lo nuevo características positivas por defecto, es menor: soy más juicioso. Quiero pensar que he aprendido a valorar el esfuerzo que supone aprender algo nuevo hasta el punto de, no sólo ser productivo, sino poder ofrecer una alta calidad en mi trabajo. Por muy necesaria que sea la prospectiva y mantenerse actualizado, nuestra industria peca con asiduidad de confundirla con dejarse llevar de forma baladí por la novedad, aporte o no. En economía existe un concepto llamado amortización, que viene a decirnos que el valor de algo se extiende en el tiempo y, por lo tanto, va contra el beneficio sustituirlo mientras su valor no está agotado (no está amortizado), a no ser que lo nuevo aporte un valor netamente superior.

Hablar en estos términos de la selección tecnológica (inversión VS amortización) nos ayuda a enfocar los problema y buscar soluciones.

¿Es posible encontrar el equilibro entre las fuerzas?

Las decisiones tecnológicas no se toman en el vacío, hay un contexto previo, procesos y personas implicados. Necesitamos aprender a reflexionar sobre tecnología no por las cualidades intrínsecas y universales de la misma, sino por las interacciones entre el conjunto de fuerzas en juego. Necesitamos una microeconomía del software, una herramienta que nos ayude a evaluar el equilibro y nos oriente en la toma de decisiones.

En mi experiencia, el equilibro es frágil y complicado de predecir, pues incluye preguntas de difícil respuesta como: ¿cuándo un framework que hemos usado se puede considerar amortizado? ¿cuánto va a retrasar la entrega/proyecto el uso de esta nueva librería? ¿cuándo voy a percibir los beneficios de su implantación? ¿es sensato introducir Node en un equipo de 4 personas donde 3 de ellas no tienen conocimiento web ni javascript previo y el 80% de los proyectos que vas a realizar en los siguientes 2 años son aplicaciones de escritorio?

Pero aunque sea difícil la tarea, una vez sabes que estas fuerzas existen, son fácilmente reconocibles y pensar en clave de oposición entre ellas aporta un inmenso valor en la toma de decisiones. A partir de ese momento, has pasado de ser programador a convertirte en CTO: piensas la PYME como una unidad de producción y estás teniendo en cuenta no sólo tu proyecto o intereses personales sino la evolución de la empresa. Incluyes en tus análisis que, a las finales, esto va de ser rentable para dar de comer a los que la componen.

En esta encrucijada por encontrar el equilibrio, a lo largo de los años, he ido detectando ciertas variables que modulan la intensidad relativa de la inversión y amortización:

Experiencia del equipo

La historia de por qué Disqus usaba Backbone y Django como opción por defecto refleja el tipo de cosas que tienes que preguntarte. La cuestión clave es saber si, además de ti, hay alguien (en tu equipo directo o a salto de subcontratación) que pueda echarte una mano ahora o pueda recoger tu testigo a medio plazo. Si trabajas en una PYME seguramente vas a necesitarla más pronto que tarde ya que esto es como una comunidad donde, si bien hay distribución del trabajo, hay también mucho de pluriespecialismo y colaborar un poco en todo – bien por tamaño del equipo, bien por apurones.

Capacidad de adaptación del equipo

Relacionado con lo anterior, es esperable que la experiencia y capacidades de tu equipo estén alineadas con lo que vendes y produces. Un cambio supone un impacto, un tiempo de aprendizaje de otras capacidades, moverse hacia otras direcciones. El tiempo que le lleva a alguien llegar al punto de ser productivo ante un cambio es muy variable de persona a persona y tiene mucho que ver con su experiencia previa y su pasión por aprender. Algunas empresas lo pueden solucionar cambiando de equipo a golpe de talonario; las que nos definimos como democráticas y aspiramos a crecer horizontalmente, de manera orgánica, debemos tener en cuenta que el impacto del cambio en nuestros tiempos de producción y calidad del producto final no va a ser despreciable.

Acceso e integración de talento

Hoy en día, en España,  si te sales de Java y sus frameworks (Spring, Struts, Wicket) es probable que te encuentres con que los recién licenciados no conocen de qué estás hablando. En las escuelas de informática se está abusando de la concentración en torno a Java, probablemente por la promesa de oportunidades laborales en las «fábricas de software» (que por otra parte se ahorran tiempo de formación porque los nuevos ya vienen de casa aprendidos). En cuanto a gente con experiencia en una tecnología reciente (pongamos por caso Scala, Node), el coste de acceso a ese talento y el riesgo de que se vaya al poco tiempo puede ser prohibitivo para una PYME. Sin duda hay espacio entre tecnologías ampliamente conocidas y otras todavía minoritarias, la cuestión es saber que la decisión tiene impacto en tu capacidad de contratar talento y valorar en qué parte del espacio te conviene estar.

Mercado: oligopolios y efectos red

En ciertos mercados, las opciones tecnológicas tienden a la concentración. En mi caso -sistemas de información geográfica y web- en el stack tecnológico pesan mucho lenguajes como javascript, python y java, con esos lenguajes puedes hacer casi cualquier cosa: desde un plugin para una aplicación de escritorio a una web con servicios de geolocalización. Si buscas sinergias con otras empresas, necesitas integración con otros proyectos, quieres usar librerías existentes o simplemente reaprovechar conocimiento en este sector, conocer Ruby es menos valioso y te abrirá menos puertas que los 3 anteriores. Un economista puede reconocer fácilmente esta situación como efectos red del ecosistema (número de empresas participando, librerías existentes, disponibilidad de foros de consulta, etc). Los efectos red tienen más impacto en el éxito de una tecnología que su belleza o calidad técnica superior. Es la razón por la que PHP y Javascript ganaron la web a principio de siglo, a costa de Perl que tenía el dominio en los 90.

Nivel de indirección y reaprendizaje de la tecnología

Uno de los mayores costes del desarrollo de software es el re-aprendizaje. Al cambiar de tecnología no sólo se pierde código, sino también conocimiento. Apostar por una solución más cercana a los estándares -o con menos conocimiento específico, llamémosle magia- facilita que pierdas menos cada vez que te cambies, aunque puede ser más costoso al inicio ofrecer lo mismo que con otras soluciones con más magia. Por ejemplo, una tecnología como Backbone te habilita a usar los estándares (al final casi sólo te ofrece una manera de organizar tu código Javascript), sin embargo Angular o React te proponen el aprendizaje de una serie de idioms propios a cambio de la promesa de la rapidez de desarrollo.

Volatilidad y adaptación al cambio de la tecnología

Ligado a lo anterior, se puede decir que una opción tecnológica puede estar más preparada que otra para adaptarse al cambio. Una base de código que, por ejemplo, esté basada en Backbone es potencialmente más flexible a la hora de integrar novedades tecnológicas que otra que siga los idioms de React. Esta última tendrá que esperar a que en React se integren los cambios de los estándares o aparerezcan plugins que lo hagan – dependiendo del tamaño del ecosistema alrededor de React esto puede ser más rápido o más lento. Una situación de volatibilidad hace que el período de amortización de una tecnología pueda ser anormalmente corto, lo que afecta a tu capacidad de generar beneficio si tienes que cambiarla al poco tiempo de empezar a usarla. Pueden existir zonas del código y el proyecto con alta estabilidad (no hay ni se esperan novedades tecnológicas) mientras que otras tienen una alta inestabilidad. Lo importante es detectar dónde te interesa no casarte con nadie porque todo está en ebullición y  dónde es seguro además de recomendable hacerlo porque el período de amortización es estable y la reducción de costes es real, no sólo una promesa.

Amortización esperada de la tecnología

Esto tiene que ver con el cálculo de los beneficios esperados. Influyen cosas como lo que estimes que vas a trabajar con esa tecnología en el futuro (no es lo mismo que, durante los siguientes años, estimes un reparto de trabajo de 90% en productos web y 10% en proyectos móviles que un ratio de 60% para aplicaciones de escritorio y 40% en web). Si lo que esperas es crecer mucho en un área determinada, tendrás más espacio para amortizar la inversión porque tendrás más oportunidades de reutilizar el conocimiento y código que has hecho. El alcance de las inversiones tecnológicas deben ir acordes también con tus expectativas de negocio y evoluciones estratégicas.

Margen de inversión

En una PYME no es muy habitual poder dedicar 3 meses a realizar prototipos un poco complejos con varias tecnologías. Habitualmente los tiempos son muchos más reducidos y necesitas sacar trabajo adelante. Es importante que sepas el tiempo que tienes para equivocarte y salir del apuro cumpliendo con las entregas de un proyecto, porque eso va a ser principalmente tu margen de inversión. Aquí importa no sólo el tiempo de duración del proyecto, sino también la incertidumbre que lo rodea: estabilidad de los requisitos, conocimiento previo del dominio, confianza con el cliente para negociar reducciones de alcance o retrasos, etc. También influirá tu compromiso a la hora de solucionar los marrones donde te has metido. Por ejemplo, parece claro que el margen de inversión que tiene un proyecto de 1 mes con alta incertidumbre en cuanto a requisitos, es mucho menor que otro de 12 meses donde conoces perfectamente el dominio y los riesgos que existen.

En mi experiencia, estas variables modulan la intensidad de la inversión o amortización y, dependiendo de la elección en que te encuentres, unas pesan más que otras. Por ejemplo, a la hora de seleccionar un lenguaje y ecosistema para un nuevo proyecto, el mercado de referencia (y sus efectos red) así como la composición de tu equipo son 2 de las variables que me parecen más importantes. Sin embargo, a la hora de seleccionar una librería concreta, el nivel de indirección y volatilidad del ecosistema suele tener más peso en mis decisiones.

A medida que uno avanza y toma experiencia se van haciendo más claras éstas y otras variables, aparecen nuevas, otras se reinterpretan. Lo importante es reconocer las fuerzas, no dejarse llevar por los análisis universalistas y pensar el impacto de las decisiones desde un contexto determinado: el tuyo.

La importancia de la selección tecnológica en una PYME

Un post reciente de Manuel me hace retomar una serie que tenía a medio escribir y que fui dejando de lado por la agitación del día a día: la importancia de la selección tecnológica en una PYME.

La idea central de la serie es que las decisiones tecnológicas no se dan en el vacío y tienen impacto en otras áreas de la empresa: la contratación y evolución del equipo, la capacidad de generar relaciones con otras empresas o la comercialización y el acceso a trabajos y proyectos. Habitualmente las discusiones tecnológicas gravitan en torno a aspectos intrínsecos al lenguaje (sintaxis, el tipado, etc), dejando de lado factores extrínsecos pero quizás más determinantes en el tipo de relaciones que la empresa puede establecer.

Una PYME debe conocer su espacio en el mercado y eso, parcialmente, pasa por hablar de tecnologías de otra manera: con un lenguaje y visión económica. Con un ojo en el negocio y otro en la técnica.

Por eso os propongo un reto: escribir un post semanal durante 3 semanas relacionado con la selección tecnológica en una PYME.

Posts de la serie:

Programación y lingüística

¿Qué es un lenguaje de programación? A nivel lingüistico, se puede definir por su léxico (el conjunto de elementos de que está compuesto), la sintaxis (reglas para la combinación de los elementos, léxico y lexemas) y la semántica (el significado de una estructura gramatical).

Durante la última lectura en que me he embarcado, he empezado a pensar sobre esto, la lingüistica, la programación y sus similitudes. Por ejemplo, para entender la diferencia entre la sintaxis y la semántica es muy útil trazar analogías con el lenguaje natural: así pues, leyendo a Chomsky –Colorless green ideas sleep furiously– lo comprendo mejor.

 Y he empezado a desarrollar la convicción de que entender estas relaciones, nos da herramientas para estructurar mejor nuestras sentencias, y también, nuestro código. Al fin y al cabo código y lenguas versan sobre cómo estructurar mejor nuestras ideas:

The acts of the mind, wherein it exerts its power over simple ideas, are chiefly these three:

  1. Combining several simple ideas into one compound one, and thus all complex ideas are made.
  2. The second is bringing two ideas, whether simple or complex, together, and setting them by one another so as to take a view of them at once, without uniting them into one, by which it gets all its ideas of relations.
  3. The third is separating them from all other ideas that accompany them in their real existence: this is called abstraction, and thus all its general ideas are made.

— John Locke, An Essay Concerning Human Understanding (1690) (via SICP)

Programar, como escribir, consiste en controlar la complejidad de un sistema/idea, y transmitirla de un modo sencillo a otros. Porque

«programs must be written for people to read, and only incidentally for machines to execute»

— SICP, preface to the first edition

Una nueva época para el desarrollo

Hace unos meses, Tarek Ziadé ha escrito un ensayo muy interesante en su blog: A new development era. El resumen es: las tecnologías web (HTML5/JS) están ganando espacio e importancia a la hora de construir aplicaciones complejas en cliente (escritorio, navegador, teléfono, tablet) mientras que el servidor se está convirtiendo en un proxy a servicios ligeros con los que el cliente interactúa.

2000_2012 2015_

La lectura de este post me cogió en un estado mental propicio para empatizar, ya que llevaba varios meses construyendo una aplicación Javascript con Backbone que tiraba contra servicios JSON hechos en python/pyramid. Pasada la emoción inicial por verme reflejado en el post, me he dado cuenta de que la idea está más extendida de lo que yo creía: no son sólo los early adopters ya, sino también los big players de la industria de escritorio los que permiten hacer aplicaciones javascript (WindowsGNOME) e ¡incluso la vieja guardia dedicada a construir aplicaciones java en servidor! Quizás sea una nueva vuelta del péndulo. Quizás, que la promesa de aplicaciones multiplataforma que funcionan en múltiples entornos es atractiva. Lo que es seguro, es que la siguiente hornada de aplicaciones se harán de esa manera.

A new development era

Tarek Ziadé has posted a few months ago an interesting essay on his blog: A new development era. Summing up: web technologies (HTML5, JS) are gaining importance to build complex apps in the client (whatever it is: desktop, browser, phone, tablet) and the server side is becoming a proxy of lightweight services to interact with.

2000_2012 2015_

The post resonated with me due to the fact that my work during last months was to build a rich client app in Javascript with lightweight JSON services built in python. But, as far as I’ve seen it, this tendency is more spread than I thought: it’s not only happening within early adopters, but also within big players in the desktop realm (Windows, GNOME) and the old-school java server applications. Maybe is a new swing of the pendulum, or just that the promise of cross-platform apps that just work in multiple environments is appealing. What is certain, is that the next million apps seems to go towards that tendency.

(Geo) Database evolution while developing

During last year, I followed with interest the different approaches on how to evolve the design of a database being discussed within the postgresql community. Following is my take on that one: how this year I developed a project with an intense evolving DB design using an agile approach.

The context

My requisites for this project were twofold:

  • An evolving DB design: at the beginning of the project I didn’t know how the DB design was to going to be. I had set to use some advanced techniques for data modeling which never had used in production (dynamic segmentation and linear referencing with PostgreSQL/PostGIS) and needed an approach which supported my evolving understanding of the domain.
  • Intense collaboration with analists: the project needed some intense work on data-processing to polish and create the data for the application. I knew this was to be an iterative process where both developers and analists would collaborate together to define and clarify the model we needed.

My approach

So, in the process of improving and automating my delivery pipeline, I set some rules for the project:

  • DB management through SQL and control versioning: the database was created from DDL scripts and data was stored as CSV (if alphanumeric) or SQL (generated from Shapefiles to store geographical information).
  • Application and database evolve together: so their code should too, which in practice means I put the app and DB directories/projects under the same git repo.
  • Test driven development: I needed to break the problem in small chunks I could deal with, while my understanding of the domain improved. Besides, when refactoring the DB (schemas, triggers, functions, etc) -which happened frequently- I needed to know all the pieces were working OK. I decided to use pgTap for that.

And how it turned out?

  • The pipeline worked smoothly: both the analists and developers were working in their confort zone with the proper tools; desktop GIS applications the formers, command-line and SQL the laters.
  • git provides an excelent mechanism for versioning text, so I had powerful tools at hand for versioning SQL structure and data (diff, cherry-pick, interative rebases, etc). Besides, see where the data was varying (name and type of fields, its values, etc) allowed us to early discovered some bugs and problems.
  • Database and application evolving to the same pace. By tagging the versions we can build in seconds the binaries needed for any version of the application with the proper DB.
  • Tests at DB level are a life-saver. pgTap allowed me to refactor the database whith no risk and a lot of confidence on what I was doing. I had all kind of tests: check if a trigger is launch if an UPDATE happens, a function is working, data integrity and model validation after the initial restore, etc.
  • Same process for deplying to developing, staging and production environments, which resulted in fewer errors and no panic-moments.
  • Having the data in the repo and regenerating BD from scracth was very comfy and quick (less than a minute in my laptop the whole DB: 100Mb of raw SQL) and similar numbers when deploying to stage through the wire. In a daily bases I only had to regenerate specific schemas of the DB, so waitings was an order of seconds.

Coda

We should consider the database as other deliverable to our clients and set the same quality, standards and methodology to develop it. In that sense, agile philosophy and practices match very well with the DB evolution.

At the tools level, I was reluctant to introduce new tools and steps I didn’t know very well in such a tight schedule, so I decided to stick to the basic and spartan (git repo, shell scripts, pgTap and SQL), then iterate and grow a solution for our specific case. Although I missed some refactoring tools, it turned out to be a good approach and now I´m in good position to know the tradeoffs of the process, which in next projects will help me to choose a specialized tool, if necessary.