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.




2016/10/12

Posicionando el footer con Flexbox

Una forma de posicionar el footer, con Flexbox.

Cómo hacer que el footer esté siempre al fondo de la página, aún cuando el contenido sea mínimo.

Idea

  • El container usa display: flex
    • flex-direction: column para indicar disponer los elementos verticalmente
    • justify-content: space-between para que los elementos se separen hasta ocupar toda el área
      • Para que área tenga toda la altura, el html, body y el mismo container tienen height: 100%
  • Para indicar la altura de un elemento dentro del flex, se puede usar algo como flex-basis: 50px
    • Para indicar que el elemento no se pueda contraer, flex-shrink: 0
  • Para indicar que main ocupe toda la altura posible, flex: 1 (por default los demas están en 0)
 

2016/10/04

Proyectos felices


Internet y las nuevas tecnologías están ayudando a que la gente imagine formas nuevas de hacer las cosas y resuelva problemas.

La gente imagina soluciones y trata de implementarlas. A veces con éxito, a veces no tanto.

Y es que la forma de implementar una solución es también algo que tendríamos que mejorar.

Muchos provenimos de instituciones educativas que nos han formado con hábitos que no suelen ser los mejores. Una tendencia a establecer relaciones jerarquicas, en lugar de colaborativas. A competir, en lugar de cooperar. A proteger, en lugar de compartir. A culpar a las personas, en lugar de enfrentar los hechos. Y así.

Así que a la hora de realizar un proyecto con el que intentamos resolver cierto problema, encontramos un meta problema, que es la forma cómo nos organizamos.

Lo que puede hacer la diferencia no es cuánto dinero tenemos, ni qué tecnología usamos, sino cómo estamos organizados. ¿Es un organismo sano, sabemos cuándo algo le duele, sabemos curarlo, podemos caminar de modo sostenible?

Hay propuestas, como la de las metodologías agiles, que dan cierta luz en ese camino oscuro por el que siempre hemos venido transitando sin darnos cuenta.

Estas son algunas de las cosas que me parece se toman en cuenta en proyectos felices.

  • Lo más importante es la gente
    • El dinero es solo una herramienta
    • La gente no es una herramienta ni un recurso
    • Permite cultivar los verdaderos talentos, no los que necesitas.
      (la gente que encuentra su pasión es la que mejora el mundo)
    • Cuestiona los hechos, no a las personas
    • Cultiva una comunidad
    • Cada problema es de la comunidad
    • Cada victoria es de la comunidad
      (las clásicas recompensas individuales no hacen bien a la larga)
  • Disfrutar el camino
    • Cultiva la autonomía, la maestría, y el hacer algo por un propósito superior
    • Trabaja por objetivos, no por turnos
    • Reunirse cada día, para mirar cómo vamos
    • Reunirse cada semana, para mirar cómo lo hicimos
    • Preguntarse que salió bien y qué se puede mejorar
    • Celebra aquello que quieres que perdure
    • Equivocarse es parte de aprender
    • Un paso completo, aunque sea pequeño, es una victoria
    • Cada victoria te da energía para el siguiente paso
  • Honestidad
    • Saber decir que no
    • Mostrar con claridad y explícitamente el estado de las cosas
    • Debe haber un por qué para cada cosa que se quiere incluir en el proyecto

Muchas veces se desarrollan proyectos sin tener en cuenta casi ninguna de estas cosas. Es decir, sin tener en cuenta a la gente, con quienes finalmente tienes que contar para lograrlo.

Hay varias preguntas y retos al tratar de hacer estas cosas. ¿Por qué no funcionan las recompensas?, ¿Cómo se deben distribuir la ganancias?, etc. Algunas pueden parecer contra intuitivas, pero están apoyadas por evidencia objetiva y estudios en comportamiento humano (a diferencia de muchas cosas que hacemos simplemente porque siempre se ha hecho así). Algunas pueden parecer imposibles, pero ya hay organizaciones en el mundo moviéndose bajo principios como estos.

Quizás sea porque nuestros padres no sabían hacerlo y tampoco nos lo enseñaron. Pero es algo importante que pienso debemos aprender a hacer para prosperar en esta nueva era.

2016/07/15

Usando FiraCode en Atom en Ubuntu


FiraCode es un font que soporta ligaduras para algunos símbolos que se suelen usar en programación, haciéndolos más fáciles de leer.

https://github.com/tonsky/FiraCode

Para usarlo en Atom (en Ubuntu 14.04):

atom-text-editor {
  ...
  text-rendering: optimizeLegibility;
}

Y para prevenir que se hagan ligaduras dentro de cadenas o expresiones regulares:

atom-text-editor::shadow .string.quoted,
atom-text-editor::shadow .string.regexp {
  -webkit-font-feature-settings: "liga" off, "calt" off;
}

Referencias:

2016/07/09

Vistas esquemáticas

En el diseño gráfico, la vista de alambre ayuda a abstraerse de los detalles y concentrarse en la estructura. Sería demasiado complicado e incómodo tener que trabajar todo el tiempo con la vista final. Además de innecesariamente costoso.

Sin embargo, muchas veces desarrollamos software trabajando todo el tiempo con la vista final.

Sería util poder contar con una especie de vista de alambre, además de a vista final. Esa vista esquemática pueda ayudar a abstraernos de los detalles estéticos de la interfaz y permitir apreciar mejor la estructura de la aplicación, o el flujo de solicitudes y respuestas.

El desarrollo de una vista de alambre podría ayudar también a construir un mejor software.


2016/05/24

Copiar un DVD en Linux Ubuntu




Usando Brasero en Ubuntu Linux 14.04

Una forma práctica:
  • Crear un iso del dvd origen
    1. Insertar el dvd en la lectora
    2. Abrir Brasero (incluido con Ubuntu)
    3. Click en Disc Copy
    4. Select disc to copy: el dvd de origen
    5. Select a disc to write to: Image File
    6. Click en Create Image
  • Quemar el iso en el dvd de destino
    1. Insertar el dvd en la grabadora
    2. Abrir Brasero (otra vez, para que reconozca el disco insertado)
    3. Click en Burn image
    4. Select a disc image to write: la imagen iso
    5. Select a disc to write to: el dvd de destino
    6. Click en Burn

2016/04/27

Reutilizar código

Hay programadores que parecen tomar la reutilización de código como un mandamiento que hay que cumplir mecánicamente para ser un buen programador.

Pero, como aprendimos con los diez mandamientos, la bondad de algo no está tanto en obedecer mecánicamente sino en comprender el por qué.

[Leer más]

2016/04/16

Sobre frameworks

Algunos desarrolladores dicen que prefieren no usar frameworks.

Empiezan desde cero y van completando el sistema con ayuda de los patrones y librerías que les parecen más adecuados.

Felicidades, eso es un framework. Cualquier desarrollador que quiera corregir o agregar algo al sistema tendrá que familiarizarse con las peculiaridades de ese nuevo esquema.

Seamos claros. Siempre se usa un framework. Si no es el de los demás, es el tuyo. Si no lo tienes hecho, irá surgiendo en el proceso.

¿Cuál es la ventaja de un framework propio? Que si el desarrollo es reciente probablemente estés muy familiarizado con él y puedas hacer cualquier cosa más rápido y mejor que alguien que no lo conoce (todos los demás).

En cierto modo, usar un framework propio, alimenta la ilusión de falsa competencia, porque eres el mejor en el juego (que nadie ha practicado tanto como tú).

Por supuesto que hay proyectos que requieren una solución a la medida, particular y específica. ¿Pero pertenece tu proyecto a ese grupo exclusivo de clientes que necesita un sastre? ¿O es como el 90% de los proyectos usuales? Quizás seas un buen costurero, quizás seas un buen sastre, pero, ¿que es lo que realmente necesita el cliente? ¿se sentirá cómodo en la playa con sus shorts de diseño? (el cual no puede forzar mucho porque no ha sido tan probado como los más baratos shorts que pudo haber elegido).

Muéstrame alguien que reniegue de usar un framework conocido y posiblemente encontremos que, aunque sea buen programador, no domina ninguno. Es natural querer usar lo que mejor manejamos, pero no es justo negar la virtudes de lo que no hemos probado o aún no conocemos a profundidad.

No existe tal cosa como un proyecto hecho sin frameworks, sólo con estándares. Lo que en realidad hay es un nuevo framework surgido en el transcurso del desarrollo, impregnado con las particulares opiniones del desarrollador sobre como se deben hacer las cosas correctamente, probablemente con escasa documentación y comunidad mínima (esas cosas requieren más horas hombre que las que pueda pagar cualquier cliente).

Existe la posibilidad de que el nuevo framework tenga alguna ventaja sobre los demás. Entonces, la manera más eficiente de que evolucione es que se vuelva open source. Si realmente es bueno, la comunidad llegará para usarlo, probarlo, documentarlo y difundirlo.

Encontrarás muchas razones por la que un proyecto open source es una mejor opción para hacer mejor software.

Cuando se hace software es importante reutilizar aquello que es bueno. Para reutilizar software, o para mantenerlo, con comodidad, es importante documentación y ejemplos. Para documentar y discutir casos y soluciones, una buena comunidad es grandiosa.

Pienso que un software es mejor cuanto más mantenible es. Algunos piensan que es mejor lo que corre más rápido, pero no se puede hacer muchas optimizaciones sobre código ilegible (y la optimización prematura es el camino a todo tipo de problemas). Otros piensan que es mejor software si usas menos líneas de código, pero no podrá evolucionar con facilidad si esa obsesión de menos líneas conduce a código menos legible que requiera numerosos hacks mentales tan sólo para aclarar la intención.

Además, el código lo va a correr una computadora, a la que le da lo mismo. Todas esas cosas de buenas prácticas, organización, frameworks, etc, no es por ellas, sino para la gente. Así que es más importante escribir buen código para la gente.

Pienso que un código es más mantenible si es más legible y si es más fácil de depurar. No importa que sea muy largo o parezca inocente, porque esa sencillez permitirá obtener versiones optimizadas también con facilidad.

Aprender un framework cuesta, pero usar un framework conocido puede hacer que tu proyecto sea más mantenible y una mejor opción para tu cliente. Si te gusta crear cosas nuevas, suele haber espacio para plugins (y mejor feedback para tu trabajo). Si quieres realmente ser autor de un framework, aprenderás mucho de la comunidad antes de intentar crear una. Puede que te ayude tener mejor perspectiva conocer a otros con muy alto nivel colaborando con entusiasmo en proyectos open source. Aprenderás a valorar la gran cantidad de tiempo y conocimientos que se puede condensar en un proyecto abierto, más allá de lo que puedas imaginar.

2016/03/12

#NoEstimates

   

https://oikosofy.safechkout.net/NoEstimates-Book  

Un desarrollador (o su representante) conversa con el cliente (o su representante):

- ¿Qué es lo que se necesita hacer?
- ABC, ¿cuánto tiempo te tomará?
- x

Luego de x tiempo:

- Ya pasó x, ¿cómo vamos?
- Aún en la tarea
- Vamos retrasados

Finalmente:

- Ya está listo ABC
- Ok, pasa la prueba. Pero se atrasaron y%
- Ok, trataremos de hacerlo mejor

Situaciones de ese tipo se presentan durante el desarrollo de un producto y nos parecen normales. Sin embargo, expresan una serie de supuestos que no son necesariamente ciertos. Ni siquiera relevantes.

¿Qué es lo se necesita hacer?
Supone que el cliente (o su representante) saben lo que se necesita hacer. Casi siempre no es así, y determinar lo que se necesita hacer es algo que habrá que resolver. ¿Qué es lo que quieres resolver? suele ser una mejor pregunta.  

¿Cuánto tiempo te tomará?
¿Cuánto tiempo toma hacer algo? Si has hecho algo similar varias veces, puedes tener una idea. Pero como programador habrás experimentado que muchas veces hacer exactamente lo mismo, con la misma gente, toma un tiempo diferente. Algunas razones:
  • La programación es una actividad creativa
  • Las actividades creativas requieren una buena conexión con el subconciente
  • La conexión con el subconciente es sensible al humor, el stress, etc
  • Los equipos de trabajo están conformados por personas
Y, si nunca has hecho algo similar, quizás sientas que debas importar la respuesta que otro desarrollador similar, de otro equipo similar, para un cliente similar. Pero eso no es correcto por algunas razones:
  • El trabajo no lo va a realizar ese desarrollador ni ese equipo para tu cliente en tu contexto. Cada equipo es distinto y el rendimiento de un equipo es sensible al contexto.
  • En realidad, no estás seguro de que lo que hay que hacer sea similar a lo que ellos hicieron.
Cuando nunca has hecho algo similar, es necesario empezar a hacer y ver qué tal lo vas haciendo, antes de poder ofrecer alguna estimación sincera.

Vamos atrasados
Supone que la estimación fue correcta. Si hubieras dicho una cifra mayor estarías a salvo. Algo como el doble más el 10% más el número que pensaste. De hecho, muchos desarroladores, o sus representantes, usan ese tipo de tácticas para estar tranquilos; pero el cliente, o su reprepresentante, saben que puede pasar y entonces se produce un regateo de tiempos estimados.

Cualquier supuesto atraso o adelanto es irreal si la estimación no es correcta. ¿Es correcta la estimación? Ya vimos que no es posible que lo sea.

Imagina que un entrenador se acerca te mira y te dice 'mmm tu debes estar saltando unos 150 cm'. 'Sí señor', respondes, mientras le ayudas a colocar la valla. Tomas tu distancia, corres y saltas, llevándote la valla de encuentro. 'Qué mal' dice el entrenador. 'Sí señor', respondes. Si hubieran puesto la vaya a 60 cm hubiera sido 'Qué bien, excelente'. Así de absurda es la situación.

Sería mejor aprender a aceptar las capacidades reales de la gente y trabajar con eso, en lugar de intentar hacer pronósticos y calificaciones arbitrarias.

Además, considerar que, tanto para el clima como para los humanos, todos los pronósticos pueden fallar.

Aprendiendo a programar

Aunque términos como ingeniería de software y ciencias de la computación dan la impresión de que hay un dominio del tema, en realidad estamos aprendiendo a programar.

Quizás no se trata tanto de algoritmos óptimos, sino de encontrar un proceso sostenible que permita desarrollar sistemas también sostenibles. Lo óptimo será alcanzado eventualmente.

Persiguiendo la ilusión del óptimo inmediato es que se suele perder el camino, del mismo modo que un artista principiante que trata de hacer un cuadro trabajando perfectamente cada centímetro cuadrado, para lograr un resultado que no cuadra porque las partes no siguen un bosquejo que nunca trazó.

Encontramos buenas prácticas en programación imperativa. Pero el retorno de la programación funcional parece indicar que son soluciones creadas para problemas generados por usar el modelo imperativo en primer lugar. 

Así, estamos en camino de aprender el oficio de programar.

Programación mental

En los años 70, cuando los ciclos computacionales eran muy caros, nadie podía imaginar usar las computadoras para diseñar software. El software era diseñado en papel, para luego ser codificado por programadores y funcionara a la primera, si era posible.

En las escuelas de programación se incentivaba a la gente hacer todo en papel antes de escribir una línea de código. Correr una línea de código en una computadora era más caro que correrlas en la cabeza, así que los programadores usaban sus cabezas, y mucho papel, como simuladores de computadoras.

En los años 80, con el ascenso de la computación personal, hacer software se volvió una actividad comercial importante. Así que la industria y las universidades impulsaron más la creación de productos de software. Como venían haciendo, tratando de usar la experiencia que tenían en desarrollar otros tipos de productos. Sin embargo, la ejecución de los proyectos de desarrollo de software empezó a mostrar que había cosas importantes que funcionaban de modo diferente.

En los años 90, cuando los ciclos computacionales ya no costaban lo que antes, los programadores se dieron cuenta que tenía más sentido usar la misma computadora para explorar con ella las cosas que quisieramos que ejecute, en lugar de seguir intentando que nuestros cerebros traten de imitar ese proceso.

Considerar los icebergs y los andamios

Lo que se quiere desarrollar se puede representar con algo como:

No es cierto que alguien pueda desarrollar una versión final directamente. Similar a un iceberg, las 9/10 partes de lo que se tiene que hacer queda debajo de las aguas.


Los andamios son necesarios para levantar y producir lo que se verá. Es la infraestructura util que sin embargo será removida y descartada luego. La construcción de andamios también es parte de la producción de software.


Aprovechar la computadora para explorar

El software de hoy es más complejo que el de los 70s, cuando era normal instar a resolver el diseño primero en papel y simulando mentalmente los procesos que realizaría la computadora.

Hoy es mejor aprovechar la potencia computacional disponible.

TDD (Test Driven Development) es una técnica que construye cajas de prueba que determinan cuando el software está cumpliendo lo que se requiere. TDD promueve un proceso de descubrimiento para diseñar software.

Hay partes del diseño que se puede realizar con más flexibilidad mentalmente, pero hay otras donde es más razonable usar la computadora. Permitirse codear, fallando y acertando, explorando, ayuda a tener una mejor estimación. 

¿Es necesario estimar?

Los manejadores de proyectos han sido entrenados a resolver problemas con contextos definidos, desempeños uniformes y destinos determinados.

Por otro lado, la mayor parte del desarrollo de sistemas consiste en adaptarse a un contexto cambiante y manejar los desempeños irregulares hacia destinos inciertos.

Y es insistir en usar buenas herramientas en un contexto equivocado lo que conduce a muchos de los problemas en el desarrollo de software.

El uso de estimaciones es un ejemplo de eso. No es muy util tratar de estimar algo en un contexto con tanta variabilidad. Se convierte en una tarea ingrata que solo produce halagos o llamadas de atención completamente arbitrarias. Sin embargo, es algo que se sigue haciendo.

#NoEstimates, de Vasco Duarte, es un libro que habla sobre eso.

En el video, Vasco explica como las estadísticas de story points muestran un comportamiento irregular sobre el que es inútil tratar de hacer estimaciones.

En cambio, el número de historias que puede resolver un equipo por periodo muestra un comportamiento más regular.

Es decir, es irrelevante tratar de asignar puntos de dificultad a las historias.

Y parece ser que las estimaciones en desarrollo de software vendrían a ser un error metodológico.