Vuelta al Blog y algunos consejos para la carrera

Cambios de Empresa, Viajes a Shanghai, a Palo Alto, en el mismísimo Silicon Valley, construcción de plataformas para Cloud Computing, uso intensivo de Git, GitHub, continuous Integration (Integracion Contínua), implementacion de Continuous Deployment (Despliegue continuo), Culturas de Start Ups, etc., son algunas de las novedades de este año que ya se termina. Son demasiadas para un solo post. Vamos a ir retomando de a poco este espacio de reflexión sobre tecnología de la información, buenas practicas de Desarrollo y todo lo que hace a las metodologias ágiles y al desarrollo de software en general.

La verdad es que tuvimos un poco abandonado (tachen "un poco") a este blog gran parte del año. Hemos estado envueltos en un proyecto altamente demandante de tiempo en una empresa Start Up. Algún día con un poco mas de perspectiva escribiremos sobre esta experiencia que ha tenido de TODO menos aburrimiento. En parte es por eso que no hemos podido escribir en este blog. Estuvimos en unos de esos periodos de aprendizaje intensivo, mezclados con no-pocos-cambios y experiencias de toda índole. Y todo suceso de este estilo conllevan un ritmo que no dan mucho margen para pararse a pensar y reflexionar demasiado sobre lo que esta sucediendo.

Hoy quiero dejarles esta reflexión.

Cuando recién empezaba en esta profesión (hace poquísimos años....bueno tampoco tantos che! unos 16 añitos...) no había la diversidad de ofertas que hay en este momento. Uno elegía entre dos o tres opciones a lo sumo e iba pasando de proyecto en proyecto mas o menos como y cuando podía. Tampoco me importaba demasiado porque en ese momento pensaba (no lo pensaba, en verdad, lo "sentia" de alguna manera porque si me paraba a pensarlo es obvio que no es asi) que tenia infinitos proyectos por delante.

Habiendo ahora tantos proyectos, tantas empresas y ofertas dando vueltas por el mundo veo a un montón de gente que se conforma con lugares mediocres, con proyectos tan interesantes como palear las arenas del Sahara en verano y se aferran a trabajos malsanos o ambientes enfermos como si estuviéramos hace 30 años atrás donde un empleado entraba a una gran empresa y sabia que se iba a retirar en ella.

Por el otro lado veo tambien a chicos muy jóvenes, con mucho empuje y ganas pero que en lugar de elegir lugares adonde aprender, repito: adonde r-e-a-l-m-e-n-t-e aprender, van saltando de trabajo en trabajo como sapo perseguido porque un trabajo le ofrece 10 pesos mas que otro, sin planificar a mediano plazo. Sin planificar en que área, en que tipo de proyectos le gustaría trabajar. La gente que trabaja en IT en USA tienen muy claro esto de planificar sus carreras a mediano plazo digamos.

Muchas veces he tenido que elegir entre proyectos. A veces entre ganar mas plata y hacer algo que me interese. Elegir entre el bolsillo o el corazón. Y créanme lo que les digo, las veces que elegí con el bolsillo... nunca salieron como esperaba.

No estamos planteando acá una postura romántica o naif o a la San-Francisco-De-Asis, "Salven al mundo!! Sigan sus corazones", "Viva la pobreza", "Si a la Revolución Arabe", no (es decir, Si a la revolución Arabe pero no a Vivir en la pobreza ). Sabemos que uno trabaja principalmente por dinero y que lo que busca en general al cambiarse de trabajo es un crecimiento...en dinero.

Pero lo cierto es que si es "solo" el dinero, si el trabajo no te motiva, es aburrido o te desmotiva a cada paso, tarde o temprano terminarás odiando lo que haces, o a tus compañeros o jefes o a todos juntos... incluyendote. Y 40 horas semanales (o mas!) es demasiado tiempo para hacer algo que uno odia, verdad?.

Asi que les dejo la GRAN VERDAD NUMERO 1 de este fin de año, a modo de reflexión.

GRAN VERDAD NUMERO 1:

Hay un numero limitado de proyectos de desarrollo en los que participaremos en nuestras vidas. Elijamos aquellos que realmente nos apasionen. Somos de los poquitos profesionales en el mundo, los de IT, que podemos darnos este lujo.

Asi que, aún cuando esten recien comenzando la carrera, y sobre todo si estan en esta situacion, empiecen por pensar que quieren, que les gusta. Que les gustaria hacer los proximos años.

1. Si solo conocieron un lenguaje de programación, experimenten con otros.
2. Si solo estuvieron en consultoras de sistemas, traten de estar en el depto de sistemas de una gran empresa.
3. Si solo estuvieron en un determinado tipo de proyectos o metodología, experimenten con otros.
4. Traten de cambiar a proyectos que sean interesantes, por la tecnología o por el tema de negocio relacionado.
5. Traten de rodearse de personas que sepan mas que ustedes.
6. Empiecen un blog de sus temas favoritos, participen en foros,
7. Hagan de su CV un diamante en bruto, al cual agreguen items puliendolo asi dia a dia.

Y si hacen algún trabajo que realmente los apasiona, si son buenos y se esfuerzan cada dia por mejorar, por crecer profesionalmente, si se preocupan y toman cada nuevo comienzo como una gran oportunidad, y piden reconocimiento (noten que no dije "esperen reconocimiento"), créanme, va a suceder. Van a ganar dinero y hacer algo que les apasione.

Elijan siempre con el corazón.

Calidad III : La Relatividad del concepto

En los comentarios del post sobre la Calidad del Desarrollo de Software II tanto Walter Risi comoErnesto Kiszkurno aportaron un par definiciones distintas y muy interesantes de la calidad de software.

El concepto de la calidad de Software, en general, es decir Que hace que un software sea de calidad es uno de los temas que más discusión ha causado dentro de la comunidad de sistemas desde hace décadas.

En los 2 posts anteriores sobre Calidad del desarrollo hemos evitado justamente este tema ateniéndonos nada mas (pero nada menos) que al concepto, bastante más concreto, de que es lo que hace que un desarrollo sea de calidad. Es decir, para usar la metafora-que-odio-de-la-fabricación, que calidad tiene su construcción, su Calidad Interna.

Pero para no esquivar el bulto al problema más general, podemos plantearnos entonces , Que determina que un software sea de calidad?

El Juego

Uno de los sistemas que más utilizamos en nuestra época de estudiantes en Exactas (UBA) fue un juego (como no podía ser de otra manera) de estrategia en tiempo real llamado Dune II. Fue un juego que nos apasionó y en el cual podíamos pasarnos horas jugando hasta terminar las misiones. No obstante ese juego tenia un par de bugs molestos, uno de ellos con la Inteligencia Artificial de la maquina que justamente en determinadas situaciones no respondía bien en la defensa y el otro con el manejo del gusano de arena que ha veces se tildaba y quedaba ciclando en algún loop escondido.

Si nos hubieran preguntado allá en el tiempo pero incluso ahora que opinabamos de la Calidad de ese desarrollo, creo no exagerar en decir que era Sobresaliente, excepcional.

Hubiera agregado algo si la empresa dueña del juego arreglaba esos bugs? Probablemente hubiera sido lindo, quizás un poquito mas interesante pero....eso no hubiera cambiado la percepción de la Calidad del producto que teníamos, era sencillamente de Calidad.

Entonces, que es lo que determina que un producto de software sea de Calidad....y bueno... si no queda otra, ensayemos algunas respuestas habituales:

1) que sea utilizado por mucha gente?

Windows es el caso arquetípico de software utilizado por mucha gente que no obstante....digamos que jamás ha sido famoso por su Calidad (piensen sino en el caso cercano del Vista y ni que hablar de otros...ejem fallidos como ....alguien se acuerda del Milleniun?)

El software de Mac en general tiene asociado una fama de mucha mayor Calidad y es utilizado por muchisima menos gente.

2) que sea fácilmente usable?

El problema para determinar aquí que tal sistema es de Calidad por su usabilidad, más allá de los recientes libros y normas sobre usabilidad de Diseñadores gráficos, es que los usuarios tienden a encariñarse poderosamente con la interfaz de usuario que conocen. Siempre prefieren lo conocido por sobre lo novedoso.

Piensen sino en lo que diría un usuario de WordStar o WordPerfect si tuviera que usar el Word actual o, viceversa, si un usuario de Word tuviera que usar el Wordstar y para ambos la usabilidad de la herramienta que usan/usaban era formidable. Ni que hablar de la pelea entre los amantes de Vi versus Emacs versus editores de linea tradicionales.

Para los amantes de linux cualquier linux es totalmente fácil de usar pero si le damos una consola de comandos a una persona que siempre uso Windows...bueno...inmaginense su juicio.

3) que Tenga cero defectos?

Permitan me una sonrisa irónica, Jeje, no se conocen casos de software que se alegue que sean de Calidad por no tener Defectos sencillamente porque todavía no ha habido un software que no tenga defectos.

4) Que tenga muchísima funcionalidad y features?

Más allá de los casos conocidos como los productos de Office y para que vean que no la tenemos en contra de Microsoft ambos autores de este blog hemos utilizado un par de productos de GIS (Sistemas de Información Geográfica) de una empresa anglosajona que se podrían definir como el paraíso de la acumulación de funcionalidad y features. Uno de ellos se focalizaba en plotear mapas, el otro para hacer carga, procesamiento y consultas en sistemas de información Geográfica.

Cada uno de los productos tenia cientos de features y comandos, muchas veces con funcionalidad superpuesta que creaban una especie de frankestein gordo y pesado, un mamotreto de distintas funcionalidades mezcladas adonde nada se hacia realmente bien o perfomante porque todo era una solución de compromiso para poder hacer muchas cosas que casi nunca se necesitaban.

5) que Sea de bajo Costo y termine dentro de la planificación?

Seguramente son requisitos para el Gerente de un proyecto, el de Marketing o Ventas e incluso los interesados o StakeHolders pero...y los usuarios?

6) Que tenga buena calidad de desarrollo?

Esto justamente es lo que hablamos en el post anterior, y así como creemos profundamente que es un requisito indispensable por el mismo motivo que un edificio sin buenos cimientos se derrumbará, no es suficiente para que todo el producto, el sistema sea de Calidad. Es decir, podemos tener un sistema de una calidad de desarrollo excepcional pero que no sea útil para el o los usuarios en cuestión.

La raíz del problema

Justamente el problema que tiene cada una de las definiciones que intentamos y que han sido intentadas alguna vez, es que la CALIDAD es un término relativo. La calidad que es adecuada para una persona o tipo de persona puede ser totalmente inadecuada para otra.

Jerry Weinberg en su libro "Quality Software Management: System Thinking" habla justamente sobre este tema, y en particular como este concepto de "relatividad" se esconde incluso en

algunas de las definiciones más famosas de Calidad de Software.

Por ejemplo la de Crosby: "Calidad es el cumplimiento y satisfacción de los requerimientos", es decir que un sistema es de calidad si cumple con sus requerimientos.

El tema, o kid de la cuestión y que deberíamos preguntarnos es:

"Requerimientos de Quien o para Quien?", entonces, para ser más precisos deberíamos decir:

"Calidad es el cumplimiento y la satisfacción de los requerimientos de algunas personas"

Para cada persona el mismo producto tendrá distintas "calidades" y de hecho entonces cada sentencia que alguna vez se ha hecho o se hará acerca de la calidad del un sistema es una sentencia acerca de lo que consideran que es la calidad un determinado conjunto de personas.

Por ello, la próxima vez que estés desarrollando software, siempre, siempre preguntate:

"Quien o quienes son las personas detrás del concepto de calidad que están pidiendo para este sistema en particular"