De la mano de mi regreso al Perú decidí volver a acercarme a mi universidad, y aparte de colaborar como Jefe de Practica el ciclo pasado desde hace unos meses estoy participando en el Proyecto Consejeros de Carrera de la Bolsa de Trabajo (BTPUCP), es en ese marco que soy contactado por la BTPUCP para una entrevista sobre mi experiencia profesional, mercado laboral y consejos para los jóvenes estudiantes de Ingeniería Informática, entrevista llevada a cabo por Reiner Diaz durante el mes de Agosto, la cual quiero compartir con ustedes a la espera de sus opiniones.

Mi agradecimiento a Reiner y a la Bolsa de Trabajo por esta oportunidad de compartir mis puntos de vista especialmente con las nuevas generaciones de nuestra universidad.

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.

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?

Hay lecciones que uno las recuerda como si hubieran sido ayer, y esta si bien ocurrió hace como 18 años, la tengo siempre en mente cuando surge algo nuevo, pero… empecemos desde el principio.

Era una clase de Lenguajes de Programación 1, la dicto el profesor Alejandro Muñoz (un Ing. Civil con bastante pasión por los temas de informática) y el tema que tocaba era C++, para ese entonces ya habíamos aprendido Pascal (algunos laboratorios habían sido bien largos), Fundamentos de Programación y algunas cosas muy interesantes en Algoritmos y Estructura de Datos, pues bien, la primera sesión no se trato de explicarnos que incorporaba C++ sobre su antecesor C (el cual habíamos visto en la primera parte del curso), sino para plantearnos como surge la Programación Orientada a Objetos, como una respuesta a la Creciente Complejidad del Software, el cómo los programas tenían cada vez mas y mas líneas de código, por lo cual la Programación Estructurada ya había tocado su techo, siendo la OOP la respuesta al ser una nueva forma de ordenar los proyectos, así como para enfocar el código hacia entidades mas cercanas al mundo real.

Y claro, aun faltaban pocos años para que el boom de Internet nos cogiera por sorpresa, pero ahí nos quedamos con esa idea, la OOP como respuesta a todo, pero por otro lado vemos la aparición de Visual Basic y su enfoque RAD, en el cual (¡oh herejía) la OOP brillaba por su ausencia, pero aun asi permitió el desarrollo rápido de soluciones que si las hacias en C++ hubiera sido recontra complejo, claro que luego a alguien se le ocurrió una buena idea: mezclar el RAD de Visual Basic con el orden de la OOP y surgió Delphi, y asi hemos visto una sucesión de nuevas respuestas (nuevos retos, recuerden), como comente hace un tiempo , pero quien lo expone mejor es Esteban:
La primera aplicación que hice en mi vida profesional, fue una típica intranet para una empresa. Todo el código y acceso a la base de datos, se ejecutaba en archivos ASP.
Luego me dijeron que está mal acceder directamente a las tablas de la base de datos desde el código, por lo tanto implemente store procedures para cada uno de los accesos a la base.
Luego me dijeron que está mal mezclar lógica de negocio y de presentación en el mismo archivo…..
…..pasé de tener un simple archivo ASP (o ASPX, o JSP) a tener que crear un archivo HTML, una clase model, una clase controller, una clase repository de acceso a datos con su respectiva interface, una clase service que maneje la lógica de negocio con su respectiva interface, una clase para test unitarios, otra clase para test de integración, aprender a utilizar (como mínimo y básico) un framework MVC, ORM, de Unit Testing, Mocking, de inyección de Dependencias y de autenticación.
Todo para mejorar la productividad y velocidad en el desarrollo de aplicaciones. Todo para que el “desarrollador no pierda tiempo en programar aspectos secundarios de la aplicación y se concentre en lo mas importante, que es la lógica de negocio.”.
No se ustedes, pero a mi este ciclo de evolución del desarrollo de software me parece que esta muy alejado de la palabra “productividad”.

Efectivamente, esos han sido los vaivenes y trends por los que hemos pasado los desarrolladores en los últimos 15 años, es que efectivamente una vez que nos terminaron de convencer acerca de la OOP, eso no fue suficiente, tocaba programar basado “en componentes” y de ahí todo lo que cuenta Estaban en su post.

Y si, si bien esa historia puede ser descorazonadora para quienes producimos software debemos recordar algo:
• Siempre se nos pedirá mas y mas funcionalidades, y mas funcionalidades significan mas líneas de código, osea mayor complejidad.
• El entorno donde correrá tu aplicación cambiara, no tiene sentido pensar en tu web como la antigua aplicación de facturas hecha en Fox, porque ahí entran diversos factores que por mas que la funcionalidad sea “similar” a lo que ya había, cambian totalmente la forma en que la tendrás que desplegar y por ende estructurar el proyecto, baste mencionar el tema de seguridad y todas las consideraciones de zona militarizada que eso conlleva.
• Es impredecible saber con que interactuaran nuestras aplicaciones en el futuro, pero está claro que aun a la clásica aplicación de facturación se le puede pedir integración con Google Maps para que te ayude a ubicar la dirección del cliente.
• No puedes estar seguro de cuánto tiempo vivirá tu aplicación, pero alguien tendrá que mantenerla, por lo que hay que tener consideración con el que le toque hacerlo.

Llegados a este punto debemos reconocer algo, muchas de estas modas, surgieron para afrontar los retos que iban surgiendo progresivamente ante problemas que antes no había, o que terminaron volviéndose mas repetitivos terminandose al final conceptos ya asumidos "por defecto": OOP, Web, BD relacionales, SOA, etc; ahora bien, eso no quita que hubo muchas soluciones para necesidades inventadas, por lo que pasaron sin pena ni gloria (¿alguien recuerda los “behaviours” en IExplorer 5?).

Ahora bien, el problema que debemos afrontar es saber cuándo seguir o no una tendencia (ya me paso a mí con LINQ 2 SQL, pero pese a ello era claro que los ORM habían venido para quedarse) y sobre todo si esta aporta real valor a nuestra solución, ya exprese mis dudas respecto a los nuevos patrones de diseño, pero de nuevo Esteban nos ofrece su visión de porque algunas cosas se terminan imponiendo (sin necesidad): Assumptions Driven Development. Es que es así, implementamos por inercia cierta arquitectura (de moda) sin tener en cuenta cual es el escenario real para la cual esta tiene sentido, o porque esperamos que cierta condición se cumplirá en el futuro y para ello “hay que estar preparados”, y como bien se apunta en el articulo esas condiciones nunca terminan de cumplirse pero en el camino ya hemos agregado complejidad innecesaria a nuestro proyecto.

No es sencillo, la verdad, pero como dije al final algunas cosas vinieron para quedarse: OOP, aplicaciones distribuidas, nuevas interfaces de usuario mas ricas, interconectividad, y ante ello no queda sino tener la suficiente cabeza fría de saber si la novedad que estamos queriendo implementar en nuestro proyecto agrega valor o no al producto a ser entregado, si los retrasos y complejidad añadidos son superados por las ventajas futuras (a veces puede que no ), la cosa es no temer a la respuesta de un análisis hecho a conciencia.

Por ejemplo, estoy convencido que ciertas capas de las aplicaciones pueden beneficiarse muchísimo del uso de pruebas unitarias, componentes algorítmicos puros, formulas matemáticas, financieras, su determinismo es tan alto que una prueba unitaria de veras se luciría para probar el código, pero de ahí a querer una cobertura del 100% o plantearse el TDD como panacea para mejorar la calidad de los programas... me lo tomo con pinzas, a riesgo de que me llaman hereje indicando que he “missed the point”.

Ojo, nótese que prudencia no es pasividad ni conformismo, pues de lo contrario estaríamos como las empresas que siguen usando mainframes.

Si, es complicado, pero es mejor tener las cosas claras y no renunciar al análisis para saber separar la paja del trigo.

La verdad es que no habia pensado en el tema, a pesar de tener una posición clara sobre ello, hasta que hoy en la mañana vi unos twitts que remitian a este twitt: "¿Debería ser el jefe de proyecto tu mentor? ¿Q figura es la q debería acompañarte en tu desarrollo profesional?", lo cual me llevo a pensar en dos experiencias personales respecto a la figura del mentor...

Hace unos años di un cambio profesional, y con ello fue introducido a la figura de Career Manager, un profesional de rango mas avanzado en la organización, el cual debería ayudarte a identificar tus puntos de mejora para seguir avanzando, realizar la evaluación de desempeño (preguntándole a tus jefes, pues ojo a esto, el CM, salvo excepciones, no puede estar en el mismo proyecto que el supervisado), a la vez que proveerte de información de como se esta moviendo la organización, ademas de ser una figura informal de "abogado" en las relaciones con tus superiores.

Lógicamente que todo esto forma parte de un proceso mas o menos burocrático dentro de las organizaciones, pero que en el fondo tiene mucho sentido, pues gracias a mi primer CM pude aprender diversos detalles de la cultura de la organización, y conseguir apoyo para los planes de formación y sobre todo algo que siempre recordare, el como intercedió por mi cuando un responsable de proyecto quiso hacer una jugada con la imputación de horas.

Durante ese tiempo, también tuve ocasión de trabajar con colegas en las que su mentor era precisamente el Jefe de Proyecto, lo cual me intrigo haciéndome conversar informalmente con ellos a fin de saber que opinaban de la figura, sacando la conclusión de que si bien en este modelo el mentor, al ser tu jefe, tiene la información de "primera mano" sobre tu desempeño, no permite generar la suficiente confianza como para que haya una relación fluida en la que el mentorado pueda confiar totalmente sobre los problemas directos de la marcha del proyecto.

Tuve ocasión de comprobar eso directamente, pues al final se me designo sucesivamente como CM de dos programadores junior, así que ante el reto trate de ganarme la confianza de mi mentorado, explicándole lo que había visto en la organización, el enfoque de hacer las cosas y lo que se esperaba de nosotros, calculo que debí darle suficiente confianza, pues un día me llama prácticamente desesperado ¿qué había pasado? un analista se retiraba a otro modulo de su proyecto, dejandole a él parte de sus responsabilidades técnicas, lo cual le asustaba pues eran temas que solo había visto ligeramente, y claro, le asustaba decirle eso a su jefe de proyecto, por lo que luego de tranquilizarlo procedí llamar tanto al responsable de los CM como a su jefe para saber lo que había pasado, la cosa era sencilla, eran necesidades de negocio, estaban alerta de que era un reto, así que no habría tanta presión en un primer momento mientras se adecuara; así que con esa información me toco transmitirle un mensaje tranquilizador, lo cual funciono pues unos meses despues, cuando me toco proceder a la evaluación, me confeso que no era tan fiero el león como se lo pintaba.

Así que por esta experiencia directa, creo que un mentor o CM no debería (salvo coyunturas) ser directamente el jefe del mentorado, siempre queda un conjunto de cosas en la cual se necesita cierta confianza que tal vez no se pueda tener dentro del propio proyecto. Dicho esto, soy consciente de que cuando se avanza en la pirámide no hay tanto margen para asignar responsables que no sean los jefes directos, pero es algo que se debería procurar en la medida de lo posible.

A veces un hecho fortuito te llama a la reflexion, ayer recibi una llamada de un headhunter que me hizo un entrevista telefonica para incorporarme a su base de datos, a fin de que con suerte esto derive en un proceso de selección posterior, entre las diversas preguntas (algunas clasicas, algunas nuevas) hubo una que casi que me cogio con la guardia baja y fue la que da titulo a este post ¿En qué clase de empresa te gustaria trabajar y en cual no?, logicamente para esta clase de preguntas la respuesta tiene que ser rapida, asi que solo atine a decir que me gustaria trabajar en una empresa que da importancia a las tecnologias de la informacion como herramienta importante de sus diversos procesos de negocio, pues partiendo de esa base se ve como va a tratar a la gente de tecnologia (yo entre ellos, ejem ejem), por lo cual esto es un punto de partida para todo.

Tal vez mi improvisada respuesta puede parecer un poco obvia, pero a poco de pensar te das cuenta que en realidad "estas pidiendo mucho" pues el dia a dia te demuestra que ese enfoque no es el seguido por un buen numero de empresas, siendo el caso de que la parte de IT se ve como algo colateral, y no vinculado al core del negocio.

Una de las ideas mas claras de este "enfoque" viene dada cuando la empresa decide que los tecnologos no son "core" del negocio, por lo que si bien requieren contar con ellos, casi solo un milagro hara que se fiche a un Analista Senior (y ya no te digo un Programador), a pesar de su continuidad, lo cual deriva en las situaciones que ya comente hace un tiempo.

Esta situación ha evolucionado hacia decisiones en la que una empresa externa asume, ya no el contrato para el desarrollo/implantación de una nueva aplicación, sino la gestion total de todos los procesos de IT, a fin de que la empresa contratante se centre en el "core del negocio" pues "nuestro negocio es vender XX no hacer programas", ademas de procurarse un ahorro de costes o el convertir lo que es un gasto fijo en un gasto variable, todo bien desde el punto de vista financiero o administrativo, pero a la larga implica un debilitamiento del propio conocimiento de la organización sobre lo que ellos tienen, o como dijo una compañera hace tiempo "en cada transferencia (de conocimiento) algo de conocimiento se termina perdiendo", y ese fenomeno es lo que a la larga reduce las capacidades de la empresa para reaccionar prontamente ante los retos del mercado.

Esto no debe tenderse por ir hacia la postura de que la empresa debe de "hacerlo todo", sino en el hecho de que no se debe renunciar totalmente a la gestion de IT y al conocimiento detras de el, tanto en las operaciones del dia a dia como en la elección correcta del proveedor(*) para las necesidades que hagan falta, es que hasta en eso se dan errores como cuando hace poco se me pidio dar mi opinion para un nuevo software que se tenia que comprar (por requerimiento legal, no por necesidad de negocio), no me tardo mucho ver que la propuesta no valia la pena, pues dicho software estaba hecho en una herramienta que fue descontinuada por su proveedor hace 4 años, pero por si eso fuera poco el desarrollo estaba cerrado a un esquema que no contemplaba ciertas peculiaridades del modelo de negocio/producto de la empresa, por lo que necesariamente tendria que haber una "personalizacion" que en este caso no seria tan solo de reportes o "alguna pantalla extra" sino de la estructura basica del modelo de base de datos, con esa percepción recomende continuar con la busqueda de alguna otra oferta, pero no se me hizo caso, siendo este otro escenario de cuando las tecnologias de la informacion no son tomadas en serio por la organización.

Otro tanto puede decirse de las empresas que presumen de serias y con cierta facturacion, pero que no tienen pagina web o peor aun.... pareciera que el diseño de su site ha pasado por un proceso caotico.

Regresando a la pregunta original, tambien podria decir que seria un reto el integrar una organizacón que este dispuesta o en proceso de darle importancia a TI como herramienta para mejorar sus resultados, mejor ¿no?

Visto lo visto.... ¿Que tan en serio crees que las empresas se toman al departamento de TI en su empresa?

(*) Que al final de cuentas sabe algo de tecnologia que tu no, pero que viene a ayudarte en tu negocio, no a llevar el negocio por ti.