El rol del arquitecto

Cada vez está más de moda tener un "arquitecto de software" en el sector de sistemas. Sin embargo, muchos son los que se quejan de que dicho rol es un invento, o una mera forma de hacerte creer que te ascendieron o que cambiaron tus responsabilidades.

Existen empresas donde esta realidad es cierta. Donde los arquitectos son simplemente desarrolladores con otro título. Donde en vez de darle todo el aumento de sueldo que quería esa persona, le dieron la mitad y le propusieron ascenderlo de puesto. Todo muy lindo, todo muy rico (diría un amigo) pero es cualquiera eso.

El arquitecto de verdad debe poder ver a través de una gran cantidad de aspectos en los desarrollos de software. Tiene tareas a nivel micro como a nivel macro. Por ejemplo, un arquitecto debería ser quien dictamine los estándares de calidad de la empresa a nivel código, base de datos, interfaces, etc. Sin embargo, también debe ser alguien capaz de unir dos sistemas gigantes e integrarlos para que funcionen correctamente.

Mi opinión personal es que además debe ser un programador innato, capaz en cualquier aspecto que involucre esa función:

• Código
• Conocimiento de tecnologías
• Mentalidad científica
• Capaz de depurar cualquier cosa
• Mente abierta
• Etc

Además de ser un programador, debe poseer algunas habilidades sociales. Las suficientes para interactuar con otros colegas programadores y con personal de jerarquía. Ya que un arquitecto debe poder:

• Entender qué es lo que se necesita
• Crear ideas novedosas que puedan impulsar la productividad
• Idear proyectos de desarrollo para esas ideas
• Impulsar la aprobación de dichos proyectos
• Y muchas veces, liderar los mismos

O sea que tiene que tener algunas características de líder de proyecto y de analista funcional y técnico.

¿Entonces un arquitecto es un gurú?

No necesariamente. Aunque siempre conviene que sea así. La razón es simple: El arquitecto implícitamente toma decisiones a mediano y largo plazo, que afectarán el futuro de la empresa de acá a unos 2, 5, o hasta 10 años. Incluso más.

Las propuestas y las micro y macro decisiones que tome van a enmarcar el futuro de la forma de hacer software en la empresa. Este es un punto que generalmente todos pasan de largo. La responsabilidad de un arquitecto es tal que puede llevar a la empresa al fracaso de no haber sido bien elegido o de haberse tomado malas decisiones. Y lo que es peor, no lo vas a ver venir hasta que sea tarde.

Claro que esto es un idealización de lo que debería ser un arquitecto. Un transformador interno de los sistemas de información de la empresa. En lo posible, una persona devota que no sólo estudie y se actualice constantemente, sino que también busque participar de la comunidad de investigación en software, para llevar el software cada vez a un nivel mayor.

No se trata solamente de hacer frameworks, o se dictaminar cómo deberían relacionarse unas clases. Esas serían tareas de un arquitecto junior. El arquitecto de verdad debe ver el futuro, pesar los diferentes factores y tomar decisiones. 

Decisiones bien tomadas podrían hacer que la empresa pueda iniciarse en otras tecnologías que antes no exploraba (como por ejemplo, una empresa dedicada a .NET que pueda moverse a IPHONE, por dar un ejemplo).

Y si el presupuesto y el conocimiento son suficientes, podrá desarrollar productos tan baratos y fáciles de mantener que los márgenes de ganancia serían muy importantes.

¿Ahora, cuál es el seniority de un arquitecto?

Esta pregunta me hace acordar a un aviso de computrabajo que ví hace un tiempo. Buscaban un project leader "junior". Entonces me puse a pensar... qué significa ser junior en este cargo?

¿Debe saber programar? Mínimamente, para poder estimar las tareas con precisión. Porque sino serán los desarrolladores quienes las estimen, y no él (esto no quiere decir que no pueda corroborar fechas con los dev).

¿Debe saber analizar? Totalmente. Muchas veces los requerimientos deben ser analizados por el TL al no haber un analista técnico disponible. Aún así, el TL debería tener en claro de qué vá el software a desarrollarse, y no ser una mera máquina de métricas y estimaciones.

¿Debe tener estudios? Absolutamente. No me parecería correcto que un líder de proyecto "lidere" a personal que es más capaz que el mismo. La típica frase "El que sabe, sabe, y el que no, es jefe" es tan triste y real que lo llegamos a tomar como una joda. Pero la posta es que las situaciones donde se aplican son justamente los grandes baches que una empresa debe corregir al instante. Un "jefe" o "líder" incapaz provocará grandes daños económicos imperceptibles a la empresa, por el simple hecho de que no genera ni la mitad de lo que puede generar un TL decente.

Un poco me estuve yendo de tema, y podría seguir analizando qué clase de background debería tener un TL, que si bien se fijan, no analicé ninguna de las tareas que tiene que hacer un TL.

Pero a lo que voy es que en ese aviso me imaginé "si pido más de X no me van a tener en cuenta" y simplemente concluí "gano más como desarrollador". Es evidente que si incluyeron la palabra JUNIOR en un aviso es porque quieren pagar poco. Además, conozco personas que no tienen idea de sistemas y arrancaron a trabajar de project leader DIRECTAMENTE, sin background alguno. "¿Qué es una tabla?" <--- No se sorprendan cuando les pregunten eso. De pedo conocen una tabla en excel en el mejor de los casos. Desconfíen muchísimo de gente así. No es culpa de ellos que los hayan endulzado con un cierto sueldo y responsabilidades, cargo y beneficios, cuando ellos no tenían idea de lo que se necesita para ser efectivo en ese puesto. Pero después estarán atrapados por siempre al menos que decidan estudiar por su cuenta. Ser TL y después moverse a un puesto de desarrollador Junior no es una opción.

Lo mismo ocurre con los arquitectos. No pueden ser arquitectos quieren no tienen un importante background en programación. Es evidente. ¿Qué arquitectura vas a diseñar si todavía no sabes lo que es un patrón? ¿Qué clase de decisiones vas a tomar si nunca tuviste que romper y re-armra un sistema? No señores, un arquitecto JUNIOR debe ser como mínimo un programador Senior. Y estamos hablando de unos 4 años de experiencia continuada como mínimo.

Yo tengo una idea del seniority del arquitecto que quizás no aplica a la concepción actual de muchos. Estamos acostumbrados a ver el seniority como un simple título que se gana con el tiempo. Sin embargo, tenemos desarrolladores que después de 5 años siguen siendo unos soquetes. Y después ta el pibe ese que hace un año que está y es un bocho. Sin embargo, quien es "Senior"?

Se pueden ir imaginando hacia donde voy:

• JUNIOR: Alguien que ha programado mucho pero no ha adquirido grandes conocimientos en arquitectura y desarrollo de software. No lideró equipos ni tiene demasiados conocimientos técnicos mas allá de los que ganó con su experiencia laboral. Sin embargo, DEBE ser un Senior en programación, al menos en términos temporales. El JUNIOR en Arquitectura es alguien dispuesto a aprender, y nunca puede ser el cabecilla del sector. Es decir, no puede tomar decisiones que afecten demasiado al futuro de la empresa. Es probable que en esta categoría apenas esté aprendiendo UML.
• SEMI-SENIOR: Es aquel que ya tiene muchos más conocimientos que el JUNIOR, y obviamente es SENIOR en programación. Conoce UML, conoce arquitecturas, conoce patrones, conoce tecnologías. Sin embargo, le falta aprendizaje, y probablemente, capacidad. Quizás no tenga la mente muy abierta, o no sea tan creativo como uno quisiera, por lo que sus decisiones pueden ser erradas muchas veces, debido a un mal proceso de análisis, o porque simplemente no vió las fallas básicas en sus propuestas. En mi opinión, es un recurso útil, siempre y cuando esté bajo un arquitecto SENIOR.
• SENIOR: Este es el real transformador de la empresa. El que destruye y re-construye los cimientos bajo los cuales se produce software. Es como que levante una máquina de ensamblaje diferente todos los días en una fábrica de hamburguesas. Es el que toma las decisiones y generalmente son acertadas (luego analizaremos el concepto de decisióna acertada en arquitectura). Es el cabecilla del sector de arquitectura y el que se debe encargar de resolver los problemas de sistemas. Porque sistemas resuelve los problemas de todos, pero nadie resuelve los problemas de sistemas.

Es dentro de este concepto de Arquitecto Senior que para mí se encuentra la verdadera utilidad del rol del arquitecto. Conozco sólo 2 arquitectos de este calibre. Uno es un ingeniero que se nota que sabe, y el otro es un magíster que rediseño muchísimas cosas a nivel sistemas en una multinacional monstruosa. Mas allá de que las cosas que hizo no fueran lanzar un cohete a la luna, el apoyo a la propuesta y la implementación que logro son dignas de notar.

Es decir, que esta clase de Arq Senior son pesos pesados. Y obviamente, ¿a quién vas a dejar que tome las riendas de cómo se hace el software en tu empresa? A un peso pesado! Uno capaz de hacerse cargo de tremenda tarea.

Lamentablemente este no es el concepto de SENIOR que se maneja hoy en día. Pero esta consideración es más para las empresas que para los empleados. Para que analicen si lo que realmente quieren es un arquitecto, y si lo quieren, entonces que estén dispuestos a encontrar un "Senior" de verdad.

Esto no indica que los Junior y SemiSenior (según mi concepción) no sean útiles, pero no son suficientes.

Finalmente, para ir cerrando. 

¿Qué es una decisión acertada en arquitectura de software?

Desde mi propio punto de vista, una decisión acertada puede ser de diferente índole. La primera que nos vamos a encontrar, que creo que es la más común, es aquella decisión que es una mejora aceptable o incluso considerable sobre un esquema de trabajo actual.

Es decir, una decisión que permite al esquema evolucionar en el sentido necesario para que la arquitectura pueda seguir evolucionando más adelante. Por dar un ejemplo bobo, pasar de no tener capas de aplicación a tener UI, negocio y datos, es una mejora notable y acertada. Algo considerablemente acertado sería cambiar el framework actual de base de datos que no tiene soporte para nada excepto SQL SERVER  a un framework que soporte cualquier tipo de base de datos, y sólo requiera que se desarrolle algún que otro componente para hacerlo compatible con ORACLE, DB2, etc.

Pero esas decisiones acertadas son las más simples. Son transformadoras a nivel micro ya que cambian nuestra forma de programar y producir software, pero no cambian radicalmente el modo en que opera la empresa.

Pensemos ahora qué pasaría si mis decisiones permiten a la empresa aumentar en un 300% la productividad, aligerando la carga de trabajo de todos los desarrolladores, pudiendo dentro de unos pocos meses poder estar con viento a favor en las fechas de entrega en vez de estar siempre atrasados. Esa "magia" que logró el arquitecto (que podría ser con un framework empresarial potente, bien diseñado, y con capacitaciones eficaces a los programadores) podría realmente transformar la realidad de la empresa. Quizás ahora se puede aceptar más trabajo sin reclutar recursos adicionales. Este tipo de decisión acertada "que tiende a macro" es transformadora, pero no abrió ningún mercado nuevo. Como mucho puede llevar a la empresa a otro nivel económico, pero es sólo una inyección de evolución. Este es otro tipo de decisión acertada, que grotescamente llamada inyección evolutiva, o podríamos llamar como transformadora de la productividad.

Ahora que pasaría si gracias a nuestras decisiones la empresa puede competir con grandes gigantes como IBM, Microsoft, Apple, etc? Sigue siendo una transformadora de productividad, pero de tal nivel que el cambio es muy "sarpado", a falta de mejor palabra. Transforma tu empresa mediana en un conglomerado y temido competidor. Pero no deja de ser el mismo tipo de decisión.

Ahora, podríamos llegar a decidir hacer un framework para una tecnología que no conocemos. Imaginemos que somos expertos en .NET y decidimos ampliar nuestros conocimientos para desarrollar en IPHONE, IPAD, etc. Necesitaríamos investigación, tiempo, presupuesto, personal, y mucho brainstorming. Pruebas de concepto, pruebas de todo tipo, proyectos piloto, etc. Pero a la larga, si nuestras decisiones fueron correctas, hemos transformado a la empresa y ampliado el mercado en el cual puede participar. Nuestras decisiones aquí fueron posibilitadoras de un cambio muy importante. Tiene su nombre en la teoría de sistemas de información, pero ya me olvidé cual es. Vamos a llamarle por ahora decisión de expansión de mercado.

Es parecido, aunque no es lo mismo, hacer todo eso pero para MOVERSE de mercado, y no ampliarse. Abandonar .NET en este ejemplo. Eso sería una decisión transformadora de dirección.

Ahora, ¿cuándo es acertada la decisión y cuando no?

Pues cuando te vá bien chamaco. Y eso se vé cuando lo notas tanto en los empleados, en la empresa, y en los clientes y proveedores.

Hay más tipos de decisión que creo que existen, como las transformadoras de proceso (cambiar la forma en la que se gestiona), transformadoras de mentalidad, etc. Pero el post ya me ha quedado larguísimo y yo tengo que volver a trabajar!

Después de tanto tiempo inactivo al menos les dejo con un buen super post. Y me viene bien hacer este brainstorming para "idealizar" qué es un arquitecto de software, cargo que empiezo a cubrir desde hoy.

Waaaaaa, Where are you Jimmy?

Este ha sido un mes muy dificil! Apenas he tenido tiempo libre. Hago un post para decir que estoy vivo, nada más. Tengo varios artículos a medio hacer, así que voy a ver si este finde que me libero un poco puedo dedicarme a la escritura e investigación!

Saludos desde una nube rosa

Iniciandosé como freelancer: Mi experiencia propia.

Allí me encontraba yo, algo aburrido con el trabajo que tenía en ese entonces, y con mucho más tiempo libre de lo que tengo ahora. Tenía mis hobbies que me ocupaban tiempo y todo, pero sentía que debía hacer algo más con mi profesión. Entonces recordé a un amigo que una vez me dijo "RentACoder".

Lo googlié y resulta que RentACoder ahora se llama vWorker. El asunto es así. Voy a hablar de mi propia experiencia como freelancer en vWorker. Sin embargo, no intento hacer propaganda del sitio ni nada parecido, ya que hay muchas opciones. Pero bueno.

Lo primero que hice fué revisar el "esquema" de trabajo. No lo logré entender mucho de entrada, aunque la guía de inicio del sitio me ayudó bastante. Cree mi cuenta y armé un poco mi perfil. Luego me puse a ver en el ranking a aquellos que tenían mas "puntos" y ver qué tipo de perfil tenían. Pronto entendí que si bien puedo tener un perfil muy lindo, lo importante es la experiencia comprobable en el sitio. Es decir, la "confianza" que podemos generar en un potencial cliente por la cantidad de trabajos completados con éxito en nuestro portfolio. Y allí me cayó la gran pregunta "Necesito un cliente que me acepte sin tener nada en el portfolio".

El formato para buscar trabajo era simple. Los clientes posteaban sus necesidades (a veces bien clarificadas, a veces no decían siquiera el trabajo) y uno tenía que escribir con puro texto y licitar por una suma de dinero. No se podían ver las licitaciones de los demás, ni siquiera quiénes eran. Sólo podías saber cuántos licitaban.

Entonces quizás uno pide 50 dólares para un sistema que otro, con un portfolio ya iniciado, pedía 40 dólares. Y si perdíamos la licitación no nos podíamos enterar contra qué precio. Por ende, no sólo teníamos que acudir a nuestro criterio, sino también saber vendernos a los clientes. Y todo eso en inglés (aclaro por algunos que no la tengan clara en inglés).

Pronto me dí cuenta que la mayor competencia vendría de Pakistán, Afganistán, Arabia, etc. Es decir, países pobres. Evidentemente cobrar en dólares es mucho para ellos, seguramente más que para nostros.

Entonces me "prostituí" en un trabajito de javascript por 10 dólares. No sólo mi precio fué el mejor, sino que mi "chamuyo" fué excelente. Dividí mi post en secciones: Saludo e Introducción muy corta de mi persona, Requisitos del cliente (que logro identificar), Cómo resolvería el problema, Cuánto tardaría.

Realicé este trabajo para mi primer cliente (de origen yankilandés) y me pagó 10 dólares por el trabajo, y luego un bono de otros 10 dólares porque le caí muy bien y le pareció muy bueno el trabajo. Pronto me comentó lo desorganizada que es la mayoría de las personas que trabajan de freelancer en ese sitio. Mi post le pareció excelente y mi precio aún más, y al ver que trabaje tan bien y a tiempo quiso "comprar" mi simpatía con dicho bono. No voy a ahondar en qué era el desarrollo, pero siempre recordaré mi primer trabajo.

Al otro día ya había ganado 3 licitaciones más, dos por 20 dólares y una por 65. Lo cierto es que, emociones aparte, no me estaba siendo redituable cobrar tan poco. Pero era muy satisfactorio manejar mis propios clientes y organizarme de la forma que me parecía mejor. El trabajo de 65 dólares me costó bastante, porque hubo varios fallos en la definición de requisitos (los cuales fueron responsables 100% los clientes, quienes no tuvieron problema en pagarme para un segundo desarrollo que corrija el primero a partir de las nuevas definiciones).

Estuve así durante 3 meses, cobrando poco pero realizando trabajos de todo tipo. Aprendí problemas que ocurren en otros países que ni se me hubieran ocurrido. Bancos, financieras, agencias de marketing, cazarecompensas, etc. Estuve a punto de comenzar a aprender nuevos lenguajes de programación porque mis clientes querían que yo me encargue de nuevos asuntos, incluso sin saber nada de los lenguajes que necesitaban, porque confiaban más en mí que sus antiguos desarrollares freelancers.

Eventualmente dejé de "freelancear" por un asunto de tiempo y porque no me era placentero estar todas las noches programando. Mas allá de que eso lo acompañe con un vasito de vodka o licor, y un buen cd de dream theater en el equipo de audio.

Logré hacer conexiones y un monto mas o menos decente de dinero en dólares. Además, estuve trabajando no sólo de desarrollador, sino también realizando cosas de marketing, testing, y project manager. La experiencia fué tan importante que decidí agregarla al CV.

Entonces, si desean ser freelancers en una comunidad de habla anglosajona, busquen uno de estos sitios, regístrense, "estudien" a la competencia, adaptensé al mercado y empiecen a licitar sin dudarlo. Van a tener que pensar que su licitación debe ganarle a otras, así que si pensamos que vamos a tardar 10 días, mejor piensen si es posible hacerlo en 5.

¿Qué? ¿Les suena familiar? Pero claro, si muchas personas nos ponen deadlines ajustadisimos e incluso ridículos. Bueno después de freelancear van a ver el otro lado de la tortilla. Se van a poner en el rol del vendedor y entender el por qué de las promesas absurdas. Bienvenidos a la cultura del negocio.

Y algo importante es el gear: Netbook ASUS 1005PE de 2gb de ram. Altamente recomendada. Corro el SQL Server 100% del tiempo mientras estoy con Enterprise Arquitect, Visual Studio 2008/2010, el SQL Server Management Studio, el Chrome navegando y con gmail abierto, y otras yerbas como msn y eso.

Y no usé mucho más. Un pendrive de vez en cuando pero listo.

De última, si fracasan en freelancear, al menos conocieron algo nuevo. Lo que les recomiendo es no usar PayPal ya que tarda como 22 días en llegar el cheque. Es preferible usar Western Union que nos cobra menos y llega instantáneamente. PayPal parece ser más barato pero hay costo por emisión del pago, costo por cobrar, y costo por todo.

Complicado de tiempos

Vengo muy complicado estos días para poder postear. Pero ya estoy preparando algunos trabajillos de crítica para subir. No desesperen (Quién va a desesperarse por este blog... por dios... :D)

Los estándares de programación cuando no se aplican. ¿Quién falla?

Un día un pibe programador dijo "Ché, qué es esta variable rorColo" y vino Mister Old Grandpa a decirle "Es true cuando hay un error en el proceso de colocación."

A la papirola.

Y nunca faltan esas tablas llamadas USRPIJATBL001 o lo que es peor, que todos los datos se repitan en todas las tablas, haya o no FK.

Grandes monstruos se han construído sobre el estiércol del día a día. "Necesito un string ya. A ver... oh si, string93". Claro que estoy hablando casos extremos, que he visto poco (por suerte!). Sin embargo, muchísimos sectores de sistemas en muchas empresas están caldeadas y pelean día a día con estos problemas. Con leer The Daily WTF ya nos damos una idea.

Por otro lado es común que las variables, clases, etc, se nombren como vienen, y no se respete ningún estándar. Y sólo estoy hablando de nomenclaturas. Podemos escribir estándares sobre cualquier situación "estándar" que se nos ocurra.

Este post es para divagar un poco sobre qué ocurre y de quién es la culpa cuando esos estándares existen, pero no se respetan. ¿Están mal escritos? ¿Los empleados son rebeldes?

Vamos a analizar los actores. ¿Pero por dónde empezar? ¿Desde el management o desde la fuerza de programadores rasos? Y bueno, empecemos de arriba a tirar palos.

El management y los arquitectos que desarrollan el estándard...

Un estándard de programación tiene que pasar a formar parte de la cultura de tu empresa, porque afecta directamente a la calidad del producto software que vas a crear. Estés o no en una empresa cuyo negocio central sea sistemas, deberías siempre apuntar a hacer software de calidad, y el software se construye de muchas cosas, pero una de ellas es el código. Y en el código podemos poner solamente código o podemos implementar un modelo realmente bien pensado de forma arquitectónica para aprovechar las ventajas de las buenas prácticas.

Entonces, si debe ser parte de la cultura de la empresa, y parte del proceso de creación de productos con calidad, ¿No es una tarea importante del management (en conjunto con los arquitectos) que se implemente? Yo opino que sí. Cuando entré en uno de mis trabajos me hicieron leer guias y guias de estándares, y siempre los respeté todos. Empecé a trabajar en un sector que los utilizaba y realmente creía ver código conciso y pensar que lo podría haber hecho cualquiera. Sin embargo, luego me moví a otro sector que era todo lo contrario. ¡Un desastre!

Poco a poco fuí impulsando cambios (desde abajo, como programador) para intentar mejorar la aplicación de los estándares, además de otras cosas. Pero nunca nadie de arriba se interesó por si estábamos haciendo las cosas bien o no. Cada uno de nuestros proyectos tenía un arquitecto asignado. Sólo lo conocí en un curso, y nada más. Ni siquiera se interesó cuando se arrancó un proyecto impulsado por el sector mismo, para construir un framework de SharePoint.

Sin interés de arriba el único que puede impulsar un cambio es uno, pero lo más probable es que los cambios significativos sólo fuesen a impactar en nuestro sector y nada más. Es un estándar tirado a la basura porque no se implementa ni se promueve.

Los project managers...

Un PM se la pasa pensando en fechas de entrega, implementaciones, y tareas pendientes. Casi nunca un PM te vá a decir "che y si rehacemos el módulo X?". Tienen un trabajo bastante cargado, y son apurados por el mismo management. Sin embargo, de vez en cuando deberían impulsar cambios a mejoras en la calidad y promover la implementación de estándares. Si tus programadores trabajan mejor, se entienden mejor, y hacen las cosas más rápido, ¿no van a mejorar los resultados?. Obviamente.

Pero es difícil parar la pelota, encontrar el tiempo, y pensar la jugada. Pero lo lamento, también los culpo.

Los analistas técnicos y programadores seniors...

Si se nos presenta un estándar de programación es nuestra responsabilidad aplicarlo, independientemente de cómo trabaje el resto y del código con el que estemos trabajando. Así que si no aplicamos un estándar... obviamente, es NUESTRA culpa también. Nadie está exento.

Además, como miembros más experimentados y/o más antiguos, hay que impulsar la implementación a los programadores más novatos. Se les debe inculcar la cultura de la calidad, y una de las cosas que eso requiere es el uso de estándares.

Es culpa de todos. Promuevan y apliquen los estándares. Y si no tienen uno, es buen momento para arrancar.

Yo estoy a punto de escribir uno para la empresa en donde estoy, donde voy a usar mi experiencia propia más estándares que ya conozco. Una vez terminado, sea aceptado o no, lo publicaré aquí.

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. (??)

Creando nuevas costumbres organizativas

Muchas veces se nos ocurren ideas en medio de un desarrollo, pero carecemos del tiempo necesario para pensarlas en detalle y mucho menos vamos a poder desarrollarlas en el momento. Esto hace que muchas veces nuestras ideas se olviden y no nos acordemos de ellas hasta mucho tiempo después.

Otras veces, encontramos "chunks" de código que sabemos que podrían compartimentarse para reutilización en vez de repetir las mismas líneas de código una y otra vez. Ni siquiera estamos siendo pretenciosos de aplicar patrones de diseño y realizar una solución realmente profesional para la reutilización de ese código. No, simplemente queremos compartimentar ese comportamiento en otro lado para reutilizar, porque de por sí no tenemos tiempo para una solución profesional. Lo que es peor, muchas veces no tenemos ni siquiera de aplicar esa solución de compartimentación (Sea un método aparte, clase, etc).

Otras veces se nos ocurren modelos y clases que realmente nos podrían ayudar en el día a día, pero no estamos totalmente seguros de que sean la forma correcta, o sea que todavía son ideas que necesitan ser más pensadas.

A veces tenemos ideas para hacer aplicaciones pequeñas que nos ayuden en el día a día. Algo que nos permita grabar todos nuestros scripts de tsql que usamos para modificar la base de datos y que luego nos ayude para implementar en los demás ambientes y clientes, por ejemplo. Otro que nos genere código automático para todas nuestras tablas. Otro que tome las entidades de nuestros modelos y nos genere automáticamente nuestros ABM, ya sean ASPX o WinForms.

En fin, podemos llegar a tener infinidad de ideas (que surgen de necesidades) que podrían realmente incrementar nuestra productividad a gran escala. Incluso quizás sean tan valiosas que la empresa podría generar mucho más dinero, al poder cumplir con los proyectos en mucho menor tiempo.

La creatividad es una cosa genial, pero hay que tener cuidado con la creatividad desmesurada. He visto casos donde han puesto a programadores Juniors a codificar generadores de código.... Obviamente todavía ni sabían cómo debía ser un código.

Pero sin irnos de tema, el foco del post se centra en cómo podríamos organizar nuestras ideas para que no se pierdan. Lamentablemente cómo obtener tiempo vamos a dejarlo para otro post.

Algo que se nos puede ocurrir en un principio es tener un archivo de texto donde anotamos todas nuestras ideas. Es lo más básico que podemos empezar a hacer. Sin categorizar y sin organizar. Anotamos nuestros pensamientos e ideas y las dejamos ahí, para un día poder volver a ellas y desarrollar las ideas que realmente veamos que nos van a servir.

Luego podríamos querer organizar mejor esas ideas. Por categoría, proyecto asociado, personas involucradas, tiempo que se debe invertir, etc. Una planilla de excel puede resultar mucho más cómodo para esto, y no requerimos ningún desarrollo de nada para tener este organizador de ideas. Perfecto! De repente ahora tenemos todo mucho más organizado.

Pero el día de mañana, cuando vemos que nuestra organización de ideas nos permitió avanzar con muchos proyectos y mejorar la calidad de nuestros productos, se nos podría ocurrir "Hey, y si hago que todos los empleados aporten sus ideas?". Y ahí creamos el nuevo proyecto "Organizador de Ideas", que podrá ser una aplicación web/winform aparte, o podemos incluirlo en alguna aplicación donde ya los empleados estén acostumbrados a usar (por ejemplo, una aplicación que distribuye las tareas).

Al principio lo extendemos a un sector (seguramente sistemas) pero como vemos que dá resultado lo empezamos a distribuir a toda la empresa. Tarde o temprano terminamos teniendo toda una gestión de ideas internas muy importante que (correctamente administrado) no sólo podría llevar a la empresa a un nuevo nivel, sino que también aumentarán la moral de todos y el apego a la empresa. "Mira Jimmy, aplicaron mi idea en el reporte de balance general!". Hoy en día lograr que las personas se queden en una empresa es muy difícil, y yo lo vivo también como empleado. El factor que más me afecta es no sentir que estoy haciendo algo que me importe. En otras palabras, no estar haciendo lo que nos gustaría hacer, o estar generando los cambios que nos gustarían.

Es el problema que tuve cuando trabajé en una empresa grande. Burocracia a montones, cero creatividad en los empleados compañeros, salvo excepciones, y cualquier cosa "loca" que pudiese crear sólo iba a ayudar a un puñado de personas, y realmente no podías hacer cambios importantes ni tomar decisiones. Esto es muy desmotivador.

Una correcta gestión de ideas podría cambiar completamente el futuro de la compañía. La genialidad viene de las personas, no de ningún proceso burocrático ni de ninguna galletita de la fortuna. Generalmente uno suele tener un gurú arriba del management que dicta la dirección de la empresa. Pero... ¿y si la empresa siguiera sus propias necesidades en todos sus niveles jerárquicos?

Obviamente debemos diferenciar una idea de un reclamo: "Arreglen el aire acondicionado" no es una idea, "Despidan a fulanito" tampoco lo es. Por ello las ideas deben ser gestionadas, filtradas, y debe llamarse la atención a aquellos que participen de forma negativa. Obviamente, puede ser que arreglar el aire acondicionado sea una buena "idea" porque mejoraría la productividad y moral de los empleados. Todo debe ser analizado.

Recordemos que yo siempre hablo desde la ignorancia. Lo mío son puras ideas lanzadas al blog. Pero me resulta interesante divagar por unos momentos.

Este fué un post simplemente para fomentar el pensamiento sobre este tema. No he visto empresas que gestionen las ideas y el pensamiento en sí (que es de donde surge el verdadero conocimiento), pero seguramente hay varias por ahí (seguramente grosas en sus rubros).