Wednesday, November 9, 2016

Of dogs, economy and tribalism.

I'm a dog guy...
I love dogs since I was a kid. Back then my dad adopted a gorgeous white Grand Dane we called, ironically, "Pitufo" (that's the Latin American equivalent of Smurf). He was this gargantuan behemoth cuteness. He loved to jump on people, it was his way of being friendly. You can imagine that not everyone understood that as a friendly gesture, though; a 1.82m tall beast jumping with his paws on your chest and trying to lick your face is probably a scary thing to experience, special coming from a dog you don't know. One day Smurf escaped from my yard and decided to say hi to a passing young couple. The young woman welcome my dogs gesture by screaming like a rape victim, so picture the scene... Small young woman screaming, completely freaked out and covering her face while huge dog drooled and jumped around her. It indeed look bad for Smurf. To make things worst a policeman was witnessing the scene from about a block away. After the policeman approached the young woman declared that my horrible beast brutally attacked her and in the act ripped a expensive golden necklace from her neck and, conveniently, swallowed it. Of Course she was never able to prove anything, no attack marks of any kind and no way to establish that the necklace even existed in the first place, so me; a 35kg 8 year old 1.35m high boy and Smurf; my 87kg crazy-bloodthirsty-gold-swallowing 1.82m high monster were allowed to walk away.
Later, about 2 days after the "attack" I came to realize that the young woman's boyfriend didn't considered things settled, position he manifested by coming back to my house during the night and shooting Smurf with a hollow point .22 caliber handgun . I know basically nothing about real guns and probably less about ballistic and bullet dynamics, but I do know this: if you shoot a big dog with a small caliber gun you don't instantly kill him, instead you ensure him a great deal of suffering and a slow excruciating death. I sat down on the ground holding Smurf for what seemed like an eternity waiting for a vet the never came. He died with his head resting on my lap... I didnt cried... I still miss him.
Nowadays my family is formed by my lovely wife, my biological sons (15 and 12) and my adoptive daughters; Thelma, a noble and smart halfbreed that kind of looks like a minuscule greyhound, and Gaia a cute goofy Basset hound. The girls are a crazy couple, completely opposite both physically and behaviorally. One is super-fast and agile like a hare and the other one is basically an achondroplastic sausage with overdeveloped ears. Gaia is the youngest and as every basset hound she is as stubborn as hell.
I love my adoptive daughters, but they find new ways to rub me in the wrong way, specially when they are left alone in the house, unsupervised, for more than 20 sec. Basset hounds are famous for their incredibly sensible sense of smell, they can detect the most faint traces, a hundred particles per million, of practically odorless stuff completely imperceptible to us even if we grind down a pound of it and snort it with a rolled up bill. Needles to say; they have the superpower of finding food... needless to say they have a broad sense of what can be considered food, as most dogs do. One day, out of the blue, Gaia (my achondroplastic-supersmelling-sausage daughter) started flipping all the trash cans in the house and spreading its contents in the most inconvenient places, so I could at any time find the most repulsive things you can throw away half chewed on my pillow or inside one of my slippers. This suddenly became a habit for her, so we had to restrict the access to places with trash cans, specially the bathrooms and the kitchen. You can imagine how fast this became an annoyance. We were quite puzzled of why she started doing that but we didn't know how to find out since nothing (nothing obvious) had changed in that period.
One night, I waked up to noises in the ground level of the house, so I went down to check what was the origin of it (No baseball bat in hand, I'm Mexican, I know that statistically burglaries happen during the day... you are welcome). I get to the kitchen and find every single food cabinet open and everything that could be considered food (by basset hound standards) ripped open and spread all across the floor. Gaia and Thelma sitting in the middle slowly chewing something with their mouths dusted in flour and cookie crumbs and their bellies swollen. So I just went nuts, the frustration accumulated from weeks of guarding trash cans simply took the best of me so I started screaming at them and angrily pointing out at things while thinking: "What the hell is wrong with this stubborn pair?". If you are a dog guy like me you probably talk to dogs as if they (sometimes they do) understand you. I began this angry speech about how wrong they have been doing and how things will change the next they for them, how we will start alienating them from the house and having them spend more time outside where they could not cause any more trouble and how that will prevent the night food hastes from happening again.
We store their food on a huge container like 2 meters away from the food disaster ground zero. So I walk to the container with the intention to show them that we have plenty of food for them, and how unjustified their actions were. I open the container and notice that in fact there is food, but there is way more than it should be considering their feeding habits, and also notice that the cup we use for measuring the servings has been replaced by a way smaller one, probably 1/3 of the size of the one we use. I have this sudden flashback that connected all that was happening in an instant:
My mother in law was visiting us since the last 3 weeks, around 7 days prior of the trashcan incidents started. She had taken over feeding the dogs (I know this is probably hard to understand, but Latino moms and in laws visit for weeks at a time and usually take over or some of the activities in the house, like cooking or feeding dogs in this case). I remembered telling her that we fill the dogs plates with one serving a day measured with the officially sanctioned serving cup inside the dog food storage container.
My heart shrinked like 2 sizes as I looked at my shivering and cringed dog daughters that stared at me with shame and fear.
I'm not an expert in economics, I have no clue how markets and wealth distribution really works, I don't think anyone really has. I'm no fan of capitalism, I think it's flawed to the core but it's a less nocive model than others humanity has tried. What I know is that we sometimes overestimate our own honesty and civility, we think we act based on what we are in essence and not based on the circumstances and we think the same of other people. This is true most of the time, but bare with me.
If a guy cuts me off in traffic it's because he is a bigot and an asshole, that's the only explanation we see and the only one we want to see. We deceive ourselves thinking we are immutably good people, that our morals are intrinsic to what we are. This kind of thinking is unsustained and according to neuroscientific evidence, completely mistaken. We are, to a point, circumstantial creatures, in the sense that we act influenced more by the circumstances than to our internal sense of ourselves. We allow ourselves and justify us to do things that we make tabu for others if the circumstances push us to that. I can cut you off in traffic, not because I'm a bigot and an asshole as the people that cut ME off, but because I'm in a rush, I'm still a good guy, right? I firmly believe that the majority of us are good, cooperating and empathic people in part because we are social hominids that benefit from the common good (my nerdy way of saying "because we are good people"), but also (and probably mainly) because we have constructed a civilization safe haven, where we get the chance to switch off the survival mode in our brains for extended periods of time. This is a pretty scary thought, it implies that civilization defined by our abundance of food, shelter and overall well being is the only thing keeping us away from going back to barbaric tribalism. This means that that if our civilization that shelters us so we can spend time thinking on science, art and technology broke down, our survival mode goes back on. Any mammal sufficiently desperate to survive will not hesitate to open food cabinets and eat whatever it finds and not care a thing about social norms and pack hierarchy, if it's desperate enough it won't even blink before severing your jugular with a bite and having your offspring for dinner in front of you while you slowly fade away; this includes our sweet neighbor that waves good morning at us when we leave our driveway to work... and you... and me.
My intention is not to picture this inevitable nihilistic horizon, but a call to awareness of the importance of keeping our civilization the way it is. We need to guarantee that we will generate the safe conditions for every single member of our species to be able to switch off their survival mode so they can relocate those cognitional resources into the proverbial pursue of happiness. We need to make sure that everyone's servings are measured with the right cup.

Sunday, November 6, 2016

¿Que tienen los cuchillos de obsidiana y el Nearshoe en común?


Como siempre me gustaría empezar esta noche con una historia, disculpen uds la insistencia, pero esto es lo que los cuenta cuentos hacemos. Al terminar les prometo que la historia es bastante relevante con lo el tema que queremos tratar.

Este es parte de una historia es solo un fragmento plasmado en el Códice Boturini conocido también como la Tira de la Peregrinación que narra la migración de los Chichimecas de su lugar de origen, Aztlán,  hacia su destino final, la tierra prometida de Teoculhuacan.

El viaje inicia como muchos viajes conocidos, con un personaje misterioso y muy poderoso que convence a un grupo de aventureros a embarcarse en una aventura, en ese caso éste personaje no es otro que el mismísimo Huitzilopozchtli, el dios de la guerra, el sol y los sacrificios humanos, nuestro Gandalf mesoamericano. Nuestra historia comienza pasados más de 2 siglos dentro de este viaje tras muchas peripecias y percances los Chichimecas, que ahora se hacían llamar Mexicas, ya dentro del Valle de México, llegan a Chapultepec donde se encuentran en medio de varias otras culturas. En Chapultepec había una importante fuente de agua que era vital para la zona y los Mexicas toman control por la fuerza de esta, situación que detona en hostilidades de parte de los demás grupos del área. Específicamente la gente de Coxcoxtli, rey de los Culhuacanos toma la presencia de los Mexicas sin ninguna gracia. Los Culhuacanos no son cualquier grupo tribal de nómadas, ellos son la estirpe misma de los Toltecas, quien es son la civilización mas avanzada de esos tiempos, los Atenienses mesoamericanos, una cultura altamente letrada, sofisticada y militarmente muy bien organizada. Pasado el tiempo llega la época de sequía y como buen estratega Coxcoxtli sabe que la falta de agua hace débil al enemigo por lo que inicia una campaña en contra de los Mexicas en cuanto el manantial de Chapultepec se seca, la que da frutos y culmina en la captura de los sobrevivientes de entre las líneas Mexicas. Los Mexicas liderados por Huitzilihuitl, derrotados son tomados prisioneros y llevados hasta Atizapan, que no es más que un estéril baldío donde pululan las culebras, donde se les mantiene en sujeción. Coxcoxtli los somete bajo yugo de tributo y estos pasan sus días labrando la dura tierra para producir suficiente para cubrir su deuda y alimentarse de las sobras. 

Años después llega la zona una nueva amenaza para los Culhuecanos, los Xochimicas que buscan expandir su territorio. Xochimilco representa una amenaza ya que es un pueblo enteramente bélico y brutal como nada que los Culhuacanos hayan visto antes y sus constantes embates tienen a las tropas de Coxcoxtli cansadas, heridas y con la moral por los suelos. Los sabios aconsejan al rey que de uso a sus esclavos y los use para debilitar al enemigo. Coxcoxtli acepta y convoca a Huitzilihuitl a una reunión frente a su trono de palma. Coxcoxtli con un tono despreciativo le comunica a Huitzilihuitl su plan, le pide que tome a su mejor grupo de guerreros y embista a un campamento de avanzada Xochimilca que tiene nerviosos y temerosos a sus generales. Como prueba de que cumplió con lo comandado le pide que corte la oreja derecha de todo Xochimilca caído y que se las traiga como ofrenda. Huitzilihuitl acepta pero le pide al rey: 

-"Rey como sabes somos un pueblo sometido que solo labra la tierra, nos es prohibido tener armas por lo que no tenemos con que pelear contra tus enemigos, Necesitamos cuahitls, escudos y atavíos de guerra"

Coxcoxtli se rehúsa a ayudarlo. Huitzilihuitl le pide entonces al rey:

-"Gran tlatoani, pudieras permitirnos hablar con tus generales para que nos informen sobre la posición y las condiciones del campamento de tus enemigos, saber cuantos hombres de guerra y y su estado moral nos permitirá planear el ataque como es debido y así vencerlos para ti."

Coxcoxtli se rehúsa a ayudarlo nuevamente. Huitzilihuitl, quien es un experimentado guerrero, el más viejo y templado en batalla de todos sus hermanos Mexicas, sabe que el rey los está enviando en una misión suicida, sabe que el plan del rey no es solo hostigar y debilitar a sus enemigos pero también deshacerse de lo que a sus ojos es una creciente plaga de Mexicas que se multiplica y que pudiera representar un problema a futuro. Aún así Huitzilihuitl decide hacer lo que el rey les pide.

Reune a su grupo cerca del ocaso y les cuenta sobre el plan del rey. Siendo el el mas experimentado les pide que no corten las orejas de sus enemigos como el rey pidió ya que sabe que sin duda los acusarán de haber cortado ambas orejas para aparentar haber hecho más de lo que hicieron, así que les pide que corten las narices en su lugar. El grupo planean brevemente el ataque. Improvisan lanzas hechas de carrizo y algunos precarios cuchillos de obsidiana que obtienen en una beta que han encontrado cerca del río. Y parten al anochecer a buscar el campamento xochimilca siguiendo el cauce del río.

Pasan 2 dias sin saber del grupo. Coxcoxtli está seguro de que no van a regresar, pues sabe que la hazaña, tal como los 12 trabajos de Heracles, está diseñada para no ser lograble. A la mañana del 3er dia a la distancia ven regresar al grupo casi completo, teñido de sangre seca color marrón entre ellos Huitzilihuitl camina cargando una bolsa hecha de hojas de plátano. El general Mexica se aproxima al trono del sorprendido rey y proclama:

-"Gran rey, hemos cumplido la tarea que nos has pedido, el campamento Xochimilca ya no es más. He aquí la ofrenda que nos pediste."

Deja, entonces caer pesadamente la bolsa a sus pies la cual se abre y revela el escalofriante contenido; al menos 80 narices todas llevando los adornos típicos de los guerreros Xochimilcas. 

El rey se aterroriza de la imagen, siente miedo en su corazón, horrorizado le pide que se marchen, ¿Que clase de bestias son estos Mexicas que sin armas borran de la tierra un enemigo poderoso como los Xochimilcas que ni los más experimentados generales Culhuacanos logran herir? 
Led informa que el yugo queda rota y la deuda saldada, que salgan de sus tierras como hombres libres, pues lo que han hecho es terrible que se marchen como amigos de los Culhuacanos, incluso les ofrece a su hija como gesto de buena fé entre ellos. Así Huitzilihuitl y su gente salen como hombre libres de Chapultepec para continuar su viaje.

¿Qué nos trajo hasta donde estamos?


Se que el paralelismo no es tan obvio a estas alturas, pero la relevancia de la historia se volvera un tanto más evidente mientras progresemos.

Ahora sí al tema que nos atañe. Históricamente como llegamos aqui. Al igual que el viaje de los Mexicas nuestro viaje comienza algunos años atrás. A mediados de los 90's el crecimiento y la demanda de sistemas comienza un crecimiento exponencial alimentándose del auge de esta extraña y nueva tecnología que los versados en el tema llaman; INTERNET. Comienza la era de las .COM.
Demas de los startups y el ejército de entrepreneurs que lideraba la revolución comercial cabalgando en paquetes de datos binarios hubo otro factor que intensificó la demanda por personal diestro en las artes obscuras de la electrónica y los sistemas, el ominoso advenimiento del tan temido Y2K. 

Sin más vueltas nos encontramos ahora en principios del nuevo milenio, habiendo sobrevivido el apocalipsis electrónico y habiendo sido testigos de la explosión de la burbuja de las .COM y la muerte de Napster. Este valle de recuperación que contrajo la inversión en sistemas casi a la mitad toma unos años en escalarse. La pendiente es vencida gracias al nacimiento de Facebook, la entrada de Google a la bolsa y se corona con el lanzamiento del iPhone y de Android. Comienza la era de los smartphones y los ecosistemas de apps. La integración entre el no-anonimato, la modernización de los sistemas de data mining y el big data generan una explosión en la demanda de sistemas que hace a la burbuja del .COM palidecer al llegar a una inversión máxima histórica que supera sustancialmente a la cima del desplome de las .COM. El hambre de sistemas y la necesidad de mas gente haciendolos incrementa agudizando mas la brecha entre la demanda de ingenieros y la oferta. 

Esta insaciable necesidad por sistemas desde el inicio de la era de la digitalización, pasando por la era de las PC, el Internet y los Smartphones genera la necesidad de cubrir esta demanda de gente que cree los sistemas que hagan operar toda esta gigantesca maquinaria, al grado de que la demanda no puede ser cubierta por la población de ingenieros en EUA ni ninguno de los países industrializados, eso da pie al Outsourcing de IT. El Outsorucing ya había comenzado desde los 80s hacia Asia, específicamente Bangalor, la capital tecnológica de la India. Siendo la India el segundo país con más Angloparlantes la atracción de ese capital es simplemente natural. Aunado a esto el hecho de que el sistema educativo de la India es relativamente de buena calidad comparado con los del mundo industrializado y que las rupias se compraban a fracciones de dólar, la inyección de capital al exótico subcontinente indio era solo cuestión de tiempo.

India se convierte pronto en el imperio del Offshore, aglutinando básicamente toda la gama de servicios de IT posibles, de Cloud Services, DevOps, Hosting, Sys-admins, Desarrollo de Software, DBAs, Network Admin, Cybersecurity... etc. El modelo funciona relativamente bien, es barato y si se parea con servicios en EUA permite mantener operaciones 24hrs del dia, esto es especialmente valioso tratándose de sistemas de infraestructura de misión crítica ya que hay gente disponible para atender emergencias. La cultura jerarquica y patriarcal de la india se adapta muy bien a este tipo de operaciones donde la gente tiene que ser ordenada y no correr riesgos ya que se trata de mantener las luces encendidas, la predictibilidad es un factor muy importante.

¿Dónde nos encontramos en la actualidad?


Por otro lado, dentro de esta gama de servicios, hay un sector importante cuya naturaleza es muy diferente; el Desarrollo de Software. A diferencia de los servicios cuyo propósito es mantener las cosas funcionando, el desarrollo implica un skill y mind set muy diferente. El desarrollo de software comprende la administración de incertidumbre y expectativas cuya materia prima es la información extraída a través de comunicación efectiva para ser maquillada en un producto que es seguro pero eficiente, complejo pero mantenible, funcional pero escalable. Uno de los retos más importantes que se tiene en un modelo de offshore es precisamente la comunicación. La comunicación se ve mermada por factores como la diferencia de usos horarios, el lenguaje y la cultura. En el caso de la India, sin ser excepción, es un problema que no es facil de sortear. La india esta en una zona horaria a 11hr aprox de diferencia entre cualquier región del continente Americano, culturalmente es muy distinta, me atrevería a decir que es casi incompatible con EUA. Las operaciones de desarrollo demandan mucho orden y control, los proyectos para funcionar deben adoptar una estructura mucho más rígida que demanda más supervisión e incluso contar con buena parte del personal ubicado físicamente en EUA (alrededor del 30-40%), lo que disminuye sin duda los beneficios. La distancia presenta otro tipo de problemas, como viajes largos y costosos entre locaciones (25-32hrs de vuelo en un costo entre $2000 y $4000 dólares) y costos por comunicación por voz más elevados.

Estas deficiencias abren una ventana de oportunidad para países con talento, infraestructura y capacidades similares para volverse parte de la industria. En el caso específico de México, que cubre el perfil y que además tiene la ventaja de ser el vecino del sur y el socio comercial más importante de EUA se vuelve una oportunidad histórica. Nace entonces el Nearshore.  

La industria de IT en México desde principios del 2000 ha crecido de forma constante no solo por las ventajas económicas que ofrece; Menor supervisión, costos de comunicación y viaje mucho más accesibles, sino especialmente por las ventajas culturales. En el ámbito del desarrollo de software el mexicano es crece en un ambiente donde se celebra la perspicacia y el trabajo inteligente. No es de sorprenderse que los inversionistas tengan los ojos puestos en México en la actualidad, específicamente en Guadalajara donde se vive un periodo de bonanza y expansión por la entrada de capitales importantes al estado logrando así un máximo histórico de exportación de servicos de IT que conforma ya la mayor parte de las exportaciones estatales. Los resultados obtenidos con desarrolladores mexicanos rivalizan con aquellos de los países históricamente asociados con la tecnología como Ucrania y Finlandia. No es una casualidad que año con año sean universidades mexicanas distribuidas a lo largo de todo el espectro socio-económico las que resulten como ganadoras de concursos de ciencias, robótica y matemáticas, venciendo a universidades de la talla del MIT y CalTec. Esto habla que a pesar de la falta de capital, estructuras de desarrollo educativo y apoyo gubernamental hemos, como sociedad, salido adelante y destacado en los escenarios internacionales por puro y crudo mérito propio. El potencial existe, falta saberlo explotar y mantener.


Optimizando: Lo que podemos mejorar.


Si bien la oportunidad en la que se encuentra el país actualmente es histórica, aún hay muchas barreras que derribar y muchas mejoras que implementar. No solo en infraestructura y maduración en si de la industria, sino también, y sin duda las más importantes en materia de nuestra mentalidad, percepción de México en extranjero hacia lo que nuestro talento local puede lograr. Hoy por hoy la nueva generación que se incorpora al mercado laboral innegablemente viene mejor preparada técnicamente que lo que cualquiera de los mas veteranos de esta industria estuvimos cuando en su momento egresamos. Sus programas de estudio son mucho mas actualizados y enfocados en una industria que es hoy una realidad y que marca muchas pautas sobre las habilidades que deben desarrollar.  

Tenemos comos país muchos retos por delante, muchas cosas que e deben arreglar que llevan décadas estando sistemáticamente mal; corrupción, una brecha socioeconómica que no deja de crecer, falta de oportunidades para los emprendedores, un gobierno indiferente a la problemática de la mayoría y muchas cosas que están simplemente mal. No es mucho lo que podemos hacer para borrar de un dia a otro todo eso que nos ancla como pais, pero si hay podemos iniciar este largo viaje con muchos pequeños pasos que estan de la talla de cualquiera de nosotros y que colectivamente contribuyen a llevarnos como sociedad a estar mejor y prepararnos para el despegue que de verdad creo que estamos a punto de ver. Las siguientes recomendaciones pueden parecer inconsecuentes a simple vista, pero creo que sumadas pueden cambiar de forma positiva la forma en la que trabajamos y contribuir mejorar nuestra industria.

"I found it is the small everyday deeds of ordinary folk that keep the darkness at bay. 
Small acts of kindness and love."
-Gandalf the Grey - The Hobbit: An Unexpected Journey - Movie

Job-Hopping Horing


Existe un fenómeno laboral que se ha disparado en los últimos años y cuya práctica es notablemente mayor entre millennials que en el ámbito se conoce como Job-Hopping (Yo le llamo Job-Horing). Este consiste en cambiar de trabajo al menor disgusto y desden. Si bien el cambiar de trabajo puede ser una buena estrategia de crecimiento, si no se hace de la manera correcta puede resultar detrimental a largo plazo. Una persona que cambia de empleador en tiempos menores a 1 año da la impresión de inestabilidad, poca seriedad y falta de compromiso. Los cambios de trabajo deberían ser un evento planeado con un objetivo en específico, deberían ser parte de una estrategia más grande. La recomendación que este viejo les puede hacer es:

Cambia de trabajo cuando hayas logrado algo y tras haberlo logrado sientes que dejaste de aprender. Nunca cambies de trabajo solo con el fin de incrementar tu salario, ni librarte del idiota de tu jefe, Trata a tu trabajo como a una relación de pareja; aprende, diviértete todo lo que puedas y si el pozo de conocimiento se seca y ya no puedas ni aprender ni contribuir nada, entonces márchate en buenos términos. Eso es mucho más sostenible que volverte un promiscuo laboral. 

Desarrollo de Talentos


Existen pocas maneras de darle forma al futuro de manera directa que enseñar, mas aún si la enseñanza se lleva un paso mas allá. Dicen los que saben que hay maestros, bay excelentes maestros y hay mentores. Un mentor lleva la honorable labor de la instrucción al siguiente nivel haciéndose cargo de la impartición de conocimiento pero también de el coucheo, el seguimiento y la asesoría a largo plazo de su aprendiz/padawan. Un mentor asume la responsabilidad por la carrera de quien mentorea. Varios estudios como el de la Universidad Columbia Business School encontraron una correlación entre personas que sus carreras fueron enriquecidas con n mentor y hasta un 25% de ingreso superior al de sus contrapartes que en igualdad de condiciones no tuvieron un mentor.

El mentoreo no solo enriquece al aprendiz sino que también sirve como mecanismo de crecimiento para el mentor. Esta industria necesita que más gente sea cobijada bajo el ala de lo que tenemos más experiencia para asegurar que no solamente crecerémos en número sino en capacidades. 

Consigue un mentor o mejor aún, hazte de un buen padawan.

Agile que no es FrAgile: Madurando la industria


La cantidad de incertidumbre que se maneja hoy en dia con los proyectos de desarrollo hace que ls Metodologías Agiles sean una excelente forma de manejo de proyectos. Sinembargo es muy común que las empresas caigan en la trampa de usar el Agile como pretexto para mantener el descontrol y dejar de practicar procesos de ingeniería de software madura. Agile no es un substituto de la buena planeación y los procesos de calidad. La documentación, por ejemplo, no está peleada con los los preceptos de Manifiesto de Agile si ésta es usada como herramienta de interacción entre individuos. Necesitamos de herramientas efectivas de comunicación, muchas veces los documentos de la formalidad que estos sean pueden ser el puente que conecta 2 mentes que pretenden colaborar. Aprende sobre comunicación visual y los diagramas básicos de UML, te pueden ayudar mucho.

Aprecia a tus compañeros de trinchera y cuida tu trinchera


Pasamos 40hrs promedio conviviendo con la gente que trabajamos, en momentos de estrés es posible que esa cifra se dispare a 60-80hrs dependiendo de lo tarde que vaya tu proyecto, esto es significativamente pas de lo que convivimos con nuestras familias. Es por eso que es vital que nos llevemos bien. No existe fuerza más destructiva para el éxito de un proyecto que un colaborador tóxico con el que nadie puede trabajar inconsecuentemente del nivel técnico y las capacidades que este tenga. 

"We few, we happy few, we band of brothers;
For he to-day that sheds his blood with me Shall be my brother"
Shakespeare - Henry V

Aprende a apreciar a tus compañeros, genera relaciones de respeto y mutua admiración. Procura que en el proceso de contratación de personal nuevo participe buena parte de tu equipo, asegúrate que durante éste consideras no solo por su habilidad técnica, sino por su carácter y la actitud. Vale mas una persona que que se dispone a aprender y que genera armonía que alguien que no necesita aprender nada pero es una agente de disrupción y conflicto. Apoya a tus compañeros, mantente en contacto con tus excompañeros de trabajo, haz amigos y si puedes adopta a algunos como parte de tu familia, Recomienda gente que sepas que es buena, aprende a ser suficientemente sabio para aprender de los demás y suficientemente humilde para que los demás aprendan de ti.

El que no avanza retrocede


En este negocio no podemos dejar de aprender, es vital que nos mantengamos en constante movimiento y que seamos los mejores autodidactas cada dia. Todo esto se resume en una recomendación: Además de leer y practicar mucho, trata siempre de ser el idiota de la mesa, el mas tonto de la plática, el que menos sabe y el que menos conoce de tu grupo de trabajo, es decir, rodéate de gente que te edifique y te enseñe cosas nuevas, busca y aprende de los que ya fueron y vinieron y se saben más historias que tu. Si en algún momento te sorprendes siendo tú el que más sabe y el que más conoce, es porque ya te quedaste atras.

La Imagen de México

En la actualidad cuando la gente piensa en innovación, tecnología no piensa en México. En el cast de The Big Bang Theory no hay un latino, por señalar un ejemplo de la cultura popular que no reconoce lo que hemos logrado. Cuando la gente piensa en México piensa en mariachis, tequila, playas, fiesta y gente cálida. Y claro que eso es parte de nuestra cultura y estamos orgullosos de ser cálidos anfitriones en nuestro país del que estamos orgullosos. Pero somos mucho más que eso. Necesitamos trabajar duro en esta industria, ser conscientes de la responsabilidad que tenemos como representantes de lo que el talento mexicano puede hacer. Somos más que jardineros y jornaleros incansables.

Comentario Obligado sobre Trump, Presidente Electo


La situación actual con nuestro vecino y socio comercial más importante está sin duda preocupante y claro que el mensaje que mandaron el 9 de Nov del 2016 es pésimo y pinta un futuro que parece más bien un pasado que ya habíamos dejado atrás. 

¿Qué le espera México después de esto?  ¿Es este el fin del crecimiento de las exportaciones en materia de servicios especializados de IT? Sin duda la respuesta es un rotundo NO. Es cierto que el peso perdió 13% de su valor en una noche, una caída comparable con la que sufrió en la crisis de 1994. Esto es está directamente ligado a al resultado de las elecciones por la posición del ahora Presidente electo concerniente al TLC y la relación comercial México-Norte América. 

Los países en desarrollo como México basan mucha de su economía en la exportación de materias primas y productos generados de la explotación directa de recursos materiales (commodities). Esta vía de crecimiento es un buen comienzo pero tiene muchos límites a largo plazo, límites tales que México ya había alcanzado independientemente de quien fuera electo mandatario en EUA. Lo que da el siguiente empujón a los países para subirse al tren de la industrialización es sumarse a la cadena de valor a nivel global. Es decir, cuando un país madura en sus procesos productivos lo suficiente para poder competir en mercado abierto con otros países. México ya había logrado ese estatus, tanto es asi que somos el mayor exportador de autopartes del mundo. Pero esa segunda fase del crecimiento también tiene sus límites, ya que forza al mercado a una espiral de valor descendiente, es decir, el país será competitivo mientras pueda seguir operando con costos cada vez mas bajos, entregas más ambiciosas y calidad creciente. Esto genera condiciones económicas que eventualmente se vuelven insostenibles además de que son completamente dependientes de conocimiento e innovación que viene del exterior.  México se encuentra casi en el final de esta fase, en un estado de transición entre ésta y la siguiente, aún crecemos y somos competitivos pero no por mucho tiempo pero iniciando una innovación local de bastante importancia.

La tercer fase de que un país tiene que emprender es moverse de la manufactura y la maquila a un mercado que se alimenta de innovación interna del propio país. Pasar del simplemente hacer a el innovar y hacer cambia el escenario volviendolo un ciclo virtuoso que genera crecimiento sustentable y sostenible. Esto requiere, entre otras cosas, más inversión en R&D tanto pública como privada, más énfasis educativo y cultural en carreras relacionadas con ciencia e ingeniería y políticas públicas que permitan la el crecimiento de la industria local. Eso es precisamente lo que la India logró en los 80ts y 90ts. Lo que Mexico necesita son exportaciones basadas en productos manufacturados, diseñados en el país que compitan con equivalentes en el mercado global. Necesita exportación servicios especializados de talla mundial que no solo cubran las necesidades de empresas de inversión extranjera sino también las de la industria local. Ahí es precisamente donde entramos todos los que navegamos las sórdidas aguas de esta industria. El siguiente paso tiene que ver con apuntalar la industria de la exportación de servicios de IT y fortalecer el ciclo de la innovación y el desarrollo. Es nuestro momento de salir a pelear con los Xochimilcas.

¿Que tienen entonces en común los cuchillos de obsidiana y el Nearshore?


En la idiosincrasia mexicana el ingenio es una herramienta que trasciende y supera el poder y la posición. El Mexicano es entrenado desde pequeño entonces en alcanzar metas a pesar de no tener los recursos suficientes, donde se aprende a nadar arrojándose al agua y no ahogándose, donde la escasez y la carencia se vuelven combustible para la innovación. El mexicano como el resto de latinoamerica tiene una caracteristica que lo distingue por encima de las demás. ¿Cual es característica del carácter de los Mexicanos que más los representa? Sin duda: nuestra altísima resiliencia

México como cultura ha soportado sin fruncir el ceño, embate tras embate al grado de que la respuesta natural del mexicano ante la tragedia es el humor, no como forma de escape sino como una casi nihilista celebración de lo dura e indiferente que es la vida para los afortunados y los menos desafortunados por igual.  El mexicano cobra fuerzas de la derrota y se fortalece con las caídas y se crece al castigo. Somos descendientes, por un lado de guerreros forjadores de imperios y por el otro de conquistadores viajeros. La resiliencia nos hace aferrados, tercos e implacables cuando se trata de llegar a una meta. Esa implacabilidad da como resultado buena parte de nuestro ingenio, que nos permite obtener recursos de donde nadie más los ve, desde remplazar una banda de carro con un cinturón para que el taxi pueda seguir trabajando, hacer lanzas con carrizo y cuchillos de obsidiana para matar Xochimilcas o hasta dar con el diseño de un motor superluminal que distorsiona el espaciotiempo para mantener un marco de referencia temporal constante que es teóricamente viable (Motor Warp de Miguel Alcubierre).

En el desarrollo de software, donde se lidia con incertidumbre todo el tiempo, donde siempre hay metas cambiantes el tener un grupo de gente incansable que está entrenada desde niños en buscar la manera de sacar adelante las cosas, con apoyo, sin apoyo y muchas veces a pesar del apoyo es una ventaja competitiva que es apreciable a simple vista. La capacidad de los mexicanos de lograr metas que en el escenario internacional nadie realmente espera que puedan lograr, como exterminar un campamento de avanzada Xochimilca con armas improvisadas o ganarle en una olimpiada de robótica al MIT y CalTec o en nuestro caso , ser hoy por hoy el centro de Tecnología más grande del mundo para Herbalife.

"Lo que impide la acción anticipa la acción. 
Lo que se interpone en el camino se convierte en el camino."
-Marcus Aurelius.

Ya para cerrar, me gustaría volver a la historia del principio, esta es la parte que falta por contar. Pasadas unas décadas tras la salida del cautiverio culhuacáno, los Mexicas encuentran finalmente el proverbial águila parado sobre un nopal devorando una serpiente. En ese sitio fundarán l lo que es posiblemente la ciudad más importante de todas las civilizaciones mesoamericanas hasta la fecha, una ciudad con importantísimos avances tecnológicos y sociales que bien rivalizan con cualquier urbe europea de la época. ¿Cómo logra una cultura de guerreros nómadas volverse una civilización altamente organizada ? Los Mexicas aprendieron mucho durante sus años con los Culhuacanos, si vien estaban sometidos los años de convivencia les enseñaron, los maduraron y expandieron su visión sobre las cosas. El periodo de subyugación les sirvió sin duda como entrenamiento para lo que venía. El dia que ellos fundaran su propia civilización. 

México está en un momento histórico, esta puede ser nuestra oportunidad de crecer como nación, de cambiar el estereotipo de Speedy Gonzales sobre lo que nuestro país y nuestra gente es realmente. Este puede ser nuestro momento de fundar civilizaciones, de mejorar la calidad de vida de nuestra gente, de lograr el reconocimiento internacional por lo que podemos hacer, La industria de sistemas tiene el tamaño económico para poder disparar este país hasta las nubes.  Todas las grandes culturas a lo largo de la historia, tienen orígenes similares a los de nuestro relato,  todas vienen de humildes orígenes donde la escasez y carencia eran siempre presentes donde se fortalecieron en medio de la sequía y las vacas flacas. Todas usaron el embate para crecerse y fortalecerse y eso las preparó para llegar hasta donde llegaron. Solo falta estar preparado. Ayudanos haciendo la parte que te toca.

Thursday, September 13, 2012

Difference between agile and Agile



    The Agile manifesto was the common ground found by a (heterogeneous) group of 17 software development experts (who now call themselves The Agile Alliance) with different backgrounds that included Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming. They all agreed, in spite of their dramatically different points of view,  on a list of 12 base principles of how software development should be managed. This 12 point list is now known as the Manifesto for Agile Software Development.

    1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    1. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
    1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    1. Business people and developers must work together daily throughout the project.
    1. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    1. Working software is the primary measure of progress.
    1. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    1. Continuous attention to technical excellence and good design enhances agility.
    2. Simplicity--the art of maximizing the amount of work not done--is essential.
    3. The best architectures, requirements, and designs emerge from self-organizing teams.
    4. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    These 12 principles are based on 4 essential guidelines:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    Please note that this guidelines are presented as a dichotomy (which is by itself controversial), this means that all Agile project must mainly align to the left side of this list (the Light side of the Force you might say?).
    So in simple words; you are not on an Agile project if you value documentation over working software or you value more your plan that responding to change. Now let me clear something up before some of you start rising an eyebrow in disapproval... It’s perfectly ok to value comprehensive documentation over working software or processes and tools over individuals and interactions, some projects have to work that way, it all depends on the nature of the project, which brings up the question:

    Is Agile the approach the best someone could have on a software developments nowadays?
    The answer: NO!!, it depends on the nature of the project, Agile is not going to work on all projects.

    Why agile is not the same as Agile.

    There has been a lot of confusion lately caused by the abuse and misuse of the term Agile. So let’s clear out what is strictly Agile and what isn't.  Just remember the essential principles and why the manifesto was created for in the first place. People can call their approach agile (notice the lower case "a") which can mean whatever they want, this is the main source of all the confusion regarding Agile Development. Agile is by itself an adjective that describes something flexible that reacts fast. That fact plus all the buzz Agile Development (notice the capital “A”) has generated recently has caused people to indiscriminately use it to describe their project, design, coding, management, testing and even documentation techniques or methodologies as "agile" when they believe that they are "fast" or "faster than..." by whatever arbitrary standard they can think of, so you can  append "agile" to anything you want to, just to make it sound trendy and cooler;

    The "agile" incremental beer drinking technique (I know a couple of guys I work with how are experts on this).

     Agile is just a set or principles that are open to interpretation. There is no methodology set on stone you can follow or any set of tools you could use. This is a good thing if you think about how flexible it can be. You can hypothetically allocate virtually any kind of project within this frame and improve is greatly, but the down side is that you can easily get lost in the path that doesn’t have any barriers on the sides that delimit it clearly. This explains why you can buy 2 different Agile books and still get contradicting opinions on the same subjects.

    So just to wrap things up;

    • Agile: Is a set of 12 principles for software development aimed to increase productivity by prioritizing activities that add real value to the project and to the deliverables. Agile is leveraged by an incremental and iterative approach.  It is a great way to manage projects in which the requirements are not completely defined by the start (like most of the projects we engage on at DMT). It can be risky to follow it on project that demand requirements to be perfectly defined upfront or that requires a very detailed change process (basically any project that by nature requires you to value any of the guidelines right side).
    • “agile”: Anything that moves quickly.

Thursday, April 26, 2012

In a Country not so far, far away


Everyone working in any IT market with a serious enough  job knows for a fact that the all time champion of outsourcing is by all means the exotic sub continent of India. India has the great advantage, besides the currency exchange differences between USD and Rupiahs, that they have a this huge population of well trained, English speaking people (its entire population is around 900+ million that's 9 times Mexico's ). This makes them the worlds largest talent pool (second after China) for all USA based operations. India also embraces a self improving and study culture that most people adhere to. They also are perceived as a more westernized culture compared to Korea or China which is a bonus for any USA organization outsourcing operations with them because that turns communication flow smoother. USA businesses prefer them for all those reasons and this preference is the cause of the great economic growth they have been experiencing in the last 2 decades.

Moving operations offshore is no easy task as you surely can imagine. It requires infrastructure, process definitions, certifications and a whole universe of mechanisms and bureaucratic leaps of faith for the USA based customer to be able to supervise all relevant activities. Besides that, for IT related outsourcing, specifically for that related to software development of any level,  there is also the matter of establishing effective communication with the offshore team. That communication is always going to be slower and more inefficient than between local-native software developers due to cultural and language differences. This communication overhead adds up to the cost of the total operation along with the required investments on infrastructure (Bandwidth, phone lines, conference  calls, etc). There also needs to be more supervision so this is usually covered by adding onshore managers to serve as communication bridges between onshore and offshore team members. Some times it is worth for someone on the offshore team  to visit the customer so that adds traveling expenses. Add all up and the resulting  additional cost is know as TEC (Total Engagement Cost) which means the additional money customers need to pay to afford an offshore team that they otherwise wouldn't pay if they had only onshore people.

The pretty part of offshore is that even with the TEC, the total operation cost is still lower than a onshore team this to the difference in per-engineer net costs. For instance, consider this data:

Country
Position
Avg. Annual Salary (Local Currency)
Avg. Annual  Salary (USD - 4/25/2012)
India
Java Web Developer - Senior
$744,985 INR
$14,190 USD
Mexico
Java Web Developer - Senior
$242,208 MXP
$18,439 USD
USA
Java Web Developer - Senior
$87,638 USD
$87,638 USD

In operation terms this means that you can have 6 Indian engineers for the same cost as 1 USA engineer or 4 Mexican engineers. So its really obvious why US companies move operations offshore. If you noticed on the above data India is roughly 25% to 30% cheaper than Mexico is, which is one of the main reasons you must certainly work with someone who gets his paycheck from iGate Patni, Tata or Infosys.

Now that's not the whole story, remember the TEC? Well that's a big game changer because according to experts TEC on India is about 25% higher than in Mexico an South-America which levels the playing ground for those of us who live here.
There is where the Nearshore marketing term appears into scene.

What's the difference between Offshore and Nearshore? Easy… a smaller TEC and also time zone alignment (which is not always a good thing as we'll discuss it later) . Another good thing about it has to do with travels. One on the requirements of any offshore manager is to visit its offshore team at least one time a year. This helps him connect with the team and boost their morale. Also it is beneficial to bring someone on the offshore team to work onshore from time to time because of the same reasons specially if there is some delicate matter at hand (alpha testing, new development, requirement gathering for a redesign, etc). Given that premise, consider that commercial flights to Bangalore take 22hr ( plus the additional adjustment time) while a short trip from Connecticut to Aguascalientes or Guadalajara is roughly 3hrs to 5hrs, to Rio de Janeiro is around 8 to 10, so that's another perk you get from having a closer (nearer in this case) team. Another aspect to take into account is that Mexico has a lower turnover rate (10%) compared to India (almost 40%) this to the fact that the Mexican labor market is not as harsh as that of India also working conditions are more endurable at medium term, specially those that have to do with working schedule.. There is also the communication matter, What country (excluding Canada) is more culturally aligned to US that good o'l friendly neighbor Mexico?

Then there is the productivity loss associated to every offshore project. US based companies calculate that the productivity loss with India based teams is around 25% so for they to get the same productivity of 4 US based developers they need to have and 5 Indian developers, While in Mexico and South America the productivity is around 10% so you can basically keep teams the same size than those base d on US. This productivity loss is generally a by product of communication overhead and time zone differences.

Considering the previous this is what customers get when you decide to get a Mexican development team to do the bit gardening:

  • Cheaper phone calls.
  • Less communication overhead.
  • Cheaper and more accessible trips.
  • Shorter Trips.
  • You can get anyone on your team onsite almost the same day.
  • Less turnover.
  • Less productivity loss.
  • Working in the same time zone without risking team burnout.

So why is India then still the undisputed master of IT? Well it has to do with the fact that Mexico and South America are in the newer in this market (20 years average) and also that the English speaking population is significantly smaller than that of India so on-boarding processes are slower. Also the Indian government has created great incentives and bureau shortcuts to ensured that the IT Industry blossoms like a white lotus (made of cash), while in Mexico, for instance, there is no real support for the IT industry and also historically Mexico has never been a start-up friendly place.


I work with lots of people located on Bangalore and Mumbai, they are exactly as anyone would expected a development team from any place on the world to be. The older and experienced ones are walking encyclopedias with great talent and insight, the newer ones are not that savvy but filled with excitement and willingness to learn, and interns are just keyboard operators awaiting their moment to shine. The same happens here, exactly the same. Also companies here follow the same kind of best practices as any offshore service provider in the world, this practices are in fact enforced by the US companies that hire the services (ITIL, CMMI, SAS70, SOX404, etc) so there is really isn't way of not having them.

The only difference I've been able to perceive is that we are willing to take more risks than they are, I guess the job market pressure there is intense, or so have some friends located there told me so, they need to be very careful with the decisions they make to avoid losing their heads, while our job market is less predatory so there are lots of opportunities here and the competition is not that fierce so losing our jobs for a gut made decision is not something that keeps us up at night. Having this freedom is and advantage in many cases where someone has to take a bullet to prevent a greater damage.

So if you'r planning your big start-up and you are short on resources, why not look south and give a try to a Mexican Development team which you can , we are just as capable, but closer and also we can arrange your visits to happen during big festivities (like "San Marcos Fair" on Aguascalientes, A.K.A. "The World's Biggest Cantina" ) so you can get as drunk as a mule, after all, what happens in Mexico stays in Spanish.

Gracias!

Friday, March 16, 2012

Java - Getting the memory size of an object.

Because the way Java language and the way JVMs are implemented, this apparently trivial task is more complex than it may seem specially when compared to C++ where all objects have a size() method. Java memory architecture is built to abstract the developer from direct manipulation of memory so that the developer can focus on more relevant tasks, this comes with a price.

There are 3 basic approaches you can take in order to do this all with their pros and cons:
  • Memory guess (Heap Size prior object creation - Heap Size after object creation = Object Size)
  • Java Instrumenting Query
  • Serialization

Memory Guess
This is the simplest approach because of the fact that you have a pretty easy access to the Heap Size via:
 Runtime.getRuntime().totalMemory();


The issue with this approach is that you cannot control what is being thrown into the heap at a given time, JVM is shared by a lot of processes that run in a given machine so this is a error prone approach that is not recommended.

Java Instrumenting Query

Starting on Java 5, all JVM have built in instrumentation features . This features can be used to monitor objects size in memory by creating an agent and setting it up for the JVM. This is by far the most precise method of getting the object's size from memory, but it's by no means the easiest/straight-forward. Another drawback is that this may change depending on the JVM you are using (the next example applies only to Oracle's Standard JVM 5 )

The agent looks something like this:

import java.lang.instrument.*;
import com.somepackage.SomeClass;

public class MyAgent {
  public static void premain(String args, Instrumentation inst) {
    SomeClass obj = new SomeClass();
    long size = inst.getObjectSize(obj);
    System.out.println("Bytes used by object: " + size);
  }
}
Then you need to register the agent to the JVM by initializing the application with the folowing parameters:

java -javaagent:agent.jar

That will cause the agent to be registered on the JVM instrumenting layer where it will be able to monitor object's size.
Next you can access these feature with something like:
public class MyAgent {
  private static volatile Instrumentation globalInstr;
  public static void premain(String args, Instrumentation inst) {
    globalInstr = inst;
  }
  public static long getObjectSize(Object obj) {
    if (globalInstr == null)
      throw new IllegalStateException("Agent not initted");
    return globalInstr.getObjectSize(obj);
  }
}
As you have certainly noticed this is no as intuitive as it may seem.
Serialization
This technique uses Java's serialization features to calculate the objects size. This is not the most precise way to do it because memory specific serialization works in a slightly different way than regular object serialization but its a pretty good approximation. One drawback of this approach is that it requires the object to be measured to be Serializable.
This is how a method that mesures the size would look like:
public long sizeOf(Serializable object){
 if (object == null) {
  return 0;
 }

 try{
  final ByteCountingOutputStream out = new ByteCountingOutputStream();
  new ObjectOutputStream(out).writeObject(object);
  out.close();
  return out.size();
 }catch (IOException e){
  if (log.isWarnEnabled()){
   log.warn("Unable to determine object size: " + object.toString(), e);
  }
  return -1;
 }
}
One of the greatest drawbacks of this simple approach is that OutputSreams in general are one of the most commonly known resource hogs in Java so you should treat them with care.

Sunday, March 11, 2012

Crítica a "10 Ideas Erróneas sobre PHP"

Hace algún tiempo me encontré con un post que hablaba sobre las 10 ideas erroneas sobre PHP. Me pareció interesante la idea de hacer un arquetípico post de 10 puntos defendiendo un lenguaje de programación, situacion que por si misma me parece un tanto chusca.

Antes de empezar quisiera aclarar algo. He sido desarrollador de PHP por más de 6 años (de hecho siempre me he considerado un PHPer en recuperación). Dada esa experiencia puedo decir sin temor a equivocarme que PHP es una excelente herramienta para el 95% de los proyectos Web (pequeños), es accesible y tiene una comunidad bastante extensa y heterogénea (esto puede ser un problema en ocasiones). También desarrollo en Java desde hace 7 años y he hecho algunos proyectos en C Sharp con .NET, Flex y actualmente me encuentro en un desarrollo que utiliza Grails (Groovy on Rails) y Griffon por lo que he tenido algo de experiencia con tecnologías muy distintas y filosofías casi opuestas.

Puedo decir con mucha seguridad que PHP definitivamente no es suficiente para proyectos Enterprise donde se tienen que considerar cosas como Estándares, Instrumenting, Automatic, Procurring, Mensajeria y casi cualquier cosa que tenga que ver con trabajar en ambientes distribuidos (en cluster). Los short comings de PHP se deben precisamente a la falta de una plataforma de desarrollo dirigida no solo por la comunidad sino regulada por alguna instancia que la mantenga vigente y sobre todo actualizada.

He aquí mi crítica a los puntos tratados en el post mencionado:

1.- PHP no es un lenguaje “compilado”, es un lenguaje interprete:


El hecho de que el motor de Zend permita "compilar" los scripts a un estado intermedio optimizado (bytecode?) no quiere decir que el lenguaje sea compilado ya que esto es una funcionalidad del motor de Zend y no del lenguaje (La inmensa mayoría de los proyectos corren en una instalación estándar de Apache). Lo mismo se puede hacer con Javascript utilizando Rhino (y algo de voodoo) y eso no hace a Javascript un lenguaje nativamente compilado, o si?

2.-PHP no puede… (Acceder a Memoria, Utilizar Hardware, etc.)


El tener que recurrir a un lenguaje de bajo nivel para compensar las carencias del intérprete de PHP valida precisamente esta afirmación. Es lo mismo si yo digo que con Python puedes leer los pensamientos de las personas... claro solo necesitas crear el Hardware que lo transfiera a paquetes compatibles con TCP/IP y lo envíe hasta el servidor donde Python los leerá.

3.- PHP no puede hacer algo que se puede hacer en la lengua X.


Este punto es redundante con el punto 2, creo que el propósito de incluirlo fue meramente de marketing para llegar al mítico "10" en la lista para que se vea más “oficial”. Sin embargo al inicio listé una serie de cosas que PHP no puede hacer y durante el transcurso de las demás criticas incluiré más, y no solo por la limitante de ser un lenguaje Script interpretado y estructurado, sino que a Diferencia de Java o C (Utilizando .NET) PHP es solo un lenguaje mientras que C y Java son Plataformas de Desarrollo. Ahora, casi cualquier cosa es posible con la cantidad de tiempo y recursos necesarios el problema es el esfuerzo requerido para hacerlo, en cuyo caso PHP requeriría un esfuerzo ENORME para lograr hacer algunas cosas que Nativamente los Frameworks de Java y .NET.

4.- PHP es solo para el desarrollo en WEB.


PPH fue concebido con el propósito de hacer paginas dinámicas y es claramente un lenguaje para desarrollos web. Es decir, no puedes programar drivers para una tarjeta gráfica o un Smartphone con PHP, los usos que planteas son solo extensiones del propósito WEB del lenguaje.

5.- PHP solo es controlado por Zend.


En esto tienes toda la razón. Lo que me parece curioso es que puedo inferir basado en tu comentario que por alguna razón consideras que el hecho de que PHP sea controlado por Zend es algo de alguna manera negativo. Me parece curiosos porque eso es precisamente lo que le ha faltado al lenguaje durante más de la mitad de su existencia; Una instancia seria que lo regule, esto permite que la evolución del lenguaje y de toda la gama de tecnologías que las que depende sean dirigidas y sean por lo tanto más exitosas, propongan más avances y por lo tanto atraigan a más desarrolladores. Eso ha sido uno de los grandes éxitos de Java (Con SUN y ahora Oracle) y de C y C++ con .NET (con MS).

6.-La documentación de PHP es incompleta he insuficiente.


Existe documentación oficial del lenguaje y es bastante completa. Sin embargo al no haber regulaciones ni estándares cada Liberia puede o no tener documentación suficiente o de plano no tener documentación alguna, pero esto no es algo exclusivo de PHP ya que lo mismo sucede con Java por ejemplo, aunque en menor medida ya que los desarrolladores Java favorecen grandemente a aquellas librerías que se apegan a las implementaciones sugeridas por Oracle o SUN en su momento y eso es un incentivo fuerte para que aquellas que no lo hacen caigan eventualmente en desuso y desaparezcan. Esta es otra de las ventajas de tener una instancia reguladora.

7.- Los proyectos de PHP no son reutilizables, ya que no son orientados a objetos.


En esto tienes razón también, pero por las razones equivocadas. Wordpress es un CMS y el usarlo no significa reutilizar código. Lo que la crítica plantea es que existe un gran número de desarrolladores PHP que no tienen ni siquiera fundamentos básicos de OOP. El OOP implica (usándose bien) componentes reutilizables por lo que muchos desarrollos en PHP no cumplen con esta buena práctica. Sin embargo, nuevamente esto no es un problema de la tecnología en si sino de la comunidad que hace mal uso de ella.

8.-PHP es peor que Ruby On Rails, Python Django, X framework en otro lenguaje


No creo que se pueda comparar un lenguaje contra un framework. El acercamiento orientado a modelos de Ruby on Rails o Grails es muy útil y muy fácil de usar para cierto tipo de proyectos, pero calificarlo como "mejor" es completamente subjetivo. Ahora es una realidad que el crecimiento de estas tecnologías es algo que debería alertar a los desarrolladores PHP ya que ofrecen lo mismo que la plataforma PHP pero mucho más robusto y accesible. Creo que la transición de PHP a Ruby on Rails es algo que se puede dar de forma muy natural para un desarrollador PHP, muchos de los que conozco ya han comenzado a agregar Ruby a su CV. Ruby debe ser visto como una herramienta más en el arsenal del desarrollador y no como una competencia, estamos hablando de tecnologías de desarrollo no de religiones.

9.-PHP no es bueno para los sitios Web escalables o aplicaciones de alto rendimiento


Facebook es una excepción. La razón por la que esa hecha en PHP no es porque haya sido la mejor opción sino porque era lo que Mark Zuckerberg sabia usar cuando comenzó el desarrollo del sito y desde ahí se comenzó a ampliar el fundamento que el planteó. Facebook ha tenido que compensar las limitantes de PHP utilizando técnicas bastante interesantes de Infraestructura y por eso el sitio opera bastante bien, pero insisto, esto no prueba que PHP sea apto para aplicaciones de alto rendimiento ya que su éxito dependería de herramientas externas (y algo de voodoo). Este artículo por ejemplo habla de cómo tuvieron que reescribir desde cero el Intérprete de PHP para poder hacer su plataforma extensible:
http://www.sdtimes.com/blog/post/2010/01/30/Facebook-rewrites-PHP-runtime.aspx


10.- Los desarrolladores de PHP son baratos porque no están calificados


En esto tienes toda la razón en una parte, es mentira totalmente que la razon sea por falta de calificación. El costo de un desarrollador obedece a las reglas de mercado de cualquier servicio o producto; Oferta y Demanda. Existen menos ofertas para desarrolladores PHP y muchos desarrolladores y muchas ofertas para Java y .NET, y pocos desarrolladores. Es por eso que Java y .NET es más caro porque es un bien "escaso" y por lo tanto los desarrolladores Java y .NET ganan mejor que los PHP (de 25 a 30% más dependiendo del Seniority).
Lo interesante de esto es ¿Qué causa esta diferencia de números?. PHP al ser una tecnología mas accesible permite que más gente con menos experiencia pueda adoptar el lenguaje, Mientras que Java y .NET tienen una curva de aprendizaje mayor y son más demandantes como primer tecnología para la gran mayoría de la gente. Yo creo (aunque no lo podría probar) que el éxito de PHP se debe precisamente a esta accesibilidad (No ser fuertemente tipado, el OOP es opcional, No compilas, no hay un framework o API que debas aprender para poderlo usar, No te metes con Patrones de Diseño si no quieres, No hay Maven ni ANT ni builds, ni dependencias, etc) pero como todo tiene su costo y este es que siempre habrá más gente y más competencia y por lo tanto los sueldos no son tan buenos.

Para concluir:

No soy muy fan de este tipo de posts porque hacen parecer a las tecnologías diferentes como religiones y plantean una división en la gente que no es realista. Las tecnologías son solo herramientas y como tales hay unas que son buenas para clavar clavos y otras para apretar tornillos, esto no las hace ni mejores ni peores. Existen algunas herramientas que tiene más de un uso y otras que son más especializadas eso es todo. Lo importante como desarrollador es que no te aferres a al lenguaje que sabes usar como si fuera un credo infalible y te ofendas cuando alguien que maneja alguna otra tecnología señala fallas de la que tú sabes usar y trates de defenderlas ciegamente. Lo importante es que mantengas la mente abierta y que agregues más de esas tecnologías a tu caja de herramientas y te hagas un desarrollador más completo. Quieres ser un mejor desarrollador PHP? Simplemente aprende Java, Python, Scala, Lingo, C o cualquier otro lenguaje.

Thursday, March 8, 2012

Another nail in the Flash's coffin - The rise of HTML5 Games



You'd probably already heard about Game Closure, but if you haven't this is what you been missing...

Game Closure is an independent student start-up company that developed a pretty interesting and amazingly robust Javascript/HTML5 game SDK. The SDK can be used to create games not only for web browsers (Facebook games) but they can be deployed also to iOS and Android devices. The SDK offers client/server real-time communication so this opens the possibility of massive multiplayer capabilities.

They have been recently in the spotlight turmoil since they presented Pop Star Defense, the first game to run in all mentioned platforms which they presented on Google I/O last summer. The interesting thing here is that this endeavor usually required up to 6 months to accomplish by traditional means to any Game Developer company regardless of their size, but it only took 5 weeks to the guys on Game Closure so everyone is looking at them with dollar signs on their eyes since then. Probably the most notable of this eagerly interested companies are of course the FaceBook and Zynga couple but also includes Motorola and EA.

I'm almost certain that Zynga will be the one ultimately acquiring the company, that's mainly because they lack the any solid HTML5 strategy this becomes obvious when you look at Zynga's game portfolio and realize that its almost 100% Flash based. In a culture where Flash is decaying and lingering like a sick old cat Zynga needs to make a tremendous leap before someone else picks up the market they drop to the floor , so for Zynga, Game Closure is precisely the way to get that leap. It has recently announced that Zynga has pushed the offer to around $100 million green bills, this is almost 8 folds bigger than the last offer Game Closure received (which was around $12 million).

So I guess will be seeing HTML based farms, coffee shops and cities in our friends and wives Facebook. This is just another push towards the edge of the abyss of oblivion for Flash. As I have expressed on on the past, the only thing (IMHO) keeping Flash from flatlining is precisely the dependence Zynga has (had) on it…