Hablamos de desarrollo de software, y de cualquier cosa que venga a cuento de eso.
Un poco en joda, un poco en serio, depende el humor del día.

jueves, 31 de julio de 2008

Monitos con navaja

Leyendo este post en La pastilla roja me encontré con la descripción del siguiente experimento:

Uno de mis experimentos favoritos sobre el comportamiento es aquel que se hace con unos monos y un manojo de plátanos. Cada vez que un mono se acerca al manojo para coger un plátano se propina una descarga eléctrica al resto del grupo. Con el paso del tiempo los monos aprenden y se dedican disuadir por la fuerza a cualquiér congénere que trate de acercarse a la fruta.

Hasta aquí todo es muy lógico, lo curioso sucede cuando se van reemplazando los monos previamente electrocutados por otros que nunca sufrieron dicho castigo. Estos monos continúan propinando palizas a quienes se acercan a los plátanos a pesar de que ellos mismos nunca sufrieron los efectos de las descargas eléctricas hasta con que, con el paso del tiempo, se pega a cualquier mono que trate de acercarse a los plátanos sin que ninguno de ellos sepa porqué lo hacen.

La vida está llena de comportamientos que fueron útiles en un pasado lejano pero que han dejado de serlo largo tiempo atrás.

Es muy común encontrarse con este tipo de cosas en cualquier equipo de desarrollo. Un nuevo programador que se integra a un equipo suele sufrir mucho este tipo de situaciones. Al tener una mirada fresca sobre el código (y también sobre sus nuevos compañeros de trabajo), percibe claramente este conjunto de prácticas (algunas graciosas otras no tanto) que tienen más que ver con la historia o la cultura creada en el equipo que con cuestiones técnicas o lógicas. Prácticas que en algún momento tuvieron sentido pero ya no, y que nadie se ha molestado en cuestionar. Pecando con un poco de soberbia, el nuevo a veces tiende a pensar que sus compañeros no piensan demasiado (¡error!).

Si en este punto esperan comentarios sarcásticos sobre ese tipo de cosas, esta vez los voy a desilusionar. Si bien es claro que estas actitudes tienen sus vicios, son la otra cara de la moneda de lo más básico del proceso de desarrollo de software.

Porque esta repetición "sin sentido aparente" es consecuencia inevitable (y deseable) de la división por capas, el encapsulamiento y la división de tareas. A ver, seamos claros. Si tengo que programar la funcionalidad X y se que tengo que utilizar "MiClase"... ¿miro el código de "MiClase" para entender exactamente cómo funciona o miro código con funcionalidad parecida a la que tengo que hacer y que también utiliza "MiClase" para entender cómo se usa? ¿Hay algo de malo en esto?

Tal vez a alguno se le cruce por la cabeza "copiar y pegar sin pensar". No, no estoy hablando de esa situación (que también existe, pero esto es otra cosa). El programador mira el código, lo interpreta, lo entiende y lo encuentra razonable sin entrar en detalles. Entonces toma la referencia que necesita y la adapta.

Como programadores, tomamos mucho de lo que vemos "como está", sin cuestionarlo demasiado. Y cuanto más éxito tenemos en este camino, más reforzada se ve esta conducta. Podemos hacerlo si el proyecto está bien estructurado y el código es parejo en cada capa, que es lo esperable. Si el proyecto es una sopa de algoritmos ni siquiera encontremos qué copiar.

¿No les parece que hay algo como que está mal? Sí, las palabras. Si en vez de empezar este artículo hablando de monos pegándose unos a otros hubiese comenzado con "la documentación de referencia más importante es el código" todo sonaría mucho más lindo. ¿Por qué decimos que "el código es la referencia más importante" y utilizamos esa frase para obligarnos a respetar los estándares y las buenas prácticas hasta en las funciones más triviales? Porque todo el código, TODO, es pasible de ser utilizado como referencia, nos guste o no, de manera controlada o no.

Si dejamos una lógica medio enrevesada dando vueltas por ahí, o algún código comando, pensando "bueh, pero esto está encapsulado acá, y es algo sin relevancia"... volvemos dentro de tres o cuatro meses y lo vemos esparcido como un virus por todo el sistema... como TODO el resto del código, por otro lado. Sólo que cuando ese código "esparcido" no tiene nada de malo, prácticamente no nos damos cuenta.

Pero sí hay algo que está mal: volvamos al "nuevo". El tipo va y pregunta "¿por qué esto está hecho así?" Y le contestan "porque se hace así, siempre lo hicimos así". Esas no son razones para dar a nadie.

La respuesta más correcta sería "no sé, siempre lo hacemos así, pero si querés ver bien fijáte en tal lado". Es decir: obviamente nadie tiene en la cabeza el por qué de todo, pero si es indispensable que la estructura del proyecto permita inferir dónde está el por qué de todo. Yo no sé "por qué", pero sí sé que hay un por qué, y dónde buscarlo, por las dudas.

Y hay que estar abierto al cambio, a la mejora. Sigamos la anécdota. El nuevo va, mira, entiende, y como lo ve razonable se olvida de todo, no hay nada del otro mundo allí. Eso se repite un par de veces (digamos de paso que éstas son las "conductas observables" por las cuales se transfiere la cultura) mientras va aprendiendo un poco cómo se hace todo. Hasta que en una de esas sí encuentra algo que no tiene sentido.

¿Qué hacemos? Bueno, espero que haya quedado claro que la frase "dejálo y hacélo como siempre, siempre lo hacemos así" no tiene sentido, mucho menos ahora.

La opción de máxima sería corregir y corregir todos los lugares en donde esa incoherencia se ha "copiado y pegado", que es el equivalente a erradicarlo. Pero la realidad es que a menos que el proyecto esté infectado con ese tipo de cosas por todos lados (en tal caso está desahuciado), es más probable que el tema sea más o menos benigno. En este caso, alcanzará con cambiarlo de aquí en más y tal vez, de a poco el código corregido se distribuya tanto como el otro lo hizo en su momento.

Voy a por mi plátano, hasta el próximo post.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

miércoles, 30 de julio de 2008

Cuidado! Procrastinador viral altamente adictivo.

La gente de Microsiervos ha cometido una gran imprudencia al publicitar en este post un jueguito terrible que puede arruinarnos la cabeza. El daño ya está hecho, así que me no siento culpas de sumarme a la estampida.

Aquellos que no teman la ira de jefes y clientes o que no tengan nada mejor que hacer (y mucho tiempo libre por delante) que se animen y sigan el link. Habiéndolo visto y toqueteado apenas un poco he decidido abstenerme de más porque está como para perder la tarde completa.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

Troll-Post

A ver, acabo de bajar este post de h@anz...el Geek que recuerda la famosa frase

La programación en bajo nivel es buena para el alma del programador.

esta vez adjudicada a John Carkmack (digo adjudicada porque ya he leído tantas variaciones por tantos personajes diferentes que no pongo las manos en el fuego por ningún crédito).

Más allá de lo gracioso de la frase en sí, yo me pregunto... ¿a quién miércoles puede gustarle programar en bajo nivel? Solo una manga de inadaptados ajenos a la realidad pueden preocuparse por si el bit n está en 1 o en 0 y festejar si logran hacer una aplicación que, por ejemplo... ¡comunique dos dispositivos por un puerto serie! (algo que para un programador "como la gente" -de "alto" nivel- sería casi trivial)...

¿Cómo es que puede existir, en pleno siglo XXI, gente deseosa de lidiar con MOV PUSH CLR SET y yo qué se qué más (¿qué problema tienen contra las instrucciones de más 4 letras?)...

Parecen fanáticos ingleses o yanquis, a contramano del mundo, utilizando el sistema ¡hexadecimal! u ¡octal! (¿cómo es que eligen esas bases? Supongo que se juntan todos en convención y empiezan a discutir "yo creo que base 9 es la más difícil de entender, usemos esa"... "no, no, no, base 17 es peor... mejor quiero decir...", "yo tengo otra idea... usemos una base aleatoria...")... pero ¡¡¡por Dios!!!! ¿CUANTOS DEDOS TIENE ESTA GENTE? ¿2, 4, 8, 16, 32... CUÁNTOS?

En fin, por suerte viven encerrados en sus cajitas de silicio, gracias al cielo por ello.

PD: Ahora en serio, saludos a todos uds. con el mayor de los cariños y la más grande de las envidias... pero no me vengan con sus problemas, si se puede tocar no tiene nada que ver conmigo.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

martes, 29 de julio de 2008

5 libros 5

5 libros 5 que nada tienen que ver con sistemas, recomendados por las más variadas razones en desorden, sin ánimos de hacer ranking.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

Firefox, la competencia, nuestros errores y sus aciertos.

Firefox 3

Tengo que reconocer que soy un cabeza dura. He sido usuario de Internet Explorer desde siempre. Nunca usé Netscape, nunca usé Opera ni Safari ni ningún otro, salvo ocasionalmente en algún cibercafé o en la computadora de algún conocido.

Los detractores más fanáticos de Microsoft se estarán preguntando ¿por qué? ¿nunca te aburriste de los cuelgues, la lentitud, los mensajes delirantes? Bueno, como dije al principio de este artículo, soy un cabeza dura.

La verdad es que a mí me interesa surfear la red, no ir probando todo lo que va saliendo por allí. Una vez que encuentro un programa que cubre mis modestas necesidades, ya no busco más. Y con esta excusa siempre me mantuve fiel al bendito IE a través de todas sus versiones.

Hasta que este fin de semana me harté. Esta es una pequeña reseña de cómo un producto de software puede perder a uno de sus más fieles usuarios.

La historia debe haber comenzado a principios de este año, sin que yo me diese cuenta. Imagínense que luego de una vida de fidelidad uno no se divorcia de un día para el otro. Todo comenzó cuando Google compró Writely y lo transformó en Google Docs.

Comencé utilizando Google Docs como un repositorio. Es decir, editando offline luego subir el archivo. Los retoques o actualizaciones posteriores, casi siempre muy acotadas, sí las hacía online.

Pero de un tiempo a esta parte comencé a crear mis documentos en Google Docs directamente online, atraído por las herramientas de colaboración, que son fantásticas. Si bien de vez en cuando se produce alguna que otra colgadura, la verdad es que jamás había perdido ni una sola letra o número...

... hasta hace un par de semanas. Lo que sigue no tiene ningún tipo de base científica o de investigación previa. Es mi pura percepción como simple usuario el hecho de que desde hace un par de semanas el IE comenzó a funcionar realmente mal con Google Docs. Si bien en un principio lo atribuí a problemas de lentitud en la conexión, luego me dí cuenta de que el proceso del IE comenzaba a "comerse" toda mi memoria, colgándose de vez en cuando varios segundos en alguna tarea que llevaba mi procesador al 100% sin ningún motivo.

Los problemas empeoraron cuando, hace una semana más o menos, comencé a utilizar Google Reader. Tendré apenas una veintena de blogs en mi lista (no sé si la cantidad tendrá alguna relación con todo esto), pero eso era suficiente para que el IE durmiese una pequeña siesta, "casualmente" (post hoc ergo propter hoc) antes de que el Reader actualizara algo.

Juro que tengo configurado "Iniciar cada ventana del IE en un proceso separado" (claro que desde la aparición de la funcionalidad de los tabs esto no tiene mucha injerencia, ya que no suelo abrir más de una ventana), pero el hecho es que primero en forma esporádica pero luego cada vez más frecuentemente las colgadas del IE tiraban abajo al explorador de Windows, cerrándome también otras ventanas (carpetas abiertas, otras páginas...).

Me encontré a mi mismo en la costumbre de cerrar el Google Reader para acceder a Google Docs y viceversa. Hasta que, como despertando de un sueño profundo, pensé "¿qué estoy haciendo? No debería acostumbrarme a esto. No hay razón por la cual no pueda tener dos o tres o 10 pestañas abiertas con páginas dinámicas de actualización frecuente si es que tengo ganas".

Me dí cuenta de que le estaba tolerando al IE una incomodidad que no le tolero ni a la aplicación web que estoy desarrollando en mi trabajo.

¿Por qué Firefox? Supongo que por lo del "download day" y todo el marketing alrededor de eso. También porque sé (no vivo en un zócalo) que es el segundo navegador más utilizado.

En resumen: Microsoft tiene mucho que aprender. En menos de 10 minutos tenía mi navegador instalado, paquete de idioma español, dos o tres plugins que me gustaron, el Google Toolbar... y todo con una naturalidad, velocidad y comodidad asombrosas.

¿Qué es lo que más me ha impresionado en estos primeros días de uso?

  1. La diferencia de velocidad es impresionante a simple vista.
  2. La no-intromisión en mi experiencia como navegante. Los ofrecimientos de descargas de plugins, advertencias y demás fueron siempre oportunos, y nunca me molestó dos veces con la misma cosa.
  3. Con respecto al IE, prácticamente todo está en el mismo lugar, sino mejor ubicado.
  4. Y para cada tarea del IE (por ejemplo descargar archivos) me encuentro con una mejora en su equivalente Firefox... que no es solamente un "chiche nuevo" sino que descubro que "esto era exactamente lo que necesitaba".

¿Qué rescato para mi trabajo como desarrollador de todo esto?

Creo que uno como usuario promedio no testea aplicaciones todo el día. Las usa. Y las seguirá usando a menos que se presente un problema, no importa qué tan bueno sea el producto de la competencia, no lo probará a menos que esté buscando una alternativa. Así que si tenemos la suerte de tener usuarios, lo mejor es no molestarlos.

Así que creo que no es el marketing el que hace la competencia nos robe clientes o usuarios. Son nuestros propios errores los que nos hacen perderlos.

Una vez desilusionado del producto que usa, uno es como un turista extranjero en la calle Florida. El cartel más grande es el que llama más la atención. Ahora sí el marketing es vital (pero recordemos que si nunca hubiésemos desilusionado al usuario esto no hubiese sucedido).

¿En qué se centró mi atención apenas comencé a utilizar el nuevo producto? Justamente en aquello que me había desilusionado del anterior. Ergo, hay que ser el mejor donde el competidor falla.

¿Y cómo fidelizo a los usuarios? Fácil. Volvemos al primer punto. Una vez que estén utilizando el sistema, éste debe ser lo más transparente posible. Invisible, si se pudiera. Nada de mensajes, actualizaciones, ofertas, preguntas inoportunas o ininteligibles (y mucho menos repetidas), ni nada que se le parezca.

¿Y cómo se recupera un cliente? Si me guío por mi propia experiencia, no lo sé, por eso es importante no perderlo. Si el Firefox me desilusiona probaré otro, pero dudo que vuelva a utilzar el IE.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

Las confusiones de ahora...

de Vagabundia, visto en Humor Geek.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

lunes, 28 de julio de 2008

Sobre el soporte del conocimiento

Acabo de leer esta entrada en navegapolis.net. Básicamente presenta dos tipos de jefes: orientados a resultados y orientados a personas, y dos tipos de trabajadores: los que ven al trabajo como una obligación a la que hay que acudir todos los días y los que lo ven como un medio de realización personal. Esto como un muy breve resumen, les recomiendo segur el link.

Me pareció muy interesante cómo se relaciona esa clasificación con el modo en el que la organización conserva o pretende conservar el conocimiento.

Si combinamos la "orientación a resultados" por parte de los jefes con la "obligación de acudir todos los días" por parte de los trabajadores, tenemos una organización en la cual el conocimiento está basado en el proceso. Lo asocié rápidamente con algunas las grandes consultoras de software, en las que los procesos están fuertemente establecidos y el trabajo es realizado por una pirámide de programadores, con base en los juniors y ápice en los seniors o arquitectos de software. En estas organizaciones un sólo programador senior podría coordinar gran cantidad de proyectos, estableciendo estructuras que luego serían rellenadas con código altamente estandarizado (o no, pero en todo caso encapsulado de tal manera que no pueda afectar al sistema en conjunto) por un ejército de programadores de menor experiencia.

Por un lado este esquema soporta una alta rotación (y de hecho la hay) y asegura continuidad más allá de las personas. Por el otro no se incentiva la creatividad, genera mayor dificultad para promover cambios y me imagino que el desarrollo debe ser necesariamente más lento que lo que comento a continuación.

En el otro extremo, si juntamos "orientación a las personas" por parte de los jefes y "realización personal" por parte de los trabajadores, podríamos suponer que el conocimiento está asentado en las personas. La imagen es la de un pequeño equipo de trabajo en el que las soluciones son discutidas entre iguales que defenderán sus puntos de vista de acuerdo a su experiencia, modo de trabajo y opiniones personales.

Este último esquema estará más afectado por la rotación, ya que si cambian las personas de alguna manera cambiará el proceso y el conocimiento. Definitivamente es un espacio propicio para la creatividad, los bruscos cambios de dirección y los desarrollos veloces. También es verdad que es un espacio propicio para la desprolijidad, las fallas de calidad, el descontrol, y que en este esquema pueden producirse tensiones que paralizarían al proyecto si el equipo no logra resolverlas.

Es obvio que, como dice el artículo, estas visiones de blanco/negro nos apartan de la realidad, que es mucho más gris y rica en posibilidades.

Si vamos al caso del desarrollo de software, es indudable que la "orientación a equipos" y el "conocimiento basado en las personas" ha ganado la batalla en el mundo real. El negocio del desarrollo se ha vuelto hostil hacia aquellas organizaciones de movimientos lentos, y las metodologías ágiles han propuesto soluciones efectivas para los problemas señalados (la rotación, las tensiones internas, etc.).

Sin embargo, ningún equipo puede sobrevivir si no tiene una estructura que lo soporte. Y creo que es en esta estructura de contención donde el conocimiento debería tender a basarse en los procesos. ¿A qué estructura me refiero? Pienso, por ejemplo, en las tareas de seguimiento del avance del proyecto, gestión de los cambios, versionado, instalación, seguimiento de incidencias, etc.

Cuanto más dinámico, cambiante e inestable se vuelve el desarrollo, más estables deberán ser estas estructuras.

Por ejemplo, si el negocio nos hace cambiar el rumbo frecuentemente, deberemos gestionar estos cambios con eficiencia. Si no lo hacemos llegará el momento en el que no podremos diferenciar "lo que el sistema hace" (supongamos que lo hace bien) de lo que "el sistema debe hacer" (que tal vez es otra cosa). Es el momento en el que ante una duda funcional (lo que debe hacer) se recurre al código (lo que hace).

Pero esta pretendida estabilidad no implica necesariamente trabajo monótono, repetitivo y estandarizado... no para los humanos por lo menos. Monótono, repetitivo y estandarizado es la definción de lo que un programa puede hacer. Para cada una de estas tareas de soporte existen herramientas.

En "mi mundo ideal" el equipo se dedica solamente a aquello en lo que no puede ser reemplazado por un programa: ver cambios en el negocio, diseñar, desarrollar. El conocimiento en una organización así está basado parte en el proceso (materializado en las herramientas de gestión, de diseño, versionado, instalación, etc.) y parte en las personas, un equipo motivado resolviendo nuevos problemas con creatividad (y todos felices y contentos).

¿Qué es más motivador: testear un sistema o diseñar tests automáticos?

¿Confeccionar y seguir una larga lista de pasos de instalación o desarrollar un instalador completo?

¿Actualizar un sinfín de documentos de diseño cada x meses o pensar un sistema que nos permita sugerir y debatir continuamente hasta llegar a una conclusión, llevando un registro de todo eso que todo podemos consultar en cualquier momento?

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

C# Coding Standards

En más de una entrada he insistido sobre lo importante que es la uniformidad en el estilo de codificación en un equipo.

Desde que empecé con C# utilicé C# Coding Standards for C#, by Lance Hunt (creo que alguien me pasó la referencia, lamento no poder darle el crédito correspondiente, mi memoria es pobre).

Tiene la ventaja de ser muy claro y compacto, cercano a todo el código que se ve en internet, y alineado con el formato que está configurado por defecto en el Visual Studio de Microsoft.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

viernes, 25 de julio de 2008

Desafío II

Nos hemos puesto a discutir aquí sobre una pantallita muy inocente que encierra una funcionalidad muuuy sutil de Windows XP. Tanto que hasta ahora pocos se dieron cuenta de cuál es.

¿Cuál es la "sutil funcionalidad" que deschava este print screen, que no está trucado ni nada por el estilo?

Respuestas a los comentarios, que modero y los libero al final. Abajo (el post anterior) tienen el "Desafío I", para el fin de semana.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

Desafío I

¿Cuál es la diferencia entre var1 y var2? No es broma, hay diferencia.

var1 se obtiene haciendo:

DateTime var1 = DateTime.Now.Date;

Y var2 se obtiene como:

DateTime fecha = DateTime.Now.Date;

DateTime var2 = new DateTime(fecha.Year, fecha.Month, fecha.Day);

Si creen tener la respuesta mándenla como comentario, que los modero y libero todos al final.

Actualización: corregido el error de tipeo en la ultima línea de código (es "new DateTime(fecha.Year...)" y no "new Date(fecha.Year...)" como decía antes. Gracias Nicolás por el aviso.

Es increíble la capacidad que tengo de meter errores de código hasta en el más trivial de los ejemplos. Imagínense lo que sufrí antes de que apareciera el IntelliSense.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

martes, 22 de julio de 2008

Simpleton (un post a cuatro manos)

Ya van un par de veces que diferentes amigos me cuentan de una entrevista de trabajo en la que se han visto enfrentados a interrogatorios casi policiales al estilo de los que siguen (con comentarios del que la vivió, que nos deleita con su sarcasmo):

¿Qué patrones de diseño utilizás habitualmente? ¿Qué GRASPs reconocés en este código? ¿Qué Microsoft Application Blocks conocés? ¿Cuáles utilizaste? ¿Conocés WPF, WCF?

-Uno piensa: "¿Te pagaron un cursito de Microsoft y querés demostrar que estabas prestando atención?"

Luego continúan preguntando por una lista interminable de productos de Microsoft, estándares, tecnologías... la chancha, los veinte y la máquina de hacer chorizos...

-De acuerdo, uno no está siempre en la cresta de la ola, pero no es necesario hacernos sentir unos buzos de profundidad.

Entonces uno se pone a pensar... ¿realmente utilizan todo eso? Están el horno... no quiero ver lo que son esos proyectos.

-...si es que existen proyectos ya implementados y funcionando con todas esas nuevas tecnologías.

-Me da la sensación de que en teoría son unas bestias avezadas, pero no sé si sabrán nadar en el caos de un sistema funcionando (sí, nadar, hoy estoy acuático).

-Ni hablar del caso de que tengan que hacerse cargo de un muerto (flotando, para el caso) con el código atravezado de heridas abiertas, cuando hay que resolver el asesinato para ayer porque la viuda (el dueño de la empresa y del barco) quiere cobrar el seguro de vida.

-Y aunque se implementen en distintos proyectos, luego hay que pensar en la rotación de personal: no todos los marineros saben remar con remos nuevos, y hay viejos piratas (como el dueño de éste blog) que programa mejor con su vieja brújula que cualquier nuevo almirantito con sus aparatos GPS.

Gracias por eso último... creo... encima que estoy perseguido con la edad...

Volviendo al tema de la entrevista, en vez de evaluar la capacidad para dirigir el barco, la experiencia piloteando en tormenta, la muñeca aceitada para dar un giro de timón sin que la nave zozobre preguntan si sabemos apretar los botoncitos del nuevo panel de comando.

Literal de la entrevista:

YO: - "Tá bien, pongo los application blocks, ¿y cuando fallen?"

EL: - "Son de Microsoft, están recontraprobados..."

YO: - "Lo mismo dicen de cada Windows que sale..."

EL: - "Pero tenes el código abierto, podés entrar, leerlo y tocarlo."

YO: - "Microsoft no programa como yo, no programa como vos, no programa como mi equipo o tu equipo. ¿Alguna vez probaste leer código de otro, sin saber qué reglas sigue para codificar?"

EL: - "Las reglas de Microsoft están escritas por toda la web."

YO: - "O sea que para arreglar un error (que no espero que ocurra, por lo tanto va a fallar cuando menos lo espere) tengo que además de leer el código de MS leerme toda la web para entender qué es lo que hace? ¿No es más fácil si lo hacemos nosotros y después lo corregimos nosotros, sabiendo cómo lo escribimos?"

EL: - (Sonrisita socarrona, pensando) "Este no tiene idea."

YO: - (Sonrisita socarrona, pensando) "Grumete con barquito nuevo, cuántas horas te quedás fuera de horario tratando de que el portaaviones funcione con aparatos que no hiciste ni conocés... aparatos que cuando quieras aprender en medio de la tormenta te van a hundir mientras pedís que te salve con mi barquito de madera. GIL."

Corolario: no estoy en contra de las nuevas tecnologías, pero no todo lo que sale es bueno. Podría nombrar COM, Atlas, DLL Hell, y muchas otras que prometían balas de plata, y quedaron en el camino. Sepamos discernir lo útil de lo novedoso, lo maduro de lo experimental... y seremos mas felices, aunque sigo buscando la manera de comprarme un yate.

Pero dejemos el sarcasmo de lado para analizar más fríamente la situación. Un par de aclaraciones:

No estoy muy de acuerdo con el estilo confrontativo en entrevistas de trabajo. Creo que es mejor tratar de mostrarse como uno es, y si no cuadramos con el tipo de proyecto, saludar con una sonrisa y hasta luego. Pero me encanta el sarcasmo, así que dejo esos afilados comentarios tal cual los recibo.

En principio dejo de lado por obvio el tema de las nuevas tecnologías. Hay que tenerles un ojo encima, pero cuidado con apurarse en la implementación, o en embarcarse habiendo probado sólo un "Hello World!". Concentrémonos en el tema patrones y bloques de código.

Está claro que tanto los patrones, guías de diseño, buenas prácticas, application blocks, librerías de clases, ejemplos, experiencias y demás son esenciales en nuestro trabajo, y que debemos conocerlos y aplicarlos... donde y cuando corresponde, y siempre teniendo en cuenta los objetivos reales del código que estamos creando.

Y es que muchas veces se pierde esto último en medio de una maraña teórica: el objetivo, el negocio. Y el hecho de que la mejor solución es siempre la más simple que lo satisface. Ojo, no la más rápida de implementar, sino la más simple.

Por dar un ejemplo: los application blocks. Están muy bien como referencia, para analizarlos, para tomarlos como ejemplo, para conocer todos los recovecos del lenguaje y del framework. Pero, dado que están enfocados a soluciones generales, a dar un ejemplo de perfección teórica, suelen ser demasiado complejos para cualquier proyecto que encima tendrá sus particularidades si es que busca diferenciarse de alguna manera.

Está bien utilizarlos siempre que los conozcamos en profundidad (no teóricamente, sino que conozcamos realmente bien el código) y que tomemos la precaución de encapsular la funcionalidad que nos ofrecen. Esto último es importante ya que de otra manera un factor externo como es la estructura de un application block condicionaría la estructura de nuestro propio proyecto, haciéndonos perder el control del mismo.

¿A qué me refiero con "control"? Es claro que lo perdemos cuando empezamos a dar respuestas del tipo "Hagamos esto de esta manera (mucho más complicada) para poder utilizar... [tal o cual pedazo de código que saqué de xxx]".

Son respuestas que en épocas de apuro se aceptan (todo vale), pero que no pueden convertirse en lo normal y cotidiano. Yo diría "salgamos con esto en esta versión y apenas esté en firme hacemos el refactory" (y lo hago, ojo). Porque puedo hacerlo una vez, pero si lo hago dos y tres y cuatro y no voy arreglando los "ajustes" (enchastres) termino, como decía antes, adoptando una gran estructura que vuelve demasiado complejo al desarrollo. O peor, varias estructuras diferentes, cada una enfocada a la utilización de tal o cual "code block".

El uso concurrente de todas esas herramientas y patrones en un sólo proyecto puede dar lugar a conocidos anti-patrones (ver la entrada Antipatrones de diseño):

Simpleton Pattern: Código extremadamente complejo para llevar a cabo la más simple y rutinaria de las tareas. Es una medida precisa de la habilidad de su creador.

Para más y mejor referencia, recurro una vez más a Guido van Rossum que con sus conocidísimos principios de diseño viene a aportar claridad al tema:

Simple es mejor que complejo.
Complejo es mejor que complicado.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es sencilla de explicar, puede que sea una buena idea.

Creo entonces que una interminable lista de tecnologías a utilizar en un proyecto dan buena cuenta de qué tan mal estructurado está, o de qué tan desesperados estarán sus responsables por conseguir un salvador que pueda meter mano en todo eso al mismo tiempo (y cuanto más complejo, más difícil conseguirlo).

La historia terminaría con nuestros entrevistadores deslumbrados por un postulante que los supera en capacidad para recordar siglas (e inventar significados para las que no conoce), al que intentan captar disfrazando el terrible desastre mencionado arriba como una juguetería llena de novedades brillantes... postulante que se suma al proyecto en calidad de "oráculo" sólo para demostrar una absoluta inoperancia, falta de experiencia y de sentido práctico.

A uno de los mejores programadores que conozco (no te pongas colorado) tengo que recordarle todos los santos días alguna tarea trivial en C#, que olvida tan rápido como aprende. Y me imagino que eso le pasa simplemente porque no está pensando en el código, en cómo se hacen las cosas, sino en qué es lo que hay que hacer.

Para decirlo claramente: las herramientas no son importantes. Lo importante no es el código (ni el nombre) de los application block, ni el código de ejemplo (ni el nombre) de los patrones. Lo importante es su estructura, que tomamos de base para buscar la más apropiada en cada caso particular sin perder nunca de vista el negocio para el cual estamos programando.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

sábado, 19 de julio de 2008

Nostálgico

Qué ha sido la informática / la computación / los sistemas en mi vida desde que tengo memoria hasta hoy. La verdad que puede estar medio incompleto, pero creo que ya es hora de dejar esto que comenzó como un post entre artículos y terminó comiéndose varias horas de mi vida. Tal vez (no creo) después siga.

El Atari 2600, mi primera y única consola de videojuegos. Nada que envidiarle a la WII, Xbox o esas chucherías que venden ahora. Todavía creo que esos joysticks son los mejores que jamás tuve. Me acuerdo del Moon Patrol, del Galaxy, del H.E.R.O., del Montezuma... (¡por favor abran ese link!).
La CZ1000, la primera computadora (calculadora grande diría yo) que toqué en mi vida. La tenía un amigo en la primaria.
La Atari 800XL, mi primera compu (snif...). Tuve dataset y luego diskettera.
Con esa máquina aprendí BASIC y LOGO. Eran todos dibujitos como éste, me aburrí en seguida, por supuesto. Pero en BASIC de Atari llegué a hacer un Póker que jugaba bastante bien.
ZX SpectrumCommodore 64Commodore 128
Otras home computers que tenían mis amigos, o en el instituto de computación.
Mucho, mucho después tuve mi primer clon: una PC XT. Tenía diskettera de 5 1/4, disco de 30Mb (hubiesen entrado más o menos 6 temas en mp3), monitor Hércules (monocromático), teclado y mouse.
Ni me acuerdo qué versión de DOS usaba. Wordstar, Lotus 1-2-3, Banner, News, Dbase III (¿o el Dbase vino después?)... Usaba el GWBASIC para programar. Aprendí COBOL, pero nunca hice nada serio con eso.
El primer juego del que tengo memoria en esa máquina es el Rick Dangerous. Pero recuerdo jugar al Monkey Island 1 en monocromático (¿puede ser o me falla la memoria?). Ocupaba 8 diskettes. Qué parto era cargar esos juegos con el ¡simcga! Siempre había un problema.
Llegué a ponerle un Windows 2.0... ¡y por fin a usar el mouse!
Después vino la AT 386. ¡Con monitor VGA! Después tuve una 486 DX4. Empecé a trabajar y me compré una Pentium MMX (la primera que me compré yo solito). Después la Pentium III. Después la Intel Pentium IV Hyper Threading (y obviamente quedó obsoleta en menos de 6 meses). De todas maneras es la que estoy usando ahora.
Indiana Jones And The Fate Of Atlantis Simcity Fifa
Y el Rick Dangerous 2, por supuesto. Me crucé con un jueguito simpático llamado Wolfstein 3D (pero era un poco aburrido, en realidad). Salió el DOOM y nos dimos cuenta de que el Wolfstein había marcado el comienzo de una era. Need For Speed, Simcity, FIFA, Monkey 2, Maniac Mansion, Alone In The Dark...
Duke Nuken Doom Rick Dangerous 2
Monitor VGA, SVGA, SVGA de 17, y finalmente recuperé mi escritorio: monitor lcd, cuánto espacio. Lo perdí rápidamente, ocupándolo con la basura que ahora me rodea.
Tenía Windows 3.11, y luego Windows 95, y luego 98 y 2000 y XP... y ahí me quedé. Probé Debian, Suse, Ubuntu...
En el trabajo usaba Clipper (Summer 87), y luego 5.0. Con eso compilé mi primer .exe. Me frustré tratando de usar FiveWin para crear una aplicación Windows. El paquete estándar Office era el 5.0, y con eso aprendí VBA, y logré mis primeros formularios y aplicaciones orientadas a eventos, que no eran más que macros de Excel y Access. La aplicación administrativa sobre la que trabajaba usaba tablas .DBF, con las que había que hacer infinidad de reportes. Las procesaba con Clipper y las levantaba en Excel juntando datos sumarizados en Access. Cambié de trabajo y de repente ¡era programador! Empecé con VB 4.0 y rápidamente pasé al 5.0, donde me quedé un largo, largo rato. ¿Objetos? Nah, formularios y eventos. Empezó la era internet para mí. ASP, Javascript, HTML, servidor SQL, luego PHP, XML, ASP .NET. Pasó otro largo rato. Cambié de trabajo y empecé .Net 2.0 con C#. Adiós VB, no hay vuelta atrás. De repente me enteré que era "Arquitecto". Bueno, suena importante, bienvenido sea. "Ajax". Aplicación web. Trabajo en equipo.
La red era una Novell 4.51 (no estoy seguro de la versión), en anillo con cable coaxial. Cada vez que se rompía un poco el cable había que ver por dónde y se caía toda la red. ¡Me dieron e-mail! No podía navegar, y no tenía con quién escribirme (salvo un par de amigos, a los que igualmente veía todos los días). ¿Cómo se llamaba ese servicio al que uno mandaba una URL y devolvía la página por mail? Me compré un modem. Un US Robotics de 56K. Bienvenido al infierno de las interrupciones (Plug and Play cambió nuestras vidas realmente, pero la convivencia con los jumpers fue un desastre). Me conectaba a un servicio pago de internet telefónica. Usaba el mIRC para chatear. Hice un montón de amigos con algo llamado ICQ que tenía todo el mundo. Saqué un Hotmail. Empecé a estar online en casa también, y ya nunca pude desconectarme. No tengo tele (nunca conecté la antena) pero si se cae Fibertel me pongo nervioso. Messenger. Puaj, prefiero el ICQ... ya nadie tiene ICQ :-( Apareció el GMAIL, y Google empezó a archivar mi vida. Puedo saber qué estaba haciendo el 23 de marzo del año 2005... pero no me interesa. De todas maneras, está muy bueno.

Salen cosas nuevas todos los días. Pero todas me parecen reediciones de cosas que ya conozco. Debo estar viejo.

Actualización: acabo de releer esto y emprolijarlo un poco. Realmente he hecho cosas inútiles en mi vida, pero ésta se las lleva todas... ¿saben lo que me costó acomodar esas imágenes?

Actualización 2: casi me olvido de dedicar esto a todos aquellos (una sola persona en realidad, sabe quien és) que lo hicieron posible manteniéndome despierto y pegado al teclado en horas delirantes.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

jueves, 17 de julio de 2008

The Geek Test

Parece que hoy no va ser un día muy productivo en este blog...

Este Geek Test es altamente adictivo. Lo bueno es que nos permite sugerir nuevas preguntas, así que pueden volver cada tanto.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

¿Cuántos elementos de HTML podés nombrar en 5 minutos?

Muy buen desafío, siguiendo por aquí. Luego les digo cómo me fue.

Vía Zurdito.com.ar.

Actualización (soy horrible para estas cosas):

45
Created by OnePlusYou

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

miércoles, 16 de julio de 2008

iPhone 3G

Ni me interesa, ni me gusta ni disgusta. No lo voy a comprar, no me van a dar uno gratis. No conozco a nadie que lo tenga (personalmente). Pero no quiero tener el único blog del planeta sin una entrada sobre el iPhone. Por favor sigan leyendo.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

Los primeros pasos (pero antes un poco de nostalgia).

La nostalgia

El otro día me cayó el viejazo. Uno de esos momentos en que algún manejo de fechas medio desprolijo devuelve un resultado que en principio sentimos como un "way out of range" pero que después se valida. Dicho en criollo caí en la cuenta de que hace cinco (!) años que estoy de ayudante en la facultad.

Eso disparó todo un hilo acerca de los problemas de acompañar a alguien en sus primeros (tirando a segundos, en realidad) pasos en la codificación, que es básicamente lo que hago. Y siguió hacia el recuerdo de mis propios primeros pasos frente a un ejercicio. Armado apenas con un par de instrucciones básicas que difícilmente sabía de memoria, logré determinar si un triángulo era isósceles, escaleno o equilátero a partir de la longitud de los lados, que ingresaba el usuario. Tenía... creo que 11 o 12 años (¡cuánto más sabe alguien de esa edad ahora!).

El hilo quedó dormido un rato y luego volvió en el tiempo hasta el recuerdo de las primeras veces que dí clase. Tenía un par de alumnos particulares (amigos y conocidos) a los que les daba clase de DOS, LOTUS, WORDSTAR (!), luego Windows, Office, etc. De esas experiencias queda una larga colección de CDs de música importados (¿qué más podía hacer con el dinero?) y sólo continúan las eternas clases de computación a mi señora madre, desafío que todavía no he superado (aunque parece que esta vez...).

Snif... bueh, a lo que importa.

Empecé a escribir esto cuando encontré algo en común en todas esas experiencias. Todas comenzaron con el mismo problema.

El escenario

Yo quería usar la computadora (Atari 800XL) para "guardar información" según recuerdo (creo que mi imagen mental venía a ser algo como ahora es internet), pero básicamente porque la tenía un compañero de la escuela y en su casa jugábamos juegos que eran mejores que los míos (yo tenía el Atari 2600).

Mis primeros alumnos particulares querían (dependiendo el caso) llevar una lista de videos, redactar cartas, contabilidad casera, contabilidad profesional, comunicarse con amigos, buscar información en internet, etc.

Mis alumnos de facultad quieren aprobar. Si aprenden, mejor.

El tema es que aprender a "usar la computadora", no es lo mismo que "aprender a llevar la contabilidad". Aprender a "usar la computadora" es más parecido a aprender a escribir:

Para aprender a escribir tenemos que saber hablar. Para aprender a usar una computadora tenemos que saber algo de aquello para lo que la vamos a usar. Para aprender a programar, por ejemplo, tenemos que saber resolver problemas mediante una serie de pasos sencillos.

Luego aprendemos una serie de símbolos que sirven para expresar aquello que ya sabemos decir. Aprendemos qué es una ventana, el cursor, un ícono, un botón, los sonidos, todas esas convenciones que nos resultan ahora tan naturales (pero que en algún momento aprendimos). En programación aprendemos un lenguaje.

Luego utilizamos esos símbolos para expresar lo que se nos ocurra y nos olvidamos de ellos. Ni siquiera los vemos, se vuelven transparentes (prueben concentrarse en la palabra "vaca" sin pensar en una vaca). Es cuando la secretaria sabe que para enviar la correspondencia a una lista va a usar la computadora. Tal vez no sabe ni qué programa debe utilizar y mucho menos cómo, pero mirando un poco lo va a encontrar, o si no lo buscará en internet y podrá entender la ayuda que encuentre. Es cuando utilizamos un lenguaje de programación para resolver problemas de negocio, pero ya casi no pensamos en la sintaxis o en el estilo sino que estamos concentrados en el negocio.

No hay nada más. Luego es práctica y perfeccionamiento infinito.

Ahora voy a mi experiencia como ayudante:

El primer paso ("aprender a hablar") ya está dado, es el conocimiento previo con el que viene el alumno.

El segundo ("aprender los símbolos") es trabajoso, a veces aburrido. Se trata de definir, de presentar, de buscar la mínima memorización necesaria para arrancar. La didáctica ayuda con reglas para expresarse claramente y exponer ordenadamente.

El verdadero desafío es el tercer paso ("expresar lo que se nos ocurra"). Es un "click" que con un poco de suerte se percibe claramente (¡en serio!). Digamos que el hito es el primer ejercicio que se resuelve bien sin ayuda. Cada persona es diferente y tiene mucho que ver con las tendencias personales. No todos dan este paso. Por lo menos en lo específico de la programación muy pocos lo hacen durante el curso (si siguen en la rama de la programación seguramente lo harán más adelante). Los que lo logran aprueban fácilmente con algo de práctica, los que no deben compensar con mayor esfuerzo, memorización y repetición.

Recuerdo mi eterna lucha en la secundaria: 10 en matemática, 4 en geografía. Nunca encontré lógica alguna en la geografía, siempre tuve que memorizar todo con muchísimo esfuerzo para aprobar con lo justo. Y claro que hay lógica en la geografía, sólo que no entra en mi cabeza. Matemática sólo practicaba para poder hacer rápido el parcial.

El problema

Retomando, hablaba de un problema. ¿Cuál es el problema? La ansiedad. La búsqueda del resultado, el exclusivo interés por el resultado.

Con respecto a mis primeros alumnos particulares, cada uno de ellos quería hacer algo específico (ej.:llevar la contabilidad) y sólo eso. No tiene nada de malo, pero me costó mucho entender que eso no era "aprender a usar la computadora" (ese lenguaje que les permitiría hacer cualquier cosa), sino simplemente utilizarla como una licuadora ("introduzca la fruta por la parte superior... fije la tapa... presione el botón...").

Es más difícil cuando lo que nos piden aprender es tan complejo que no puede ser memorizado de esa manera. Ejemplo: "solamente quiero usar internet"(!?). Es todo un desafío hacer que el alumno asuma este esfuerzo que a veces se percibe como excesivo en comparación con cada "necesidad" tomada individualmente. Es decir: parece demasiado hablar sobre cómo está armada internet para navegar por la web, pero la alternativa a eso es una serie interminable de instrucciones para la mensajería instantánea, el correo, el explorador, el p2p, cada uno de ellos en todas sus infinitas variaciones y productos. Haciendo hincapié en el lenguaje y con una orientación general, el resto está ahí, justamente, en internet.

Pero yo era chico, y no creo que me haya ido muy bien en eso.

En la facultad el equivalente es el pobre aspirante a analista funcional o gerente de sistemas que se siente tan perdido como yo me sentía en las clases de Dirección General. Nada se puede hacer por ellos salvo ayudarlos a pasar el examen práctico lo menos dolorosamente posible (esperando que por lo menos encuentren interesante la teoría).

Percibo una especie de actitud típica en estos alumnos, que es la de intentar memorizar estructuras o series de pasos mecánicos, "recetas", para resolver los problemas (aplicando tal vez la misma solución que yo al "zafar" geografía memorizando todo). Para ver bien lo dificultoso del intento, volvamos a la analogía con la escritura: ¿cómo puedo memorizar un método para trasladar lo que digo al papel? Por ejemplo: como hacen las computadoras, por fonética. Para un ser humano es casi impensable.

El problema de "lograr que asuman el esfuerzo" es, en este caso, un poco menor (al fin y al cabo la motivación está). Pero hay que empujarlos suavemente a dar aunque sea un primer paso por vencer la dificultad en ver la lógica general detrás de cada solución, más allá de que luego se memoricen ciertas estructuras con el sólo objetivo de aprobar.

El final, siempre abierto, siempre ambigüo

A modo de cierre: creo que, como siempre, el verdadero arte está en ubicarse en la situación e intentar que el alumno se lleve lo más relevante de acuerdo a sus propios objetivos, al tiempo que cumple con los mínimos estándares a los que obliga el título en aquellas áreas que no sean tan de su interés.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

martes, 15 de julio de 2008

Todo un ejemplo de bug tracking...

y de cómo deben analizarse y discutirse los cambios y mejoras a implementar en vistas a una nueva versión de un sistema en producción, en este caso de Ubuntu.

Meneado hace un rato.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

10 computadoras revolucionarias.

La gente de LiveScience hace una lista de las 10 computadoras revolucionarias desde 1822 hasta la actualidad.

Vía alt1040.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

lunes, 14 de julio de 2008

Los verdaderos programadores....

Mientras espero que se me caiga una idea de verdad, salgo de cacería por ahí:

Los programadores de verdad no necesitan comentarios — el código es obvio.

Los programadores de verdad no documentan. La documentación es para los idiotas que no pueden leer un volcado de memoria.

Los programadores de verdad pueden escribir bucles de 5 páginas sin confundirse.

Los programadores de verdad escriben su código en binario. O como mucho ensamblador.

Los programadores de verdad escriben código automodificable, especialmente si con ello consiguen ahorrar 20 nanosegundos en un bucle.

... la lista sigue en este post de nulleando. No se pierdan de seguir el link a "el verdadero macho argentino" que está al principio del post.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

Stripes

Me llamó la atención por lo simple y complicado a un tiempo. En esta página prueben arrastrar las bandas negras verticales sobre la figura de fondo.

Visto en Google Blogoscoped.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

viernes, 11 de julio de 2008

Control

"Cada vez que siento que tengo las cosas bajo control, sé que tengo un problema: no estoy en contacto con la realidad."

Xp2008, Katti Vilkki, Nokia Siemens Networks

Visto en Presión Blogosférica.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

miércoles, 9 de julio de 2008

Documentación

Primero lo primero: ¿de qué documentación estoy hablando? Tenemos diferentes tipos de documentos que cubren absolutamente todo lo que puede ser documentado: qué, quién, cómo, cuándo y por qué.

Quiero enfocarme en la documentación interna del equipo desarrollo, aquella que dice cómo se deben hacer las cosas. Documentación que debería responder, por ejemplo, a este tipo de preguntas: ¿cómo me conecto a una base de datos? ¿cómo hago una consulta? ¿cómo armo una pantalla? ¿cómo le presento los mensajes al usuario?

Si se pretende cierta unicidad entre diferentes módulos de un sistema o entre diferentes desarrollos de una misma empresa implementados por diferentes personas es indispensable un marco de trabajo, un framework propio que se montará sobre la herramienta de desarrollo que estemos utilizando. Este framework constará no sólo de herramientas de código (clases, interfaces y demás) sino de prácticas comunes para organizar proyectos, carpetas, nomeclatura, etc.

Ahora, una cosa es que este framework exista y otra el grado en que es efectivamente utilizado por los desarrolladores. Y esto dependerá en buena medida de la documentación que exista acerca del mismo. Por ejemplo, cuando un nuevo integrante se incorpora al equipo es indispensable poder entregarle un manual que detalle los estándares de estilo utilizados, las herramientas que puede y debe utilizar para llevar a cabo las tareas comunes, los estándares visuales de la interfaz del usuario. Una vez estudiados e internalizados estos documentos podrá comenzar a trabajar....

No, mentira.

Conozco (de oídas) de empresas en las que esta documentación existe. Incluso me han contado de casos en los que es frecuentemente actualizada (por ejemplo para cumplir con alguna norma o estándar certificado). Actualizados o no, los usos más frecuentes de este tipo de papeles son la elevación de monitores de plasma (¿vieron que en algunos modelos los soportes son demasiado bajos y no son ajustables?), la recolección de polvo, la decoración de bibliotecas y estanterías (quedan muy feas cuando están vacías) y otros por el estilo.

Cuando un nuevo integrante se suma al equipo, es usualmente depositado frente a una computadora y una pila de CD's de instalación. Ése es su primer día. A fin de evitar que quede atrapado en los brazos de morfeo se le entregará la documentación de la que hablaba en el párrafo anterior, si es que existe (usualmente con efectos opuestos a los que se prentendían). Si no existe y la gente no está muy ocupada, charlará un largo rato. Si la gente está ocupada... Consejo: no está de más llevar una revista el primer día. Con suerte podrá abrir el proyecto antes de irse a casa.

El segundo día lo verá enfrentado a un mar de código y (con suerte) una tarea entre manos. Si la documentación existe y ha sido leída, e incluso retenida, probablemente sea encontrada tan irrelevante como la tarea a desarrollar.

Pero las cosas funcionan, uno se desarrolla, aprende... el secreto está en la documentación. La verdadera documentación.

En algún momento, por obligación, lástima o caridad, alguien se acercará al nuevo integrante y le dará una visión general de lo que está viendo. Con eso podrá investigar un poco más en el código. Después de comer (charlando sobre la estructura del proyecto) se baja un poco más a detalle, siempre de palabra, "después lo ves en el código"... y así.

¿Qué pasa cuando no hay nadie que pueda llevar a cabo esa capacitación informal? Lo mismo, pero es mucho más lento. El nuevo integrante empezará a mirar primero la estructura general y bajará al detalle de a poco. O tal vez empiece buscando el lugar donde tiene que realizar su pequeña asignación y siga las ramificaciones desde ahí... las técnicas son tan variadas como las personas.

Pero... ¿de qué se trata este artículo? ¿documentación interna? ¿establecimos que no sirve? ¿listo?

Arriesgo una teoría. Lo que muchas veces sucede (recalco: por lo menos en mi personalísima experiencia) es que la documentación es requerida por alguien ajeno al equipo de desarrollo: el líder de proyecto, el gerente de sistemas, una norma, una metodología de trabajo (que nos dice "es necesario tal y tal y tal otro documento"), etc. En estos casos la documentación está obviamente orientada a cumplir con ese objetivo o requerimiento en el momento en que debe ser cumplido. Servirá para eso y nada más. Cuando intentamos utilizarla para otra cosa (por ejemplo para instruir "al nuevo") fracasa como fracasarían nuestros sistemas de facturación si intentáramos hacer que controlen los motores de un barco.

Si necesitamos tener documentación interna de referencia, tendremos que pensar en esa situación y crearla con ese único objetivo en mente. Recalco **necesitamos**. Como todos los sistemas, y la documentación ES un sistema, si no hay una necesidad real, jamás será utilizada. Si el equipo es estable y las incorporaciones esporádicas, será mucho más fácil capacitar al nuevo de palabra, y es lo que sucederá. Si el código es claro, de manera que en cada capa de la aplicación el código existente sirve de referencia para lo nuevo, tampoco habrá nada más que consultar, y así. Ahora, si en el equipo hay alta rotación habrá que bajar esa charla informal de la que hablábamos a papeles, o darla todos los días (cualquiera prefererirá lo primero). Si estamos trabajando en mantenimiento con mucho código heredado, enmarañado y confuso, será mejor que cada vez que descubramos alguna estructura o subsistema lo anotemos prolijamente en un documento aparte, porque volver a leerlo desde el código no será fácil.

Les aseguro que así es más fácil, e incluso entretenido documentar.

Ensayo una lista de "buenas prácticas informales":

  • La primera fuente de documentación interna es el código. La respuesta más frecuente a "¿cómo se hace tal cosa?" es "fijáte en tal lado y seguí la idea". Tratemos de documentar con el código o en el código.
  • Si hay que documentar tareas comunes, pocas palabras y muchos ejemplos extraídos de algún sistema.
  • Si hay que documentar estructuras de capas o flujo de ejecución a través de diferentes módulos, lo más sencillo de entender son los gráficos, con referencias a la ubicación en el proyecto del código correspondiente. Son molestos de hacer y mantener, es cierto. Pero relatar el proceso de impresión de un reporte desde la toma de parámetros hasta el deslpiegue del documento es mucho más difícil.
  • Ubicar la documentación donde se la necesita. Es muy común tener una enorme bolsa llamada "documentos" donde hay que revolver para encontrar algo. Si tengo un documento que explica el acceso a datos, ¿por qué no adjuntarlo al proyecto junto con el código de la capa de acceso a datos?
  • Tratar de que sea una tarea constante, no esporádica, que cualquiera pueda corregirla.
  • Versionar, todo.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

lunes, 7 de julio de 2008

División de tareas.

Clásicas, casi eternas discusiones entre programadores y analistas / líderes de proyecto. En este caso, responde el programador:

"Cada cual a lo suyo. Vos vení con problemas y yo te doy soluciones. Si me venís con soluciones, te voy a dar problemas."

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo