sábado, junio 07, 2014

Programar apesta

Esta es la traducción de "Programming sucks", un blog post escrito por Peter Welch, quien también tiene un libro llamado "Y después pensé que era un pez". La razón por la cual lo pongo en mi blog (cuando no he puesto ningún artículo de ningún tercero anteriormente) es porque en base a mis experiencias profesionales plasma desde un tono muy sarcástico y hasta cierto punto real gran parte de la realidad de las personas que desarrollamos software. Se agradece cualquier comentario en general o en lo particular, y también con respecto a la (mala) traducción. Disfrútenlo.


Cada uno de mis amigos que tiene con un trabajo que consiste en recoger algo más pesado que una laptop más de una vez por semana eventualmente encuentra una forma de agregar algo como esto a nuestras conversaciones: "Bro, tu trabajo es fácil. Acabo de trabajar una semana de 4700 horas cavando un túnel por debajo de Mordor con un desarmador".

Tiene un punto muy válido. Mordor apesta, y ciertamente es mucho más pesado físicamente cavar un túnel que presionar un teclado a menos que seas una hormiga. Pero, sólo por el bien del argumento, podemos estar de acuerdo en que tanto el estrés como la locura son malos? Ok, Bienvenido al mundo de la programación.

Todos los equipos de programadores están formados (y conformados) por gente loca

Imagina que te unes a un equipo de ingeniería. Estás emocionado y lleno de ideas, probablemente acabas de salir de la escuela y lo único que conoces es un mundo de diseños hermosos y limpios, cuya unidad estética llena de propósito, economía y fuerza es inspiradora. Comienzas conociendo a Mary, líder del proyecto de la construcción de un puente en un área metropolitana. Mary te presenta a Fred, después de pasar por los quince puntos de seguridad instalados por David sólo porque a David le robaron su suéter de su escritorio una vez y sólo una. Fred sólo trabaja con madera, así que te preguntas porqué Fred está involucrado ya que este puente va a soportar tráfico pesado en horas pico, y en consecuencia va a estar lleno de autos llenos de humanos mortales que estarán cruzando una caída de 61 metros sobre rápidos salvajes. No te preocupes, dice Mary, Fred se va a encargar sólo de las banquetas. Banquetas, qué banquetas? Bueno, es que Fred puso un buen caso de uso para banquetas que ayudarán a que el puente se vea más bonito. Por supuesto, tendrán que estar construídas sin barandales, ya que hay una política muy estricta de no barandales impuesta por Phil, quien por cierto no es un ingeniero. Nadie sabe a ciencia cierta qué es lo que hace Phil, pero definitivamente está lleno de sinergia y también muy cerca de la gerencia, donde nadie de los ingenieros quiere lidiar con él por lo cual sólamente dejan a Phil hacer lo que quiere. Sara, entretanto, ha encontrado varias tecnologías ultramodernas de pavimentación, y las ha agregado todas al diseño del puente, así que tú tendrás que trabajar alrededor de cada uno a medida que la construcción del puente progresa, ya que cada uno añade un soporte diferente, así como cuestiones de seguridad. Tom y Harry han estado trabajando juntos por años, pero tienen un feudo constante con respecto a usar el sistema métrico o el imperial, lo cual se ha convertido en un caso de que "gana quien haya llegado a esa parte del diseño primero". Esto ha sido un dolor de cabeza para la gente que de hecho ha estado trabajando en ensamblar todo. Se han dado por vencidos al respecto y sólo han forzado, martillado o soldado conforme han podido con las partes que estaban a la mano. También es importante mencionar que el puente fue diseñado como un puente de suspensión, pero nadie sabía bien como construir un puente de suspensión, así que alcanzaron a construir la mitad y después sólo agregaron columnas de soporte extra para mantener lo que llevaban del puente en pie, sin embargo dejaron los cables de suspensión ya que (más o menos) siguen sosteniendo algunas partes del puente. Nadie sabe bien qué partes, pero todo el mundo está absolutamente seguro de que son partes importantes.

Después de que te han presentado a todos, estás invitado a contribuir con algunas ideas frescas y nuevas, pero no tienes ninguna porque eres un ingeniero de propulsión y no sabes absolutamente nada acerca de construir puentes.

Manejarías a través de este puente? Nop. Si de alguna forma fuera construido, todas las personas involucradas serían ejecutadas. Aún así una versión similar a esta dinámica es como cada uno de los programas que has usado en tu vida ha sido escrito. Software para bancos, sitios web, y programas que hay en todos lados que deberían proteger información en internet, pero no lo hacen.

Todo el código es malo.

Todo programador (ocasionalmente), cuando está solo en casa apaga las luces, se sirve un vaso de whisky, pone un poco de música electrónica y abre un archivo en su computadora. Es un archivo diferente para cada programador. Algunas veces fue escrito por ellos mismos, algunas veces lo encontraron y sabían que tenían que guardarlo. Leen entre líneas, y lloran por su belleza. Después las lágrimas se tornan amargas cuando recuerdan la condición del resto de los archivos y el colapso inevitable de todo lo que es bondadoso y verdadero en el mundo.

Este archivo es buen código. Las variables y funciones tienen nombres sensibles y consistentes. Es conciso. No hace nada obviamente estúpido. Nunca ha tenido que vivir en lo salvaje, o hacerle frente a un equipo de ventas. Hace exactamente una cosa, mundana y específica, y la hace BIEN. Fue escrito por una sóla persona, y nunca ha sido tocada por otra. Al leerlo asimila poesía escrita por alguien en sus 30's.

Cada programador empieza escribiendo un pequeño y perfecto copo de nieve como éste. Después el viernes le dicen que necesita escribir seiscientos copos de nieve para el martes, así que hacen un poco de trampa aquí y allá y quizá copian algunos copos de nieve y tratan de juntarlos o le piden a un compañero que les ayude trabajando en uno. Pero éste lo derrite, y después todos los copos de nieve del programador son amontonados formando una cosa horrenda e indescriptible, entonces alguien pone un Picasso encima porque nadie quiere ver la orina de gato chorreando sobre todos los copos de nieve derritiéndose a la luz del día. La siguiente semana, todo el mundo le echa más nieve para tratar de evitar que el Picasso se caiga.

Hay una teoría que dice que esto se puede prevenir siguiendo "estándares". El problema es que hay más estándares que cosas que las computadoras son capaces de hacer, y estos estándares son todos "mejorados" y maliciados por las preferencias personales de la gente que los programa, así que ni un sólo código ha logrado salir al mundo real sin haber hecho unas cuántas docenas de cosas idénticas de diferente manera otras tantas docenas de veces. Las primeras semanas de cualquier trabajo siempre se las dedicamos a averiguar cómo funciona la aplicación, incluso si estamos familiarizados con cada uno de los lenguajes, frameworks y estándares involucrados. Todo esto porque los estándares son unicornios.

Siempre habrá oscuridad.

Pasé algunos años creciendo con un clóset en mi cuarto. El clóset tenía un diseño bastante extraño. Parecía normal, pero cuando te metías a guardar algo descubrías que en la pared de tu derecha había otro compartimento, lo cual era una repisa muy conveniente. Después te acercabas, lo veías, y la pared de la parte de atrás de la repisa revelaba un espacio de horroroso vacío, donde la luz no entraba y el cual inmediatamente identificabas como el retiro de día de todo monstruo voraz que mantenías a raya con lámparas y peluches cada noche.

Así es aprender a programar. Llegas a conocer las herramientas útiles que usas en tu día a día, después miras a tu alrededor, y encuentras algunas otras herramientas a la mano y son ellas las que te muestran el horror sin fin que siempre hubo enseguida de tu cama.

Por ejemplo, digamos que eres un web developer promedio. Estás familiarizado con una docena de lenguajes de programación, cientos de librerías, frameworks, estándares, protocolos, etcétera. Todavía tienes que seguir aprendiendo constantemente la velocidad de más o menos ésta semana, y también recordar validar los cientos de cosas que conoces para ver si han sido actualizadas o alguien las rompió, y asegurarte de que todas juntas siguen funcionando y que nadie arregló el bug en una de ellas del que te valiste para hacer algo que creíste era muy listo el fin de semana que andabas borracho. Estás al día, que bien! Después todo falla.

Qué pasó!? Te dices a ti mismo, y empiezas a rastrear el problema. Descubres que un día, un idiota decidió que ya que otro idiota decidió que uno sobre cero debía ser igual a infinito, podían usarlo como un seudónimo de "infinito" al simplificar su código. Después alguien no tan idiota decidió que esto era estúpido, que era lo que el idiota original debería haber decidido, pero ya que no lo hizo, el no tan idiota decide ser un imbécil y hacer de esto un error en su nuevo compilador. Después decide no decirle a nadie que esto era un error, porque es un imbécil, y ahora todos tus copos de nieve son orina y no puedes ni siquiera encontrar al gato.

Eres un experto en todas estas tecnologías, y eso es bueno, porque ese nivel de experiencia te permite pasar sólamente de seis a ocho horas tratando de averiguar qué está mal, en lugar de perder tu empleo. Ahora tienes algo seguro que agregar a esos millones de pequeñas cosas seguras que tienes que memorizar porque la mayoría de los programas de los que dependes han sido escritos por idiotas e imbéciles.

Y eso es sólo en el área que elegiste trabajar, la cual representa una pequeña fracción de todas las cosas que hay por conocer en las ciencias computacionales de las cuales probablemente nunca aprenderás nada. No hay una sóla persona viva en el mundo que sepa cómo funciona en la Macbook de hace 5 años que usas. Porqué te decimos que la reinicies? Porque no tenemos ni la más mínima idea de qué le pasa, y es más fácil inducir un coma en ella para que su equipo de doctores automáticos internos traten de averiguarlo por nosotros. La única razón por la que las computadoras de los programadores funcionan mejor que las de los usuarios es porque los programadores saben que las computadoras son como niños pequeños esquizofrénicos con enfermedades autoinmunes y no les pegamos cuando se portan mal.

Mucho trabajo se hace en el internet, y el internet es un paisaje del infierno muy especial.

Recuerdas aquello acerca de gente loca y código malo? El internet es precisamente eso sólo que literalmente un billón de veces peor. Los sitios web cuyos carritos de compra son glorificados que tienen quizá tres páginas dinámicas son soportados por equipos de personas que trabajan contrarreloj, porque la verdad es que todo está fallando todo el tiempo, en todos lados, para todos ellos. Mientras lees esto, alguien que trabaja en Facebook está viendo decenas de miles de mensajes de error y frenéticamente está tratando de encontrar el problema antes de que todo se colapse. Hay un equipo en una oficina de Google que no ha dormido en tres días. En algún lugar hay una DBA rodeada de botellas vacías de refresco cuyo esposo piensa que ha muerto. Y si toda esta gente deja de trabajar, el mundo arde. La mayoría de la gente no sabe bien qué hace la gente de soporte, pero créeme, si todos ellos se fueran a comer al mismo tiempo no llegarían ni a la esquina antes de que te quedaras sin balas protegiendo tus latas de comida de bandas de mutantes.

No puedes reiniciar el internet. Trillones de dólares dependen de una telaraña maltrecha de acuerdos no oficiales y código "suficientemente bueno, por ahora" con comentarios como "TODO: Arregla esto es un hack bien peligroso pero no se que pasa!!!" que fueron escritos hace diez años. Y eso que ni siquiera he mencionado las legiones de gente que atacan varias partes del internet, ya sea por espionaje o por dinero, o porque están aburridas. Has escuchado de 4chan? 4chan podría destruir tu vida y tu negocio porque ha decidido una tarde cualquiera que no le caes bien, y no nos preocupamos por 4chan porque una bomba nuclear más no hace mucha diferencia cuando estás en un invierno nuclear.

En el internet es aceptable decir "Sabes qué, esto más o menos funciona a veces si usas la tecnología adecuada. y BAM! es parte del internet ahora. Cualquiera con un par de cientos de dólares y una computadora puede agregar un poco del código más horrible que quieran a una parte del internet y todo se empeora un poquito. Incluso los buenos programadores ya ni se molestan en leer las antiguas especificaciones descritas por las organizaciones que la gente creó para implementar algunos unicornios, así que todo el mundo emplea la mitad de su tiempo enfrentando el hecho de que nada va de acuerdo con nada o hace sentido y podría fallar en cualquier momento. O sólo tratamos de taparlo y esperar que nadie se de cuenta.

Aquí están las reglas secretas del internet: Cinco minutos después de que abres un navegador por primera vez, un niño en Rusia tiene tu número de seguro social. Te inscribiste para algo? Una computadora del NSA ahora rastreará automáticamente tu ubicación física por el resto de tu vida. Enviaste un correo? Tu dirección de correo ahora se muestra en un póster gigante en Nigeria. 

Todas estas cosas no son ciertas porque no nos interesan y no hacemos nada por detenerlas, son ciertas porque todo está roto porque no hay buen código en ningún lado y todo el mundo sólo trata de que todo siga funcionando. Ese es tu trabajo si trabajas con el internet: Esperar que lo último que escribiste sea lo suficientemente bueno para sobrevivir unas cuántas horas para que puedas ir a cenar y a dormir.

No empezamos locos, nos están volviendo locos.

ERROR: Attempted to parse HTML with regular expression; system returned Cthulhu.

Chistoso, no? No? Qué tal esto:

"Eso se llama arrayReverse?"
"s/camel/_/"
"Ok gracias"

A poco no fue esa persona de gran ayuda? Con el camel? Acaso esa no parece una respuesta apropiada? No? Bien. Aún puedes encontrar a Jesús. Eso significa que aún no has pasado la mayor parte de tu vida leyendo código lo suficiente como para empezar a hablar en ese idioma. El cerebro es particularmente bueno para lógica básica y ahora hay una carrera completa en no hacer nada mas que lógica muy muy compleja. Enormes cadenas de condiciones abstractas y requerimientos deben ser aprendidos a través de cosas como comas faltantes. Hacer esto todo el día te deja en un estado mental afásico mientras ves los rostros de las personas cuando hablan y no sabes cuando han terminado porque no hay un punto y coma. Te sumerges en un mundo totalmente carente de significado donde todo lo que importa es que una pequeña serie de números fue a parar a un laberinto gigante de símbolos y una serie diferente de números o la foto de un gatito salió del otro lado.

El impacto destructivo en el cerebro es demostrado por los lenguajes de programación que escribe la gente. Esto es un programa:

#include 

int main( int argc, char** argv ) {
    std::cout << "Hello World!" << std::endl;
    return 0;
}

El programa anterior hace exactamente lo mismo que el siguiente programa:


`r```````````.H.e.l.l.o. .w.o.r.l.di

Y que éste programa:
>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]
>++++++++[<++++>-] <.>+++++++++++[<++++++++>-]<- .--------.="" .------.--------.="">++++++++[<++++>- ]<+.[-]++++++++++.

Y también este:

Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook.
Ook! Ook. Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook?
Ook! Ook! Ook? Ook! Ook? Ook. Ook. Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook.
Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook.
Ook? Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook.
Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook!
Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook. Ook! Ook. Ook! Ook? Ook! Ook! Ook? Ook!
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook! Ook.

Y una vez alguien escribió un lenguaje de programación que permitió a alguien más escribir esto:

#:: ::-| ::-| .-. :||-:: 0-| .-| ::||-| .:|-. :||
open(Q,$0);while(){if(/^#(.*)$/){for(split('-',$1)){$q=0;for(split){s/|
/:.:/xg;s/:/../g;$Q=$_?length:$_;$q+=$q?$Q:$Q*20;}print chr($q);}}}print"n";
#.: ::||-| .||-| :|||-| ::||-| ||-:: :|||-| .:|

El autor describe el programa de la siguiente manera: "Dos líneas de código que parsean dos líneas de comentarios embebidos en el código para leer los números mayas que representan los caracteres individuales ASCII que describen el título de la revista, rendereados en arte ASCII rotado 90 grados"

Ese programa ganó un concurso, porque por supuesto que sí. Quieres vivir en un mundo como este? No. Este es un mundo donde puedes fumar una cajetilla diaria y nadie lo cuestiona siquiera. "Por supuesto que fuma una cajetilla diaria, quién no?" Eventualmente todo programador despierta y antes de que se encuentre totalmente conciente ve su mundo entero y cada relación en él tiene bloques de código, e intercambian historias al respecto como si los viajes de LSD impulsados por el sueño fueran una cosa normal que le pasa a todo el mundo. Este es un mundo donde la gente evita el sexo para escribir un lenguaje de programación para orangutanes. Todos los programadores forzan sus cerebros para hacer cosas que los cerebros no deberían estar haciendo en una situación que no hay forma de hacer mejor, de diez a quince horas diarias, cinco a siete días por semana, y cada uno de ellos está lentamente volviéndose loco.

Así es que no, no soy requerido para ser capaz de levantar objetos que pesen más de 22.6 kilos. Lo cambié por la oportunidad de trasquilar el vello púbico de Satán mientras cena el contenido de mi cráneo abierto, todo para que unos cuántos bits del internet sigan haciendo su trabajo por algunos días más.

jueves, enero 12, 2012

De la educación informática en México y hacia donde ir

En días pasados tuve la oportunidad de tener una charla informal con un grupo de jóvenes recién egresados (y algunos en los últimos semestres) de la carrera de ingeniería en sistemas. Esto debido a que un buen amigo mío me pidió de favor que platicara con ellos acerca de mi experiencia en desarrollo (de hecho sus palabras fueron "háblales de lo que se te ocurra"). Amablemente accedí y dicha charla fue la que me inspiró a escribir este post.

Les hablé de varias cosas, entre ellas la premisa principal fue: Hacia dónde vas o a dónde quieres llevar tu carrera? Curiosamente la mayor parte de ellos quiere tener sus propias empresas. Esto nos llevó a hablar acerca de lo complicado y competido que se encuentra el mercado mexicano de software dirigido a pequeñas y medianas empresas (para el cual inevitablemente gran parte de nuestros egresados dirige sus esfuerzos en sus primeros años como profesional), en el cual lamentablemente la mayoría de éstas prefiere al que da mas barato y no al que ofrece la mejor calidad en muchos de los casos. Les hablé también de cómo a nadie le importa tu carrera mas que a ti, y es por esto que tienen que preocuparse por cultivar sus conocimientos y seguir aprendiendo frecuentemente. De cómo la "zona de confort" puede absorberte hasta el punto en el que dures cierto número de años haciendo lo mismo sin aprender nada nuevo (y en algunos casos ni ganar más), hasta que llega el día en que te das cuenta que te has quedado atrás... entre muchas otras cosas. En repetidas ocasiones noté la expresión de las personas a las cuales les estás hablando en otro idioma y no te entienden absolutamente nada.

He visto con tristeza cómo pasan los años y la calidad de la educación universitaria al menos en mi ciudad sigue siendo tan deficiente como cuando yo egresé. Es muy triste hablar con jóvenes que están en mi misma universidad y me repiten sus malas experiencias educativas tal y como si fueran las mías, después de 6 años de haber egresado: Profesores que no conocen las materias que imparten, que no asisten a clases, que insultan a los alumnos. Materias deficientes y desactualizadas, técnicas y/o lenguajes de programación que ya no se utilizan en la actualidad, etcétera. Dicho tiempo es el mismo que tengo esperando escribir lo siguiente: Es increíble, irritante e intolerable el mal estado de la educación en algunas universidades de México en lo que respecta a ingeniería en sistemas, o específicamente hablando, programación. Mientras que en Rusia, Estados Unidos, Inglaterra y otros países de primer mundo los jóvenes universitarios ya escribieron su propio protocolo de comunicación de datos, aquí apenas se nos menciona lo que es. Mientras ellos crecen con unix y lo utilizan durante toda su carrera, nosotros apenas y hemos escuchado hablar de "Linux", cuya definición generalizada es la de "un windows gratis"... Y podría continuar con infinidad de tecnologías y herramientas que mientras ingenieros en las últimas etapas de sus carreras conocen y utilizan en un muy alto grado en países de primer mundo, nuestros ingenieros ni siquiera saben que existen.

La pregunta es: Hay manera de cambiar esto? Definitivamente la respuesta no viene por parte de nuestro sistema de educación, el cual se encuentra afectado por algunas personas que por un lado no cuentan con dichos conocimientos y por otro no tienen el más mínimo interés en contar con ellos y mucho menos que sus estudiantes lo hagan. Yo creo que la solución mas viable viene desde afuera, está en cada uno de esos estudiantes a quienes realmente les interesa aprender. El problema viene cuando vemos ese porcentaje, el cual no es muy alto. En ese caso, cómo hacemos que nuestros jóvenes, futuros ingenieros en sistemas Mexicanos, se interesen por cultivar sus conocimientos, por aprender nuevas tecnologías o lenguajes de programación?

El estudiante de ingeniería en sistemas, inclusive el recién egresado PROMEDIO tienen un panorama muy limitado en lo que a su profesión respecta, incluso al egresar de su carrera (ésto con respecto a programación). No conocen más de dos o tres lenguajes de programación, de los cuales al menos dos son materias obligatorias dentro de su carrera. De éstos, el nivel de dominio es de aproximadamente (en mi opinión) un 60% del núcleo del lenguaje cuando mucho. Como consecuencia de esto, su conocimiento de frameworks de dichos lenguajes es nulo. Otra cosa verdaderamente alarmante es su falta de cultura informática. La mayoría nunca han leído un libro de programación que no haya sido parte de su carrera (esto asumiendo que efectivamente leyeron los libros de su carrera). La mayoría no ha oído hablar de libros como el pragmatic programmer, code complete o refactoring, y ni siquiera saben que existe el pragmatic bookshelf. No saben absolutamente nada de metodologías de desarrollo de software, especialmente de metodologías ágiles. No saben quiénes son los autores de los lenguajes de programación que utilizan, ni quiénes son los principales contribuyentes del open source. Muchos menos saben de personas más jóvenes cuyas contribuciones han hecho posibles las herramientas y técnicas de programación más utilizadas en el siglo 21 tales como Martin Fowler, David Heinemeier Hansson, Gavin King, Blake Mizerany, Venkat Subramaniam, entre muchos, muchos otros.

He tenido la oportunidad de trabajar con personas de muchos países (Estados Unidos, India, Rusia, Moldova, Argentina, Brasil, Inglaterra...). En algunos casos (no en todos) la educación universitaria ha sido superior a la que recibí yo. En otros, ha sido Infinitamente superior. Entiendo que no podemos ni debemos pedirle todo a la educación universitaria, pero si considero firmemente que dichas universidades de las que hablo tienen la obligación de actualizarse y preparar mejor a nuestros futuros ingenieros. Se me ocurren varias cosas que podrían llevar a cabo. Por ejemplo, los profesores deberían inculcar a sus alumnos la semillita de la curiosidad. No les cuesta nada darles a conocer que no sólo existen lenguajes como Turbo C y Pascal, y que en el mundo real dichos lenguajes no son con lo que la mayor parte de los sistemas empresariales están hechos. Que lo más seguro es que ni siquiera van a programar en ellos al egresar (de mis colegas de carrera, diría que un 10% utiliza en su trabajo los lenguajes de programación que nos enseñaron en la escuela). De igual manera, las personas que están al frente del departamento de informática deberían llevar a cabo una reestructuración mayor al catálogo de carrera, ésto con la finalidad de proporcionar a sus ingenieros herramientas y conocimientos acorde a las necesidades de la industria del software de hoy en día, la cual lamento informarles que ya cambió. Ya no es la misma de hace 20 años cuando hicieron el catálogo de carrera. Hoy en día necesita ingenieros que conozcan lenguajes como Ruby, Java, scala, groovy, javascript... Que conozcan tecnologías como ruby on rails, Spring, Hibernate, Grails y un largo etcétera. Que sepan de orientación a objetos, de patrones de diseño, de arquitecturas de software, de principios SOLID, de paradigmas de programación No Turbo C, ni Pascal, ni Flash...

Por otro lado, es alarmante la pasividad, parsimonía y conformismo (en muchos casos parte de nuestra cultura) que tienen nuestros estudiantes por aprender. Yo lo viví. Yo no leía, ni estudiaba, ni me preocupaba por aprender lo que se supone me deberían de enseñar como parte de mi carrera. Y como yo ha habido, hay y habrá muchísimos estudiantes en México. En general no nos educan ni nos enseñan a ser estudiantes activos. No leemos. No nos preparamos. No nos interesa. Creemos que saliendo de la universidad nos vamos a hacer ricos y vamos a ser exitosos, pero nunca nos preocupamos por el cómo. En otras palabras, es un problema de actitud, y en gran medida, cultural.

Sin embargo, el común denominador del ingeniero de software profesional desde mi punto de vista es el siguiente:

  • Se preocupa por aprender nuevos lenguajes y tecnologías
  • Es autodidacta y lo pone en práctica día a día
  • Se mantiene informado con respecto a nuevos (y viejos) lenguajes, tecnologías y frameworks
  • Tiene una mente abierta que le permite seleccionar la herramienta adecuada para el trabajo
  • No tiene miedo ni parálisis paradigmática por incursionar con una nueva tecnología o lenguaje

Qué necesita el recién egresado o cualquier ingeniero de software para llevar a cabo esto? Si acaso la virtud de ser autodidacta, la cual no todos tienen. Fuera de ahí, todo es cuestión de actitud y y deseo hacer las cosas. Esto es algo que es necesario inculcar a nuestros jóvenes. Es necesario que los ingenieros en sistemas con experiencia como yo nos acerquemos a los jóvenes y a las universidades y hagamos esto de su conocimiento. Para ello existen las comunidades de software por ejemplo, donde la gente puede enriquecer sus conocimientos de manera gratuita y gratificante. Por otro lado, nada nos cuesta acercarnos a las universidades y hablar acerca de esto. Cuál es el beneficio? Generar una comunidad de profesionales que se ayuden unos a otros, lo cual inevitablemente elevará el nivel de la comunidad en cuanto a desarrollo de software y mejorará la industria mexicana. Sé que no es fácil, pero es la una de las formas más sencillas que tenemos de combatir el rezago informático en el que nos encontramos y así poder competir con los países de primer mundo en todos los aspectos.

Te interesa? Entonces ve y haz algo por nuestros jóvenes de alguna forma. Da una charla en una universidad. Asiste o expon en alguna de las comunidades de software en tu ciudad. Habla con uno, dos o un grupo de jóvenes de tus experiencias. Diles lo que en tu opinión deben hacer para mejorar. Más de uno te lo agradecerá.

miércoles, mayo 25, 2011

Especialista o generalista?

Como producto de mis experiencias en el desarrollo de software a lo largo de estos años, me he formado una opinión/teoría/psicosis que dice así: En el desarrollo de software hay dos caminos que puedes seguir en los primeros años de tu carrera. Son como dos lados de la fuerza. No necesariamente uno es bueno y el otro es malo. No hay un lado de luz y uno de oscuridad, ni eres un Sith o un Jedi por estar en uno ni en otro. Me refiero a el ser especialista contra el ser generalista.

Hubo un momento de mi carrera en el que me preguntaron: Tú que quieres ser, especialista o generalista? En ese momento dije sin pensarlo mucho: Especialista! En ese momento no tenía clara ni la definición, ni las ventajas, ni las desventajas y sobre todo, diferencias entre uno y otro como la tengo hoy. Pensamientos que quiero plasmar para la posteridad.

Comencemos analizando al Especialista, alias mago, gurú o Master of the [inserta_nombre_de_lenguaje_o_tecnología] Universe. El especialista es un experto en una disciplina (al ser experto en varias se convierte en generalista). Conoce hasta los más mínimos pormenores y recovecos de dicha disciplina, ya sea un lenguaje de programación, una tecnología, un framework, etcétera. Así como un amplio set de características o herramientas que giran en torno al mismo. Se ha enfretando a los problemas más complejos de dicha disciplina, y ha aprendido cómo solucionarlos.


Y empecemos por el ejemplo. Un verdadero especialista en un lenguaje de programación o tecnología conoce el core de la misma a la perfección. Sabe las diferencias entre las versiones de la 1 a la más reciente (que puede ser la 12). Conoce los bugs que cada una de las versiones tiene, cómo pueden surgir y los workaround para "solucionarlos". Si tomamos como ejemplo más concreto a un especialista en Java, sabe como funciona la máquina virtual, cómo colapsarla, conoce incluso el código del garbage collector, el módulo de seguridad java y demás características o añadidos del lenguaje. Vive para solucionar problemas complejos en sistemas construidos sobre dicha plataforma. Y lo mejor de todo es que es capaz de hacerlo sin problemas gracias a sus múltiples experiencias, y en consecuencia percibe cuantiosas ganancias por hacerlo. Llega, soluciona el problema y la mayoría de las veces, se va. En ciertos sectores del software se le conoce como consultores. Exponle un problema en específico a un consultor y te lo solucionará de inmediato (básicamente porque para eso lo contraste como experto).

Por otro lado tenemos al generalista. El generalista conoce un gran número de lenguajes de programación, desde estructurados, funcionales, declarativos, orientados a objetos, etcétera. No es un experto en todos ellos pero conoce las características generales de cada uno, así como las ventajas de utilizar uno sobre otro para llevar a cabo una determinada tarea. De la misma manera conoce un gran número de herramientas y frameworks para llevar a cabo todo tipo de objetivos, desde el boostrap de un proyecto, pasando por migraciones de bases de datos hasta llegar al objetivo principal del sistema en cuestión. Conoce además los sistemas operativos y ambientes en los que se ejecutarán dichos sistemas, y saben cuál y porqué es el adecuado o los problemas que puedan existir a causa de dicho ambiente. Es el héroe de mil batallas (en este caso, mil proyectos). Es un consultor por naturaleza. Tiene la capacidad de llevar a cabo la incepción de un proyecto en su totalidad. Exponle el problema que tiene tu empresa y él analizará el problema y te dará una o varias soluciones para tu problema, basadas en diferentes lenguajes, herramientas, frameworks y sistemas operativos dependiendo el tipo de problema. Ya dependerá del cliente o la empresa la solución a tomar, ya sea la mas barata (y quizá la menos eficiente) o la más eficiente sin importar el costo de la misma. O inclusive un punto intermedio, ustedes me entienden.



Las ventajas de ser un especialista son, primero que nada, que el especialista generalmente tiene o puede obtener un empleo muy bien remunerado en base a esto (solucionar grandes problemas es bien pagado, no?). Si el especialista se dedica a dar consultoría, quizá ande por todas partes del mundo solucionando problemas específicos de su especialidad, y de paso divirtiéndose y viviendo bien de ello. Incluso si el especialista lo desea (sé de varios), puede convertirse en un referente de la tecnología o lenguaje que domina, ya sea en la empresa para la que trabaja o posee o como parte de una comunidad. Tal es el caso de infinidad de personas como Yukihiro Matsumoto, (creador de Ruby), David Heinemeir Hansson (creador de Rails), Blake Myzerany (creador de Sinatra), James Gosling (creador de java) entre muchos, muchos otros.

Ahora hablemos de las desventajas. Primero que nada, y como bien lo dice Chad Fowler en su libro The Passionate Programmer: Estás poniendo todos tus huevos en una sola canasta. Y esto no siempre es bueno. Que pasa si el día de mañana la tecnología que dominas se convierte en obsoleta? Que pasa si (por ejemplo) en un año o dos otro lenguaje como Scala o el nuevo lenguaje G (si, saben de quien. Y no existe, aún) destrona a Java? En un momento dado sabemos que el experto pragmático se adaptará y tarde o temprano se cambiará al lenguaje G y dejará Java. Quizás.

Otra desventaja desde mi punto de vista es la falta de perspectiva. El ser especialista te convierte en experto de un área de la tecnología, pero muchas veces te roba la perspectiva que te otorga el ser generalista. El especialista quizá quiera hacer todo con el lenguaje de su especialidad, cuando muchas veces quizá no sea la mejor herramienta para el trabajo. Un ejemplo muy sencillo es, Abrir un archivo en Java toma 10 líneas de código. En Ruby o Perl toma 3. Ah, y Perl es mucho mas rápido que Java para dicha tarea.

Una más (y muy importante) es el mercado. El generalista en general percibirá mucho por la naturaleza de su trabajo, pero al ser consultor puede haber temporadas en las que simplemente no tenga trabajo... ups. Además, su mercado puede no ser tan amplio en determinado momento. Por otro lado, también habrá temporadas en las que deba rechazar trabajo porque simplemente no pueda con tanto.

Ahora platiquemos un poco acerca de las ventajas de ser generalista. Primero que nada, nuestro amigo generalista puede estar en cualquier tipo de proyecto llevando a cabo cualquier rol. Si, sabemos que no lo va a hacer tan bien ni en tan poco tiempo como el especialista. Pero el generalista acumula experiencia en cada proyecto que lleva a cabo, y en base a esto posee un buen juicio para seleccionar tecnologías progresivamente (Gracias a Blake Myzerany por esta idea). No tiene problemas en moverse de un lenguaje, tecnología o proyecto a otro y en consecuencia generalmente no tiene problemas en encontrar trabajo. Tiene la habilidad para aprender y adoptar una nueva tecnología sin problemas, y a una velocidad asombrosa.

Cual sería la desventaja del generalista? Una sería que no está a la altura ni tiene la experiencia y los conocimientos de un especialista con respecto a una tecnología en particular. El especialista puede resolver en 1 hora lo que al generalista le puede tomar cuatro. 


En mi carrera he tenido la oportunidad de trabajar con excelentes ingenieros, tanto especialistas como generalistas. En lo personal yo estoy siguiendo el camino del generalista. Por una parte porque es el que más me atrae. Es por donde me ha llevado la vida. La empresa para la que trabajo actualmente está llena de ellos, y son brillantes en lo que hacen. Cada día aprendes algo nuevo de ellos. He visto y vivido el cómo un generalista (o un conjunto de ellos) puede llegar con cualquier cliente o compañía y decirle: Esto es lo que necesitas. Y ver cómo se convierte en un éxito y cómo el cliente queda satisfecho con el producto o servicio que se le está brindando.

Por último, les dejo una idea que me compartió uno de mis ejemplos a seguir, el sr. David Martinez en alguna ocasión. El objetivo a largo plazo de un generalista debe ser convertirse en un generalista-especialista. Esto es, a lo largo de una carrera de más de veinte años, puedes ser un experto en varios lenguajes y tecnologías, siguiendo el camino adecuado, acumulando veinte años de experiencia valiosa y valuable (en contraste con acumular un año de experiencia repetido veinte veces) y llevando a cabo decenas de proyectos. Inevitablemente llegarás ahí. David Martínez se encuentra ahí. Y allá es a donde quiero llegar yo.

Y tu, qué quieres ser y a dónde quieres llegar en 20 años?

martes, abril 19, 2011

Magma Rails edición 2010

Antes de comenzar con el tema actual, quiero decir que por un lado me siento mal de tener casi un año sin escribir nada (y seis meses con este post en borrador), y por otro lado es increible como un proyecto (o dos, o tres... y así) pueden alejarte tanto de hacer las cosas que te gustan (como bloggear). Pero bueno. Es hora de retomar el buen camino.

En Octubre del año pasado (si, ya hace mucho de eso) tuve la gran fortuna de poder asistir al primer congreso de ruby on rails celebrado en Mexico (En Colima para ser exactos), MagmaRails, el cual estuvo simplemente Excelente con E.


Hacia varios años que no asistia a ningun congreso, basicamente porque a los que asistí en mis épocas de estudiante e incluso un poco después habian sido una verdadera pérdida de tiempo. Debo confesar que mis expectativas de éste eran altas debido a lo siguiente:
  • Primero que nada, el eje central del congreso era... Ruby on Rails!
  • Segundo, tanto los creadores de Ruby y Rails (empezando por Matz) como la comunidad siempre se han preocupado por crear de manera pragmática y apegados a buenas prácticas de ingeniería desde el principio, siguiendo, patrones de diseño, desarrollo, y ni que decir del nivel de testing. Al desarrollar con rails automaticamente implementas estos conceptos y tecnicas de desarrollo y se vuelven inherentes a tu forma de desarrollar.
  • La comunidad de rails Mexico iba a estar involucrada, la cual tiene mucha experiencia real y valuable en proyectos internacionales hechos en rails.
  • La conferencia tenia el apoyo de varios patrocinadores como rubycentral, the hybrid group, entre otros. Compañias que se dedican a Rails de tiempo completo. Mas experiencia!
Y no me equivoqué. Vaya que valió la pena!

La organizacion del evento corrio a cargo de la gente de Crowd Interactive, con la ayuda de varias empresas y patrocinadores externos como rubycentral, the hybrid group y la comunidad de rails en Mexico, entre otros.



La mayor parte de las conferencias fueron impartidas por los mismos desarrolladores y diseñadores de esta empresa. El resto fueron impartidas por invitados de el resto de las empresas, como Jonathan Dean, Blake Myzerany (creador del framework Sinatra para aplicaciones web en Ruby) y Ron Evans (Principal de The Hybrid Group), entre muchos otros. Como podria esperarse de gente que viene del extranjero dedicada al desarrollo profesional de aplicaciones rails, sus conferencias fueron simplemente extraordinarias. Me quedo con las siguientes enseñanzas:
  • Ruby on rails es la mejor herramienta para desarrollar aplicaciones web a la medida que NO sean empresariales, por infinidad de razones.
  • Los puntos debiles de seguridad de un sistema web son finitos, y no son los mismos que un sistema standalone. Si realmente quieres blindar tu sistema, estudia sus debilidades y aprende a protegerlas.
  • La experiencia viene del buen juicio. El buen Juicio viene de malas experiencias (Blake Myzerany).
  • Ruby no es bueno para absolutamente todo. Java tampoco. No hagas todo en un solo lenguaje. No seas experto en un solo lenguaje. Aprende muchos y selecciona la mejor herramienta para hacer el trabajo que tienes por hacer.
  • Git es, por mucho, el mejor control de versiones que existe en la actualidad, principalmente por ser distribuido, por su manejo de ramas, repositorios remotos, etcétera (si, es tema de otro post).
  • JQuery es un framework asombroso, pero si realmente quieres optimizar tu aplicación web con él, tienes que des-aprenderlo y aprenderlo, para después conocerlo bien y saber utilizarlo de la mejor manera (tips de Jonathan Dean).
  • Si quieres migrar una gran cantidad de datos de un sistema a otro, de una base de datos o medio de almacenamiento a otro, etc. Existe una técnica llamada ETL (Extract, Transform and Load) y herramientas que te permitirán hacer el trabajo de una manera rápida y eficiente.
  • La programación es como la música (notas perfectas en armonía para una pieza magistral) y un buen equipo de desarrollo es como una de las top rock bands del mundo (si, esa que te encanta). Este concepto es bastante interesante y yo ya lo había visto de esa forma, porque he tenido la fortuna de trabajar con excelentes "músicos", si saben a lo que me refiero.
Para mi es muy interesante y emocionante a la vez ver este tipo de congresos y actividades en México. Creo que nuestro país necesita de este tipo de eventos llevados a cabo por este tipo de organizaciones, a las cuales no les interesa realmente hacer un negocio de ellos, sino enriquecer los conocimientos de la gente y mostrar a la comunidad lenguajes, herramientas y principios para llevar a cabo software de calidad.

Me emociona aun más que no fue ninguna universidad ni corporación la que organizo este evento (al cual considero un evento de calidad y vanguardia por la tematica, el nivel de las conferencias, los invitados, etcétera) sino una empresa ubicada en Colima, ciudad hermosa y pequeña, donde a diferencia de mi natal Guadalajara, las distancias son cortas, la comida deliciosa, el clima es caluroso y al parecer es un lugar donde se puede vivir muy bien. En esta ciudad hay una empresa que hace software utilizando Ruby on rails, cuya gente es altamente profesional. Ellos fueron los que trajeron a nosotros (los pocos que contamos con la fortuna de, primero que nada enterarnos, segundo asistir) una probadita de las herramientas que existen para hacer software de calidad. Enhorabuena señores, se necesitan mas empresas como ésta en México. Gracias!

Y ya para terminar, estamos listos para la revancha! (MagmaRails 2011 en Manzanillo). Si tienen oportunidad de asistir, se las recomiendo ampliamente.

    lunes, marzo 01, 2010

    El valor del software en Mexico

    Como todos ustedes saben, el software cuesta. Si, es de lo que nosotros los desarrolladores, ingenieros/arquitectos en software, Analistas de negocios, ideres de proyecto, testers y demas profesionales de IT vivimos. Es a lo que dedicamos gran parte de nuestro dia y de nuestra vida. Puedo decir que a la mayoria de nosotros nos gusta y nos apasiona lo que hacemos, pero esto no nos serviria como modo de vida si no nos pagaran por ello. El software tiene un valor cuantificable en base a diferentes metodos establecidos por la ingeniería del software y otras vertientes no "oficiales" (modelos de estimación, horas-hombre, etc.) y generalmente el software tiene un valor alto, especialmente porque en un sistema interviene mucha gente, requiere un gran esfuerzo y lo mas importante: esta hecho en su mayoria de neuronas. Es como un rascacielos, un ferrari, un F-16 o cualquier pieza formidable de ingenieria hecha por el hombre.

    Gran parte del problema del que hablamos (Y no solo en Mexico, sino tambien en otros paises, especialmente de Latinoamerica) tiene que ver con la cultura de la gente con respecto al software, en este caso de nuestros clientes. Es bastante contradictorio porque al final gracias al cliente nosotros percibimos los frutos por nuestro trabajo (si, hablo de dinero). Pero a pesar de esto no deja de ser un problema. Antes de continuar, me gustaria aclara que no estoy hablando de todos los clientes. Hay clientes buenos y clientes malos, en todos los giros. Ahora, continuando con el tema, consideremos los siguientes argumentos:
    • Primero que nada, desde mi punto de vista el problema mas grande es que en Mexico la mayor parte de la gente que utiliza software (cualquier software) tiene el falso conocimiento o la "cultura" de que el software no cuesta. Y reitero, la mayor parte, no todos. Ejemplo: Que sucede cuando necesitamos una persona o compañia necesita un software que no es gratuito? (parentesis, mucha gente ni siquiera sabe que hay software por el que hay que pagar, mucho menos que hay software open source) Acudimos al Centro de Distribucion de Pirateria mas cercano a comprar un cd pirata, o en su defecto, bajamos una version del software de internet y buscamos un crack. Listo! Un software que vale miles de pesos ya nos costo de 50 o 30 pesos, a nada. Lamentablemente en legislacion de software todavia estamos muy lejos de los paises del primer mundo, donde la pirateria no existe porque es penada por la ley. Lo mas ironico de todo esto es que en Mexico la pirateria es delito grave (Articulo 429 del Codigo Federal y 223 de la Ley de Propiedad Industrial), el cual esta penado con de 2 a 7 años de prision y multas de 100 a 10 mil dias de salario minimo. Sin embargo, en cualquier tianguis, mercado o puesto ambulante podemos ver y comprar software pirata. Es casi como ir a comprar un periodico, y las autoridades tan tranquilas...
    • Segundo (en consecuencia del primero), el cliente generalmente considera alto el precio del software (de cualquier software). Punto. En mi opinion, esto es en gran medida (independientemente del primer punto) debido a que el software no es un activo tangible para las personas y/o empresas, la gente que lo compra no puede entender ni explicarse porque esta pagando tanto dinero por algo virtual e intangible. Al fin y al cabo no es lo mismo comprar un BMW que una licencia corporativa de Oracle, SAP o similares, cierto?
    • Tercero. Los clientes siempre estan buscando "disminuir costos" y precisamente uno de los candidatos favoritos para hacer esto es disminuir los costos del software (o simplemente no gastar en el), sin saber o tener pleno conocimiento de que la funcion principal o razon de ser de un sistema es precisamente optimizar los procesos de la empresa, y por consecuencia reducir los costos de operacion de la misma.
    • Cuarto. Otro factor que interviene en los bajos costos del software son lo que conocemos como "soluciones al vapor", de las cuales forman parte el ejercito de generadores de contenido tipo Joomla. Existen infinidad de herramientas (unas muy buenas, otras muy malas) tanto para acelerar el desarrollo de un software como para casi generar el software por completo. Esto es lo que hace posible que una empresa de software pueda entregar un sistema en cuestion de dias en lugar de meses. Tal es el caso de Joomla (por poner un ejemplo), donde en base a sus modulos puedes llevar a cabo un portal web completo con un template basado en CSS, foros, e-commerce, RSS etc. en un tiempo record. El problema viene cuando se desea dar mantenimiento o agregar nueva funcionalidad a dicho sistema, ya que en el caso de los modulos o el codigo generado, generalmente es bastante complicado de entender, y en consecuencia de modificar. En el caso de las herramientas aceleradoras de software es muy diferente. Si el o los desarrolladores seleccionan una buena herramienta y saben utilizarla, los resultados pueden ser por demas favorables tanto para el cliente como para ellos. Es muy importante remarcar que no todas estas soluciones son asi. Existen muchas soluciones por demas utiles y optimas, pero hay que conocerlas y saberlas utilizar.
    • Quinto. Para cerrar con broche de oro, esto ocurre en consecuencia de todos los puntos mencionados anteriormente. Tristemente hay infinidad de desarrolladores que disminuyen extremadamente el precio que le ponen a su trabajo con tal de no perder el negocio y llevar a cabo el sistema, lo cual ha venido ocasionando desde hace varios años que la oferta del software a la medida disminuya sus precios considerablemente por la ya conocida frase (sarcasticamente) "Pero si el de enfrente me lo da en 3 pesos joven..."
    Ahora bien, de nada sirve quejarse si no propones soluciones. Que podemos hacer nosotros como profesionales del software para solucionar o al menos mitigar un poco toda esta situacion? Lo que escribo a continuacion han sido soluciones para mi y las personas cercanas con las que desarrollo sistemas. Ustedes, mis queridos lectores son completamente bienvenidos a adoptarlas como propias o rechazarlas categoricamente:
    • Haz que el cliente te conozca a ti y a tu trabajo. Que el cliente se entere de que tu eres el mejor desarrollador que puede contratar en el mercado (porque lo eres, o no?) y demostrarlo. Muestrale tu curriculum, tu portafolio de trabajo, hablale de todo lo que has hecho, de tus experiencias en diferentes proyectos. La confianza del cliente es algo que debes de ganar y nunca debes perder a lo largo de todo el proyecto, e inclusive de proyectos posteriores para los que pueda contratarte en base a la primer impresion. (esto claro, si el cliente es buen cliente).
    • Atiende a tu cliente. Siempre. Como ya lo mencione en el articulo pasado, el cliente es una pieza fundamental en el proceso de creacion de el proyecto, basicamente porque el es quien conoce perfectamente las reglas de negocio del sistema. Tener al cliente cerca garantiza que estas haciendo las cosas bien y que el sabe que estas haciendo las cosas bien. Involucralo lo mayor posible en tu proyecto y todo marchara bien.
    • Fundamenta el costo de tu sistema. Porque tu sistema cuesta lo que cuesta? Es por el tiempo de desarrollo que se le invirtio? Es acaso porque no utiliza software libre sino con una licencia comercial? Que tipo de optimizaciones tiene? Que base de datos utiliza? Cual es el stack de tecnologias que involucra? Esta hecho en un solo lenguanje o el stack de tecnologias tiene una complejidad alta? Que tan complicado fue implementarlo? Cuanto costaria si lo compra con el de enfrente? Todas estas respuestas son las que tu le debes de dar a tu cliente a la hora de manifestar el costo del sistema. Quiza el cliente no te entienda, o quiza pida una segunda opinion y comprenda que realmente el precio que le estas cobrando es justo.
    • Selecciona adecuadamente tus armas. Dependiendo del tipo de sistema que se va a llevar a cabo es necesario hacer un analisis acerca de el (o los) lenguaje(s) de programacion y herramientas a utilizar para construir el sistema. Elegir adecuadamente el lenguaje de programacion y el stack de tecnologias a utilizar garantizan en gran parte el exito del proyecto. No vas a hacer un sistema web en Delphi, verdad?
    • Define lo que vas a desarrollar, y en consecuencia a cobrar. No trabajes gratis. Define (por contrato si es necesario) todos los pormenores del  trabajo que vas a llevar a cabo, asi como el costo total del mismo. De esta manera te evitaras retrabajo, contradicciones y malentendidos con tus clientes.
    • Se etico y profesional. Una gran parte de mis clientes han venido a mi con una gran desconfianza debido a que "todos" los programadores anteriores que han contratado les han quedado mal, les han cobrado de mas, o todas las anteriores. Siempre tienes que mantener la etica y el profesionalismo ante todo. Cumple con tus fechas de entrega. Se transparente. No cobres de mas. Busca siempre la mejor solucion para tu cliente, y no la que mas te convenga a ti economicamente. No es necesario hacer un total rediseño de un sistema si el cliente solamente necesita ajustes de performance...
    Y la mas importante:
    • Selecciona tus batallas. Si el cliente no esta dispuesto a ayudarte con el proyecto, dedicarle tiempo a revisarlo junto contigo y ver que todo vaya bien, asistir a las juntas y a las demostraciones... No trabajes con el. Al final te veras envuelto en un proyecto tipo "marcha de la muerte" (death march) donde nada sale en tiempo, hay cambios de requerimientos constantemente y tu reputacion se vera dañada. Algunas veces es mejor decir no a este tipo de clientes. Ya vendran proyectos mejores.
    En conclusion, el valor del software en Mexico es y sera por varios años muy bajo. Tristemente para nosotros los desarrolladores asi es. Es por esto que gran parte de nuestro trabajo es orientar al cliente en estos temas y difundir toda esta informacion entre la gente que no la conoce. Por otra parte, lo que yo creo que podemos hacer para que las cosas cambien poco a poco con respecto al valor del software en Mexico esta escrito aqui. Al menos si no podemos cambiar al mundo, por lo menos a nosotros como desarrolladores nos ahorrara muchos dolores de cabeza y retrabajo.

    Hasta la proxima...

    miércoles, febrero 03, 2010

    Agil como el viento

    Como la mayoria de ustedes saben, la ingenieria del software es toda una ciencia, aunque algunos de nosotros la apliquemos y la queramos ver mas como un arte. Como toda ciencia, tiene procesos formales, metodologias, etc.
    A lo largo de la era informatica, y desde que surgio la necesidad de desarrollar y manejar proyectos de software, se han inventado e implementado junto con ellos diferentes metodologias para dicho proposito. La mas comun (hasta hace tiempo) era el modelo de cascada (waterfall), donde un proyecto de software (sin importar su tamaño) pasaba por seis etapas perfectamente identificables:
    • Planificacion y analisis (de todo el sistema)
    • Diseño (de todo el sistema)
    • Codificacion (de todo el sistema)
    • Pruebas (de todo el sistema)
    • Documentacion (de todo el sistema)
    • Despliegue (de todo el sistema)
    Existen dos principales (y muy grandes) inconvenientes al utilizar este modelo de desarrollo:
    • Para cuando se pasa de una etapa a otra, las reglas del negocio ya cambiaron, lo cual repercute en un cambio en los requerimientos del sistema (queeeee?, pero si el diseño del sistema ya esta hecho!)
    • La etapa de pruebas posterior a una etapa de codificacion de todo el sistema, arroja una gran cantidad de defectos, lo cual ocasionará volver a la etapa anterior (lo cual rompe con el modelo de cascada, y lo convierte parcialmente en un modelo iterativo)
    En la compañia para la que trabajo se utiliza una metodologia de desarrollo un poco diferente. Su nombre es agil. Y se lo que se estan preguntando. En que difiere agil del resto de las metodologias? .

    Agil propone un modelo de desarrollo donde la totalidad de requerimientos del sistema (todas sus reglas de negocio) se pueden dividir en pequeñas tareas llamadas historias (normalmente llamados requerimientos). En lugar de tener un solo ciclo de desarrollo (tambien llamado release), se tienen pequeños ciclos de desarrollo llamados iteraciones. La duracion minima de una iteracion es una semana, y la maxima es un mes. Durante dicha iteracion, el equipo de desarrollo en conjunto con el cliente, evaluan las historias de mayor prioridad y hacen un estimado de las historias que se pueden llevar a cabo durante el tiempo que dura dicha iteracion. Esto genera un compromiso del equipo de desarrollo hacia el cliente de tener una pieza de software funcionando y con un numero de defectos minimos al terminar la iteracion, y esta es la principal premisa de agil: Desarrollo estable y funcional de una pieza de software en pequeños ciclos de tiempo. Lo anterior permite que el proyecto tenga una gran adaptabilidad a los cambios, los cuales resultan relativamente faciles de integrar en cualquier etapa del proyecto.

    Un equipo de desarrollo agil es un conjunto de personas dedicadas a llevar a cabo un proyecto de software apegandose a los lineamientos de la metodologia agil. Generalmente involucran roles como pueden ser lider de proyecto (PM), analista de negocios (BA), analista de calidad (QA), desarrolladores (si, esos que programan) y lideres tecnicos (si, esos que saben como hacer sistemas de la A a la Z, toman las decisiones dificiles y dan la cara si se equivocan). Cada uno tiene su rol bien definido dentro del proyecto, y trabaja en conjunto con el resto del equipo para llevarlo a cabo. Lo ideal es que esten en constante comunicacion y fisicamente en el mismo lugar. Si esto no es posible... lean el siguiente parrafo (y si no, tambien).

    La segunda premisa principal de agil es el scrum. El scrum es una pequeña reunion diaria que se integra a la metodologia agil y se convierte en una poderosa herramienta para la colaboracion. En dicha junta (de 10 minutos aproximadamente) se reunen los integrantes del equipo de desarrollo y el cliente (es opcional para el, pero recomendado). Cada uno de los integrantes del equipo expone al resto del grupo cuales fueron los objetivos que alcanzo el dia anterior, que objetivos planea alcanzar y si tiene algun problema o inconveniente (roadblock) para hacerlo. Si lo tiene, una persona del equipo se debe ofrecer a ayudarle, y en caso de que nadie pueda hacerlo se debe llegar a un acuerdo acerca de como esta persona podra continuar trabajando. Esto ayuda a una constante comunicacion por parte de todo el equipo, a medir el progreso constante de cada uno de los integrantes del equipo y a que cada uno de los integrantes logre un progreso bastante considerable durante la iteracion. Todo mundo se mantiene ocupado, nadie se mantiene bloqueado.

    Hum... Mencione tambien que nos ahorramos generar toda esa documentacion (inuti, tediosa y que nadie lee ni vuelve a leer, en muchas ocasiones) cuando se lleva una metodologia formal (como puede ser CMM)? Ah, pero esto es una bendicion y una maldicion a la vez, ya que genera una gran desventaja para agil... Al ser una metodologia no tan formal como las demas, no todos los proyectos de software se pueden llevar a cabo con ella. (Nada es perfecto en esta vida).

    En la actualidad una gran cantidad de compañias de desarrollo, e incluso consultores externos han adoptado metodologias agiles para el desarrollo del software, ya que con este se pueden generar piezas de software de mayor calidad en un tiempo relativamente corto, ademas de que tanto el cliente como la parte que desarrolla se mantienen satisfechos con el desempeño, ya que los objetivos y el progreso se van visualizando al termino de cada iteracion.

    Si eres consultor externo, puedes leer un poco mas acerca de la metodologia y sus practicas. Si trabajas en una compañia de software que aun no adopta esta metodologia (o peor, que no tiene procesos formales) es una buena oportunidad de presentarselo a quien debas...

    Interesante, no?

    miércoles, diciembre 16, 2009

    De empleos a empleos

    En nuestro México lindo y querido, la gente de IT en general (IT, Tecnologias informaticas) sufre bastante para encontrar un buen empleo. Un buen empleo desde mi perspectiva es donde se tiene un sueldo competente y acorde con las labores que se llevan a cabo, donde se paga puntualmente, y te dan un poco o un mucho mas que nuestras fabulosas y omnipotentes prestaciones de ley mexicanas. Y sobre todo donde te sientes a gusto trabajando. Al menos esa fue mi experiencia y la de muchos colegas que conozco al comenzar a trabajar en nuestra area.

    Ocasionalmente buscando en las bolsas de trabajo en internet, nos podemos encontrar diferentes tipos de ofertas de empleo, entre las cuales "sobresalen" anuncios como el siguiente, en el cual respeto la pésima redacción para fines críticos:

    Se solicita ingeniero en sistemas con los siguientes requisitos:

    *EXPERIENCIA: MINIMA 3 AÑOS COMPROBABLES
    -LIDER DE PROYECTO
    -DESARROLLADOR DELPHI 2007 VER 2010, Win32, Net, Kylix
    -MODULOS ERP
    -REDES
    -DESARROLLO WEB, .NET, WIN32
    -ADMINISTRADOR SERVIDORES WIN´NT Y LINUX
    -BASES DE DATOS; FIREBIRD, INTERBASE, SQL, SERVER, PARADOZ, DBF, My SQL
    -INSTALACIÓN, MANTENIMIENTO Y ADMINISTRACIÓN DE SERVIDORES WINDOWS.
    -CONOCIMIENTOS DE PROGRAMACIÓN BÁSICA EN OTROS LENGUAJES: VISUAL, BASIC,
    jBUILDER, BUILDER C++, PHP, JAVA

    Cual es tu impresion al ver este anuncio? Estas sorprendido? asustado? te mueres de risa...? Analicemos la oferta de trabajo con detenimiento:
    • Comencemos por los 3 años comprobables de experiencia. Nosotros los programadores sabemos que en 3 años no puedes aprender todo esto. Por lo cual deducimos que el autor(a) del anuncio no tiene la mas minima idea del tiempo que toma adquirir experiencia en todo lo que pide en 3 años. En mi opinion, al menos se necesita el doble de tiempo, y aun asi no se es un experto en todas las areas.
    • Que sepa redes. El concepto de redes es muy general y ambiguo... Que parte del campo de estudio de las redes? Quieres que tu ingeniero monte toda una infraestructura de red, conecte un modem de Telmex, configure la conexion a internet en una PC o todas las anteriores...?
    • La administracion de servidores de Windows NT y Linux es una ciencia aparte. Para llegar a ser un administrador decente en solo UNO de los dos sistemas operativos (y estoy hablando sin certificacion incluida) tienes que dedicarte a la infraestructura un par de años como minimo. Tienes que ser un experto en el sistema operativo a nivel administrador, lo cual incluye (ademas del total dominio y conocimiento del sistema operativo) otras cosas como cuestiones de seguridad, certificados de red, conexiones remotas y un largo etcetera...
    • Solicitan experiencia en ParadoZ, dbase, interbase, firebird, mysql, sql server... Wow. Solo un administrador de base de datos sabe tanto. Iran a hacer una migracion de sistemas de .NET y Delphi (o legacy systems) a mysql? ...O al reves???
    • Es Paradox, no ParadoZ. Aqui hay que resaltar la importancia de la correcta escritura de las tecnologias. Y no es el unico error que hay en el anuncio. Puedes volver a leerlo si quieres.
    • Mantenimiento y administracion de servidores windows (otra vez). Al parecer, el ingeniero en sistemas, aparte de programar y mantener a punto los servidres web, tendra que repararlos cuando algo malo suceda
    En mi opinion, la persona que escribio el anuncio (que muy posiblemente sera el jefe del ingeniero al que contraten):
    • Claramente no sabe de lo que esta hablando
    • No sabe lo que necesita de un ingeniero
    • En consecuencia, no le va a pagar ni siquiera cerca a lo que una persona que va a llevar a cabo ese gran numero de labores se merece.
    Por desgracia, ese es el problema al que nos enfrentamos cientos de profesionistas en un determinado momento de nuestra vida (y muchas veces, incluso en mas de una ocasion).
    En la opinion personal de su servidor, esto es lo que puedo puntualizar:
    • El sueldo promedio de un ingeniero en sistemas, licenciado en informatica o afin en Mexico (que no trabaje para una compañia de IT) es de 6 a cuando mucho 12 mil pesos netos en su primer empleo, algunas veces en el segundo y en casos extremos puede tener hasta 3 empleos ganando una cantidad menor a los $12K. Incluso puede permanecer varios años sin un aumento de sueldo.
    • En las empresas que no son de IT (entiendase oficinas, despachos contables o pequeños comercios), el "ingeniero" es el que se encarga de TODO lo referente a IT (programacion, reparacion de equipo, montado de redes, configuracion de servidores, etc.) Tal como la persona que solicitan en la vacante que acabamos de analizar. Muchas veces por un sueldo que no remunera adecuada o equitativamente el gran numero de labores que desempeña dentro de dicha empresa.
    • Para muchas empresas los ingenieros en sistemas son intercambiables o desechables. Contratan a uno mientras soporte el sueldo y las condiciones de trabajo, pero jamas estan dispuestos a ofrecerle un mejor sueldo o mejores condiciones. Simplemente el dia que tiene una mejor oportunidad, lo dejan ir y contratan otro. Generalmente son empresas cuyos sistemas e infraestructuras son un caos por lo mismo. Si te encuentras una de estas, huye lo mas pronto que puedas!
    • Al egresar de la universidad, como la mayoria de los ingenieros "no tenemos experiencia" vamos a parar a alguno de estos mencionados empleos. Lo peor es que mucha gente que no adquiere conciencia se queda en este tipo de empleos durante toda su carrera. Se estancan y nunca se desarrollan como profesionales realmente.
    Lo mejor que nosotros, la gente de IT, ingenieros y licenciados podemos hacer para obtener un buen empleo es, en mi opinion, lo siguiente:
    • Dignificar nuestra profesion. No prestes tus servicios por menos de lo que valen. Piensa que empleos como ese al que le estas apostando por unos cuantos pesos hay miles. Muchas veces nos vemos envueltos en ellos porque tenemos meses sin conseguir empleo, tenemos necesidades económicas que no podemos evadir y tenemos que trabajar. En todo caso, no vivas pensando que tu vida va a cambiar por intervención divina. Gana dinero, trabaja, pero al mismo tiempo busca siempre ir hacia arriba, busca un mejor empleo! Si sabes que tu empleador no hara nada por mejorar tus condiciones de empleo, ese empleo no es para ti. Simplemente no te merecen.
    • Invierte constantemente en tus conocimientos. Nuestra área de trabajo (IT) ha estado, esta y estará en constante cambio. No te estanques. No te quedes atras. Estudia constantemente, aprende nuevas cosas, LEE! incluso acerca de aquellas que no te gustan. No sabes cuando surgira una oportunidad de desarrollo basada en esas tecnologias o cuando lo tendras que utilizar.
    • Enfocate en un area de conocimiento. Esta es la teoria de David Martinez, un colega mio y de los mejores programadores que conozco. Generalmente si tratas de abarcar todo el campo de conocimiento de IT (redes, programacion y su enorme numero de lenguajes, mantenimiento, sistemas operativos, tareas de infraestructura) poco a poco tenderas a ser un experto en todo... Quiza cuando tengas 50 años. Trata de enfocarte en un area del conocimiento (digamos... programacion para moviles) y vuelvete un experto en ello. Un gran numero de compañias o clientes buscaran al experto y le pagaran lo que el cobre.
    • Preocúpate por ser de los mejores. Siempre. La razon por la que en el tipo de empresas que mencione los buenos ingenieros no duran, es porque son de los mejores. Los mejores se van en busca de nuevos retos, los comunes se quedan, y se estancan. Haz lo posible por ser de los mejores hoy, mañana y siempre. Un lugar donde tu eres el mejor y mas experimentado ingeniero (el "experto") no aportara nada a tu carrera. Debes ir a donde tu eres el ingeniero mas novato, el menos experimentado. Si no tienes un reto no podras crecer como profesional.
    Una vez dicho esto, tengo dos preguntas para ti:
    • En que tipo de empresa quieres/mereces trabajar?
    Si estas en una buena empresa que te valora como profesional, con un buen sueldo, prestaciones y ambiente de trabajo, donde simplemente estas contento. Te felicito enormemente!

    Si no... Respóndete a ti mismo lo que acabo de preguntar. Analiza tu situacion y que tienes que hacer para cambiarla. Y comienza hoy. Ahorita.