¿Quieres publicar en la IEEE? ¿o en cualquier revista académica?

Gracias al blog de Lucas Ontivero, leo esta graciosa nota:

Muy gracioso, sigue siendo 1+1 = 2 (que nunca = depende como dirían los abogados) pero ahora queda mejor pues es mas difícil de entender, y es que esa es la realidad concreta en las publicaciones de la IEEE y lo digo por experiencia.

Estuve afiliado a la IEEE con membrecía en la Computer Asociation, por lo cual recibía las revistas Spectrum y Computer, era un plan interesante, pues la nomina anual no me costaba tanto al ser (entonces) egresado reciente, pero la verdad sea dicha el nivel de abstracción de la mayoría de los artículos de Computer era demasiado lo cual lo hacia poco practico dedicarle tiempo.

Claro, se me dirá que una revista así de por si es complicada, pero no, no era eso sino que deliberadamente usaban un lenguaje árido en la mayoría de los casos, lo cual contrastaba con p. ej. Software Development Magazine, una revista dedicada a metodologías y practicas para el desarrollo de software, en la cual se notaba que los autores estaban de veras interesados en que los lectores se hicieran con los conceptos planteados, y claro si bien no era un tema para el publico general, al menos había la intención de exponer los contenidos de manera razonablemente simple (pero no mas simple) y hasta amena. (*)

En algún momento sospeche que era practica deliberada de las revistas académicas (pues a pesar de definirse como asociación profesional, el enfoque tendía mas hacia el lado académico), lo cual me quedo corroborado cuando una amiga me dijo que parte de los requisitos para publicar papers en ciertas instituciones era escribir de tal manera que la idea fuera difícil de seguir ya no por graduados profesionales, sino aun por graduados de master, pues de esta manera se lograría que el debate solo sea seguido por cierta clase de publico, iniciado en ese metalenguaje y ese estilo.

Entonces, la pregunta que nos debemos hacer es si ¿el conocimiento debe tener barreras de comprensión mas allá de su propia dificultad intrínseca?, ¿se justifica ese hablar “en difícil” a fin de acotar tu auditorio y que el debate solo sea entre los elegidos?, ¿será que en el fondo son como Sheldon Cooper rechazando la divulgación y popularización del conocimiento?(**).

Parte de la razón puede estar en al naturaleza no-democratica de la ciencia, si, pues como es sabido para establecer algo como “ley” (en teoría) no es necesario consenso ni votaciones, sino demostrar de manera repetible y verificable lo que se esta planteando, el problema es que (creo) eso lleva algo que Miguel Angel Sabadell comento hace tiempo en Muy Interesante, de que la comunidad científica espera apoyo de la sociedad (y el estado) para sus actividades, pero no esta dispuesta a que esta tenga injerencias sobre el rumbo que deban seguir sus investigaciones, puesto que si la sociedad interviniera en lo que se debe investigar se dedicaría mas tiempo en cosas menos “glamorosas” como mejorar los sistemas de calefacción y ventilación de las casas.

Así que en parte se puede explicar esa ´tendencia casi natural a querer volver el conocimiento como coto de caza privado a cargo de la elite intelectual.

 

(*) En honor a la verdad debo reconocer que fue en Computer donde tuve conocimiento por primera vez de lo que eran las metodologías agiles, ya que excepcionalmente los autores se preocuparon por ser lo suficientemente claros para plantear esa idea (entonces) novedosa.

(**) Aunque en honor a la verdad su adorado Richard Feynman era un conferencista bastante claro y ameno.

Cuando toca levantar la mano

En el entorno industrial existe la clásica pelea entre el área de ventas y el área de producción: “No están cumpliendo con el plazo que le hemos ofrecido al cliente” “Los de ventas ponen plazos y metas imposibles”, dilema que casi sin variantes se traslada al desarrollo de software, y muchas veces creemos que es un callejón sin salida, pero escarbar un poco lo que paso podría ayudarnos a reducir esta clase de situaciones.
Parte del problema viene de la teoría de “si a los programadores les damos la especificación bien detallada, las cosas saldrá en tiempo y reduciremos problemas” , pero claro, por mas que se  detalle, al momento de construir pasan cosas y vemos que esta idea no es tan simple como parece, y si le añades conceptos como “pool de programadores”… desastre garantizado, en ese sentido es conveniente citar a lo que afirma Rodrigo Corral:

Habitualmente, la réplica suele ser del estilo: "eh!!! Pero si el desarrollador solo tiene que ‘poner ladrillos’ nuestros analistas se lo darán mascado’. Y nos aseguramos de tener los mejores analistas y seleccionar los adecuados’. Cualquiera que haya trabajado con este modelo sabe que no hay nada más difícil que implementar un diseño de otro, sobre todo si eres un desarrollador novel, como suele ser el caso. Las trabas de comunicación y los miles de detalles que hay que especificar hacen que no sea rentable hacer un diseño tan detallado como para que solo haya que ‘poner ladrillos’. Que nadie entienda con esto que creo que no es necesario el análisis y el diseño o los analistas, pero su labor es otra, su labor es la de establecer patrones, marcar pautas claras, escribir código especialmente sensible, vigilar la calidad del código, según la metodología asignar tareas a otros desarrolladores etc… Pero creo que no es productivo que el analista solo diseñe. Hay tantas decisiones que tomar en cada línea código escrita…

Pude comprobar en carne propia cuando tuve mi primera responsabilidad de gestión técnica, el equipo de análisis nos había dejado especificaciones bien detalladas sobre la funcionalidad de las pantallas a desarrollar, y así emprendimos el camino con mi equipo de programadores, el problema llego cuando nos topamos con dos pantallas en que no nos poníamos de acuerdo sobre como implementar el flujo de acciones de usuario, así que las conversaciones fueron a mas con la analista, resultando que al final llego una contraorden, las 2 pantallas se cancelaban (teniendo que tirar todo el trabajo avanzado) y se reemplazaban por una completamente nueva, mas aun siendo que había dudas sobre lo escrito en la (nueva y detallada) especificación hubo que dedicarle tiempo de conversación de lado a lado con la analista. Así que en este caso bien podríamos haber intentado ajustarnos a la especificación y entregar “algo” que evidentemente luego seria rehecho, pero no, nos correspondía avisar que esa especificación no era consistente y alertar a tiempo (es mas, visto en retrospectiva debimos avisar días antes).

La misma sensación la tuve hace unos meses cuando en una sesión de planeamiento, la Analista/Product Owner propuso un cambio de funcionalidad que entre otras cosas involucraba hacer severos ajustes a la integridad referencial de algunas tablas, el equipo estaba dispuesto a acometer la tarea, pero preferí indicar que los cambios tenían potenciales consecuencias que debían determinarse por anticipado, por lo que cancele la sesión de planeamiento y nos derivamos a una sesión de brainstorming para ir cubriendo las posibles implicancias, para de esta manera ofrecer dos alternativas, con sus pros y sus contras. Para la siguiente semana con ese documento y el apoyo de otro analista técnico la PO pudo decidir totalmente informada y asimismo ser consciente de que el tiempo no era tan corto como ella suponía.

Es que de eso se trata, si como desarrolladores percibimos que la especificación no esta clara o tiene implicancias no previstas, no debemos callarnos, debemos avisar antes de que sea tarde, y por lo mismo reconocer que esa comunicación e interacción de ida y vuelta se va a dar, y no esperar que todo se haga siguiendo ciegamente la especificación.

¿Y tu? ¿Alertas de los riesgos de una especificación a tiempo?