lunes, 29 de septiembre de 2008

Refactorización para programadores de verdad.

Estaba a punto de responder al comentario de Iboisset sobre Panqueque System II cuando me dí cuenta de que daba al menos para un pequeño post.

Aquellos que estamos ya un poco viejitos vivimos la revolución de las metodologías ágiles como un viento de aire fresco que barrió con viejos conceptos metodológicos que nos condenaban (a los programadores) a ocultar prácticas hoy habituales, pero que en ese momento se consideraban poco menos que meritorias de pena de muerte.

Es decir: nosotros ya programábamos de a pares, diseñábamos a medida que codificábamos y pensábamos en el cambio continuo, sobre todo en pequeños y medianos emprendimientos donde el peso del ciclo de vida no era tan asfixiante.

Y también, de vez en cuando... refactorizábamos.

Pero no como ahora, que utilizamos pruebas automáticas (o directamente programación guiada por pruebas), en donde (si tenemos suerte, pero en general es así) el manager del proyecto sabe que hay que probar la funcionalidad continuamente y entiende cuando le decimos que necesitamos recodificar o rediseñar cierta parte de la aplicación sin cambiar su funcionamiento, y nos permite asignar horas a esa tarea de forma abierta y planificada.

Si nos pedían una nueva funcionalidad o el arreglo de un error, éso era lo que iba a presupuestarse, implementarse y probarse. Y si el código estaba tan enrevesado que era imposible hacerlo en los tiempos requeridos (calculados muchas veces en base a los requerimientos sin tener en cuenta la calidad del código existente donde tenían que implementarse)... bueno, a eso se le llamaba "aumento de la curva de costo de mantenimiento", se suponía inherente al desarrollo de software y la solución propuesta era, simplemente, agua y ajo (aguantarse y ajoderse).

Eso en la superficie. Por debajo, como nosotros la sufríamos, había ocasiones en las que... ¡máh sí! ¡Yo lo doy vuelta como un guante! Agarrábamos, presupuestábamos un par de horas de más en algún requerimiento, tratábamos de que pase desapercibido, y hacíamos esa modificación transversal que tanto necesitábamos para odiar un poco menos nuestro trabajo de mantenimiento.

¿Pero quién nos probaba? Si modificábamos algo que impactaba en casi todo el sistema no podíamos decírselo a nadie... si surgía algún error en alguna pantalla que "nadie había modificado" había que disfrazarse de nadie para pasar desapercibido.

Aquí engancho el comentario de Iboisset:

"No obstante, en mi opinión, para esto también hace falta un perfil alto en el equipo, no todos los miembros del equipo "saben" hacer el código bien. Se me enfadarán pero es así."

En aquellos tiempos era imprescindible un perfil alto en el equipo, por las razones arriba mencionadas. Hoy, como bien dice Iboisset, también. Pero por suerte tenemos herramientas que permiten alcanzar ese alto nivel aprendiendo de la mejor manera posible: haciendo.

Con un buen conjunto de pruebas unitarias y un equipo de testing funcional despierto y consciente de que hubieron modificaciones transversales al sistema, el programador puede experimentar, intentar y equivocarse hasta lograrlo sin arriesgar su vida en el intento.

La diferencia de trabajar bajo una u otra metodología es brutal:

  • La calidad de todo el código mejora con el tiempo.
  • La calidad de nuestro trabajo mejora con el tiempo.
  • Porque al intentar un refactory, y aunque no lo logre, el programador gana en conocimiento sobre todo el sistema, sin quedar estanco en las porciones que él conoce o que ha implementado.
  • El mantenimiento se hace interesante, no una pesada carga. Una pequeña corrección puede llevarnos a descubrir un nuevo patrón y a implementarlo en el resto del sistema. Mantenimiento ya no significa necesariamente una interminable sucesión de pequeños parches.

Pero refactorizaciones... ésas eran las de antes. Sin red, como trabajan los programadores de verdad.

sábado, 27 de septiembre de 2008

No estaba loco: el orden de los using sí es importante.

Por años he soportado el gaste de cuanto programador ha trabajado conmigo:

No soporto ver los "using" desordenados.

Una breve explicación:

Eso no puede ser. No puedo dejarlo así. Me decían que no tiene mucho sentido, que no sirve para nada y que es un detalle obsesivo y una pérdida de tiempo. Nunca me importó el qué dirán. Si por casualidad o por error abro un documento, lo dejo así:

  • Las librerías ordenadas por nivel, desde la de más bajo hasta la de más alto, y separadas por un renglón (esto último es especialmente importante).
  • Dentro de cada librería orden alfabético, aunque a veces me tienta más preservar la estructura de pirámide visual, con el namespace más corto arriba y el más largo abajo. Como esto último es una regla que no tiene que ver con la programación, pero queda más lindo, dudo y lo pienso un poco en cada caso.

¡No soy el único! De hecho, miren Visual Studio 2008:

¡Todo un menú para reorganizar los using! Y más vale que lo usen.

viernes, 26 de septiembre de 2008

Un cuento para el fin de semana.

Allá lejos y hace tiempo, en primer año de la secundaria (creo), tuvimos que escribir un cuento para la clase de literatura. En esa época yo escribía bastante, así que afiné alguno de los que ya tenía escrito.

Como no existía ni web ni Google, mucho de ese material se me ha terminado perdiendo (no me da lástima, realmente). Pero éste, por H o por B, terminó encerrado en un cajón de mi escritorio y acaba de ver la luz debido a un repentino ataque de orden. Es la fotocopia del que presenté en aquella oportunidad, escrito a máquina (¡ja!)... toda una obsolescencia. No es taaan off topic de este blog, que de cualquier manera hacer tiempo que perdió el rumbo. Aquí va.


Inutilizado

X se levanta, mejor dicho, la mitad mecánica de X hace que se levante, la otra mitad, su cerebro biológico, todavía disfruta de los placeres del sueño.

Uno se viste mientras el otro duerme, uno desayuna mientras el otro recién se despereza, uno sale a la calle y comienza a caminar.

El aire frío de la mañana termina de despertar al otro, observa su reloj y la calle desierta, se mira los pies. Caminan sin que él intervenga.

Recuerda... recuerda aquellas películas, proyecciones mentales sobre un mundo ruidoso, en donde los medios de transporte invadían todo con sus extraños ruidos... Mundos en donde la gente constantemente emitía ruidos para comunicarse. Bueno, ahora también, sólo que con menor frecuencia. No hay autos. No hay voces. No hay ruido. X se alegra de vivir en esta época.

Mientras, sus pies lo han llevado a la oficina, entra a su despacho y ve en la computadora la lista de tareas del día. Después de ordenar su ejecución en su bio-chip se conecta a una videoteca y elige sus proyecciones favoritas y...

Como todo el mundo X posee sólo una de las 25 millones de terminales de bio-chp en el planeta. Implantado en la parte central del hipotálamo y, una vez programado, es capaz de organizar todas las tareas que un ser humano debe realizar en un día, dejando al cerebro biológico libre para dedicarse al sueño programado, a visualizar encuentros deportivos, a charlar mentalmente con un amigo o ir de la misma manera a una fiesta en uno de los tantos centros de programación especial. Todo esto contando con la ventaja de la comunicación telepática directa, tarjeta de crédito implantada, etc. Como un cerebro suplente que nos dirige cuando nosotros mismos no tenemos tiempo o ganas de hacerlo.

Todos los días transcurren exactamente igual para X y para los 25 millones restantes. Al levantarse, siempre con la misma sábana, el mismo día de la semana, siempre con el mismo pie... los 25 millones al mismo tiempo. Al desayunar, siempre la misma taza, el mismo café, el mismo sabor... los 25 millones al mismo tiempo. Ya las diferencias no existen. El chip actúa exactamente igual todos los días, repitiendo la misma tarea hasta la muerte. Ya nadie es realmente distinto.

El cerebro ha logrado desarrollarse más a causa del tiempo libre sólo en algunos casos: los científicos. La gente común duerme y se divierte, ni siquiera estudia... "¿Para qué? Allí arriba tenemos la computadora que nos hace el trabajo, utilizándonos...". Así piensa el mundo.

X es lo que uno llamaría un psiquiatra, mejor dicho, el chip de X está programado para ser lo que uno llamaría un psiquiatra. Sin embargo, X es diferente. El atiende a sus pacientes, no se distrae en una charla con alguien distante dejando que su chip haga su trabajo. "Contacto personal", lo llama.

3/10/3014

Aquel día, al igual que los demás, X se hallaba atendiendo a una tal Z. Pero algo pasó. Su jefe, Y, lo llamó mentalmente.

-Sabe que yo atiendo personalmente. Estoy ocupado.

-Esto es especial, debe venir -cortó. parecía preocupado.

Miles de disculpas emanaron de su cerebro por retirarse antes de lo previsto. Tomó control de sus miembros y se dirigió él mismo al despacho de su jefe. Sentado en la mesa se hallaba Y y detrás de ella un sujeto al que X no había visto nunca. Ni siquiera lo saludó.

-¿Qué tiene? -preguntó X.

-Se desconectó. No tiene implante. ¿Entiende? No puede escucharnos, no puede hablar a menos que emita sonidos, no....

X se sobresaltó. En su vida había visto a alguien sin implante. Es más, suponía que no existía nadie en esas condiciones. hasta ahora.

-Supongo que tendremos que hablar verbalmente -dijo en voz alta el hombre. X e Y lo miraron boquiabiertos. X trató de disimular su estupefacción. Y se retiró.

-Bien, comencemos -la voz de X salió ronca. Tosió. Hacía tiempo que no hablaba.

-Seguramente se pregunta cómo llegué a prescindir del implante. Antes que nada debe saber que soy científico. Estudio el cerebro human. El verdadero.

He descubierto que, si no dejamos de usar implante, nuestro cerebro se atrofiará, quedará... inutilizado. La gente común lo usa cada vez menos. Algunos ya no recuerdan que pueden hablar verbalmente. Otros no lo han hecho durante años. Si esto sigue, la comunicación telepática desplazará totalmente a la otra y, paulatinamente, se nos atrofiará el habla.

Por otro lado, la gente controla cada vez menos sus miembros. Imagínese qué pasaría si el cerebro perdiera el control directo. El chip tendría que ocuparse de todo y autoprogramarse.

Sucesivamente perderemos nuestro control y terminaremos como robots. Sólo podremos pensar, sin posibilidad de ejecutar nuestros deseos. Nuestro cuerpo se convertirá en la prisión de nuestro cerebro.

X escuchaba atentamente y anotaba. Era sólo un loco más. Un inadaptado que buscaba excusas para ocultar su miedo. Ha tenido bastantes de éstos en su carrera. El hospital se encargará de él. Sólo hace falta un pequeño ajuste.

7/9/3064

Es una mañana fría, X trata de recuperar el control de sus miembros pero no puede. Trata de llamar a alguien mentalmente pero no puede. Su cuerpo bebe café pero él ya no lo siente. Sale a la calle, ve a la gente que como él ya no controla su propio cuerpo....

Cuando ellos mueran, sus chips harán funcionar su cuerpo y serán robots en todo sentido. Caminarán de aquí para allá, trabajarán, vivirán normalmente... Se convertirán en una sociedad-maqueta que fue humana y que nunca volverá a ser...

X recuerda vagamente... aquel día... un paciente... desconectado.


Resistí la tentación de corregirlo, al fin y al cabo nunca será una gran obra de arte, pero me cayó simpático en la relectura. Espero que a ustedes también.

Usos y abusos de la teleconferencia.

STEWART: Hay tres cadenas de noticias financieras transmitiendo todo el día. A propósito de la crisis financiera, el otro día vi en CNBC a un tipo hablando con ocho personas diferentes (con la pantalla dividida en ocho partes) y todos decían cosas como “No tengo idea”. Es como si llegara el huracán Ike, y uno pusiera el Weather Channel y estuvieran todos gritando “¡No sé qué carajo pasa! Me estoy empapando y está muy ventoso y no sé por qué y eso me pone triste”.

El extracto es parte de este post de Malas Palabras, que simplemente me causó gracia y por ello terminó aquí.

Me pregunto si alguna vez llegaremos a algo de este estilo por el camino del abuso de las herramientas de trabajo para equipos dispersos alrededor del globo.

jueves, 25 de septiembre de 2008

Panqueque System II: Un caso de dependencia del cliente.

En Panqueque System hacía referencia a esos sistemas en los que el rumbo cambia 180º de vez en cuando, en una forma tal que por más ágil que uno quiera ser, termina embrollando el desarrollo.

Se me habían ocurrido dos causales: problemas en las definiciones y dependencia del cliente. Había empezado por desarrollar un poco el primero. Vamos al segundo.

Trabajé casi siempre en empresas chicas, a lo sumo medianas. Así que conozco de primera mano la importancia de el cliente, sobre todo cuando se lo puede nombrar en singular y ya se sabe de quién estamos hablando.

En el caso que tengo en mente, la aparición de un comensal importante, de buen apetito y bolsillo aparentemente generoso motivó la aceleración del cierre de un producto de evaluación de desempeño que si bien teníamos prácticamente terminado todavía no había sido utilizado en una evaluación real.

La idea original era atraerlo con un buen precio por evaluación más algún sablazo por customizaciones que, bien implementadas, serían nuevos sabores a ofrecer en nuestra recién abierta panquequería, que tenía forma de aplicación web.

Creo que el modelo de negocio, tan natural en estos tiempos que corren, era demasiado innovador para el momento del rubro (no es autobombo, yo sólo picaba código), y el cliente demasiado grande.

Esos dos factores se juntaron para que se negociaran cambios de tal magnitud y especificidad que en la práctica hicieron imposible su aplicación como opciones a ofrecer al público en general.

De un lado del escritorio no existía la mentalidad de utilizar una aplicación web como un "servicio enlatado", por lo que se terminó pidiendo cualquier cosa.

Del otro lado la dependencia económica era tal que se terminó concediendo cualquier cosa, y el desarrollo tuvo que abrirse en dos versiones divergentes, una dedicada exclusivamente a éste cliente y otra estándar que permanecía en vidriera.

Así, se vendió el desarrollo de un programa a medida al precio de un par de customizaciones. Y como era una aplicación web, el cliente comió una vez, dos tal vez, y satisfecho su apetito continuó por su camino libre de ataduras, sin nunca más volver.

Creo -ya aclaré que estoy alejado del rubro- que no se logró posicionar la versión estándar como un servicio web a utilizar "como está" y que actualmente se encuentra más o menos abandonada.

Esta anécdota ejemplifica bien la situación en la que el panqueque gira y gira en el aire hasta romperse en dos mitades. En este caso un comensal un poco grosero picoteó apenas de una de ellas, encima pagando sólo el proporcional, y el cocinero se quedó con las sobras. Sobras que pueden servir de tener a quién ofrecérselas a tiempo, pero no fue éste el caso, me parece.

Mi opinión es que la clave está en la metodología. Si el proyecto crea una base de componentes o una capa de negocio reutilizable que soporte los cambios de tecnología, conformarán en realidad no una pérdida en horas de trabajo sino una inversión.

Ésa salida sólo puede darse si es apoyada conscientemente por el entorno de negocio del desarrollo. Si se presiona a los programadores a cumplir con los requerimientos en tiempos extremadamente ajustados (en este caso, forzando un nuevo desarrollo en tiempos de "customización"), el código resultante tendrá una calidad acorde, y no será para nada reutilizable.

¿Es compatible la entrega en esos tiempos con calidad y posibilidad de reutilización? Las metodologías ágiles nos han enseñado que es posible entregar rápido y refactorizar después. Podemos hacer una implementación desprolija (aunque correcta para el usuario, eso es indispensable) si luego tenemos tiempo de capitalizar la experiencia reorganizando y reescribiendo el código donde sea necesario. Pero muchas veces gana la idea cortoplacista de producto terminado y a otra cosa... una panquequeada más que termina con lo poco que quedaba en el suelo. Otra variación conocida de esa frase es esperemos a que surja un nuevo negocio... por supuesto, y a que los tiempos se ajusten nuevamente.

Queda para otro post una situación más, el infierno de las preferencias. Es el caso en el que para cada nuevo cliente creamos un nuevo gusto y terminamos estancados en el mencionado infierno con más sabores que comensales. Pero como dije, será para otro día.

Actualización: Ya llegó el día: Panqueque System III: El infierno de las preferencias.

miércoles, 24 de septiembre de 2008

Youtube se rompe.

No soy muy fanático de los juegos en general y menos Mario en particular, pero la publicidad es muy buena.

Ya no saben qué hacer...

Vía Alt1040.

Línea de tiempo de Google

Con motivo de sus 10 años, Google publico una línea de tiempo (entre otras boludeces cositas. Muy Google.

Vía Alt1040.

¡Un error! ¿Y ahora dónde nos metemos?

La primera opción es enfrentar el problema, como buen desarrollador (ver ésta imagen). Pero cuando por algún motivo no queremos o no podemos hacerlo, tomamos lo que venga más a mano: abajo del escritorio, en el baño, a casa por enfermedad, licencia o muerte de un familiar lejano, en la oficina de al lado, la cafetería, esquivando al jefe...

El anteúltimo recurso sería hacer un hoyo en la tierra y meter la cabeza como el avestruz...

...pero es posible que el suelo no sea propicio para tal actividad. ¿Entonces? Y bueh, siempre hay un agujero a mano:

La imagen fue vista en Presión Blogosférica (aunque la entrada no tiene nada que ver).

Más juegos (y menos trabajo): Hoshi Saga

Hoshi Saga 3 es otro de esos juegos de "descubrimiento". En este caso tenemos que averiguar dónde está la estrella (y cómo conseguirla) a través de un sinfín de pantallas. Terriblemente adictivo.

Por si fuera poco, es el tercero de una serie que incluye Hoshi Saga y Hoshi Saga 2.

Vistos en cgredan blog.

martes, 23 de septiembre de 2008

Legado.

"Al que hizo este store procedure le deseo la muerte."

- E.V.

Dicho con completa seriedad, frialdad y convencimiento. Nótese que esto no está etiquetado bajo "humor".

Conclusión: codifica como si el que fuera a mantener tu código fuese un maníaco asesino que sabe donde vives...

lunes, 22 de septiembre de 2008

El usuario.

En principio definamos claramente usuario dentro del contexto de este post, para evitarnos problemas: usuario es el que opera el sistema en una situación real para alcanzar un objetivo determinado que coincide con el que fue requerido al desarrollar el sistema.

Mi definición tiene sus vericuetos: un analista probando una instalación del sistema no es un usuario, ya que su objetivo es el de encontrar errores, por más que esté en un entorno real. No es el líder del equipo presentando el producto, no es un hacker que intenta romperlo o extraerle información. Tampoco es uno de los empleados si simplemente lo está "explorando" para "familiarizarme un poco con él", ni es un cualquiera que lo ha abierto por equivocación, ni siquiera una persona que por desconocimiento quiere utilizarlo para algo para lo que no fue diseñado (ej.: el gerente entra al sistema de emisión de facturas (orientado hacia lo operativo) buscando saber el total de facturación de un cliente).

La definición también descarta los casos de de fallos en la interpretación o definición de los requerimientos. En definitiva, se acota el sinfín de situaciones posibles a aquéllas en las que el usuario y el sistema "quieren hacer lo mismo".

Un buen desarrollador siempre presente la siguiente máxima (hay muchas variaciones, pero ésta es la que viene más al caso):

El usuario es tonto o malicioso a menos que se demuestre lo contrario.

He tachado malicioso porque fue descartado por la definición anterior.

Entonces... ¿el usuario es tonto? ¡Qué novedad! pensará cualquier desarrollador. El que no lo sea tal vez se sienta ofendido. Lo siento, la verdad duele. El usuario es tonto. Siempre.

Tenemos un sistema interno de carga de horas. Es bastante nuevo, y muy simple. Por suerte en esta empresa no somos muy perseguidos con el horario (siempre y cuando las cosas más o menos salgan, claro) ni hay una cultura del tipo "qué-pasa-que-tus-ojos-no-están-sobre-la-pantalla", en donde suena una alarma cada vez que uno levanta la vista o no presiona una cantidad de teclas por minuto. Así que está exclusivamente orientado a cargar las horas a los proyectos correspondientes.

Cualquiera diría que tal sistema, sobre todo con el nivel de usuarios que tiene, no necesita de mayor asistencia para su uso. Error.

Es divertido ver como analistas funcionales, administradores de bases de datos, programadores de todo tipo y edad (entre los que me incluyo), líderes de proyecto, todos somos tontos a la hora de utilizarlo.

Y yo soy el primero, ojo. Basta hacer alt-tab desde el entorno de programación hacia este sistema para transformarme automáticamente en mi señora madre, que apunta y presiona compulsivamente cualquier forma cuadrada que aparezca más o menos por el centro de la pantalla.

  • Como usuarios, no hay mensaje ni sonido ni advertencia que pueda detenernos.
  • Cualquier sucesión de más de 10 caracteres con al menos un espacio en el medio (usualmente les decimos "mensaje" o "texto") pasa completamente desapercibida.
  • No importa si el monitor es de 15, 17, 19 o 40 pulgadas (en realidad cuanto más grande peor) sólo percibimos en un radio de 2cm con respecto al puntero del mouse, o en su defecto al centro de la pantalla.
  • Consecuentemente, si alguna vez leemos algo, difícilmente lo interpretemos en el contexto de la pantalla. Más probablemente lo interpretemos de acuerdo a lo que nosotros esperamos o queremos que suceda.
  • Somos incapaces de registrar nuestras propias acciones, ni siquiera las más inmediatas. No sabemos qué acabamos de tocar, ver, leer, escribir o mover.
  • Cualquier tipo de lógica deductiva (ni hablar de la inductiva) es anulado. Somos prueba-y-error. A veces ni siquiera eso, hacemos lo que creemos que hay que hacer y lo damos por hecho sin importar la respuesta del sistema.
  • A partir de la primera vez que logremos nuestro objetivo, repetiremos siempre la misma secuencia de acciones en forma automática. Hasta el más radical rediseño de pantalla sólo será percibido cuando impida que esa secuencia se complete. Si no lo impide, jamás nos daremos cuenta.
  • Ante cualquier cambio volvemos a 0, ya no sabemos utilizar el sistema. En realidad menos que 0, seguimos repitiendo acciones inútiles o contraproducentes, y probablemente estemos enojados. Recorreremos un largo camino para entender que ya no es como antes (llegaremos a 0) y luego volver a aprender.

Sí, ya sé "yo no hago eso", "yo no soy así"... vamos, no les creo. La diferencia entre un usuario experto y un novato es que el experto recurre a su experiencia para captar rápidamente convenciones y formas comunes, disminuyendo la necesidad de muchas de las secuencias de pruebas-y-errores que intenta el novato, quien además las ejecuta más lento.

¿Es así? ¿Por qué? Habrá una segunda parte.

domingo, 21 de septiembre de 2008

Vivos de milagro

Siguiendo con la seguidilla de procrastinación del fin de semana...

Vía WTF! Microsiervos.

Test de velocidad de tipeo.

Esto es a lo que llegué (después de un buen par de vueltas):

You reached 322 points, so you achieved position 12641 of 113028 on the ranking list.

You type 392 characters per minute. You have 50 correct words and you have 0 wrong words.

50 words

Speedtest

sábado, 20 de septiembre de 2008

Girar bolis.

Wikipedia: Girar bolis.

Quiero poder hacer eso, qué envidia. Tendría que empezar por practicar agarrar cosas sin que se me caigan.

Internet da para todo.

Vía esta entrada en Esquizopedia.

Roboprocrastinación gimnástica.

Nunca me sentí tan identificado con una tira de historieta: "Tomorrow", en WE THE ROBOTS.

De paso les recomiendo leer un poco hacia atrás, la tira es buenísima.

viernes, 19 de septiembre de 2008

Oferta laboral.

La acabo de recibir, hace un ratito nomás:

Actualmente la empresa donde trabajo, esta buscando un programador semi senior, con experiencia en .NET, y SQL 2005 [Ok. Hasta aquí todo normal].

Preferentemente con conocimientos de [¿y esto?] ASP, VB6, Crystal Reports.

A ver, chicos: si lo que quieren es un programador con experiencia que no tenga miedo de meter las manos en el barro y hacerle mantenimiento a una aplicación de VB6 deberían publicar exactamente eso, que los hay muchos y muy buenos (no es mi caso, tengo las uñas delicadas y usualmente recién pintadas).

Porque así como está suena un poco sospechoso... .Net+SQL 2005 (¡última tecnología!) y... ASP y VB6 con Crystal Reports (mmmm.... huele a viejo), ¿en qué terminaré programando?

¿No será que quieren un programador en VB6 y que preferentemente sepa algo de .Net (por las dudas)? ¿Y que se están dando cuenta de que ésos son difíciles de encontrar, o gente con un par de años encima que pretende un sueldo acorde a su experiencia?

¿A uds. qué les parece? ¿Soy demasiado suspicaz?

Notebook Ninja

Muy buena la animación, la música y los efectos de este juego, y de paso bastante más difícil de lo que parece en un principio.

¿Qué GTA 4? A mí déjenme con éstos que no tengo que hacer un curso de 10 días para aprenderlo (soy un tipo limitado, ya saben).

Como siempre hagan click con cuidado, les va la tarde en ello.

97 Things Every Software Architect Should Know

97 Things Every Software Architect Should Know es un interesantísimo proyecto en forma de wiki. La idea es reunir axiomas de la arquitectura de software propuestos por y discutidos entre quienes desempeñan este papel.

Cada tanto entro y pispeo las modificaciones y contribuciones. Sinceramente me muero de ganas de meter bocadillo, pero armar una frase que pegue en inglés y argumentar con la exactitud de conceptos requerida es un desafío que hasta ahora no pude superar.

Hay algunas realmente buenas:

  • If there is only one solution, get a second opinion - Timothy High
  • Avoid "Good Ideas" - Greg Nyberg
  • A rose by any other name will end up as a cabbage - Sam Gardiner
  • Get the 1000ft view - Erik Doernenburg

Hay para relamerse, y las discusiones asociadas son muy buenas. Es recomendable leer sobre aquellas con las que uno no está de acuerdo. Las mejores 97 serán incluidas en "97 Things Every Software Architect Should Know", un libro que será publicado por O'Reilly Media, Inc.

Visto en Pensamientos ágiles.

Mirá, ¡da vueltas!

Hubo, allá lejos y hace tiempo, una publicidad que no me acuerdo de qué era. Un tipo con cara de bobo delante de una máquina (monitor ámbar). Lo vemos de frente. Se acerca alguien (¿el socio?) y el informático bobo le dice algo así como "¡mirá, da vueltas!" embelesado con una "A" fea y cuadrada girando en la pantalla, de la cual estaba obviamente muy orgulloso. El otro ponía cara de "¿Ésto es en lo que perdés el tiempo con la computadora? ¿Ésto va a atraer a los clientes?".

Cuando alguien hace alguna funcionalidad tan linda como inútil siempre me trae a la cabeza esa frase.

Hace un par de días estrenaba con éste agradecimiento una nube de tags en mi blog, simple, común y silvestre, funcional. Todas las etiquetas, las que contienen más artículos más grandes que las otras. Una nube de tags, qué más.

Había visto, en mi investigación previa, el componente Tag Cloud, en el Roy Tanck's Weblog, pero como era para Wordpress no le había dado mucha bola, aunque me parecía mucho más atractiva.

Cuestión que hoy un compañero de trabajo me dice "mirá este tipo, qué buena nube de tags que tiene". Inmediatamente reconocí a la mencionada arriba, es muy bonita, ya ven.

Y me digo... ya está, ya lo hice, está funcionando... no está para Blogger... pero... da vueltas... ¡da vueltas!.

Así que la busqué, alguien la había adaptado a Blogger. La puse en el blog.

En seguida me dí cuenta de que, por ejemplo, los tags eran todos del mismo tamaño... el flash es innecesario y hace que la página tarde en cargar... hay veces en las que el movimiento no es tan fluido y mi procesador (que no es de última generación) nota la carga. Es difícil ver todas las etiquetas de un vistazo. Buscar una en especial es incómodo... ¡pero da vueltas!

A Cerebrado le pasó lo mismo que a mí (lo siento por el escrache, pero tengo que demostrar que no soy el único). Es inevitable quedarse un rato haciéndola girar cada vez que entro al blog.

Claro que hasta un par de horas después no se me había dado por hacer click... qué importa a dónde me lleva... ¡da vueltas!

Hice click entonces, recuerdo que en "procrastinación" y... me llevó a la página de la etiqueta correspondiente pero sin ninguna entrada en ella. A ver: puede que alguna de mis etiquetas tenga pocas entradas, pero seguro que procrastinación no es una de ellas.

Era, muy evidentemente, un problema con el link. Después de un rato de pruebas y puteadas maldiciones miro los comentarios en la página de donde la había sacado y veo que "algún problema" (comillas, porque no indagué demasiado) con el encoding tenía. Desistí de intentar arreglarlo.

Qué decepción... no funciona. Puedo tolerarle todo, pero no funciona. Alguien (¿quién? ¿alguien hace click ahí?) va a tocar y no va a encontrar las entradas correspondientes y abandonará decepcionado el blog.

Pero da vueltas...

Es tan linda...

Para resumir, verán que mis etiquetas ya no tienen acentos ni eñes. Sí, dice "diseno" en vez de "diseño". Pero da vueltas.

Que los sistemas, que la funcionalidad, que la solución más simple... no será muy funcional, pero gira.

Recordatorio: es evidente que en algunos casos podemos reemplazar funcionalidad esencial con unas lindas luces de colores.

BTW, Google no ha podido ayudarme esta vez, es que es demasiado ambiguo... ¿alguien se acuerda de qué era la publicidad?

jueves, 18 de septiembre de 2008

Gestores vs. realidad.

Imprescindible leer "Engañemos a la realidad" de Un Punto Azul Pálido, en el que se desarrolla un inevitable paralelismo entre las causas de la catástrofe del Challenger y algunas situaciones que cualquiera en el desarrollo del software ha vivido (o vivirá, sólo hay que esperar un poco) alguna vez.

No dejen de leer (ya verán los motivos de la insistencia, tanto mía como de Improbable) el imperdible artículo "Cuando los ingenieros se ponen en la piel de los gestores" de Historias de la ciencia, en el que se explica el apéndice de Feynman al informe de la comisión investigadora de la explosión del transbordador el 28 de enero de 1986.

Y si creen que esto es uno de esos posts cortitos de relleno, con más razón lean todo... tiene demasiado que ver con nuestro día a día para mi gusto.

Otro disparo a la productividad del Jueves.

Yo no me metería con esto si tuviese algo importante que hacer:

Magic Tiles Adventure.

Si tienen la suerte de que en un principio les parezca aburrido no le den una segunda oportunidad.

Vía Cerebrado (ojo, al mediodía, ¡eh!).

Propuesta para C#

¿Dónde hay que enviar una sugerencia para la definición de C#? ¿Hay que tener cierto consenso? ¿Hay que enviar firmas?

Este código debería dar error de compilación:

try
{
   Hago algo...
   Hago otra cosa...
   Hago algo más...
}
//hasta acá todo bien, pero...
catch
{
   ...si hay un error ¡no hago nada!
}

Ejemplo:

try
{
   Entity userData = FrontEnd.GetData();
   Data.Update(userData);
}
catch
{
}
FrontEnd.ShowMessage("Operation successful!");

Algo, aunque sea grabarlo en un log, enviarlo por mail, ponerlo en el visor de sucesos del sistema... por lo menos un puntito rojo arriba y a la izquierda del formulario... yo qué sé... lo que sea, algo.

¿Alguien me apoya?

Los verdaderos programadores...

Vía: me lo pasaron por ahí.

miércoles, 17 de septiembre de 2008

Tres tipos de programadores.

Tres canteros al pie de una catedral, que están haciendo el mismo trabajo: tallar piedras.

Un hombre se acerca al primero y le dice "¿Qué haces?".

El cantero le dice: "Tallo piedras" y la hosquedad de su mirada parece que añade: "¿No lo está viendo?".

El segundo responde diciendo: "Me gano la vida" y con su gesto de resignación parece añadir: "Es duro, ¿sabe usted?".

El tercer cantero, al escuchar la pregunta, levanta la cabeza, mira a lo alto, le brillan los ojos y dice: "Estoy construyendo una catedral".

Versión en español de Enrique Zamorano, en su libro "Las causas del fracaso de las empresas", copiado con algo de vergüenza del blog de Ángel "Java" López.

martes, 16 de septiembre de 2008

Depurar, primero con la cabeza, después con los ojos.

Error esporádico en un proceso de la aplicación. Nada más molesto. De cien veces falla tres o cuatro no consecutivas y más allá de esos fallos todo perfecto. Reintenta y sigue un rato largo, hasta el próximo.

Todo lo siguiente de palabra, charlando sin mirar el código:

¿En qué línea es?

En la que consulta los datos de activación del producto.

No tiene sentido, ésos están siempre disponibles desde que la aplicación arranca. Si no están no arranca. Y si se pierden, ¿cómo es que el sistema sigue en los reintentos?

Hay algo que baja esos datos y los vuelve a subir.

Pero el proceso que da error no tiene nada que ver con ello, sólo consulta.

Pero está corriendo casi todo el tiempo. Y entonces, de vez en cuando, se cruza con este otro desconocido que le baja los datos y que luego se los vuelve a subir.

Entonces es un tema de concurrencia. ¿Pero con qué? No hay otro proceso corriendo.

Entonces no es un proceso, es algo que ocurre a partir del front-end, tirado por el usuario.

¿Qué de lo que hace el usuario toca la activación del sistema?

¿No la estamos verificando en cada login?

A ver...

Y ahí, en la primera rutina que miramos, en la primera línea de código que chequeamos, está el maldito bicho, sutil, muy sutil: por espacio de unos pequeños milisegundos, entre que la rutina empieza y termina la verificación, baja los datos.

Ojalá todo se resolviera así. Ni siquiera es muy frecuente. Pero hay algo que es seguro: los errores más difíciles, los más complicados, no están en ninguna parte en especial del código, sino en el maldito vuelo de la mariposa china conjugado con el estornudo de un perro en París y la erupción de una mancha solar.

¿Cómo relacionarlos? ¿Qué hacer?

No sé si hay recetas, éstas son las que me funcionan:

  • De ser posible, no pensar sólo. Si no es obvio es que hay que verlo desde muchos ángulos, y la forma más fácil de tener muchos ángulos es tener al menos dos personas sobre lo mismo.
  • Si el problema no está en donde se originó el error ni antes de eso en la secuencia de instrucciones mirar el código no servirá para nada.
  • ¿Reintento la instrucción que dio el error y funciona? Concurrencia.
  • En este punto estamos seguros de que el tiempo tiene algo que ver.
  • La frecuencia del error puede acotar las posibilidades: ¿qué es lo que sucede más o menos cada n segundos, horas o días?
  • ¿No hay una frecuencia exacta? El usuario puede tener algo que ver.
  • Preparar café, porque en este punto estamos ante algo realmente difícil y que puede llevar mucho tiempo. Hay que verle el lado positivo a las cosas: al menos no hay que matarse tratando de reproducir el error, se reproduce sólo.
  • Si no lo encontramos y no es crítico, no hacer nada. Esperar a recolectar más información.
  • Si no lo encontramos y no es crítico, tal vez sea mejor pensar en otra cosa, distraerse, dejarlo estar. Es el azar el que crea la concurrencia, hay que relacionar azarosamente... eso lo hacemos mejor estando distraídos.
  • Aplicar un correctivo, algo que maneje el error y "levante" la situación siempre es posible, pero es sólo una solución temporal a ser aplicada en casos de extrema urgencia. Vamos, tiene que estar ahí.

Paciencia. Esta anécdota terminó bien, pero podríamos haber tenido que convivir con el bicho una temporada.

Y ahora que me acuerdo... mañana me espera uno parecido.

Hasta el máximo nivel de ineficiencia.

El post de Enrique Dans, Departamentos de IT: recortando por arriba, me hizo recordar un ¿chiste? bastante conocido que rezaba:

"Un empleado asciende en la organización hasta alcanzar su máximo nivel de ineficiencia."

A ver: un joven recién salido del secundario ingresa a una gran corporación como cadete. El trabajo le queda chico y se desempeña por encima de la media. A medida que va cursando sus estudios va ascendiendo a través de diferentes funciones administrativas, en las que se desenvuelve maravillosamente.

Se recibe y título en mano se presenta al departamento de personal, y luego de un tiempo su labor es reconocida con un nuevo ascenso.

Y así siguiendo. El ya-no-tan-joven prospecto va subiendo por la pirámide enfrentando retos cada vez más desafiantes, que supera con soltura, digamos de manera brillante, hasta que...

Hasta que llega a un puesto en el que ya no es tan bueno... simplemente porque no estamos hablando de un genio ni nada por el estilo. El trabajo es difícil y su desempeño ya no es espectacular.

Pero mientras se desempeñe "bien" seguirá ascendiendo (probablemente en forma cada vez menos frecuente) pero su trabajo será cada vez menos espectacular, más bien tirando a mediocre o incluso malo. Si no es tan malo como para ser despedido (nadie baja), terminará estancado allí, en ese puesto donde ha alcanzado "el máximo nivel de ineficiencia soportable por la empresa".

Conclusión: coincido con el referenciado artículo de Robert X. Cringely, "Fire Your Boss: The best place to cut IT organizations is generally at the top". Hay que cortar por arriba.

KISS: Keep it small and simple.




Estas viñetas fueron vistas en La masa, el ladrillo, la bota, el bocadillo...

KISS: "Keep it small and simple", o en una versión más agresiva (y que me gusta más) "Keep it simple, stupid!".

Y sin embargo, las viñetas de la izquierda son la vida misma, por lo menos en los proyectos en los que he participado (la mayoría aplicaciones transaccionales).

Es que el principio es simple, pero hacerlo es lo más complicado del mundo.

La complejidad del negocio está ahí, es imposible hacerla desaparecer. Sería tonto pensar que la búsqueda en internet es tan simple como la interfaz de Google.

Lo que hacen Google y Apple y que en general no logramos hacer nosotros (y que tampoco logra hacer Microsoft, si es que lo intenta) no es hacer desaparecer mágicamente la complejidad del negocio, sino incorporarla al sistema sustrayéndola de la vista del usuario.

Así, cuanto más simple hacia fuera, más complicado por dentro.

Pensemos ahora en un sistema más transaccional, del tipo "Evaluación del desempeño" (algo en lo que tuve experiencia). En todos los productos que he visto (y en los que he desarrollado) básicamente el sistema brinda una serie de opciones para ingresar al personal, configurar relaciones evaluador-evaluado y armar formularios que luego administra, muestra resultados, informes, etc.

El clásico menú del sistema, por ejemplo, es una pregunta: "¿Qué es lo que ud. quiere hacer?" Si lo preguntamos es porque no lo sabemos (espero). Así, una mayor cantidad de posibilidades revela un mayor desconocimiento del deseo del usuario de parte del sistema y eso revela... un mayor desconocimiento del negocio por parte del proveedor del sistema.

Volvamos al otro extremo, donde todo es más claro: es obvio que Google ha plasmado en su sistema un conocimiento del negocio "búsqueda en internet" muchísimo más profundo que el que cualquier ser humano individual (usuario) pueda llegar a tener. Por eso no nos pregunta más que lo mínimo indispensable: un par de términos relacionados con aquello que queremos. En nuestro ejemplo del sistema de evaluación pareciera que ni siquiera sabemos para qué entró el usuario al sistema.

A la luz de lo que vengo escribiendo hay un error de concepto en eso: el sistema es el experto, no el usuario. El sistema debería saber cómo se hace una evaluación de desempeño, no limitarse sólo a administrarla. No debería preguntar quién es el evaluador y quién es el evaluado. De alguna manera, el sistema debería inferirlo a partir de los datos que sí maneja el usuario y formular las preguntas necesarias para armar la evaluación, en los términos que maneja el usuario.

Por ejemplo: "¿Qué quiere evaluar?" A partir de la respuesta del usuario el sistema debería determinar las preguntas y también qué puestos deben evaluarse quiénes deberían hacerlo. Así, si contesto "Habilidad de los vendedores" el sistema armaría un cuestionario con preguntas del tipo "¿Se expresa correctamente en forma verbal?", preguntarme quiénes son los vendedores y quiénes sus jefes, etc.

Ahora me doy cuenta de que yo, como desarrollador, no sabía si tal o cual método era el mejor para un caso determinado (y por tanto no pude plasmarlo en el sistema)... ¿Cómo resolvía la situación, entonces? Se lo preguntaba al usuario. El sistema se lava las manos, volviéndose una excelente herramienta para hacer mal lo que no debería haberse hecho.

Más complejo todavía, el sistema podría arrancar con "¿Cuál es el objetivo de desempeño que desea cumplir?" y el usuario responder "Aumento del 50% en las ventas". Luego el sistema podría proponer, entre otras acciones, una evaluación, cursos, etc.

La diferencia de concepto es abismal. Digamos que estoy cruzando la línea divisoria entre un sistema transaccional y un sistema experto. La diferencia entre la herramienta y el conocimiento del negocio.

Muchas veces se vende una cosa por otra, y esto termina en el desengaño del cliente, que creyó comprar una solución y termina con una herramienta que sirve para hacer (eficientemente) algo que él no sabe hacer... como si yo quisiera viajar a Francia y me vendiesen un jet (ojalá pudiese pagarlo)... más me valdría un pasaje de avión de tercera clase.

Hágan el experimento... miren alguna de esas pantallas del sistema que están desarrollando o utilizando y piensen:

  • ¿Cuánto del negocio (que el sistema ya debería saber) se le está preguntando al usuario?
  • ¿Cuánta terminología de la que aparece en pantalla tiene más que ver con el sistema ("Ingresar formulario") que con el negocio ("Evaluar")?
  • Qué pasos podrían ahorrársele al usuario al incorporar al sistema qué es lo que hay que hacer de acuerdo al estado actual del mismo, en vez de que el usuario guíe al sistema a través de una serie interminable de menús y opciones.

Ésas preguntas son muy sugerentes, pero...

  • ¿Cómo hago que analistas y programadores adquieran ese nivel de conocimiento del negocio para el que trabajan? Google lo tiene resuelto: viene de las universidades, del ámbito científico, la empresa contrata conocimiento y lo almacena en forma de algoritmos, como todo lo que toca.
  • ¿Qué posibilidades necesito incorporar al sistema para plasmar ese conocimiento del negocio? Si le pregunto al usuario "¿Qué desea evaluar?" más me vale tener una respuesta (o caeríamos en el estilo Microsoft, cuyos ayudantes de resolución de problemas siempre terminan con "¿Esto ha resuelto la situación", "No", "Pues jódase Contacte con asistencia al usuario" y el ayudante se cierra).
  • ¿Qué necesito hacer para acortar la brecha entre la interfaz del sistema y el usuario? El lenguaje natural (escrito, oral) es terriblemente complejo, pero aún sin llegar al extremo de que el usuario formule preguntas en su propio lenguaje creamos una gran complejidad. Pensemos en el salto cualitativo que representa pasar de varios ABM's de configuración a un "Wizard".

En definitiva, supongo que por eso existe Google, Apple... y el resto del mundo.

domingo, 14 de septiembre de 2008

Tag Cloud

A estas alturas no espero que se den cuenta, pero por fin conseguí un Tag Cloud para el blog, que pueden ver en la barra de la derecha.

Buscando por ahí encontré varias soluciones posibles. Finalmente me quedé con el código que encontré en el blog Compender. Es de lo más simple y estudiándolo un poco se aprende bastante sobre los templates de blogger.

¡Gracias Raymond, por compartir el código!

jueves, 11 de septiembre de 2008

Panqueque System

Ésta caracterización la escuché hoy en la oficina y me quedó dando vueltas en la cabeza. Hablando de los causales del no muy lento ocaso de cierto producto ERP, se mencionó el hecho de que el sistema "se panquequeaba cada dos por tres". Es decir que los requerimientos, el diseño o las funcionalidades incluidas cambiaban abruptamente ("se daban vuelta") en forma continua, de forma tal que se reescribían casi completamente.

Si bien el cambio y la evolución son elementos comunes y deseables en el desarrollo de un sistema, se supone también cierta racionalidad. Se agrega o quita funcionalidad a partir de un núcleo conceptual que se mantiene en el tiempo o que cambia muy gradualmente.

Persiguiendo la idea, se me presentaron dos orígenes para un Panqueque System, que probablemente puedan luego sub-clasificarse: problemas en las definiciones y dependencia del cliente.

Lo que tienen en común ambos orígenes, que es en definitiva lo que define al panqueque, es el lugar en donde se encuentra la indefinición. Para que un sistema de vueltas en el aire sobre el fuego, ésta debe estar ubicada en el punto de apoyo de todo sistema: la definición del negocio. No en un sentido funcional ("cómo se ordenan los elementos en la pantalla X"), sino aquélla que nos define tiempos, alcances y restricciones generales del proyecto ("hemos vendido un sistema de XXX, que abarca el circuito desde A hasta B. Debemos dar muestras de avance cada TTT meses...").

La definición de negocio es ante todo una apuesta estratégica, la adopción de un riesgo, la declaración de una visión de muy general alcance. Es el terreno de la intuición, de la política, del regateo y la conquista del cliente.

El origen "problemas en las definiciones" implica graves fallos en la definición del negocio: o no hay seguridad sobre a qué negocio apuntamos, o el negocio es demasiado innovador o no hay suficiente conocimiento en el equipo acerca de él, etcétera.

Es esperable que si el proyecto sobrevive a un fuerte bamboleo inicial las definiciones se vayan asentando con el correr del tiempo, a fuerza de prueba y error. Como reza el adagio, "en la marcha se acomodan los melones".

Desarrollar en un ambiente así requiere de muchísima habilidad, prolijidad, de una arquitectura extremadamente resistente a los cambios y un fuerte énfasis en el encapsulamiento y modularización de toda funcionalidad en el sistema, entre muchas otras cosas. Puede que se cumplan los requerimientos, pero que el código se vuelva completamente inmanejable en poco tiempo.

Así y todo, aún considerando el peor de los casos (necesidad de recodificación), no deja de ser un modelo de desarrollo viable. Si la idea resultante realmente tiene éxito, llegará un punto en el que justifique una recodificación que materialice la experiencia obtenida.

Peor es, como en el caso del ERP que inicia este comentario, cuando existe en el seno de la empresa una lucha entre dos visiones antagónicas del negocio. No hablamos ya de discusiones dentro del equipo de desarrollo, sino de aquéllas que se dan en un nivel superior, aquél en el que se define "negocio". Puede ser una lucha interna propia (por ejemplo entre dos consultores estrella de la empresa) o proveniente del propio cliente (por ejemplo entre los dos socios que conforman la empresa que nos contrata). Ya sea una pelea explícita o implícita, esperemos recibir palos ora de un lado, ora del otro.

El impacto dentro del equipo es la sensación de hacer y deshacer continuamente las mismas funcionalidades o de estar implementando en realidad dos sistemas completamente diferentes, separados apenas por un par de opciones de configuración. También es posible que se dé un alto nivel de esquizofrenia en el sentido de que lo que por un lado se nos requiere, por el otro sea fuertemente criticado.

Si lo pensamos detenidamente nada impide, en teoría, satisfacer ambas necesidades, reutilizando lo posible. Pero digo en teoría porque en la práctica es común que la lucha de poder entre las dos visiones genere requerimientos "de destrucción de la otra parte", que vistos a la distancia pueden hasta ser divertidos. Por ejemplo: "retirar completamente del sistema la funcionalidad XXX". Vaya un requerimiento, ¿dónde está el por qué, el relevamiento, el análisis? En estos casos las causas reales no pueden describirse fácilmente ni mucho menos escribirse. ¿Qué les parece un documento en el que se lea "esta visión del módulo de ventas es infantil e inútil y no resiste el más mínimo análisis de alguien con experiencia en el rubro"?

Y así el Panqueque System se va dorando vuelta y vuelta, un poco de un lado un poco del otro. Eventualmente estará bien cocinado (de ambos lados) o quemado de uno o ambos, lo que para el caso es lo mismo.

Resta para una segunda parte el segundo origen del Panqueque System: dependencia del cliente, que aparecerá en breve. ¿Tu proyecto es un panqueque?

Actualiazación: sigue en Panqueque System II: Un caso de dependencia del cliente.

Actualiazación II: ¡Obsesionado con los panqueques! Panqueque System III: El infierno de las preferencias.

martes, 9 de septiembre de 2008

Encuesta: 12 factores clave para decidir cambiar de empresa.

Actualización: los resultados.

En El blog salmón, en las entradas "12 factores clave para decidir cambiar de empresa" (parte I y parte II) se analizan los factores clave que motivan el permanecer (o no) en una empresa, según un estudio realizado por Gallup.

Para hacerlo más interesante armé esta encuesta (anónima) para ver cómo estamos con respecto a estos 12 puntos. Pasen la voz.

Click aquí para completar la encuesta

Los puntos son los siguientes:

  1. Expectativas sobre uno mismo.
  2. Recursos de los que disponemos para realizar nuestro trabajo.
  3. Poder ejercer las propias habilidades.
  4. El reconocimiento de los demás.
  5. El apoyo de los superiores.
  6. La formación (capacitación).
  7. La consideración de nuestras opiniones e iniciativas.
  8. El sentido del propio trabajo dentro de la empresa.
  9. Calidad de los resultados.
  10. Clima laboral y las relaciones personales.
  11. El propio progreso.
  12. La carrera profesional.

(visto en lboisset's Ruminations)

Formalizar hasta paralizar.

Acabo de leer, en una de esas casualidades que necesariamente se dan en cualquier proceso caótico (como lo es mi lectura en el reader) estos dos artículos:

Por un lado,El 73% de las pruebas de desarrollo ágil han sido un éxito (Navegápolis), que comienza con las siguientes citas:

"...Los estándares para mejora de procesos de software se han tenido como forma para superar estos retos. CMMI es un ejemplo de estándar empleado por empresas de software. Según los datos del Instituto de Ingeniería de Software (SEI), aplicar este tipo de mejora suelen suponer entre tres y cinco años, y también requiere bastante inversión, de 10.000 a 45.000 euros por ingeniero (Jones 1999)... Finalmente, más del 70% de estos procesos de mejora fallan..."
"...El 73% de las pruebas de desarrollo ágil realizadas se han considerado un éxito. El estudio ha empleado métodos ágiles en el desarrollo de software empotrado en 68 empresas, implicando a 1.800 ingenieros en 17 compañías europeas en un periodo de dos años y medio..."

Luego, ¿Granizada sobre mi proyecto? El regreso de los cuellos de botella fantasma (Dirección de Proyectos):

Nuestro miedo al conflicto –en un proyecto, aunque sea en pequeñas dosis, es inevitable- hace que, para evitar que llueva y mojarnos, sobreenfriemos el ambiente. Lo único que conseguimos es crear artificialmente una situación metaestable que dura lo que se tarda en que cualquiera de los pequeños detalles que se suceden continuamente en el proyecto, una mínima chorrada, desate la caja de los truenos y una tremenda granizada asole nuestro proyecto. ¿Efecto mariposa? No, efecto “todo va bien”. Y, como dice Murphy, si crees que todo va bien en el proyecto es que no te estás enterando de nada.

Atravesar un proceso de desarrollo de software es atravesar el conflicto: con los clientes, su negocio, el "nuestro", el de cada uno de los integrantes del equipo en particular... entre todos con la tecnología, las comunicaciones, el tiempo y el uso de los recursos.

Conflicto implica riesgo y oportunidad. Sin conflicto no habría proyecto.

Pero los seres humanos (y sobre todo aquellos que son responsables de la dirección de un proyecto o inversores en él) hemos desarrollado cierta aversión al riesgo, y por ende cierta aversión a los conflictos.

Así que buscamos formas de minimizar el riesgo (conflicto), manteniéndolo dentro de ciertos parámetros, que son controlados obsesivamente. De una manera o de otra, con mayor o menor énfasis, los pasos especificados por cualquier metodología (desde el tradicional ciclo de vida hasta Scrum o Xp) intentan manejar el conflicto (riesgo).

Por ello se especifican detalladamente los requisitos o se tiene a un cliente en el equipo de desarrollo. Se diseña en forma cada vez más detallada hasta llegar a la más ínfima porción de código o se diseña pensando en el cambio continuo. Se prueba intensivamente toda la funcionalidad o se realizan varias entregas incrementales....

Como vemos, las metodologías son opuestas pero el objetivo es siempre el mismo: la minimización del riesgo, la resolución del conflicto antes de que éste aparezca (diseñamos todo para que no haya cambios o diseñamos para el cambio antes de que éste se presente).

Del otro lado del mostrador, en donde el término "metodología de desarrollo de software" no significa absolutamente nada, el cliente (o el inversor) también quiere minimizar el riesgo.

¿Pero cómo? No puede controlar el proceso, sólo el avance... pero ¿cómo podría diferenciar un sistema completado en un 50% de una muy bonita cáscara vacía?

Puede requerir que se cumpla con determinadas prácticas que son, a juicio de expertos (personas u organizaciones) en las que él confía, las mejores. Es decir, por referencias, de la misma manera en que confiamos en un plomero que viene a arreglar ese problemilla de humedad tan molesto.

Y aparecen las certificaciones.

Perfecto. Pero cierta lógica perversa en cómo se instrumentan las certificaciones tergiversa las cosas.

El cuento es conocido se lo mire por donde se lo mire:

Del lado de los grandes es "he invertido tiempo y dinero en certificarme, ahora quiero que ésto sea una barrera de entrada para mis competidores". Una vez que la empresa está certificada, cantará loas a su proceso de desarrollo certificado por más paralizante que éste sea o incluso por más que el nivel de adopción real sea mínimo. Hacer lo contrario sería tirar la inversión a la basura. El mismo razonamiento desincentiva cualquier cambio en la metodología (en los papeles). La certificación, por definición, vuelve conservadoras a las organizaciones.

La certificación puede volver tan burocrático y enredado el proceso de desarrollo que el producto final sufre brutalmente... pero "hacia fuera" nunca será culpa de la certificación (al fin y al cabo hemos pagado tanto por ella...), sino que se buscarán otros chivos expiatorios.

Del lado de los pequeños es "tengo que certificarme para vender, pero me impone ciertas prácticas que me son nocivas y encima una inversión en consultoría completamente desproporcionada de acuerdo a mi nivel de actividad". El peso de los procesos que requiere la certificación es enorme para un equipo pequeño y acostumbrado al trabajo informal, y el costo es un hueso duro de digerir para la estructura financiera de la pyme.

Por otro lado, admitámoslo, está la perversidad del papel de las empresas consultoras / certificadoras / auditoras. Es inevitable pensar en que ésta y su cliente tienen el mismo objetivo: que el cliente se certifique. La "inversión en dinero" de la gran empresa va a parar a manos del consultor, que tendrá más interés en lograr su objetivo en tanto mayor sea la inversión. No importa cuánto se lo disfrace: el consultor cobra por certificar a la empresa, no por mejorar su proceso de desarrollo.

Y le ponemos el moño pensando en que cuando la certificación falla, el consultor también falla. Ésto puede no ser relevante en una pyme que nadie conoce, pero no lograr certificar una gran empresa puede significar una fea mancha en el prontuario de la consultora.

La teórica separación entre consultores y auditores, por más que sea "materializada" en las especificaciones de la certificación, en la práctica no beneficia a ninguno de los involucrados. Esta inevitable asociación de intereses permite poner en duda todo el proceso.

En definitiva, las grandes empresas siempre terminan certificadas de cualquier cosa (¡hasta de amigables con el medio ambiente!), mientras que las pequeñas... a veces sí, a veces no.

Creo que he dejado claro (si no fue así ya es tiempo de aclarar) que no tengo problemas con ninguna metodología, sino con el proceso mismo de certificación. CMMI puede ser fabuloso, pero la certificación en CMMI, como otra ya en Scrum, XP o lo que sea, me parece sospechosa en cuanto a su utilidad para el proceso de desarrollo del producto (claro que no así para su venta o promoción).

lunes, 8 de septiembre de 2008

Sobre la evaluación de los programadores.

En PSP (Personal Software Process) o como pasarse de rosca midiendo se comenta el caso en el que un desarrollador "pierde" algún tiempo codificando (por supuesto que con algún errorcito) una función que valida fechas al estilo IsDate de Visual Basic... en realidad, idéntica al IsDate de Visual Basic.

¡Qué barbaridad! ¡Qué pérdida de tiempo! ¡Qué desconocimiento del lenguaje!

Ésta es una breve historia sobre cuatro programadores.

Programador A

Luego de un par de meses el Programador A que ha codificado la función ValidaFecha idéntica a IsDate ve ese código, se sonríe un poco y piensa "qué inútil". Borra el cuerpo de la función y lo reemplaza por la llamada a IsDate.

Programador B

Programador B no ha creado la función "inútil" para validar fechas. Luego de resolver el tema en una pantalla en particular copia y pega las 130 líneas de código en cada una de las 50 pantallas del sistema.

Pero después de un par de meses ve ese código en una pantalla, se sonríe un poco y piensa "qué inútil". Lo reemplaza por IsDate. Se queda pensando... revisa todas las pantallas y encuentra las mismas líneas junto a otras que hacen algo parecido. Está molesto, porque sabe que tiene que corregirlo y se le hace trabajoso. Le molesta pensar que tiene que probar nuevamente todas las pantallas del sistema. Finalmente, crea una clase dedicada a validaciones donde, entre otras, encapsula la función IsDate.

Programador C

Programador C ha comenzado igual que Programador B (copiando todo en todos lados), también busca en todo el sistema y las reemplaza por la llamada a IsDate en cada una de las pantallas.

Programador D

No sabemos qué solución adoptó el Programador D, pero en todo caso podemos estar seguros de lo siguiente: cuando lo vuelva a ver no reflexionará ni un segundo sobre cómo ha llegado allí, ni sobre si está bien o mal, salvo cuando se presente algún error (que puede ser en todo el sistema o en una pantalla en particular). En este caso corregirá el tema puntual y seguirá con su vida.

Ahora, con un poco de perspectiva, juzguemos a cada uno.

Obviamente Programador A es un junior, o apenas ha comenzado a programar en VB. Hizo lo mejor que pudo con las herramientas y el conocimiento que tenía. Trabajó prolijamente y en una forma tal que luego no tuvo problemas en mejorar el código a la par de su propio conocimiento.

Casi lo mismo podemos decir de Programador B. Pero en mi opinión tiene más mérito. ¿Por qué? Corrigió el error en todo el sistema y buscó la forma de que no le vuelva a suceder. Empezó un escalón más abajo que Programador A, y llegó más arriba. En realidad no importa si su solución es óptima o incluso correcta. El Programador B intenta solucionar los problemas "de aquí en más". Cuanto más se equivoque más aprenderá.

Lo único que ha aprendido Programador C es que existe una función llamada IsDate que valida fechas, que no es poco pero tampoco tanto. Es el tipo de persona que dice "muchos árboles" en vez de "bosque".

La vida del Programador D evidentemente pasa por otro lado. Supongo que poco le importará nuestra opinión de él o de su código, en tanto conserve su trabajo.

En definitiva, desde nuestro punto de vista, grandes desarrolladores que hemos nacido sabiéndolo todo y que nunca hemos reinventado la rueda, todo es una gran pérdida de tiempo. Sabemos perfectamente cuándo hay que usar IsDate y cómo se comporta por lo que nunca tendremos problemas con ella, y tal vez hasta vemos un poco inútil el encapsularla en una clase de validaciones.

Al resto de los mortales sugiero juzgarlos no por la corrección de sus soluciones en un momento dado, sino midiendo cómo capitalizan su experiencia a través del tiempo.

sábado, 6 de septiembre de 2008

¡Macho dijo la partera!

Using your browser URL history to estimate gender

Me dió:

Likelihood of you being FEMALE is 12%

Likelihood of you being MALE is 88%

Según Emezeta

[...] El sistema compara con el top de sitios web de Quantcast (el cuál posee una estimación de visitantes con sexo predominante) con los sitios que has visitado, para hacer la estimación de género masculino-femenino. [...] (ver entrada completa)

A ver, quién de uds. es más hombre, ¿eh?

viernes, 5 de septiembre de 2008

La publicidad es como el porno.

¡Es cierto!

  • Siempre avanzas rápidamente evitando la parte aburrida.
  • Los mismos conceptos son reciclados una y otra vez.
  • Si es realmente bueno, trasciende el idioma en el que está hecho.
  • ...

El resto en marilink.

jueves, 4 de septiembre de 2008

Google shit.

No estoy de acuerdo con eso de andar comentando cualquier cosa de cualquier manera, y sobre todo utilizando malas palabras y groserías cuando no corresponde, y no me gusta hacerles la fiesta a los que lo hacen... pero hay veces en que alguno de estos comentarios inapropiados es demasiado divertido como para aguantar la risa.

Axel Marazzi postea en Alt1040 el artículo "Los abouts de Google Chrome", comenzando con la siguiente frase:

"Muchos de nosotros ya adoptamos a Google Chrome como explorador por defecto. De hecho ya me comencé a preguntar qué era exactamente Firefox, no lo recuerdo bien. Todas las personas que estén pasando por la misma situación que yo tienen que tener en cuenta los siguientes abouts que te mostrarán el rendimiento del programa en tu ordenador."

Ok, al tipo le gustó el Chrome, eso está claro. El usuario uno (anónimo tenía que ser, por supuesto) le comenta:

[...] el día que Google venda mierdas te volverás necrófago (en realidad es coprófago) y podremos ver una entrada del estilo: Ya sólo como Google shit y ni me acuerdo de qué es eso de la carne ni el pescado [...]

lol

Ya sé que no debería hacerle la fiesta a este tipo de navegantes, en general no lo hago... pero todavía me sigo riendo, estuvo bien.

Testing es veneno para la mente.

Yo siempre lo pensé y por eso tengo reservado a los testers mi más profundo cariño.

Porque hay que tener ganas, realmente... pantalla por pantalla, botón por botón, probando desde las combinaciones más simples hasta las más delirantes, tratando de ganar en maldad y superar en estupidez al usuario (toda una utopía).

Y porque aunque en menor medida, ellos también sufren, junto a los desarrolladores, la suerte que el destino reserva a aquellos que han cometido graves faltas en vidas anteriores (o en ésta): no importa qué tan bien hagan su trabajo, siempre fracasarán. Si descubrieron 1000 bugs en el sistema éstos serán reparados y olvidados rápidamente, y serán denostados por "ése tan obvio" que se les pasó.

Lo que sufren ocasionalmente (gracias a ellos) los usuarios estos pobres mártires lo sufren día a día, hora tras hora, y se levantan y van por más.

Arriesgaría que los sistemas administrativos son peores. Hay tantas posibilidades, idas y vueltas, cancelaciones, aprobaciones parciales, cierres y contracierres, documentos que vencen y situaciones ambigüas que asustan. Éstos sistemas usualmente funcionan aparentemente bien, lo cual es peor, porque bajo esa apariencia de solidez pueden ocultarse graves errores conceptuales, de negocio.

¡Pero qué divertido probar un juego! Pensamos a veces... no nos engañemos. Probar no es jugar y tratar de repetir y definir aquella acción que nos transportó desde un mundo virtual a un loop infinito no puede ser sino el peor de los calvarios.

Como desarrollador a veces me fastidio, sobre todo cuando me vienen con bolu nimiedades, pero cada vez que se descubre un "pequeño agujero negro" en el sistema pienso qué hubiese tenido que soportar si se les hubiese pasado... porque a mí ya se me había pasado.

Cuando faltan, sentimos que estamos trabajando a 30 metros de altura sin red, cuando no reportan nos ponemos nerviosos... nunca está bien, si no hay errores es simplemente que no los están encontrando.

Entonces, digo, ¡defendamos a los testers! Cuidemos de aquellos pocos a los que les encanta su trabajo, sobre todo de declaraciones ignorantes y difamantes. Hago público mi voto de censura hacia Elvira Lindo, que probablemente escriba muy lindo, pero que de sistemas seguro no entiende nada. Y cito:

"Usar la inteligencia solo para buscar los errores de los demás acaba envenenando, y acaba no siendo inteligencia."

- Elvira (que no merece otro link), vía Microsiervos, quienes deberían disculparse, sí, sí, sí.

miércoles, 3 de septiembre de 2008

Batalla por el control de la oficina.

The Great Office War, un video que es casi una superproducción documentando una batalla más en la eterna guerra entre IT y resto del mundo personal de ventas, en este caso.

Vía Esquizopedia.

Ubiquity, Google Chrome, IE 8

Aplacada (apenas) la tormenta del nuevo-celular-que-no-quiero-ni-mencionar (aunque ya lo hice) tuvimos un par de días de relativa calma bloggera, parece.

En ese contexto estaba procrastinando algún comentario sobre Ubiquity, el nuevo add-on para Firefox (no sé si es exactamente un add-on, no me maten si no lo es). Ni se me hubiese pasado por la cabeza mencionar la beta del IE 8, por considerar al IE ya completamente ajeno a mi existencia (ver Firefox...) y por cierto cansancio ante tanto blog recolector de novedades que salen por ahí (prefiero linkear imágenes graciosas, buscar soberanas estupideces o escribir las mías).

Pero en el medio saltó como una bomba el tema del nuevo navegador de Google (¿el comic book de presentación se filtró por el despacho de correo? Difícil de creer...) y aquí estamos.

Realmente se pone interesante la escena. Por un lado Enrique Dans hace un análisis tal vez un poco apresurado pero no por ello menos interesante, por el otro las primeras opiniones sobre el navegador son bastante sorprendentes y tengo que coincidir con ellas. Una rápida prueba a ojo en la oficina lo muestra como un auto de carreras de F1 al lado de... digamos una Ferrari y una carreta, se imaginarán ustedes cuál es cuál.

Digo que se pone realmente interesante porque si la visión de Enrique (¿te puedo tutear?) es correcta, estamos ante tres visiones diferentes de la experiencia web. ¿Por qué digo esto? Por UbiqityUbiquity (apenas si lo sé escribir bien y ya me voló la cabeza).

Si no lo han instalado, háganlo en este preciso instante, y después hablamos:

Si bien al principio parece muy "cool", "lindo" e "impresionante" (en términos gráficos más que nada) basta usarlo "en serio" (es decir, sin ánimos de probarlo ni nada por el estilo, simplemente haciendo lo que sea que hacemos todos los días con el navegador) por un par de días para que cambie completamente nuestra forma de navegar.

Ha cambiado tanto mi forma de utilizar el navegador que no creo que tenga vuelta atrás. La atención se mantiene siempre centrada en la actividad principal, y todo gira alrededor de eso. Si estoy escribiendo un mail y quiero incrustar una página, la busco sin abandonar el mail. Si estoy mirando una página y la quiero enviar por mail lo hago, y el foco pasa al mail y vuelve a la página (o nunca sale de la página, en realidad) de una forma natural. Tanto es así que me ha llevado a meter los dedos y crear un par de comandos. Si logro afinar alguno los posteo.

En fin, para cerrar este post "de actualidad" los dejo con la recomendación de probar Ubiquity, porque creo ver que representa más un cambio de dirección que una mejora... ¿cómo se podría extrapolar ese concepto a otro tipo de sistemas? Al fin y al cabo, si se masifica los usuarios podrían pretenderlo en todo tipo de aplicaciones...

martes, 2 de septiembre de 2008

Asteroides III

Seguimos obsesionados con los asteroides (ver Asteroides y Requerimientos: cuando no son asteroides sino sólo polvo cósmico).

Aquí un buen ejemplo de la llegada de uno de ellos a nuestro escritorio: ¿Qué pasaría si un asteroide de 500km colisionara con la Tierra? (Vía ALT1040).

¿Y... dónde está el negocio?

Hablando coloquialmente, los desarrolladores solemos llamar "negocio" a todo aquello que por definición queda afuera del sistema que estamos desarrollando.

¿Por qué están separadas estas dos pantallas, si tienen una funcionalidad tan parecida? No sé, es un tema de negocio.

Es decir, es porque sí, y no se discute. Si somos curiosos (en general lo somos) preguntamos por qué, y de a poco vamos conociendo ese negocio al que servimos... Sabemos que tal persona trabaja de esta manera, que usualmente los pedidos se realizan de esta otra, que al gerente de distribución le sirve este dato pero no este otro, y así. Vamos recolectando, sin quererlo, pequeños secretos del rubro para el cual trabajamos en un momento determinado.

Y si trabajamos mucho, pero realmente mucho tiempo en el mismo negocio terminamos siendo casi expertos. Yo se "mucho" de recursos humanos, simplemente porque trabajé en una consultora. Ahora estoy aprendiendo "bastante" de la industria del juego, simplemente porque trabajo en una empresa del rubro. Hay programadores que terminan conociendo negocios tan impensados como el acero, la distribución de energía o el mantenimiento del arbolado público.

Siempre entre comillas, porque nunca dejamos de ser desarrolladores, y siempre aprendemos un poco de oídas. Obviamente no es lo mismo saber cómo trabaja un consultor de recursos humanos que poder hacerlo. Por otro lado rara vez se supera la franja de la mera curiosidad o de la anécdota puntual y se pasa al genuino interés.

En definitiva vivimos de ese negocio, porque define nuestro sistema. Sus necesidades son nuestros requisitos, sus caprichos nuestros dolores de cabeza, sus cambios bruscos nuestras tormentas, su éxito el nuestro y su decadencia el momento de hacer las valijas y buscar un nuevo hogar.

En los papeles la función de representante del negocio en el equipo le corresponde al analista funcional. Si trabajamos en un estudio o en una pyme puede que ésta función esté cubierta por el líder de proyecto, por gerente o por el mismo desarrollador, o incluso por el cliente. Pero la función siempre existe. Si no hay un cliente (desarrollamos un producto masivo) habrá un departamento de marketing, un estudio de mercado o la simple visión del dueño de la empresa sobre lo que hay que ofrecer, pero existe. En una gran consultora puede que el analista tampoco tenga acceso directo al cliente, pero de todas maneras será el contacto del equipo de desarrollo con el mundo exterior y por eso, en lo que a éste respecta, representará "al negocio".

Por otro lado, un desarrollador interesado en el negocio será menos propenso a cometer errores o a dejar pasar errores provenientes del análisis. Le será más fácil encontrar sentido a su trabajo, lo que evita la desmotivación. Por más simple que sea la pantalla, saber para qué sirve o qué tan importante puede llegar a ser tal dato para el cliente es motivador (bueh, si no lo es por lo menos no desmotiva). Lo más importante, sabrá no desperdiciar su esfuerzo en funcionalidades bonitas o difíciles pero al mismo tiempo inútiles (no tengo nada contra las funcionalidades bonitas o difíciles, pero me molestan las inútiles).

Un desarrollador interesado en el negocio es el mejor tester que puede existir. Conoce las debilidades de la aplicación y al mismo tiempo los manejos y desmanejos comunes en su uso. Sabe probar primero lo importante y luego lo accesorio, evitando errores sutiles de programación pero evidentes para el cliente (un término mal empleado en un mensaje, algo accesorio ubicado visualmente en un lugar central, un dato inútil, un ">" donde tendría que haber un ">=" y por el que el desarrollador es injustamente castigado, como si pudiese notarlo en 200 líneas de código... o en 3, lo mismo da).

En algunos casos hasta se invierten los papeles y el analista hace prueba y error contra el desarrollador conocedor del negocio hasta dar con la solución.

Lo peor es que es usualmente subvalorado, ya que es fácil adueñarse de sus aciertos y, como todo programador, es vulnerable por sus errores (que siempre los tiene).

Pero... ¿qué pasa si el negocio se va? ¿Cómo? ¿A dónde? No sé a dónde, pero se va. No está. No se lo encuentra, no responde. Imaginemos.

Durante un tiempo avanzamos en punto muerto consumiendo la energía cinética acumulada, actuando por inercia. De a poco el trabajo se va frenando hasta que alcanzamos la más absoluta inmovibilidad. "No hay nada que hacer."

Eso es imposible, siempre hay algo para hacer. Es cierto. Así que lo hacemos. Probamos hasta el hartazgo. Se corrige hasta el el más mínimo bug con una perfección obsesiva. Pero ¿quién dice que estamos corrigiendo lo importante? Errores hay muchos, pero no todos merecen ser corregidos. Ésta es una decisión de negocio. Nadie dice nada, así que resolvemos lo que mejor nos parezca.

Luego, cuando ya ni errores quedan, nos quedamos mirando aquellas zonas oscuras del sistema, aquellas sobre las que necesitamos alguna definición, con miedo. Finalmente, en el colmo de la desesperación, nos adentramos en ellas, iluminándolas con la imaginación si es necesario... aquí nos convertimos en amos y señores absolutos del sistema. Responsables por todo, librados a nuestra suerte con nuestro propio criterio como única herramienta...

...o se elige algún proyecto de aquellos que están en el tintero. ¿Cuál? El que resulte más importante (según nuestro mejor pálpito). Otra vez el riesgo, que aumenta al concentrar negocio, análisis, programación (y puede que testing) en nuestras cabezas. Lo que a esta cabeza no se le ocurra hacer, tampoco se le ocurrirá diseñar. Difícilmente logre encontrar durante las pruebas las situaciones que no contemple al programar. Al fin y al cabo, si se le hubiesen ocurrido las hubiese contemplado.

Es claro que la situación no puede sostenerse demasiado. En algún momento el negocio aparecerá. Verá que está todo en orden (gracias a nuestro héroe empresario- analista-desarrollador-tester en las sombras) y pensará que todo funciona normalmente, desconocedor de su propia suerte... más probablemente vea que la cosa se ha salido de cauce, que los detalles están pero lo fundamental brilla por su ausencia o que está, pero que era un auto y ahora tiene una lancha... que funciona perfectamente, eso sí.

O no aparecerá nunca y el desarrollo flotará a la deriva o conducido por quien demuestre voluntad de ir hacia algún lado. Algunos abandonarán con la sensación de no estar haciendo nada realmente productivo, otros le encontrarán algún sentido aunque sea personal, de aprendizaje o lo que sea.

Y la pregunta que permanecerá flotando entre el polvo que cae acumulándose en los teclados es... ¿y dónde está el negocio?