Categories
All Español

Increíble la historia de cómo alguien puede perder $6.500 por un bug en su editor de código. Resumen: publica sin darse cuenta una clave para acceder a su servicio de almacenamiento en la nube debido a un error en su editor. A los pocos minutos, esa clave empieza a usarse para acceder a su cuenta y utilizar la potencia de cálculo del servicio para minar bitcoins. via @fpuga

Categories
All Español Radar

Handmade hero

¿Y si pudieras aprender a programar juegos con uno de los principales desarrolladores de motores gráficos de la industria? ¿Y si, en vez de lecciones, recibieras un vídeo diario sobre la evolución del código fuente de un juego real, en su totalidad, explicado? ¿Y si el juego no fuese una demo, sino un producto profesional para vender en el mercado indie? Éso es lo que propone Handmade Hero, un juego desarrollado completamente desde cero por Casey Muratori.

Cada día de semana ofrece a sus suscriptores un video y el código correspondiente. Al acabar el proyecto recibirán el juego, con los vídeos y el repositorio con todo el código fuente. No sólo es un juego, es un esfuerzo por enseñar a la siguiente generación de programadores y recuperar las bases de la industria.

Categories
All Español How I work

De qué hablo cuando hablo de programar

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.

Categories
All Español

Hermosa visualización de líneas de código por proyecto. Me da por pensar en la complejidad que conlleva organizar personas y código para que un proyecto de esas dimensiones no descarríe.

Categories
All Español Radar

Los ciclos pequeños

Natalia ha escrito sobre los ciclos del tiempo y me ha hecho pensar de nuevo en lo fractal y en los ciclos pequeños como rueda dentada de los ciclos grandes. Como parece que no hay una fuerza de voluntad dada, sino microdecisiones que uno toma o no, aprovecho para traducir este viejo artículo que ahora recupera interés:

¿Qué tienen en común la dieta japonesa, los métodos de entrenamento de Mouriño y las técnicas ágiles de creación de software?

  • En la dieta española, típicamente, la alimentación se planifica por semana -el lunes pescado, el martes pasta, etc. En la japonesa, sin embargo, se come multitud de elementos de todos los tipos en una misma comida: el ciclo de planificación es diario.
  • En la práctica del fútbol profesional, se ejercitan varios aspectos: físicos, técnicos, tácticos, psicológicos, etc. Un entrenamiento suele consistir en varios minutos de carrera continua (para entrenar los aspectos físicos),  para luego realizar ejercicios técnicos o estrategia (lanzamiento de córner o salidas con balón) y finalmente charlas de preparación psicológicas. La metodología de la periodización táctica que ejercitan Rui Faria y Mouriño propone un entrenamento integrado, con varios ejercicios que potencian todo los aspectos al mismo tiempo.
  • En la industria de la creación de software, hasta hace poco más de una década, los productos eran concebidos con rígidas fases de producción, consecutivamente “análisis > desarrollo> test > documentación”. Con la emergencia del movimiento agile, crece la idea de que es posible crear mejores productos más rápidamente si se usan ciclos más cortos e iterativos donde se realizan todas las fases simultáneamente.

Lo que me llama poderosamente la atención es cómo en los 3 casos se potencian los ciclos pequeños de actividad que alimentan los ciclos grandes. Y me da por pensar si ese actuar fractalmente marca diferencia alguna entre el éxito y el fracaso.

Categories
All Español How I work iCarto

Me acabo de comprar un portátil

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.

 

 

Categories
All Español How I work

¿Qué es una oferta?

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.

Categories
All Español Radar

Me ha parecido interesante este artículo que habla de cómo la práctica de entregar wireframes es perjudicial para el diseño.  Un ejemplo más de cómo las herramientas que usamos, dan forma a lo que pensamos y podemos hacer.