diseño

El botón de los 300 millones de dólares

A veces los ingenieros estamos tan enfocados en la funcionalidad que no nos preocupamos de la usabilidad. A ver si me explico, ponemos el foco en la definición del caso de uso, nos centramos en darle al usuario lo que nos pide, pero no lo que necesita. Pero, ¿hacemos una observación de cómo usan nuestro sistema los usuarios? Tengo varias anécdotas de cómo nos hemos dado cuenta que nuestro usuarios realizan tareas manuales para acomodar el input a nuestros sistemas, tareas que no serían necesarias si nos hubieran descrito cómo llegaba la información en realidad, en vez de solicitar un formato ideal de cómo supuestamente debía llegar.

Paseando con Dromedarios

“Un dromedario es un caballo diseñado por un comité” – antiguo aforismo mentat, anterior a la Yihad Butleriana “Nunca hay tiempo para hacer las cosas bien a la primera, pero siempre hay tiempo para volver a hacerlas” – Anónimo, citado por Melvin Conway Mi más memorable encuentro y realización de la profundidad de la Ley de Conway fue hace un par de años, cuando una decisión de arquitectura se vio afectada por la organización del datacenter en que alojamos nuestras aplicaciones.

Cómo diseñar una API

OK, hemos hablado de las APIs, sobre lo que no son, pero no mucho sobre lo qué son realmente, y que importancia tienen en el desarrollo de software. Y para que no digan que sólo nos dedicamos a criticar, vamos a aportar con algunas ideas sobre como escribir una API. Antes de seguir, debo decir que para mi, las interfaces REST, o las API en el contexto de la Web 2.

Una API no es código abierto

Leo en un apunte de Micronauta la afirmación: “el triunfo total del código abierto, una tendencia en la cual la liberación de APIs que estamos observando por estos días es un eslabón fundamental.". Esta frase es el resumen de un texto en inglés que dice: Open Source wins. Open Source solutions and platforms will push proprietary systems to the brink simply because of the rate at which they adapt to change and innovation.