Diario de un Dotnetero

Ya van varias veces que veo esto ocurrir en diferentes proyectos y diferentes compañías, así que asumo que es algo relativamente común.

La historia casi siempre es la misma: se vende un proyecto grande a un cliente, quizá algo ajustado de tiempo, pero suficiente para hacerlo.  Se hace el análisis y se bosqueja el diseño rápidamente.  Se reparte la chamba y todos en el equipo se ponen a jalar: "Tú aviéntate este módulo, tú este y yo este otro".

Ves a uno de los desarrolladores involucrados en el proyecto todos los días en su esquinita, tecleando como hormiga.  Sabes que está chambeando (o al menos crees saber que está chambeando).  Cuando le preguntan:

—¿Qué rollo? ¿Cómo vas con eso?

—Bien—contesta sencillamente.  No se queja, no da detalles.  Así que asumes que todo va bien, ¿verdad?

Pasa una semana, quizá un mes o dos... tres meses, y de pronto esa persona comienza a enfermarse o a faltar misteriosamente y de buenas a primeras decide renunciar.  Para entonces ya estás a una semana de entregar el sistema que prometiste, y cuando comienzas revisar el código que el cuate hizo, te das cuenta que: 1) lo que hizo no funciona o 2) lo que hizo hace algo pero no era lo que se supone que tenía que hacer.  En otras palabras estás jodido en aprietos.

Entonces el proyecto entra en pánico.  Se oprime el botón rojo y comienzan a sonar alarmas.  Llamadas desesperadas.  Baja de unas cuerdas del techo un equipo S.W.A.T. de desarrolladores externos (o si no tienes pues con los mismos de tu equipo) y se junta a la raza en el war room para ver cómo canijos se puede hacer en una semana lo que un chango no hizo en 3 o 4 meses.  Todo mundo entra en overdrive codificando día, noche y fines de semana casi sin dormir.

Si tienes suerte, y gente MUY talentosa, igual y logras la meta.  Pero muchas veces no es suficiente.

¿Qué fue lo que pasó?  Acabas de ser víctima del SDC, o Síndrome del Desarrollador Callado.

Una de las cosas que a menudo hacemos al desarrollar software es que cuando el schedule anda apretado, lo primero que se hace es mandar a la goma las revisiones de código, las pruebas unitarias, etcétera.  Es decir, lo primero en sacrificarse en aras del calendario, normalmente son las buenas prácticas de desarrollo de software, que irónicamente son tu más valiosa herramienta para terminar a tiempo y con calidad. 

Lo que acaba ocurriendo es que si las sacrificas y tienes uno de esos desarrolladores con SDC, lo más probable es que esa persona no esté entendiendo los requerimientos y/o no tenga las habilidades para pasarlos a código y tiene demasiado temor de que se sepa.  Así que no pide ayuda, no se queja, no hace preguntas.  Simplemente se va a su esquinita y hace el intento.  Cuando va pasando el tiempo y se acerca el deadline (por algo trae dead la palabra) esa persona comienza a sentir la presión que a menudo se manifiesta en enfermedad/desaparición.

No me malinterpreten, conozco dos o tres desarrolladores excelentes, algo anti-sociales, que chambean en su cubículo/esquina, calladitos, enclaustrados una semana o dos y cuando emergen salen con una fregonería de código.  Pero son dos o tres de un montononal que conozco.

Lo peor es que la solución al SDC casi siempre es bien simple: hacer revisiones frecuentes del avance, no solo a lo que se ve (es decir, las pantallas, páginas, o lo que sea visible del sistema), sino a nivel código.  Cada semana (cuando MUCHO) juntar a otro desarrollador, y a un tester o persona que conozca los requerimientos: —A ver, vamos a ver cómo va esa pantalla.

No se trata de traer a la raza a latigazos, y tampoco se trata de hacer que la raza no le busque por su cuenta.  Se trata de no esperarse para descubrir las broncas cuando es demasiado tarde para hacer algo al respecto.  Sobre todo de que no se atasque el proyecto por cosas sencillas.  Yo, personalmente, si me atoro con algo (ya googulié, y ya lo intenté de dos o tres formas distintas) más de 3 o 4 horas y no puedo salir de ahí, inmediatamente agarro uno de mis compañeros y comienzo a explicarle el problema.  A veces con solo explicarlo se me viene una idea que resuelve el atorón, y cuando no, ellos me pueden dar ideas nuevas o enfoques que a mí no se me habían ocurrido.  Por muy chicho que creas ser, nunca faltan los días—o meses jejeje—en los que puedes caer en un lapsus brutus.

Así que si son uno de esos desarrolladores con SDC, por amor de Diosito, levanten la mano cuando se les atore la carreta.  No se esperen a que sea demasiado tarde.  Les prometo que nadie los va a morder.

Estaba leyendo este artículo hoy de Kathy Sierra y me llamó especialmente la atención uno de los últimos párrafos:

When people ask for the secret sauce guaranteed recipe for success, we say that it's quite simple: just do the "duh" thing. The Big Secret is not about knowing what magical thing to do--it's about taking the "duh" things seriously enough and actually doing them. If you could pick just one "duh" thing to work on, what would it be?

¿Qué demonios tiene que ver con el desarrollo de software?

Muchos de nosotros hemos oído de prácticas que son buenas para mejorar la calidad del software que producimos--metodologías de desarrollo ágil, técnicas para modelación y orientación a objetos, patrones de diseño o herramientas que nos pueden ayudar a automatizar y ser más pragmáticos. Para mi estos son "DUH!".

Pero ¿cuántos en realidad las ponemos en práctica? ¿Por qué no lo hacemos?

En el grupo de estudio me he estado topando con muchas personas que quieren aprender, o que quieren hacerse "expertos" en .NET y obtener su certificación. Pero pocos de ellos están dispuestos a invertir el tiempo necesario para practicar. Me parece increíble, pero es cierto. Muchos de ellos creen que el escuchar un mono hablarles de cierto tema o que con leer un libro , que ya con eso saben. Pero si los comienzas a poner a prueba, o si les haces preguntas recién que cerraron la portada del libro patinan de volada.

Creo que no que es suficiente con ser blog-junkie o podcast-junkie. No es suficiente que te chutes 1 o 2 libros al mes para aprender algo y llegar al siguiente nivel de expertise. Todo esto ciertamente ayuda--sobretodo a ampliar tu campo de visión y conocer cosas nuevas--pero al final del día, si quieres incrementar tu nivel en cierto lenguaje o tecnología pues no te queda más que sentarte un rato y tirar código o jugar con la tecnología que te interesa.

A menos que seas superdotado, no creo que puedas aprender a andar en bicicleta con leer un libro, no importa qué tan bueno sea.

Así que propongo el siguiente modelo que voy a tomar prestado de Mastery With Women de David DeAngelo, pero traducido para la raza que programa:

private void SerMaster()

{

    while (true)

    {

        EscogeLoQueQuieresAprender();

        Practicalo();

        AprendeDeLoQueHiciste();

        DecideCualEsElSiguientePasoEnTuEvolucion();

    }

}

Bueno, al final de todo creo que a mi también me salió un artículo "duh".

A ver si algo de esto les es familiar:

Chucho Melosetocho trabaja en ChidaSoft™, que ha sido contratada por Grupo Enorme (sin albur) para hacer un súper sistema porque Enorme trae pedos mayores con cómo maneja su proceso surtido de pedidos.

Grupo Enorme se dedica a hacer Chuchulucos® de todos tipos, tamaños, sabores y colores. De hecho es la empresa más grande de chuchulucos en el país. Pero últimamente, han crecido tanto que sus problemas son evidentes: cuando un cliente les hace un pedido, tardan hasta un mes en surtirlo y por lo mismo, están perdiendo terreno a la competencia, LosQueremosClientes LosQueremos, S.A. de D.R. y R.L. (o sea Sociedad Anónima de Dudosa Reputación y Responsabilidad aún más Limitada).

Así que los jefazos de Enorme se juntaron y decidieron que lo que necesitaban era automatizar todo el “proceso” de distribución, cobranza y pagos. Ellos esperan que un sistema les ahorre hasta un 25% en los costos y un 50% en el tiempo de entrega, según un estudio que hizo su departamento de “IT”—Ingenieros Tarados—y por eso contrataron a ChidaSoft™, quien sin pensarla mucho dice “pan comido” y manda al pobre de Chucho a intentar tomar requerimientos y hacer el análisis del sistema.

Pero Chucho se topa inmediatamente con problemas: la mera-mera de Finanzas, una C.P.—Cabeza de Pollo, digo, ejem… Contadora Pública—con lógica y cabeza cuadrada, se la pasa del chongo con los del almacén porque surten los pedidos de los clientes, aún cuando éstos tienen pagos atrasados; el del almacén se la pasa de la greña con los de producción porque no le entregan las cosas a tiempo y los clientes les gritan cada vez más feo porque están adictos a los Chuchulucos® y sus pedidos no están listos; y el de producción le echa la balona a los de compras que no le tienen la materia prima que necesita a tiempo… en fin… cualquier parecido a la realidad es a propósito.

Así que temeroso de perder su chamba y quedarse sin dinero para ir a teibolear, Chucho entrevista a los jefes de cada departamento por separado para ver qué es lo que necesitan que el sistema haga—intentó en un principio juntarlos a todos para que se pusieran de acuerdo pero las juntas terminaban siempre en insultos, malas palabras, sillas arrojadas y sacadas de lengua.

Cada uno de los jefazos le dice cómo se hacen las cosas en la empresa y le da una larga lista de navidad de lo que quieren que haga el sistema y de pero muchas cosas se contradicen: es evidente que nadie conoce “el proceso” y algunos no parecen saber ni a qué $#¡|\|&@dos se dedica en realidad la empresa.

Después de meses y meses de juntas por teléfono y andar conciliando requerimientos finalmente logra hacer sus diagramitas de casos de uso, sus escenarios de los casos, diagramas lógicos y todo lo demás que dicta el UML y las metodologías de desarrollo de software moderno. Se avienta una documentación clara y precisa que le pasa a al equipo de desarrollo quien con diligencia y un control de calidad estricto tira un código hermoso y elegante.

Pero Enorme no está contento. El proyecto tardó y costó casi el doble de lo que habían previsto y al correr el piloto se dan cuenta que solo ahorrarán un 10% en el costo y tiempo sobre el esquema anterior. Comienzan los gritos, los insultos y las amenazas de no pagarle a ChidaSoft™, y a pesar de que el sistema se apega a los requerimientos que todos los jefes firmaron. Enorme insiste que el sistema “no es lo que pedimos, no nos está ahorrando el dinero que estipulamos cuando los contratamos así que no les vamos a pagar”.

Abrumado y cabizbajo, Chucho visita a su Sensei, quien después de reírse descaradamente de él le dice: —Saltamontes, has olvilalo la legla del flujo: “si fluye algo le trabajo debes consilelal wolkflow, pelo si el tlabajo fluye lejos debes usal wolkflow”.

Y Sensei le presta su copia de Workflow Modeling: Tools for Process Improvement and Application Development (Alec Sharp y Patrick McDermott, Artech House © 2001).

¿Qué significa todo esto?

En mucho más de una ocasión me ha tocado hacer o mantener un sistema, y que de pronto me hable Fulanito de Tal, del departamento X para que le explique cómo funciona algo o qué se hace con cierto pedazo de información, o para pedir un cambio al sistema del cual se va a arrepentir luego de explicarle que el hacerlo impactaría otra cosa de otro departamento.

En pocas palabras, nosotros, las “personas de sistemas” algunas veces, en sabemos más del “proceso” que las mismas áreas de negocio. Y me pregunto: “¿Cómo es esto posible?”

Parte de la evolución de las empresas en los últimos 10 o 15 años ha sido el reconocimiento de que deben estar orientadas a los procesos de negocios—¿recuerdan todo el ruido que causaron “mejora continua” y “reingeniería de procesos”?

Esto es, la especialización en las empresas ha llevado a que cada departamento se preocupe tanto por eficientizar sus “procesos”, que en muchas ocasiones pierden de vista el “proceso global”: lo que la empresa realmente de dedica.

Dado que el flujo de trabajo (workflow) no es más que una abstracción de los procesos de negocio—el cual se formalizará típicamente en un sistema computacional—es muy importante saber analizar bien cómo fluye el trabajo antes de hacer la definición, análisis o diseño por tres grandes razones:

1. Para que todas áreas o personas involucradas sepan qué están haciendo en realidad—cómo está funcionando su empresa—y qué se puede mejorar;
2. No repetir simplemente cómo se hacen las cosas y/o formalizar en una aplicación actividades que no agregan valor (“no hay que pavimentar los caminos de las vacas”, o la clásica replicación ciega de procesos en papel); y
3. Determinar si en realidad hay algo que se pueda mejorar/ahorrar con un sistema, o si un simple cambio en las actividades del negocio es suficiente. Si se determina que sí agrega valor un sistema, entonces automáticamente ya se tendrán los requerimientos o características deseadas en él.

Sharp y McDermott proponen un famework como el siguiente:

Estas técnicas también sirven cuando se está considerando implementar un sistema “Enterprise”—SAP, PeopleSoft, Siebel, etc.—que cuestan un lanototota. Muchas empresas los compran pensando que así recién sacaditos de la caja van a resolver sus problemas como por arte de magia, solo para descubrir—decenas o cientos de miles de dólares más tarde—que para que en verdad les sirva tienen que adaptarlos a la manera particular en la que trabajan en la empresa, lo cual lleva a que contraten gente para que les personalice el sistema hasta el punto en el que se dan cuenta que uno hecho a la medida les hubiera salido más barato desde un principio. Todo porque no comprendían su propio workflow desde un inicio.

Lo “malo” es que aprender a modelar workflow requiere un poco de habilidades de administración de empresas o incluso ingeniería industrial—¡guácala!—pero afortunadamente en dosis no-letales. Así que los ingenieros de sistemas estamos en una posición óptima para en verdad aportar valor a una empresa cuando surgen proyectos de este tipo.

La herramienta por excelencia en este tipo de modelación son los swimlane diagrams (¿diagramas de canales? maldita traducción), los cuales son distintos a los que se manejan, por ejemplo en UML o en análisis estructurado. Quizá ya los hayan visto, no son más que diagramas de flujo puestos contra un fondo de canaletas, donde cada canaleta representa el área de acción de un Actor.

Pero leer estos diagramas es mucho más sencillo que hacerlos, así que hablemos un poco del proceso para poder llegar a desarrollarlos.

El proceso para analizar, modelar y mejorar procesos

Según Sharp y McDermott:

1. Encuadrar y definir el proceso
1. Identificar un proceso de negocios y clarificar sus límites
2. Hacer una evaluación inicial con todos los interesados
3. Establecer las metas del proceso rediseñado
2. Comprender el proceso actual (“as-is”)
1. Modelar la manera en que fluye el trabajo (workflow)
2. Hacer una evaluación más profunda tomando en cuenta los 6 “habilitadores” de un proceso de negocios: diseño de workflow, tecnología de información, motivación y medidas, recursos humanos, políticas y reglas, instalaciones y ambiente de trabajo
3. Diseñar el proceso nuevo (“to-be”)
1. Ingeniar las mejoras potenciales
2. Evaluarlas de acuerdo a los 6 habilitadores
3. Seleccionar las características principales deseadas del nuevo proceso
4. Diseñar el nuevo workflow
4. Desarrollar casos de uso y escenarios de uso—hacer la transición hacia análisis de requerimientos de sistema describiendo cómo los actores interactuarían con el sistema para realizar sus actividades.

No voy a profundizar en cada uno de los pasos, para eso les recomiendo el libro, el cual trae muchísimos “tips” basados en casos y ejemplos de la vida real, así como un montón preguntas que se deben hacer durante todo el proceso.

Mi intención, en los siguientes posts será enlazar el concepto de workflow con algunas de las herramientas de que conozco o que van a salir, especialmente Windows Workflow Foundation, que será parte de WinFX. Así que estén pendientes...

En alguna ocasión, un amigo y yo vimos en el instructivo de un CD-ROM la siguiente traducción:

“Si se atora la charola porta-CD, inserte la varilla metálica en el orificio de eyaculación de emergencia”.

El texto original en inglés, decía algo así como esto:

“If the CD tray is stuck, insert a metal paper clip in the emergency ejection hole.”

Es por este tipo de cosas que soy enemigo de los libros técnicos en español—los que tratan de cosas de tecnología, sistemas, desarrollo de software o programación.

Definitivamente no es por ser malinchista, pero creo que es necesario reconocer que si trabajamos con herramientas, lenguajes y conceptos que principalmente están siendo generados en inglés, pues hace perfecto sentido procurar manejarlos en el lenguaje original. Además, el inglés—para bien o para mal—se ha convertido también en el lenguaje global de negocios.*

Las palabras son solo símbolos

En mi experiencia, los libros técnicos en español tienen dos grandes desventajas: (1) para cuando los traducen ya están casi obsoletos, y (2) las traducciones, por respetar un español correcto a veces pueden distorsionar los significados.

Aún recuerdo algunos pasajes de los libros de redes de Tanenbaum que hablaban de los octetos, los megaoctetos y los hostales. —¿Qué jodidos? ¡Ahhhh! bytes, megabytes y hosts.

O una versión de Windows en español, donde tenía que configurar la “pasarela por omisión” para poder utilizar la conexión de red. —¿Guat? ¡Oh! El default gateway.

O el intentar encontrar el “entusiasta del CPU” (CPU fan). * Suspiro *

Las palabras, en cualquier idioma son solo símbolos para representar un concepto. Pero una vez que el cerebro hace la asociación entre el símbolo y el concepto, es difícil re-programarlo, así que procuro asociar los símbolos correctos desde la primera vez.

La generación de símbolos y conceptos nuevos en el área de tecnología y sistemas es muy rápida, y es difícil—hasta impráctico—que el ritmo de cambios en el español esté a la par. Hace 1 o 2 años, ¿cuántas personas sabían lo que era un blog o los Web Services?

También procuro aplicar la creencia de solo-inglés a la hora de escribir código. Mis clases, variables, propiedades, etcétera, están en inglés. La razón es muy concreta: si el lenguaje de programación está en inglés—especialmente en uno tan verboso como Visual Basic—me causa menos disonancia cognitiva porque todo está en el mismo idioma: los keywords, las declaraciones, y mi código.

“¡Aaargh! ¿Qué es eso de ‘keyword’? Ya comenzaste con los anglicismos. Si vas a escribir en español hazlo bien,” me diría probablemente mi ex profesor de Lectura y Redacción, quien me enseñó que “el español es el lenguaje para hablar con Dios”. **

Pues sí, pero el inglés es el lenguaje para hablar con los desarrolladores de software, así que aunque estoy enamorado de mi idioma, lo más práctico para mi es no mezclarlos en código, pero sí mezclarlos en redacción general.

Prefiero esto:

Quizá tanga o no tenga sentido, de acuerdo al contexto. En el área donde vivo—la frontera entre México y los EE. UU.—esto funciona muy bien. En otras áreas quizá no.

En fin, si saben lo que están haciendo y lo hacen conscientemente, pues ser pocho es cool.

* Cultura general: las cosas no siempre fueron así. Hace uno o dos siglos el lenguaje de negocios mundialmente predominante era el francés.

** Esto viene de una cita antigua que en algún momento me contó. No recuerdo el autor, pero decía algo como esto: “Si quieres hablar de negocios, usa el francés. Si quieres hablar con tu caballo, usa el alemán. Si quieres conquistar una mujer, el portugués. Pero si quieres hablar con Dios, usa el español”.

Me gusta leer otros blogs, y poner enlaces a ellos. Quizá esto lo vean como que me dio demasiada flojera tirar rollo sobre algo, pero en realidad hay veces que me topo con otras personas que dicen las cosas de una forma mucho más concisa y elocuente que yo. Últimamente me he hecho fanático de Christopher Hawkins, quien con su blog, Effective Software Development, habla sobre temas del proceso de desarrollo de software desde el punto de vista de un Project Manager. Comparto muchos de sus puntos de vista, así que les doy una probadita (sin albur) del rollo que él tira con los siguientes 4 artículos de él que me parecen esenciales:

• 11 Clients You Need To Fire Right Now. Habla sobre 11 tipos de clientes latosos con los cuales te conviene mejor no hacer negocios--o de plano cortar los que ya tienes. En resumen: clientes con los cuales te sale más caro el caldo que las albóndigas. Entre ellos están "el todo-por-nada", "el desilusionado", "el sospechoso", "el flake" (intraducible esa jerga, creo yo), "el hoyo de dinero" etcétera. Léanlo, y si se topan con alguno con el que hacen negocio ahorita no creo que sea coincidencia.
• En I Am Not In The Software Business, Christopher dice algo que he dicho por mucho tiempo: no estamos en el negocio de hacer software, estamos en el negocio de dar soluciones.
• The 5 Pitfalls Of Estimating A Software Project debería ser lectura requerida para cualquier PM que traiga proyectos de software. Entre las 5 cosas que hay que evitar: que estimen personas no-técnicas que no estarán involucradas en satisfacer los requerimientos, el no realizar revisiones post-mortem de los estimados, tratar de estimar sin tener requerimientos claros.
• Y finalmente, Why Your Schedule Is No Good - And How to Fix It, probablemente sea una respuesta al manejo de proyectos a la mexicana, que mencionó el Tocayo hace poco. "¿Saben por qué nadie en la compañía se toma sus días de vacaciones? Porque nadie programa los proyectos adecuadamente. [...] ¿Saben por qué nadie se toma sus días de enfermedad y trabajan enfermos? Porque nadie programa los proyectos adecuadamente. [...] ¿Saben por qué las personas no se toman sus días festivos de ley? ¿Por qué se tienen que quedar tarde? Porque nadie... " bueno, ya tienen la idea, ¿no?

OK, quizá escribir software no sea como escribir ficción. Quizá es más parecido a escribir un ensayo o un editorial, en donde quieres lograr algo específico y concreto, en lugar de postear sin sentido en tu blog como un lunático. Pero los principios son los mismos:

1. Al inicio solo tienes una idea abstracta o peor aún, solo un feeling de lo que quieres decir y/o cómo lograrlo.
2. Hasta que no te sientas a escribirlo, no desarrollas en realidad la idea de lo que quieres decir.
3. Deberías emplear 2 modos mentales: el creativo y el censor. A veces se nos olvida el segundo y algunos programillas no son mas que “primeros borradores” de lo que pudieron ser.
4. Alguien siempre debería revisar las idioteces que se te ocurren antes de publicarlas. Luego escribes 2 páginas de cosas en tu blog cuando las pudiste decir en media. Lo mismo pasa con el código.

Desde hace rato noté una analogía en el proceso mental que se sigue para escribir ficción—cuentos cortos o novelas—y el proceso que se sigue para escribir software.

Creo fervientemente que el crear software es mitad arte y mitad ciencia, favoreciendo fuertemente al arte.

Algunos de los mejores codificadores que conozco tienen bastante de bohemio. Les piden un sistema o un requerimiento, y pasa una semana… dos semanas quizá y los ves sin hacer nada, tranquilos como si ponderaran la cantidad de hojuelas que trae la caja de Corn Flakes que se comieron en la mañana… Se echan un café o una chela—dependiendo de la hora del día—y ponderan otro rato más. De pronto, en una sentada de 1 o 2 horas se sueltan vomitando código que a un mortal le parecería inicialmente indescifrable, pero al inspeccionarlo de cerca resulta ser compacto, eficiente y genial.

Sin embargo, la mayoría de nosotros—creo—no somos así, más bien somos como los escritores normales, que tienen que aprender semi-sistemáticamente a evolucionar sus ideas.

Así que ahí les va un cuento y les dejo a ustedes sacar las similitudes. Cualquier coincidencia con cómo se desarrolla—o debería desarrollarse—el software no es mera coincidencia.

Las aventuras de Pito Pérez

Pito Pérez es un joven—ni tan joven—de treinta y tres, chaparro, medio regordete, prieto pa’ acabarla, ah pero eso sí, muy hábil con las viejas. Tiene aspiraciones de escritor, pero en realidad trabaja para el Municipio en el departamento de tránsito entregando placas, porque es el único lugar donde le sirve su título de Licenciado en Filosofía y Letras de la Universidad Técnica Regional del Norte del Tercer Mundo.

Un día se le ocurre la genial idea de convertir sus aventuras teiboleras en un cuento corto. En uno de los alucines que tuvo se imaginó que las señoritas que bailaban en esos establecimientos eran literalmente de otro planeta: con solo una sonrisa y una enseñadita de nalgas, convertían a los hombres débiles (osea el 99% de ellos) en zombies descerebrados de quijada abierta que obedecían ciegamente a sus comandos, les daban todo su dinero y hacían únicamente lo que ellas querían.

Claro que también habría en la historia un héroe—basado en él por supuesto—que era inmune a las emanaciones feromónicas de la raza de viejas extra-pechugonas extra-terrestres que amenazaban con dominar el mundo.

“Esa es la trama, a grandes rasgos”, pensó él, aunque en realidad no tenía ni puta idea de exactamente qué quería ni a dónde iría con la historia.

Con voz de anunciador de la serie viejita de Batman en su cabeza se escucha:

“¿Serán suficientes para nuestro héroe las katas mágicas que le aprendió al David DeAngelo en persona? ¿Logrará nuestro héroe dominar esta amenaza a la civilización, salvar al planeta y hacerse de un súper-harem? No se pierdan el próximo capítulo de Las Aventuras del Gran Pit…, ¡ah caray! Como que no es bueno ese título, ¿verdad?”.

En fin, ya en pleno trance creativo se sienta a escribir la historia. “Lo más importante para escribir una historia es sentarse a escribirla”, le enseñó su profesor de la facultad de artes y ciencias políticas.

Y después de 10 páginas de prosa sin censura, sin siquiera revisar la ortografía, saca un primer borrador. Como le enseñaron en la Uni, cambia su “cachucha de escritor” por la “cachucha de revisor” y comienza a disectar la historia, con la agudeza de un cirujano plástico. Se da cuenta que el primer borrador apesta, gacho. Pero está bien, porque como le dijo su profe de ficción, “un primer borrador debe ser malo”.

Dos días después, acaba de cortar la mitad de la paja a la historia, de re-escribir párrafos enteros y de reacomodar la trama y el cierre para dar un efecto más dramático, aunque se parezca a la película del Sexto Sentido. Y contento y feliz con su gran obra maestra la manda a la revista TVyNovelas para ver si la publican. “Digo si publican las hazañas de la Gloria Trevi, seguramente les interesará mi historia, y si no, se las mando a los de Reader’s Digest ¿no?”.

Unas 2 semanas después recibe una carta del editor de TVyNovelas diciéndole que le encantaría publicar su cuento, pero que ve “áreas de oportunidad”:javascript:void(0) Publish Post

“Estimado Sr. Pérez: bla blah bla, bla blah… nos interesó su historia… bla blah blah … Si logra bajarle otras 2 páginas y se deshace del personaje mamilas del DJ chilango que se la pasa haciendo ridiculeces, entonces tendrá una historia que estaríamos orgullosos de publicar.”

“¿Deshacerme del Frank? ¿Qué están locos? ¡Piden a un artista cambiar su arte, jamás!”

Pero después de humear 3 días sintiéndose el regalo de Dios a la literatura castellana—después de Octavio Paz, claro—le gana la ambición del reconocimiento y el deseo de que su cuento sea publicado. Hace las modificaciones solicitadas por el editor y se da cuenta que en realidad sí quedó una mejor historia.