Mostrando las entradas con la etiqueta proyectos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta proyectos. Mostrar todas las entradas

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/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.

2014/01/23

Kanbiando con Kanban


Hace unos días, en mi trabajo, hicimos una actividad interesante.

Se propuso a los miembros del equipo un problema de programación no muy complejo. Se eligió un lenguaje de programación y una sola computadora, cuya pantalla se reflejaba en un televisor para todos, donde cada uno trataba de avanzar lo que pudiera durante 5 minutos.

Excepto el jefe, que debía mantenerse al margen haciendo intervenciones ocasionales, nadie más que quien estaba en su turno podía hablar, contando a los demás que iba haciendo y por qué lo hacía.

Además podía buscar en Google, y modificar o borrar el código previo.

Se sucedieron varias rondas y paso un par de horas sin que lográramos escribir una solución funcional.

Entendíamos la solución a la que queríamos llegar, y probablemente todos hubieran podido escribirla trabajando solos durante quince minutos o media hora. Pero, por alguna razón, no la lográbamos alcanzar.

Cuando terminó la jornada, me retire, pero el problema continuaba en manos que quienes podían quedarse.

Me sentía frustrado, pero, conforme pasaba el tiempo me iba sintiendo además instruido. Un problema simple y solucionable se había vuelto prácticamente irresoluble debido a las condiciones de trabajo impuestas.

Estas condiciones fueron tales que prácticamente anulaban la comunicación. Eso inhabilitaba el trabajo en equipo. Al menos, él trabajo en equipo usual.

Reflexionando, me di cuenta que, al inicio, nadie asumió el reto como un trabajo en equipo. Cada uno quería, de ser posible, terminar el problema en su turno.

Luego, cuando las primeras rondas iban mostrando que no sería tan fácil, apareció gente que prefirió hacer explícita una estrategia en lugar de programar. Entonces, el trabajo de todos empezó a encauzarse y parecía que se resolvería pronto. Nos estábamos adaptando.

Es allí donde el jefe cambió de pronto las reglas. Dijo que estaba clara la solución y que el reto sería ahora tratar de escribirla una sola persona, desde cero, en 5 minutos.

Además de transformar el problema en una competencia de tipeo, de entrada, eso destruía la comunicación incipiente que había surgido espontáneamente. Fue entonces cuando me retiré.

Camino a casa iba pensando que pasaría si esa prueba se repitiera cada semana. Creo que iniciaríamos sacrificando tiempo de programación para establecer mejor primero un marco de trabajo y luego la estrategia para resolver el problema. Y luego recién empezaríamos a codear.

Me pregunte luego cuántos proyectos habrá así en la vida real. Con gente competente y sin embargo sin avances significativos. Y todo por una organización contraproducente.

Deming, el padre de la mejora continua de la calidad, decía que el 95% del resultado éxito o fracaso se debía a la organización y solo 5% a la gente.

Pero no es obvio. Mucha gente tiende a culpar a la gente y lanzarse a tomar medidas correctivas en ese sentido. Llamadas de atención, recorte de privilegios, castigos, en el peor de los casos. Capacitaciones y coaching en el mejor de los casos.

Pero, si la causa es la organización, no se solucionará nada. A menos que se empondere a la gente para que la pueda mejorar.


Un par de días después, asistimos a un seminario sobre Kanban (la metodología de visualización de flujo de trabajo inspirada en las prácticas de Toyota).

Resulta que es una herramienta muy simple y poderosa para visualizar el estado del flujo de trabajo en una organización. Y para hacer evidentes sus virtudes y defectos.

Siendo evidentes los defectos, es más fácil proponer cambios de políticas e ir gradualmente cambiando la organización.

Yo pensaba que venía utilizando Kanban, al menos en mis proyectos personales. Descubrí que lo estaba haciendo de modo incompleto. Para que Kanban haga su magia, es necesario hacer hacer explícitos los límites de trabajo en progreso (WIP, por sus siglas en inglés) y las políticas de aceptación de tareas.

Ahora estoy leyendo y aprendiendo más al respecto. Un libro que me parece sumamente útil y fácil de leer es "Scrum y Kanban: Usando lo mejor de ambos", de Henrik Knigerg y Mattias Skarin.

Estoy viendo que podría usarlo también para mejorar mi forma de estudiar... y hasta para procesar con más eficacia las montones de cosas que quiero hacer en la vida (Personal Kanban)

Una gran virtud de Kanban es que te permite iniciar como eres ahora, con lo que tienes ahora.

Viva Kanban \(^_^)/

2014/01/13

En equipo

Es muy diferente escribir código solo que en equipo.

Cuando eres solo una persona, tienes más libertad para elegir lo que te gusta o desechar lo que no te gusta. Para elegir usar patrones que solo tu conoces, para inventar tu propio framework, para usar los hackings que te gustan...

Cuando eres solo una persona, escribes código para solucionar un problema. Y punto.

Pero cuando estás en un equipo, escribes código para solucionar el problema de modo que otros puedan entender la solución y mantenerla.

Eso puede ser un poco más complicado. Porque la mayoría de tu equipo puede tener otras preferencias de formato, usar mejor otros frameworks, y cosas como los hackings (que te hacen googlear media hora para entenderlos), no son recomendados.

Pierdes la sensación de control total que puedes sentir cuando dominas tu código. En su lugar, va apareciendo el sentimiento de que todo es caos.

Y, sin embargo, del caos surge un orden, y soluciones valiosas, si las sabes ver. Es cuestión de abrir la mente para estar dispuesto a aprender... que nunca se acaba de aprender. Y que hay soluciones que no son tuyas ni mías, sino de ambos.

Cuando aparece la sinergia, donde uno más uno es más que dos, es como magia que jamás conocerías si no fuera porque trabajas en equipo. Y entonces, lo valoras.

2013/11/06

El lenguaje de programación correcto

"Las especies que sobreviven no son las más fuertes, sino las que se adaptan mejor al cambio"
-- Darwin

En internet, parece ocurrir algo similar. No prosperan los lenguajes de programación que te hagan más fuerte, sino los que te permitan adaptarte mejor al cambio... en cierto ambiente.

Por ejemplo, php es popular en proyectos educativos y sociales. Java es popular en proyectos empresariales. C es popular en proyectos técnicos. Otras alternativas importantes son Python, Ruby, etc.

Muchas personas tienen sus preferencias y a veces tienden a tomar posiciones, pero es importante ver más allá y recordar cuál es la razón por la que programamos.

Cada lenguaje existe por alguna razón. Porque de algún modo es la mejor respuesta para cierto problema. Porque es la mejor especie en cierto ambiente.

Pienso que no hay una solución "correcta" ni una manera "correcta" de hacer las cosas universalmente. Cada problema contiene su solución, y es importante estar atento a la solución que te está cantando el problema, en lugar de pretender que escuche la que nos gusta cantar.

Así podemos aprender nuevas canciones :-)

¿Cuánto puede mejorar tu software? ¿Qué tan clara es la especificación? A más ciclos de desarrollo, más probabilidad de acercarse al ideal.

¿Cuántos ciclos de desarrollo puedes realizar? ¿Qué tan sencillo es de iterar o incrementar? A más contribuyentes, más probabilidad de encontrar excelentes contribuciones.

¿Cuántos contribuyentes puedes encontrar? ¿Qué tan sencillo es comunicarse? Hay más probabilidad de encontrarlos si los lenguajes son más atractivos, los entornos de desarrollo más asequibles, el camino de inicio más motivador.

Quizás por eso un lenguaje de programación no tan fuerte puede a veces llegar tan lejos. Es importante tener en cuenta el ambiente para prosperar.

2011/06/19

Proyectos como sistemas biológicos

Los proyectos de software no salen tan bien como se quisiera.

Un programador solitario, con talento, puede hacer código muy bonito, hasta cierto punto.
Cuando el proyecto llega a cierto tamaño o complejidad, es cada vez más difícil continuar.

Varios programadores, con talento, formando un equipo, pueden hacer algo muy bueno, muy por encima de lo que serían capaces con sus talentos individuales, hasta cierto punto.
Cuando el proyecto llega a cierto tamaño o complejidad, es cada vez más difícil continuar.

Los proyectos exitosos son aquellos que alcanzan ese punto límite no tan lejos de la meta que se proponían.

Pero la mayoría lo alcanza mucho antes.

Tratando de explicarse esto, hay quienes culpan a la gente. Pero sucede incluso en equipos compuestos de gente talentosa.

Parece que la respuesta es la organización.

La forma en cómo se organiza a las personas, las reglas o normas que siguen, de algún modo, van tejiendo una trama que, eventualmente, ahoga el proyecto.

Quizás haya un modo de lograr una organización sostenible.

Por lo pronto, se ha visto algunas cosas que funcionan mejor que otras.

Algo visible es más fácil de corregir. Algo simple es más fácil de ver. Algo modular es más simple de hacer. Algo descentralizado es más modular. Algo libre es más descentralizado. Algo que podemos corregir es más libre.

Cada ser vivo puede considerarse un tipo de sistema. Cada ser vivo tiene una vida, corta o larga, con un patrón de nacimiento, desarrollo, apogeo y remisión. Quizás sea propio de cada sistema. Quizás cada sistema está condenado por la complejidad que es capaz de alcanzar. El apogeo sería el aviso de la remisión inminente. Y la remisión el preámbulo de un nuevo nacimiento.

Quizás debamos dejar de comportarnos como si pudiéramos diseñar proyectos eternos, que muchas veces conducen a intentos efímeros, y diseñar proyectos con ciclos de ascenso y remisión, que inspiren y exhalen, que corran y duerman. Y todo eso, mientras evolucionan.