2016/11/19

Saber usar lo que hay

Una idea común:

  • No es necesario usar ningún framework complicado. Puedo implementarlo yo mismo.

Ok, siempre y cuando:

  • Estará bien documentado este nuevo framework (así es, vas a crear un framework que sólo tú conoces), y preparado para evolucionar (así es, eventualmente le encontrarán cosas que mejorar)
  • Puedes costear ese desarrollo extra.
    Ese montón de esfuerzo y tiempo puede ser interesante para el desarrollador, por amor al arte, pero podría también ser enfocado mejor a la idea principal del producto en lugar de a la herramienta.
  • No estará documentado pero no importa porque solamente tú vas a mantener el proyecto
  • No estará documentado pero no importa porque el producto tendrá una vida corta


Es decir, no es buena idea cuando:
  • No hay tiempo ni recursos para documentar o preparar el framework para evolucionar
  • No hay documentación, no estarás disponible eternamente, y eventualmente alguien más va a mantener el proyecto
  • No hay documentación y el producto tendrá una vida mediana o larga
    Ya que aún cuando sólo tú seas quien le seguirá haciendo manteniemiento, luego de unas semanas sentirás como si lo hubiera escrito otra persona


Reinventar la rueda cuando estudias algo es instructivo. Se puede aprender muchas cosas.

Pero cuando es otro el problema principal, reinventar la rueda, estando disponible algún estandar, puede ser muy improductivo. Es apostar que se puede hacer algo tan genial que superará la gran cantidad de horas de experiencia y experimentación acumuladas en el estandar, además de la comunidad de productos derivados, guías y expertos disponibles.

Si el caballo ha ganado algunas carreras antes, puede ser. Pero si es nuevo, o se trata de puro azar, no parece muy recomendable.

Así que es importante reconocer que siempre se usará un framework. La cuestión es si usarás uno más estándar, aceptando sus pros y contras, o si usarás el tuyo propio, el que irá surgiendo sobre la marcha.

Es bonito cuando algo nuevo surge. Algo diferente y mejor que cualquier cosa que hay. Es excelente cuando uno tiene la confianza de hacer algo así. El intentarlo te puede dar un gran poder sobre el destino del proyecto. Y con un gran poder viene una gran responsabilidad. Es mejor si tienes la experiencia para distinguir si puedes asumirla, y si es oportuno.

Es importante recordar que para resolver un problema o desarrollar un proyecto, las herramientas no son lo determinante. Tampoco simplemente usar bien cierta herramienta. Puedes tener un martillo de muy buena calidad y ser excelente con el martillo, pero será complicado usarlo ara ajustar un tornillo.

Más importante es hacer buen uso de aquellas que tengas disponible y te ayuden a resolver el problema.

2016/11/11

De producir software a vender software


Imagina que trabajas varias horas pintando una pared. Luego armando unas mesas. Después un escaparate. Finalmente, organizando las cosas que se van a exhibir.

Esperas, por supuesto, que el dueño del stand te pague por las horas que has estado ocupado, las herramientas que has usado, los materiales, y tu profesionalismo.

¿Qué dirías si te dijeran que, como no se logró vender mucho, tampoco te pagarán mucho?

Piénsalo un momento.

¿Tiene sentido para tí (el constructor)?

¿O tiene sentido para el dueño del stand (el vendedor)?

Los constructores y productores esperamos un pago en función de lo que construímos y producimos.

El vendedor espera un pago en función de las ventas.

Esa diferencia de expectativas es importante.

Si tenemos dos stands A y B, el A construido por nosotros con mucho empeño y calidad, y el B construido con materiales de segunda y poco gusto (según nuestro imparcial criterio), ¿cómo nos sentimos si el stand B arrasó en ventas y no el stand A?.

¿Te ofenderías? No, porque las cosas que se venden no tienen que ver contigo. Tú te dedicas a construir stands.

¿Se ofendería el vendedor? Sentiría que no resultó su estrategia de venta, pero no estaría ofendido contigo, que cumpliste con tu trabajo, ni con los clientes, que prefirieron comprar en otro lado. Así son las ventas.

¿Qué pasaría si el dueño del stand A esperara que los clientes eligieran su producto debido a las muchas horas que trabajaron en el stand, en las herramientas que usaron y el profesionalismo para construirlo?

Sufriría la gran parte del tiempo que no vendiera como espera (una proporción de 10 a 1, según se dice).

Un vendedor entiende que lo importante es el valor que producto tiene para el cliente, no para el productor.

Debido a eso, puede pedir por el producto mucho más de lo que le costó producirlo. Incluso lo suficiente para compensar las veces que le pagaron menos que eso o que no logró la venta.

Esa diferencia de pensamiento es importante.

Valor, trabajo y utilidad

Hay una teoría de pensamiento económico que proponía que el valor de las cosas es lo que costó producirlas. Parece tener sentido. Construir una mesa mejor parece más trabajo que construir una mesa común, así que debería costar más.

Pero no todos los carpinteros son igual de hábiles. ¿Qué pasa si Pedro tarda dos semanas en construir la misma mesa que Juan tarda solo una semana?. Podríamos decir que Juan impregna la mesa con el valor de su habilidad y por eso debe costar más. ¿Y si llega Pablo con una máquina que hace diez mesas mucho mejores en un solo día? Habría que hacer lo mismo con la máquina, que su poder impregna de gran valor las mesas que produce.

Es una forma de pensar que tiene sentido para un productor o constructor.


Otra escuela de pensamiento económico propuso que el valor de las cosas es lo que la gente está dispuesta a pagar por ellas.

Quizás al comienzo cuesta un poco asimilarla. Al menos para mi lo fue. ¿Qué pasa si alguien me quiere pagar menos de lo que me costó producirla? Puede pasar. Pero también puede pasar lo contrario, que estén dispuestos a pagar mucho más de lo que costó producirla.

Una estampilla puede costar un centavo. Pero puede valer un millón para alguien que la considere especial.

Una mesa puede costar 10. Pero si invento una forma de producirla a 0.01, la gente aún me pagará con gusto los 9 que para ellas es menor que su valor en otro lado.

Es una forma de pensar que tiene sentido para el vendedor.

Y es la forma de pensar que ha prevalecido.

La experiencia del usuario

Construir software tiene un costo. En horas hombre, en herramientas, en profesionalismo. Como productores de software, naturalmente esperamos ser pagados en función de eso.

Pero un vendedor de software piensa diferente. Copiar software tiene un costo muy bajo. Aún así, la gente que lo considere valioso pagará mucho más. ¿Cómo hacer algo valioso para la gente?

El vendedor entiende que será pagado en función del uso que se le pueda dar al software. Pudo haber estado toda la compañía trabajando en una característica super sofisticada, algo muy costoso de desarrollar, pero si los usuarios no la consiguen aprovechar, si no la entienden o si ni siquiera se dan cuenta de que existe, entonces es como si no existiera, algo sin valor.

El valor del software que producimos está en función de la experiencia del usuario.

Entender eso puede tomar su tiempo.

De hecho, hay equipos de programadores que se proponen desarrollar un producto con la ilusión de que la aplicación de su mejor profesionalismo, sus mejores herramientas y esfuerzo, garantizará el exito. Son programadores con el pensamiento de productores.

Es necesario pensar diferente.

Tal vez no totalmente como un vendedor, pero sí tomar algunas cosas de su punto de vista. Aceptar la realidad. Aceptar que el valor de un producto está dictado por el usuario.

Como el valor está determinado por la experiencia, es importante mejorar esa experiencia. Las interfaces son como el intermediario entre el usuario y lo que quiere lograr. Debería facilitarle el camino, hacerlo agradable, permitirle mantener el máximo de energía para lo realmente importante.

El uso determina lo que algo es

El valor de algo está determinado por su utilidad, por lo que significa para quien lo quiere.

Lo que algo es está determinado por cómo es usado, por la manera en que lo utiliza quien lo tiene.

Una característica no existe hasta que un usuario la use.

No importa lo cuidadosamente que hayamos diseñado una característica. Lo que importa es cómo la llega a usar a gente. Si nadie la descubre, ¿qué valor le pueden dar?. Por ejemplo, se dice que sólo un 10% de las características de MS Word es usado por el común de la gente, así que cualquier procesador de texto que cubra esas características es igual de funcional.

Como contraparte, hay usos que la gente da a ciertas herramientas, definiendo caracerísticas que nunca fueron diseñadas. Un navegador de Internet, por ejemplo. Pensado para compartir documentos vinculados, se comenzó a usar para imitar otras formas de comunicación, y también para comprar y vender. Y fue ese uso, y no el académico/científico original, el que impulsó el desarrollo web.

El uso que la gente haga de algo también puede darnos pistas de lo que está necesitando.

Conclusión

Si eres productor de software y quieres vender software, hay formas de pensar diferente que vale la pena considerar aprender.

¿Cómo hacer algo que valga para la gente? Es una pregunta importante.

Lo que hagas no tiene valor hasta que alguien lo use. Entonces es importante empezar por ahí; asegurar del modo rápido que estás atendiendo la necesidad correcta. Después ya puedes mejorar la solución, iterativamente.

2016/11/10

Don't Make Me Think


Don't Make Me Think, de Steve Krug, es un libro que estoy leyendo recientemente.

Es acerca de usabilidad.

El termino usabilidad es frecuentemente usado en el contexto del diseño las interfaces de usuario (UI).

Buscamos que la UI permita una buena experiencia de usuario (UX) al ser usada.

En los eventos que he asistido y en otros textos que he consultado sobre el tema, se suele hablar de procurar un diseño visualmente atractivo, reducir el número de pasos para cada tarea, etc.

Puede que sean buenos consejos, pero a veces se toman "porque así es", de manera dogmática, y eso tampoco está bien. Es mejor cuando podemos dar una razón para cada cosa.

Y creo que este libro nos aproxima un poco más a esa razón.

Lo importante es minimizar el número de signos de interrogación que se forman en tu cabeza.

Don't Make Me Think: No me hagas pensar... en aquello que no es la tarea principal.

Cuando un usuario se acerca a una interfaz, es porque quiere algo. La interfaz es el intermediario. Una buena interfaz no es necesariamente la que sea la más bonita, la más mínima... ni siquiera la más rápida. Sino aquella que ofrezca un camino de menor resistencia entre el usuario y su destino. Aquella que le cobre menos tributo, que le deje con más energía para hacer aquello que realmente quiere hacer.

User eXperience, Dev eXperience...

Pensando así en una mejor experiencia de usuario, podemos ver que el concepto es válido para otros contextos.

Como desarrollador, quizás has experimentado el uso de esquemas de trabajo poco usables. Donde las venias y los protocolos forman un bosque de arbustos sobre pantanos sobre los que se puede avanzar, pero es tedioso y consume innecesariamente tu energía.

Don't Make Me Think podría ser un lema a la hora de programar. Las herramientas, frameworks, y protocolos que usamos son los intermediarios entre los desarrolladores y aquello que quieren realizar. Podemos elegir aquellas que ofrezcan el camino de menor resistencia, que nos faciliten las cosas, y nos dejen con más energía para lo principal que hay que resolver.

Podemos pensar en DX, experiencia de de desarrollador y ver cómo mejorar nuestro código. No se trata de que el código sea el más pequeño, ni el que se ejecute más rápido, ni el que contenga ingeniosos hacks. Se trata de que el código que hagamos no nos haga pensar innecesariamente en cosas ajenas al problema principal.


Y podemos pensar en aplicar esto en otros contextos:
  • Para procurar que la experiencia en el entorno laboral sea más usable por el talento humano. La empresa es el intermediario entre sus colaboradores y sus anhelos profesionales. ¿Cómo moejor la experiencia de trabajar en una empresa?
  • Para procurar que la vida en un país sea más usable por sus ciudadanos. El gobierno es el intermediario entre los ciudadanos y sus anhelos para vivir mejor. ¿Cómo mejorar la experiencia de vivir en una ciudad, en un país?

2016/11/01

El Principio de la Máquina Mínima

El desarrollo de un sistema es una serie problemas que se van resolviendo.

Puede haber varias maneras de resolver un problema. Podemos hacer uso de herramientas. El equivalente en software de martillos o cinceles.

El conjunto de todas las herramientas que usamos es parte de nuestro sistema de construcción. Aún sin proponérnoslo, el uso de herramientas determina siempre un framework de desarrollo.

Como en todo framework, a cambio de la ayuda que nos da, habrá limitaciones y convenciones que tenemos que seguir. Habrá cosas que un martillo nos permitirá hacer y otras que no.

Podemos visualizar al framework como una gran máquina, compuesta por todas las herramientas y las convenciones que determinan.

Una máquina puede ser muy útil. Pero tiene un costo adquirirla o construirla. Un costo dominar su uso. Y también un costo de operación.

Una máquina complicada tiene un gran costo de operación.

A veces usar una herramienta puede constituir un problema por sí mismo. Como cuando se maneja una gran herramienta en una obra.

Una máquina mínima sería el framework menos complicado que hace lo que necesitamos que se haga en un contexto determinado.

Puede ser que una grúa también se pueda usar para clavar un clavo. O una piedra. Pero un martillo es el menos complicado de los tres. Cuesta más que una piedra, pero es más confiable y requiere menos esfuerzo. Puede que una grúa también pueda clavar un clavo, además de levantar los materiales de construcción de la casa que construimos, pero es mucho más costosa, espaciosa, requiere ser encendida y una gran pericia para lograrlo.

El contexto es importante.

Puede ser que para clavar un clavo un martillo esté bien. Pero si necesitamos algo más masivo, tal vez notemos que podríamos usar un martillo neumático. En ese otro contexto, usar el martillo neumático puede ser menos complicado.

El principio de la máquina mínima es simplemente evitar el desperdicio de usar ambientes de desarrollo con características que excedan lo que realmente se necesita.

Así, usar un ambiente similar al de producción, conectado a motores de bases de datos, optimmizadores y caches, para desarrollar los templates, es utilizar potencia y complejidad innecesaria. Podría bastar con un servidor web simple con servicio ficticio de datos, incluso datos en hardcode. Para esa etapa, en ese contexto, es suficiente.

El ambiente que sirve muy bien para desarrollar backend no necesariamente es el mejor para desarrollar frontend.

El mito del framework zero

A veces alguien propone no usar ningún framework. Después de todo, no tenemos que preocuparnos de aprender a usar un framework si este no existe en primer lugar, ¿no es así? Terminan de desarrollar un sistema y dicen "no he usado ningún framework".

Pero si analizamos su trabajo, encontraremos un conjunto de módulos, herramientas, convenciones y patrones de uso. No habrá sido bautizado, pero eso es un framework.

Entonces, ¿siempre hay un framework?. Así es.

La cuestión se reduce a si es tuyo o de alguien más.

Es mejor que sea mío, después de todo, tengo así el control absoluto de mi proyecto y no tengo que aprender nada más, ¿no es así?

Como sabes, hay muchas peculiaridades que tener en cuenta a la hora de resolver un problema para el mundo real. Diferencias entre navegadores, inconsistencias en los lenguajes, cosas que no funcionan como se supone que deberían funcionar. Y suelen ser criaturas elusivas, que no se muestran frente al desarrollador sino que les gusta saltar frente a la cara del usuario.

Puede ser que seas un desarrollador genial. El mejor del mundo. Pero, ¿tienes realmente todas esas horas hombre para atender los issues que provienen del uso de tu software?, ¿tienes el tiempo para documentarlo detalladamente?. Quizás sea buena idea volverlo un proyecto abierto y aceptar la ayuda de la comunidad. Con organización, promoción, trabajo y algo de tiempo quizás lleguemos a obtener... algo parecido a uno de los frameworks que podríamos haber elegido al inicio? Pero, está bien, ¿no?, después de todo ¡tenemos un nuevo framework!.

¿Era el problema principal que querías resolver? ¿Era realmente necesario?

Usar un framework propio otorga no solo un gran poder, sino una gran responsabilidad.

En estos tiempos es fácil retroceder ante la primera dificultad y tratar de hacer todo desde cero, puro, como a mi me gusta. Es la ilusión de que si construyes la herramienta perfecta, lo que constuyas con esa herramienta también lo será. Pero son dos cuestiones completamente diferentes. Puedes ser bueno haciendo herramientas, pero eso no garantiza que harás una buena mesa.

Un buen consejo es no caer en la parálisis del perfeccionismo. Usar primero lo que ya hay. Luego corrige lo que puedas. Luego mejora lo que puedas.

Los bundlers

Un bundler, como webpack, puede ayudar mucho a la hora de construir los bundles que se suelen requerir para desplegar una aplicación.

En la etapa de despliegue.

Sin embargo, hay flujos de trabajo que fuerzan a usar el bundler en la etapa de desarrollo.

Eso le agrega complejidad al trabajo. Puede ser una máquina mínima para el contexto de despliegue, pero no lo es para el contexto de desarrollo.

Transpiladores

Un transpilador permite usar una sintaxis más cómoda en la fuente. Luego de la transpilación se obtendrá un resultado que se puede usar en el despliegue.

Puede ser que para la parte de desarrollo se obtenga menos complejidad. Pero es a cambio de mayor complejidad para compartir código, mantenerlo y depurarlo.

¿Realmente te está permitiendo el transpilador tener un flujo de trabajo más simple y ser más productivo? 

A veces, se critica alguna librería por su tamaño. Cuando usas transpiladores quizas la fuente sea pequeña, pero el resultado puede ser más grande que lo normal y menos optimizable.

A veces es simplemente la ilusión de que usar lo mejor producirá lo mejor.

Es importante tener en cuenta el contexto y buscar la simplicidad de manera más holística.

2016/10/31

El mito del mejor software


Hay una historia acerca de un hombre al pie de un farol, buscando sus llaves. Alguien que llega para ayudarle, después de un rato le pregunta si está seguro que las perdió allí. "No, las perdí en la esquina", le contesta, "pero aquí hay más luz".

Un absurdo similar puede ocurrir cuando se elige una tecnología arbitrariamente y no por si contribuye efectivamente al problema que se quiere solucionar.

Cuando alguien se afana en manejar la mejor tecnología, reducir su código y optimizar la carga, simplemente "porque sí", porque es "la forma correcta", en realidad está imitando a aquel hombre. Esmerarse en hacer el mejor software posible es un problema diferente. Pero buscamos ahí porque es un problema donde tenemos más luz.

Nos gusta resolver el problema del mejor software, donde tenemos más luz, que el problema que realmente tenemos que resolver, donde aún está oscuro.

Puedes notar que a muchos programadores les gusta entrar a ese juego de juzgar la virtud de una solución en función de la tecnología usada para construirla.

"¿Con qué lo hicieron?"

Un programador puede tener preferencia por las tecnologías de vanguardia, otro por las super optimizadas, otro por las escalables, etc. Siempre será posible escoger un escenario desfavorable para cualquier tecnología con la que no simpaticemos.

Es una discusión no productiva. Hacer el mejor software no garantiza que se solucione el problema. No es que esté mal buscar la excelencia técnica; simplemente se trata de otro problema.

"¿Funcionó?"

Sería una pregunta más razonable. Una vez que una solución funciona, es cuestión de iterar para llegar a las optimizaciones o solucionar problemas relacionados.

La verdadera tarea no es hacer el mejor software posible sino solucionar un problema.

Hay muchos ejemplos de buenas soluciones hechas con software que se mira por sobre el hombro (Wikipedia, WordPress, Drupal, la base de Facebook, por ejemplo, son hechos con PHP).

Una solución no es buena por el software con que se hace, sino por su oportunidad y relevancia.

Resolución Iterativa de Problemas

Hemos sido educados con un sesgo importante hacia la resolución determinista de problemas.

La forma determinista postula que hay una forma correcta de resolver un problema. Ya sea porque es la más económica, o la más veloz. La solución.

La economía o el tiempo suelen ser los criterios últimos para evaluar una solución.

La forma determinista es como resolvemos los problemas que ya sabemos cómo se resuelven.

Como cuando aprendes a resolver problemas tipo para un exámen de admisión, o los casos de actuación en un protocolo.

¿Has resuelto alguna vez el problema de los dos trenes? Uno parte de A, el otro de B, distante tantos km, a tales velocidades, averiguar a qué hora se cruzan. Un problema con una solución ya conocida. Eso es resolución determinista de un problema. La forma con la que nos han enseñado a pensar. No funciona muy bien para explorar.
La forma iterativa es como realmente resolvemos los problemas cuya solución no conocemos.

Consiste en esbozar diversas alternativas y disparar tentativamente para encontrar alguna que funcione. Una vez que se tiene una línea que llegue al otro lado, se va iterando, corrigiendo la dirección, el apoyo, el material, hasta que poco a poco se tiene un puente que permita cruzar. Una solución.

¿Has jugado Angry Birds? Tienes una honda y varios proyectiles para intentar derrumbar una estructura. Sólo tienes pesos aproximados, alguna idea del viento. ¿Cómo lo resuelves? Lanzando cosas, usando diferentes combinaciones de impulso y ángulo hasta encontrar una respuesta satisfactoria. Eso es resolución iterativa de un problema. Así es como resolvemos las cosas por descubrimiento. Algo que vale la pena aprender a hacer mejor.
La forma iterativa admite muchas soluciones. Cualquiera respuesta que satisfaga la necesidad es una solución. Esta solución puede ser iterada, para optimizarse, para que sea más económica, para que sea replicable o escalable.

La economía o el tiempo pueden ser criterios para evaluar una solución iterativa. Pero sería ingenuo limitarse a ello.

Ya que la solución se va iterando, tiene valor la mantenibilidad; qué tan facil es entender la solución, corregirla y evolucionarla.

En la resolución iterativa de problemas los intentos de optimización prematura tienen el efecto de limitar las opciones disponibles y hacer más complicada la resolución.

Cuando la solución sea muy conocida, se podría usar de modo determinista, como en los libros de texto.

Un problema de los libros de texto es que no te cuentan la forma iterativa en que se se resuelven los problemas.

Cuando las metodologías agiles proponen una forma iterativa de organizar el desarrollo de un proyecto, puede haber una resistencia social (la jerarquía vertical resistiéndose a ser horizontal), y también una resistencia cultural.

Pienso que la resistencia cultural es básicamente el pensamiento determinista resistiéndose a ser iterativo. La gente desconfía de las soluciones iterativas. Básicamente porque no ha sido educada para resolver problemas iterativamente.




Buscar

Más artículos