2017/01/13

La falacia de "hacerlo sin frameworks"

Hay una idea difundida entre muchos desarrolladores acerca de que es mejor no usar un framework en lo posible.

El Framework F tiene las deventajas a, b y c; por lo tanto, si no lo usan, evitarán esas desventajas, concluyen.

Veamos por qué esto es una falacia (un razonamiento errado que parece correcto). Las falacias son peligrosas porque parecen correctas.


Un framework es, en esencia, un conjunto de convenciones sobre cómo usar un conjunto de librerías.

Cuando usas un framework, vas notando cómo sus convenciones condicionan el modo en que abordas las tareas y resuelves los problemas. Poco a poco, empiezas a visualizar las soluciones en términos del framework.

Esa pauta que establece el framework puede ser de gran ayuda para mantener orden y estabilidad en un proyecto. Y también para darle continuidad.

Pero también puede ser que las convenciones sean demasiado reguladoras, restrictivas o limitantes. O que haya problemas que sean de solución muy dificil o imposible en términos del framework.

Entonces tenemos:

Framework F
Pros Contras
m a
n b
p c


Para analizar qué framework elegir, sería:

Framework F Framework G Framework H
Pros m
n
p
Contras a no no
b no no
c no no

Así que si esos frameworks tienen esas desventajas, no los usemos y así las evitaremos.


Suena lógico. Sin embargo, es un error.


Lo que realmente están proponiendo es esto:

Framework F Framework G Framework H Framework X
Pros m ?
n ?
p ?
Contras a no no ?
b no no ?
c no no ?

¿Qué es el Framework X?

Es el framework (propio aunque negado) que se irá definiendo (sobre la marcha).

Las preferencias de uso, las posibilidades y limitaciones, y el contexto de trabajo del equipo de desarrollo, determinarán un conjunto de librerías y cómo se deben usar.

Es decir, un framework.


Por eso, lo que realmente están proponiendo los desarrolladores que "evitan frameworks" es:

"No uses un framework conocido (con todas sus ventajas, horas de prueba, comunidad y documentación) y usa mi framework (que aún no existe pero va a ser mejor que todos ellos)"


Si aceptas esa propuesta, automáticamente estás asumiendo un proyecto extra que deberá correr en paralelo al que quieres realizar. Porque hacer un buen framework consumirá tiempo y recursos en codificación, documentación y capacitación.

No es que te estés ahorrando el costo de usar un framework; estás asumiendo el costo de hacer uno.

"No hemos usado ningún framework, así que no tienes que aprender nada nuevo para empezar".

No es verdad. Verás que tendrás que familiarizarte con el conjunto de funciones y librerías que están usando, la forma en que las llaman y la particular (o peculiar) manera como el proyecto se ha organizado (o ha resultado ser).

Si usas un framework conocido, puedes tener más apoyo de la comunidad, documentación, casos de ejemplo, etc. Habrán más personas que ya lo conocen y están disponibles para colaborar contigo.

Es cuestión también de saber ver el vaso medio lleno y valorar las virtudes del modelo open source.

El efecto Dunning-Kruger

Es un efecto psicológico que se observa en todas las personas, de pensar que son más competentes en aquellas cosas en que realmente tienen más limitaciones:

Why Do Incompetent People Think They're So Great?


¿Estamos siendo afectados por el efecto Dunning-Kruger?

Usando las buenas partes

Creo que es importante ser claro en lo que se hace, y tratar de mostrar claramente lo que sucede cuando nos damos cuenta que está sucediendo.

Porque solamente podemos construir castillos de verdad usando ladrillos de verdad.

Reinventar la rueda es muy util para desarrollar las habilidades de invención.

Poder hacer un propio framework que sea comparable con los frameworks conocidos es algo admirable.

Pero no es el mejor camino minimizar lo que esos frameworks conocidos son para que así la tarea de competir con ellos resulte más fácil o nuestro trabajo parezca más meritorio.


Siempre es posible encontrar algo desfavorable en un framework, algo que no puede hacer tan bien y que quizás nosotros podamos hacer mejor (en un contexto más simple, aisladamente).

Me parece más interesante juzgar los frameworks en función de las cosas favorables. De lo que nos permiten hacer. De los problemas que nos pueden ayudar a resolver.

Porque tampoco podemos construir castillos con ladrillos que no tenemos. Hay que usar lo que sí tenemos.


Hay una cita de Addy Osmani como recomendación acerca de los frameworks:

“First do it, then do it right, then do it better.”

Primero usa lo que hay, conócelo realmente. Si encuentras algo que mejorar, corrígelo. Luego intenta hacerlo mejor.

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.

Buscar

Más artículos