La calidad contra el tiempo

Cuando uno ha llegado a un buen nivel de entendimiento de patrones de diseño, arquitecturas de aplicaciones, conocimiento de los frameworks de las empresas por las cuales pasamos (con sus ventajas y desventajas), conociendo qué podemos esperar de los demás (según su seniority, experiencia, funciones, etc), llegamos a un momento donde nos preguntamos: Si hicieramos las cosas apuntando siempre a una mucho mejor calidad, ¿Habría una ganancia para nosotros y la empresa?

Pensemos en la siguiente frase que leí el otro día: "No te quejes de que las cosas no estén bien hechas. Si lo estuvieran, no tendrías trabajo". Es excelente e ilustra muy bien la realidad de las empresas de software. Hasta ahora no he pasado por ninguna que tenga un gran desarrollo de frameworks, con diseños excelentemente pensados, extensibles, que puedan evolucionar, etc.

Linux puede hacerlo, Google puede hacerlo, Microsoft (algunos productos nomás) puede hacerlo. Por algo están la cima, por algo pueden competir de la manera que lo hacen. ¿Pero puede una empresa pequeña competir de tal manera? Facebook no nació de adentro de una piscina de dinero. Creo que todos estamos familiarizados con la película "The Social Network". Tengo mis propias críticas de la misma, pero las dejaré para otro post. Ahora pensemos en el concepto demostrado por el protagosnista.

Todo inició "hackeando" sitios web de otras universidades para armar una competencia de "qué chica te gusta más" y rápidamente construyó un sistema de ranking online. No hubiera sido posible de no tener una buena base de conocimientos de programación. Pero qué estoy diciendo! No hubiera sido posible sin entender bien la programación, el manejo de servidores, los tipos de seguridad, etc. Con todo ese conocimiento, Zuckerberg fué capaz de crear un "negocio" prácticamente en una noche. Si bien no recibía ganancias por él, no faltaba mucho por hacerse para que eso fuera posible. Claro que después se dedicó a lo que es facebook.

Lo que nos permite hacer todo esto tan rápidamente no es sólo conocimiento (aunque es algo ESCENCIAL), sino también nuestra proyección a futuro y la calidad de nuestro código.

Imaginen un escenario más cercano a nosotros. No es lo mismo iniciar una aplicación con base de datos (abms y esas yerbas) teniendo un framework para conexión a datos, que no teniendo nada. Supongamos que la programación del negocio y las interfaces de usuario, sin manejo de datos, nos toma 2 meses. Entonces, los datos en una aplicación de este tipo nos tomarían como otros 2 meses o mes y medio si no tuviéramos framework. Con framework podríamos tardar 3 semanas y con un auto generador de código medio "pelele" o de código débil podríamos tardar una semana o un poco más, por la complejidad que ese código mal generado nos podría generar, y si tuviéramos un framework y además un generador de código con alta calidad en su producto podríamos estar tranquilos que con un par de horas podríamos generar todos los datos y estaríamos muy seguro de lo generado. Tardaríamos más en crear el modelo de datos que hacer la capa de datos en sí.

Ven la importancia? Reducimos en 2 meses el desarrollo de nuestra aplicación. Claro que son números sacados de la galera, pero estoy seguro de que no estoy tan alejado en el porcentaje de disminución de tiempo que cada escenario refleja.

Imaginen la importancia de esto en los siguientes aspectos:

* Licitamos por un proyecto. Somos los que prometemos las mejores estimaciones de tiempo. Eso no sólo es bueno por el tiempo en sí, sino porque nuestros costos probablemente serán los menores, por lo que podremos obtener (Además) un mayor margen de ganancias.
* Nuestros programadores encargados de la arquitectura, frameworks y generadores de código podrán alcanzar un gran nivel de conocimiento (con la adecuada guía)
* Nuestra empresa podrá expandirse y tener un sector de arquitectura dedicado a resolver problemas al sector de software.

Y aquí en este último punto hay algo muy importante. Sistemas está para solucionar los problemas de los demás, pero quién soluciona los problemas de Sistemas?

Generalmente en las empresas no hay tiempo para desarrollar los frameworks, arquitecturas, generadores de código, y refactorear las aplicaciones actuales para mejorar su calidad y disminuir el costo de manutención. Invertir en un sector de arquitectura es una inversión REAL. Ponemos X plata hoy para mañana tener X+Y plata, donde X fué la inversión y donde Y es la ganancia. GANANCIA. DINERO. VIEJA, ES GUITA LO QUE SE PIERDE DÍA A DÍA.

Yo manejo una teoría donde una aplicación puede llegar a recrearse por completo en menos de una hora, adaptándola a nuevos estándares, arquitecturas y necesidades, todo estando bajo una misma base extensible, consensuada y proyectada para un fin como ese. Pero claro, irónicamente me falta tiempo para desarrollarla. Ese proyecto lo tengo pendiente desde hace tiempo, aunque hace poco empecé a hacer anotaciones para que en algún momento pudiera iniciar mi proyecto de investigación. Mientras tanto, continúo conocimiendo la mayor variedad de problemáticas posibles para sistematizarlas en un futuro y poder encauzar todas las acciones de un negocio en una arquitectura extensible que intuya automáticamente las decisiones de negocio a tomar, pudiendo establecer las particularidades de cada negocio, pero sin olvidar que todo se resume a las matemáticas. Claro que si tu problema entra en el campo de las sociales, ya no te podré ayudar (al menos por ahora). Habrá que seguir negociando con proveedores, teniendo una fuerza de ventas, etc. Pero nunca digas nunca, yo creo que en algún momento las sociales se reducen a una matemática extremadamente compleja que hoy por hoy no nos es posible teorizarla, y por eso lo tenemos como una disciplina aparte. Además si dicha matemática existiera, sería simplemente menos costoso y más rápido usar nuestras habilidades sociales que realizar todos los cálculos pertinentes (hoy por hoy).

Persona detrás de la pantalla leyendo: "Bueno este flaco fuma de la buena."

No podemos pasar nuestra vida programando. Llega un momento donde todo profesional que aprecie a su carrera y le ponga importancia debe tomar una decisión: ¿De qué sigo? Hoy en día hay algunos caminos posibles (deben haber más):

* Gerenciamiento
* Liderazgo y Conducción
* Arquitectura
* Otros no relacionados tan directamente a software. Redes, hardware, etc.

Es imposible preveer las dificultades del futuro, y nunca vamos a tener un generador de código que nos solucione nuestros problemas para toda la vida. Pero con una teoría bien armada que apunte hacia eso (o que tienda a infinito, por decirlo de una forma análoga un poco estúpida) podemos apuntar alto en nuestras decisiones de arquitecturas. Claro, lo más probable es que no logremos llegar tan alto, pero no hay que perder el orgullo por ello.

El costo del tiempo que hoy perdimos pensando y mejorando nuestras arquitecturas y generadores lo ganaremos mañana durante el resto de nuestras vidas.

Quizás el día de mañana todo desemboca en una raza de Terminators que pueden hacer de todo mejor que los humanos, incluyendo cosas tan humanas y dificiles de sistematizar como negociar con otras empresas, armar campañas de marketing, tomar decisiones políticas a nivel internacional, etc. No creo que llegue a ver eso en esta vida, pero estoy seguro que el día de mañana la subjetividad y la personalidad podrán programarse y parametrizarse.

¡¡Pero basta de volar!! El punto final es que poner nuestro esfuerzo al servicio de la calidad, apuntándo alto o aunque sea a resolver algunos problemas menores locales siempre nos va a favorecer.

Dedicar 25% de nuestro día a ello puede marcar la diferencia. 2 de 8 horas por día puede hacer que el día de mañana nuestro trabajo sea más fácil 8 de 8 horas por día.

Saludos desde una mesa puesta en una nube en el cielo, jugando al ajedrez con el arquitecto de matrix. (??)