¿Particionar o no particionar?

Hoy he tenido una de esas epifanías sobre una cosa que uno supone como básica, y que por eso mismo hacía más de 10 años que no pensaba sobre ella: ¿particionar el disco duro o no particionar? Y el resultado es que he decidido quedarme con 1 única partición.

Hoy he tenido una de esas epifanías sobre una cosa que uno supone como básica, y que por eso mismo hacía más de 10 años que no pensaba sobre ella: ¿particionar el disco duro o no particionar?

Por qué dividir mi disco duro en particiones

La sabiduría convencional nos dice que un disco duro debe tener al menos la partición del sistema operativo y la de datos separadas. En otras como swap y temporal es más fácil encontrarse opiniones diversas. La sabiduría nos dice que:

  • tenerlas separadas hace que tengas un entorno más resilente, ya que si el sistema se estropea en una actualización o por un virus, puedes reinstalar uno nuevo sin tocar la partición de datos.
  • permite hacer cosas como tener varios sistemas instalados en distintas particiones compartiendo la de datos.
  • es una manera de asegurarte que el sistema operativo reside en los primeros sectores físicos del disco duro, donde el acceso a lectura es más rápido y, por lo tanto, tendrás mejor rendimiento.

Cuando me he puesto manos a la obra para llevar esa sabiduría a la práctica me han entrado unas dudas existenciales que describo a continuación.

Por qué tengo 1 única partición

Mi sistema inicial es un Ubuntu 14.04 con LVM con una única partición y encriptado. Mi plan inicial era usar LVM para crear una nueva partición para los datos dejando la del sistema operativo en unos 25Gb.

La razón principal de haber decidido usar LVM es que me permite redimensionar las particiones dinámicamente. Uno de los problemas que tuve con mi anterior portátil es que la partición del sistema operativo -donde también residían las bases de datos- llegó a su tope de capacidad en el peor momento: cuando necesité actualizar una BD a pocas semanas de una entrega. La BD en cuestión ocupaba unos 10Gb y necesitaba otros 5Gb de espacio que no tenía en el sistema, pero sí en la de datos. Como no podía redimensionar las particiones y ponerse a instalar las BD en la partición de datos llevaría un montón de tiempo, me puse como un loco a borrar kernels no usados, limpiar cachés, eliminar locales y desinstalar programas. Al final conseguí hacer sitio y salí del paso.

La primera lección aprendida es que es increíble la cantidad de basura que uno acumula. La segunda, que no me gustan las particiones.

Por eso, con la compra de mi nuevo equipo, me he estado replanteando si particionar o no y cuál es la mejor estrategia ahora, en 2015. Me dió por pensar sobre esto principalmente porque mi equipo incluye un disco SSD de 512Gb. A nivel práctico esto significa que:

  • un disco SSD, a diferencia de los de aguja, la velocidad de acceso a los distintos sectores físicos del disco es la misma, no depende de la posición que tengan. Es decir, tener el sistema operativo en la primera partición ya no es un diferencial para el rendimiento.
  • el espacio que tengo es justito para todo lo que quiero almacenar en él durante los siguientes años. Decidir cómo particionarlo supone un problema porque tengo que pensar cómo. Es cierto que el uso de LVM mitiga los efectos de esta decisión ya que podría cambiarlo en el futuro si el sistema crece más de lo previsto o la de datos se me quedase corta. Pero la verdad es que me da pereza pensar en esto de las particiones y tener que juguetear con ellas. Tampoco sé cómo puede resultar o si voy a tener problemas, no estoy experimentado con LVM, así que tengo una aproximación conservadora.
  • no necesito tener partición de datos compartida entre varios sistemas porque tengo sólo 1. Si necesitase un Windows para hablar con la administración, puedo virtualizarlo; de todos modos, en los últimos 6 años no recuerdo haberlo necesitado. Tampoco tengo planeado ponerme a probar nuevos sistemas Linux en paralelo.
  • tengo un sistema de backup que funciona y que permite recuperar datos entre ordenadores de un modo sencillo, con lo que usar las particiones como medida anti-pérdida de datos si hay un problema con el sistema no me aporta nada.

Todo esto me ha hecho reflexionar. Sabiendo, además, que si estoy equivocado y sufro un desastre o mal rendimiento siempre estaré a tiempo de jugar con LVM para organizarlo de otra manera, me he propuesto probar una nueva estrategia que parece más adecuada hoy en día. He decidido quedarme con una única partición.

De qué hablo cuando hablo de programar

La visión hegemónica de un programador baila entre la superespecialización de las factorías de software y el vaquero indomable de las startups que puede hacer cualquier cosa desde la soledad de una cafetería. Necesitamos otro relato.

A grandes rasgos, como programador, me puedo identificar con el trabajo que llevan a cabo un carpintero, escritor, modista o diseñador industrial. Todos ellos crean una estructura donde no la hay y le dan una forma agradable que la gente quiere usar. Lo que es completamente diferente con respecto a ellos son mis herramientas, las tareas diarias que realizo y el conocimiento específico que necesito para llevar a cabo mi trabajo. Cada oficio tiene sus cosas, aunque existan lecciones compartidas de unos a otros.

Las actividades del día a día

En mi empresa, creamos productos para organizaciones. Diseñamos herramientas para la toma de decisiones y compartir información. En ese contexto, mi día a día pivota en torno a 3 actividades diferenciadas:

  • entender los procesos del cliente, para lo que es necesario conocer el dominio en el que trabajas: ¿qué datos se recogen? ¿qué tareas necesitan resolver con esos datos? ¿cuáles son los roles de la gente que participa? El objetivo es entender qué hace el cliente para proponer mejores maneras de hacerlo con ayuda de la tecnología. La mejor herramienta que he encontrado en esta actividad es la conversación con el cliente y compañeros. Suelo también dibujar gráficos en papel. En digital menos, porque me lleva más tiempo y el gráfico no tiene vocación de permanencia, es meramente una herramienta para pensar y comunicar.
  • diseñar el producto, crear la herramienta que se adapte al proceso: ¿debemos usar una metáfora de mapa o de ruta? ¿Cómo componer la interfaz? ¿Cuál es el siguiente paso que un usuario debe hacer? En esta actividad el objetivo es determinar cómo un usuario interactúa con el producto y cómo eso da forma al proceso. Uso mucho el papel para comunicar el flujo o composición de las interfaces del producto a mis compañeros y clientes, pero coge relevancia lo digital para mostrar capturas de ejemplo de otros productos, realizar bocetos, etc. Y, por supuesto, un editor de texto (enfocado a programación) para implementar esas ideas. Hay mucho de ajuste en esta actividad, de probar si lo que pensaste inicialmente tiene sentido, de tratar de entender el espacio de la solución y decidirse por lo que mejor encaja. También tiene mucho de pegamento entre el análisis y la programación.
  • dotar de estructura al producto: ¿cómo diseñamos la base de datos? ¿y la arquitectura de mensajes? ¿es necesario ajustar la estructura o conviene generar deuda técnica? El objetivo de esta actividad es construir la solución. Esto es lo que convencionalmente se entiende como programación: escribir en un editor de texto lo que has aprendido del diseño y análisis. Mi principal herramienta es el editor, claro, y las interfaces que me ofrezcan las tecnologías que uso (base de datos, consola, etc). Suelo también garabatear mucho en papel para pensar. Mientras no se nos ocurra algo mejor, el papel me parece la tecnología definitiva para explorar ideas: flexible, rápida y desechable.

Estas actividades no son secuenciales (análisis > diseño > estructura) ni estancas, se retroalimentan y hay ciclos también en ellas.

Capacidades y equipo en contexto

Es importante que el equipo tenga todas estas capacidades, aunque cada persona tendrá fortalezas en un área u otra: alguien puede conocer muy bien el dominio porque ha trabajado en él, otros pueden ser mejores diseñando el producto porque conocen lo que la tecnología puede dar y tienen la empatía suficiente para entender el proceso, etc.

Hay días en que no sé cómo llamarme a mi mismo: ¿analista, diseñador de interacción, programador? Medio en broma, medio en serio, con los íntimos digo que soy fisico-químico de sistemas de control interactivos. La historia del término tiene su gracia y, en verdad, refleja muy bien lo que hago: estudiar las fuerzas y estados por los que un sistema puede pasar y dotarlo de interactividad. No deja de ser una boutade. Tampoco es que me importe no tener un nombre sino muchos dependiendo del contexto. Además, en el sector nadie sabe en realidad cómo llamarse a sí mismo: UX, UA, IxD, diseñador gráfico, programador, programador backend, arquitecto de software, testeador, programador frontend, growth engineer, etc. ¿De verdad necesitamos tantos nombres? Creo que existen porque señalizan cuál es el silo en que te ubicas en una organización, el departamento y nivel de jerarquía. Yo suelo utilizar sólo 3: analista, diseñador de interacción y programador. Creo que comunican las actividades principales y son ampliamente conocidos en el sector, no necesitan ser explicados. Lo que me gusta de ellos es que transmiten una sensación de amplitud, de recoger todo lo que una actividad puede ofrecer; señalan a mi interlocutor que estoy capacitado para hablar con él (que es lo que me interesa de un nombre) evitando el efecto: ah, es que tú sólo haces UX, no te veo como un igual.

Por otro lado, en cuanto a la secuencialidad de las fases habría mucho que decir, pero tiende a ser cierto que por la propia naturaleza del trabajo los ciclos iniciales del proyecto contienen más análisis y los finales menos, por ejemplo. Además, al estudiar lo que hacen otros, me he dado cuenta de que el día a día de los programadores es muy distinto dependiendo cuál sea tu producto y sector: ¿creas productos para organizaciones? ¿juegos? ¿herramientas de publicación? ¿películas? ¿música? No me refiero únicamente a conocimiento especializado (cómo dibujar un mapa, cómo renderizar un personaje en un juego, etc), sino a cosas más amplias que impactan en cómo enfocas tus actividades diarias. Por ejemplo, una arquitectura específica puede tener mucho sentido en un sector pero no en otro simplemente por cosas como cuáles son los canales de distribución de tu producto.

Crear productos, de principio a fin

Cuando hablo de programar, hablo de todo esto. De la actividad que me permite crear productos de principio a fin.

Por desgracia, creo que todavía hoy la visión hegemónica de un programador baila entre la superespecialización de las factorías de software y el vaquero indomable de las startups que puede hacer cualquier cosa desde la soledad de una cafetería. La primera transmite que no eres nadie si no eres el jefe de todos esos compartimentos estancos; la segunda, que no necesitas compañeros y pares para ser mejor y llevar tu proyecto a cabo. Necesitamos otro relato. Necesitamos una visión equilibrada de la programación como trabajo en equipo y carrera a largo plazo.

No me frusto tampoco con esta visión descompensada pues no conviene olvidar que la nuestra es una industria muy joven. Empezamos, ahora, a tener a nuestros propios viejos programadores. Quizás entenderemos de verdad lo que significa programar cuando el tiempo pase y las historias que cuentan los mayores se transmitan entre generaciones. Por eso admiro a personas como Ward Cunningham y Kent Beck que, a pesar de formar parte de los pioneros de la industria, siguen en primera línea a sus 60 años, haciendo lo que se les da bien: crear productos de principio a fin.

Me acabo de comprar un portátil

Donde cuento las vueltas que he dado para comprar un portátil y trato de entender por qué necesito un equipo que puede enviar un cohete a la luna.

Luego de casi 5 años con el portátil de empresa, me he visto obligado a comprar uno nuevo. Lo cierto es que, personalmente, me daba una pereza increíble actualizarme y ponerme a comparar características para saber cual me convenía. No me llama conocer el último componente de cada aparato ni soy nada coqueto en lo que se refiere a estar a la última. Me rebelo contra las modas de hoy en día en forma consumo minimalista. Uso mis superpoderes de comprador con cabeza.

Mi problema

La situación actual era tan sangrante y antiproductiva que no tuve remedio: mi equipo actual tarda 6 minutos en realizar un proceso que mis compañeros de proyecto realizan en 40 segundos.

Por otra parte, ese proceso es central a la actividad y lo tengo que realizar varias veces por hora: consiste en hacer un cambio en el código de una web y verlo, es decir, la actividad básica de cualquier programador. Sí, 6 minutos: desde que modifico el código hasta que el paquete war es generado y desplegado en un entorno Java para ser visto en una web. En ese tiempo sólo me queda esperar, pensar en el siguiente problema o resolver microtareas que me despistan del objetivo que tengo entre manos. Es decir, en 1h puedo hacer 8 cambios. Si estás leyendo esto y eres programador valora cuántos cambios necesitas para ajustar y resolver un problema habitual. Aunque moví todo lo que pude a ciclos de feedback cortos (del orden de segundos) gracias a una política de tests agresiva, hay cambios que necesito verlos en la web con otros objetos cargados (es decir, tampoco pude montar un entorno mínimo de prueba que fuese más rápido de desplegar).

Por lo demás, el portátil actual funciona para tareas ofimáticas y cualquier otro proyecto de desarrrollo en los que participo. Evidentemente, uno nuevo siempre será mejor, pero no tenía la necesidad de cambio. Sólo por este proyecto.

El análisis: ¿necesito más micro o más memoria? ¿un disco SSD?

Lo primero que hice fue preguntarle a mis compañeros de proyecto cuáles tenían ellos. Quizás con algo modesto podría arreglar. Pero nada más lejos de la realidad, me quedé asombrado de las máquinas que me decían: entre 12 y 20 Gb de RAM, procesadores quad-core y discos SSD. Como mínimo. Miré los precios de mercado para algo similar … y me entró una depresión. ¿En serio tengo que gastarme esto por 1 proyecto?, pensé. No es que sea agarrado en las cosas que realmente tienen un impacto en mi vida ni mucho menos, pero hay cifras que verlas juntas generan un estado mental de desequilibrio.

Por suerte, Fran y Pablo se habían comprado 2 ordenadores con características distintas entre sí pero en un rango de precios aceptable para mí. Abusé de su hospitalidad y les pedí que montasen un mini-entorno de desarrollo con mi proyecto en sus equipos para hacer unas pruebas. Salieron bien y recuperé un poco el color en la cara. ¡Había solución a mi dilema sin empeñarme!

Como dije, los portátiles que usé de conejillo de indias eran diferentes (dual core VS quad core, disco SSD VS de aguja, 1.5Kg VS 2.5 KG, …) así que tampoco tenía una idea clara sobre qué estilo de portátil escoger. Durante unos días me puse a analizar cómo uso yo el equipo, si las actividades que hago son más intensivas en CPU o en RAM y si la mejora del acceso a disco que promete el SSD es en mi caso relevante. Lo cierto es que esto resultó más fácil de lo que creía inicialmente; total, tenía 6 minutos que rellenar entre cambio y cambio. Me encontré con que en mi día a día es fundamental el acceso a disco: tanto porque en los proyectos siempre uso bases de datos como por la compilación de archivos (que genera nuevos archivos en disco). El micro, en momentos puntuales llega a su límite por alguna actividad como la compilación de código pero en general está muy liberado. Los 4Gb de RAM actuales se quedaban cortos a la mínima que abría un navegador, un editor de código y alguna otra actividad. Esto encajaba con mis sensaciones en los últimos años, así que me decidí por una configuración mínima: disco SSD, un micro dual-core i7 y 12Gb de RAM, más de los que nunca creí poder llegar a usar. Con eso de mínimo, tenía garantizado que me servía para el proyecto y el gasto no era inútil.

Me fui de nuevo a las tiendas. Casi me entra la segunda depresión. Uf, vaya precios. Por otro lado, las configuraciones mainstream no pasan de 8Gb de RAM y salirte de ahí sube un montón. Por suerte para mi bolsillo, no era prudente ponerse a cambiar de portátil en medio de un proyecto así que tenía 4 meses hasta que fuese crítico hacerlo. Podía esperar. A una oferta, a que bajasen los precios de la configuración que yo necesitaba o que los portátiles mainstream subiesen la RAM disponible. Y así me puse, a la espera, con un ojo en la marca que empaqueta los teclados que tan bien le sientan a mis manos y que construyen portátiles con certificación militar de durabilidad, por si sonaba la flauta. Por desgracia para mí, en esta iteración se habían pasado de rosca y, por los mismos componentes, salía en unos 200€ más cara que la competencia. Voy a tener que comprarme un porta de hipsters, pensé. Definitivamente no era mi mejor momento. Con todo, me dije que tenía 4 meses y que la situación podía cambiar, así que esperé.

Durante varias semanas estuve revisando varias opciones de portátiles que me valían. El tiempo pasaba. De 6 en 6 minutos. Hasta el 27 de Agosto. Entonces, Thinkpad decidió hacer un 10% de descuento en sus portátiles por la vuelta al cole. Un 10%. Con la configuración que yo quería. Thinkpad, mi primera opción si bajaba de precio. Actué como un felino. Rápido, sin dudas. Compré.

En un par de semanas recibiré mi nueva máquina que, además de ser preciosa, es tan potente como para enviar un satélite a la luna. Ah. Y desplegar un war a Tomcat en menos de 1 minuto. Y, no sé por qué, me da por pensar en el estado de la tecnología en el Siglo XXI. Me deprimo. ¿En serio? Nuestra profesión necesita nuevas herramientas. Esto tiene que estar mal organizado. Un war en Tomcat. Un cohete en la luna.

 

 

¿Qué es una oferta?

Donde me planteo una serie de preguntas: ¿qué hacen las compañías de servicio en una oferta que las compañías de producto no hacen o hacen de otra manera? ¿Es posible casar la innovación necesaria para sobrevivir con tiempos ajustados para pensar el producto?

Cuando uno habla de compañías de software, en ocasiones se hace necesario diferenciar entre compañías de producto y de servicio. Por la propia naturaleza de cada una, sus fases de comercialización son distintas. En una empresa de servicios cobra especial importancia la construcción de una oferta.

Estos días mi atención ha girado en torno a esta diferencia: ¿qué es una oferta? O más concretamente, ¿qué hacen las compañías de servicio en una oferta que las de producto no hacen o hacen de otra manera?

La oferta como fase de conceptualización del producto

Una oferta pone sobre la mesa lo que se va a hacer y en qué condiciones compensa hacerlo. Exige realizar 2 actividades diferenciadas: problem setting y problem solving, proponer una solución y estimar cuánto lleva su ejecución.

product-development-bill-buxtonLas compañías de producto también realizan esas actividades, pero las llaman de otra manera: fase de diseño del proyecto, ideación, conceptualización, etc. En muchos sectores (audiovisual, automóviles, etc) en esta fase inicial se realizan prototipos que permiten explorar el espacio de la soluciones, los productos posibles para el problema que uno desea resolver. Si los prototipos convencen y la idea tiene cierto sentido, se consigue presupuesto para llevarla al siguiente paso: producción. En proyectos software es mucho menos habitual ver esto, sin embargo, es igualmente necesario “pensar el producto” y “realizar el producto”. Y aunque uno no desconecta el cerebro y deja de pensar cuando empieza a ejecutar, sí es cierto que con el paso del tiempo, la actividad de “pensar” es reemplazada paulatinamente por la de “ejecutar”.

El contexto de una empresa de servicios

Una oferta para una empresa de servicios es el equivalente de la fase de conceptualización de producto. Pero condensada. Y con restricciones derivadas de que, habitualmente, conocer en detalle los procesos del cliente durante el momento de realizar la oferta es difícil. Tampoco es habitual construir diferentes prototipos que validen la idea y el enfoque. Por todo esto, en una oferta se concentran riesgos derivados de una concepción del producto errada o bien de una estimación optimista de las tareas. Todo aquel que haya participado en ofertas sabe que si esos riesgos emergen durante el proyecto se transforman en retrasos en las entregas, pérdida de dinero o ajustes del alcance, dependiendo de la relación cliente/productor y el tipo de contrato.

Verlo así da un poco de miedo y parecería que las empresas de servicios son unas irresponsables que no se preocupan por pensar. Sin embargo, en muchas ocasiones, estos riesgos se ven mitigados por varios factores:

  • en general, las ofertas se realizan dentro de un dominio (banca, ingeniería civil, etc) donde los analistas tienen experiencia y un conocimiento aproximado de los procesos del cliente.
  • muchos proyectos en empresas de servicios comparten modos de hacer las cosas o código en forma de librerías que el equipo va construyendo, con lo que uno no empieza de cero cada vez.
  • hay casos donde se realiza una primera oferta de análisis, para plantear a posteriori soluciones concretas.
  • es posible incluir tiempo de conceptualización en el proyecto siempre que el cliente sea consciente de que el alcance es abierto y ajustable.
  • ciertos tipos de contratos favorecen que los riesgos de la exploración de los productos posibles sean asumidos por el cliente, por ejemplo, en aquellos con un alcance abierto pero un precio y tiempo fijados.

Sea como sea, una oferta contiene riesgos que es necesario gestionar. Es sin duda un reto combinar la necesidad de innovación ante el agotamiento del mercado con fases de conceptualización de producto generalmente ajustadas.

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: