Lucas Ontivero : Empresas

Pocas mujeres programando

Lucas Ontivero — Thu, 12 Jan 2012 05:13:21 GMT

Termino de leer el artículo de Martin Fowler: DiversityImbalance y la verdad es que no estoy de acuerdo con lo que sugiere ese post. Al parecer Fowler piensa que la razón de la bajísima proporción de mujeres programadoras se debe a que estas son excluidas por un sistema algo prejuicioso sobre las capacidades o inclinaciones de las mujeres.

Que la falta de mujeres programadoras es un problema grave, es algo evidente, al igual que lo es el hecho de que en una industria, en la que la necesidad de encontrar nuevos talentos se acrecienta día a día, solo se cuente con la mitad de la población (la masculina). También estoy de acuerdo en que este desbalance daña nuestra profesión, y en cierto punto nuestra reputación.

Ahora bien, lo que realmente me sorprende es que el desbalance se produce principalmente en el rubro programación y no tanto así en otros muy próximos como Testing, Business Analysis, UI Design o Project Management. Es decir, estamos rodeados de mujeres pero difícilmente nos sentamos al lado de una. Por esta razón, y siguiendo el pensamiento de Fowler, me pregunto ¿será que la gente de Testing, los analistas funcionales, los diseñadores de interfaces de usuario y los gerentes de proyecto son menos prejuiciosos que los programadores? ¡Por supuesto que no!

Yo estudié en la Universidad Tecnológica Nacional (Argentina) en donde todas las carreras son técnicas y entre ellas, las carreras con mayor número de mujeres eran ingeniería de sistemas e ingeniería química pero en otras carreras como mecánica, electromecánica, industrial, metalúrgica, civil y otras que no recuerdo, los muchachos se sentían afortunados si en alguna de las materias encontraban una chica. ¿Estoy siendo lo suficientemente claro?

Una situación similar, aunque a la inversa, se puede observar (al menos en mi provincia) en las carreras en las que predominan las mujeres como son los casos de las carreras de lenguas, odontología, psicología, recursos humanos entre otras. ¿Pero por qué sucede esto? ¿Será que existen prejuicios sobre las capacidades de los varones en esas carreras? ¿O quizás no tengan las aptitudes necesarias?.

Este desbalance ocurre no solo en lo que a programación se refiere sino que es común a muchas profesiones o actividades, no obstante es curioso que del número total de mujeres en las empresas de desarrollo de software muy pocas se dediquen a programar. Entonces es aquí en donde el terreno se puede volver algo escabroso. Entiendo que independientemente de la cultura, existe cierta presión social tanto sobre hombres como sobre mujeres que condicionan de cierto modo sutil, aunque poderoso, la elección de las profesiones y/o actividades que cada cual puede desempeñar y es quizás por eso que parezca natural observar grandes desbalances en carreras fuertemente técnica y tradicionalmente reservada a los hombres (como por ejemplo: ingeniería metalúrgica) y lo mismo sucede con aquellas en las que históricamente han sido reservadas para las mujeres (ejemplo: enfermería).

Mi hipótesis es que socialmente la programación es vista como un trabajo reservado para los hombres y esa visión es fuerza suficiente para producir el obvio desbalance que vivimos diariamente en nuestras empresas. Por esa razón es que entiendo que la manera más eficaz para reducir este desbalance es trabajar para cambiar esa percepción social y de ese modo lograr que más y más mujeres se interesen por esta pasión que es programar. Entonces, manos a la obra!

Programar no es tan complicado

Lucas Ontivero — Sun, 08 Jan 2012 05:23:23 GMT

Es fácil entender por qué los hombres de negocio prefieren cantidad de desarrolladores sobre calidad de desarrolladores, es por lo que yo llamo el pensamiento lineal en la administración y que no voy a discutir nuevamente aquí pero solo diré que esa tendencia lleva implícita la idea de que programar no es tan complicado y por lo tanto cualquier programador podrá hacerlo bien.

Lo que cuesta entender es el por qué Ivar Jacobson dice que el 80% del trabajo de programación es algo mecánico (“it is not brain work” - según él). Ivar Jacobson es uno de esos personajes que todo el mundo debe conocer y cuyos aportes han sido grandiosos (salvo este) y por lo tanto se merece el mayor de nuestro respeto aunque sinceramente lo primero que pensé cuando lo escuché por primera vez fue: “ojalá hubiese estado presente un programador iraquí para que le tirara un zapatazo”

Si a la tendencia de “los hombres de negocio” de preferir cantidad sobre calidad se le suman las opiniones de verdaderos gigantes de nuestro medio como Ivar Jacobson, la idea de que programar es relativamente sencillo toma todavía mucha más fuerza y nos hace un flaco favor. Sumado a esto tenemos una realidad difícil de falta de talentos debido a la gran demanda de desarrolladores en la industria que lleva a que conseguir buenos desarrolladores sea una tarea complicada.

Por estos motivos es que muchas empresas completan sus puestos con lo que muchas veces llaman “programadores promedio” que hace referencia a aquellos programadores cuya principal destreza es la fuerza bruta. (Si como dijo Lampson: todo problema en computación puede ser resuelto añadiendo un nivel de indirección; según el “programador promedio”: todo problema en computación puede ser resuelto añadiendo un IF)

Lo interesante del caso es que las expectativas que se tienen sobre el desempeño de estos programadores son muchas veces demasiado altas y así se pretende lograr software de calidad superior con desarrolladores de calidad promedio desviando el foco hacia las metodologías, QA, auditorías y herramientas entre otras cosas.

Está claro que para muchas tareas de desarrollo no se necesitan genios, también es cierto que las tareas que requieren mayores destrezas las deben realizar aquellos con mayor experiencia y conocimientos, es claro además que todo el mundo es distinto y que no se pueden contratar todos rock stars pero una cosa es decir esto y otra mucho más delicada es decir que programar no es tan complicado.

Management deficiente (I)

Lucas Ontivero — Fri, 09 Dec 2011 08:58:49 GMT

Introducción

La historia del software está plagada de ejemplos de proyectos que fracasaron estrepitosamente, estos por lo general han excedido el presupuesto estimado, el esfuerzo estimado y el tiempo estimado en muchas veces y si bien parece que la industria viene haciendo avances importantes en estos problemas, aún hoy es común ver u oír de proyectos que fallan de manera espectacular.

Voy a introducir solo algunas de las razones de por qué esto sigue sucediendo, de cómo puede solucionarse y de cómo afecta a los equipos. Pero el foco voy a centrarme en la gente, en cómo los afecta, en sus reacciones y motivaciones (o desmotivaciones) y para ello voy a usar un ejemplo real de un proyecto en el que participé.

Costos

Todos los proyectos que fracasan tienen una característica en común: superan los costos. Sea porque se renegocian o porque pierden dinero o porque no ganan lo esperado, o porque se extienden en el tiempo (también representa un costo) o por el motivo que fuera, los costos están siempre relacionados al fracaso de un proyecto.

Uno de estos costos, y probablemente uno de los que más afectan a la moral de los equipos es el llamado costo de calidad probre, costo de mala calidad o costo de no calidad, esto es, cuanto cuesta (dinero) desarrollar software con defectos (bugs) y luego tener que arreglarlos. Mientras más alto es este costo, más probabilidades existen de que un proyecto fracase.

Una introducción a La Historia

La historia con la que quiero ejemplificar se basa en el desarrollo de una aplicación gubernamental en la que trabajé y a la cual me referiré con el nombre ficticio de “pyjs”. En este proyecto, el costo de calidad pobre era una aberración, cada caso de uso requería un esfuerzo de entre 2,5 y 4 días-hombre de desarrollo y se le hallaban un promedio de 12 bugs. Así, el equipo, formado por alrededor de 13 desarrolladores desarrollaba algo así como 40 casos de uso por sprint de 2 semanas.

Lo interesante de esto es que con esos 40 casos de uso, venían también unos 480 bugs! Digamos que si arreglar cada uno de eso bugs costara tan solo una hora de desarrollo, esa bolsa de bugs costaría 480 horas-hombre, a digamos algo así como 10 u$/hs serían u$ 4.800 tirados por la ventana cada 2 semanas.

Un poco más sobre este costo

Una de las razones por la que deben atacarse rápidamente las causas de este costo es porque este crece de manera exponencial a medida que la detección de los defectos se aleja de la fase de desarrollo. Así, llevándolo a lo cotidiano, cuesta mucho menos (menos dinero) encontrar un defecto en una revisión de código antes de subirlo al repositorio que encontrarlo durante la etapa de pruebas ya que aquí se debió utilizar tiempo del equipo de pruebas, hay más reportos, más administración, etc. Ni que hablar si en lugar de encontrarlo el equipo, lo encuentra el cliente.

Volvamos a La Historia

En el pyjs la relación testers/desarrolladores era muy baja, no por algún número teórico sino por la simple razón que el equipo de pruebas no daba a basto y por ende se retrasaba cada vez más hasta llegar el punto de que probaban funcionalidad que se había terminado más de un mes atrás. Así las cosas, para cuando reportaban los defectos, el equipo ya estaba desarrollando otras funcionalidades (muchas que dependían del correcto funcionamiento de las anteriores) y una vez acumulados estos bugs se repartían muchas veces a “el equipo de los bugs”, esto es, a miembros del equipo que no habían estado involucrados en el desarrollo de esos casos de uso y que por lo tanto no los conocían, no sabían qué debía hacer esos casos de uso, cómo se relacionaban con otros casos de uso ni nada en lo absoluto. Esto convertía a estos desarrolladores en los “mártires de turno” (digo “de turno” porque alguna vez los cambiaban).

Una cosa curiosa es que la líder de proyecto comentaba que se requería el mismo esfuerzo para desarrollar los casos de uso que para arreglarlos y por esta razón en algunas ocasiones se alternó un sprint para desarrollo y el siguiente para corrección de bugs. Esto quiere decir que a menos que al cliente se le presupuestara 3 o más veces el costo de desarrollo, el proyecto era inviable.

Otra cosa a tener en cuanta es que si los casos de uso no tuvieran defectos, el proyecto podría haberse terminado en quizás en la mitad del tiempo.

Reacciones del management

Ante semejante situación, las reacciones del management fueron las siguientes:

Remover a aquellos desarrolladores que habían participado en el desarrollo de las funcionalidades con mayor número de defectos.
Incrementar el número de desarrolladores e incrementar el “seniority” del equipo incorporando personas con mayor experiencia (incrementando los costos). Esto llevó a la necesidad de “distribuir” al equipo ya que estos nuevos desarrolladores estaban en otras ciudades.
Asignar más presupuesto al proyecto para posibilitar que desarrolladores “externos” al equipo participaran en la creación de casos de uso de manera independiente (desde sus casas y en horarios extralabolares)
Pedir a los desarrolladores que por favor entendieran la situación del proyecto y que no generaran más defectos.
Pedírselo de nuevo
… y de nuevo…. y otra vez más.

Reunión de retrospectiva tras reunión de retrospectiva los líderes de proyecto (digo los porque en realidad eran 2!) repetían que el mismo sermón a los desarrolladores: “Entindan! Les pedimos que por favor entiendan que tienen que generar menos bugs a la vez que necesitamos que incrementen la velocidad!”, “A esta situación llegamos por la falta de compromiso de los desarrolladores”, “Necesitaban más memoria y se las dimos, pidieron cursos y se los estamos gestionando, ahora recapaciten!”

Cómo afectó al equipo

Si esto no bastaba para bajarle la moral a alguien, si alguno con una psiquis de acero todavía permanecía en pie, los reportes de estado del proyecto realizados por teléfono a los superiores argumentando que el proyecto estaba como estaba por una “falta de compromiso”, “por los descuidos”, “por no leer la documentación correctamente” más otras actitudes desmotivantes como los mails pidiendo al equipo que “piensen en las cosas que están haciendo mal”, acabaron con las fuerzas del equipo.

El mismo equipo que reunión de retrospectiva tras reunión de retrospectiva decía que los tiempos estaban muy comprimidos, que los bugs se detectaban muy tarde y que se sentían presionados a entregar aun a sabiendas de que estaban entregando con baja calidad.

Por otro lado, la remoción de prácticamente la mitad del equipo de un plumazo, personas que quizás se desempeñaban algo por debajo del resto pero que hacían valiosos aportes al proyecto (recuerdo que muchos de ellos trabajaban muchas horas de más e incluso cuando se les pidió trabajar un fin de semana lo hicieron de buena gana), no ayudó a mejorar en lo absoluto sino todo lo contrario. De hecho esta fue la primera acción que se tomó.

La moral de un equipo es algo que debe cuidarse celosamente y protegerla porque marca una diferencia enorme en los resultados. Por eso, luego de que la moral bajara al nivel más bajo que recuerdo, el equipo comenzó a realmente desempeñarse por debajo de sus posibilidades, a importarle menos sus resultados, a ser lo que todos los días se les decía que eran: descuidados y poco comprometidos.

Costos de calidad

Existen otros costos de calidad divididos según las tareas específicas que requieren como costo de inspección, costos de prevención y así, pero básicamente lo que se busca es invertir (dinero) en actividades claves que reduzcan el número y severidad de los defectos, idealmente identificándolos en las etapas más tempranas posibles donde el costo de un defecto es menor.

Costos de calidad en esta Historia

En el pyjs la inversión en actividades de “prevención” era prácticamente $ 0,00. La justificación era que no había tiempo, que las entregas al cliente requerían que se utilizara todo el tiempo disponible en el desarrollo de las funcionalidades pactadas. Por esa razón, cuando se pidió al TL que no se siguieran desarrollando las pruebas unitaria y luego cuando propuso volver a realizar las revisiones de código obtuvo un “no hay tiempo para esas cosas”.

Por fortuna, digo que la inversión fue de “prácticamente” $ 0,00 porque se autorizó que el arquitecto desarrollase un generador de código y un set de componentes reutilizables en 4 días, lo que ayudó al proyecto a salir solo un poco de apuros. Esto se autorizó gracias al poder seductor del pensamiento mágico que todo “generador de código” despierta en algunas mentes.

Mi reacción

Como esto estaba muy claro para mi, retrospectiva tras retrospectiva planteaba la necesidad de incorporar aquellas prácticas que todo el mundo sabe que dan resultado: revisiones de código, pruebas unitarias (aunque sea en aquellas funcionalidades más delicadas), reuniones técnicas para aunar criterios o despejar dudas (el equipo se dividía entre 4 ciudades distintas).

Por otro lado, con el fin de obtener feedback más rápido por parte de testing, propuse incrementar el equipo de testing y agilizar las pruebas, filtrar aquellos defectos que no eran realmente defectos o que no se querían o podían arreglar en ese momento (los reportes de defectos en crudo a los desarrolladores es una perdida de tiempo descomunal), no enviar funcionalidades sin probar al cliente (una práctica habitual que encarecía el proyecto y le causaba muchísimo daño).

Por último, no desmotivar al equipo!

Fin de la Historia

Mis recomendaciones cayeron en oídos sordos todas la veces, ni siquiera formaban parte de las minutas de las reuniones de retrospectiva ya que la razón de los problemas no eran ningunas de esas estupideces que yo decía sino que era un tema de falta de compromiso, descuidos y falta de profesionalidad.

A todo esto, la pregunta obvia era: ¿si existe falta de compromiso en algunos miembros entonces por qué no se los remueve?. Y la respuesta fue que no se iba a modificar más el equipo porque la falta de compromiso era general! Yo creo que la razón era otra: si luego de cambiar a la mitad del equipo se cambia a la otra mitad y todo sigue igual…. ¿que se le reporta a los jefes? ¿que los 13 nuevos desarrolladores son tan indolentes como los anteriores?

Conclusión

Yo tenía una hipótesis de que los proyectos sí fallaban la mayoría de las veces por cuestiones técnicas, esto era porque he visto algunos pocos proyectos fallar por problemas técnicos pero ahora está claro que los grandes y monumentales fracasos son en verdad por un management deficiente.

¿Quién quiere ser líder de proyectos?

Lucas Ontivero — Fri, 25 Nov 2011 02:59:05 GMT

Hace un par de semanas atrás estábamos reunidos todos los líderes de proyectos y líderes técnicos del sitio de Córdoba porque nos visitaba uno de los mandos altos de la empresa, luego de tratar una serie de asuntos, este preguntó a los TLs ¿Alguno de Uds. piensa ser líder de proyectos y seguir la carrera de management?. De los 15 o 20 TLs ninguno levantó la mano.

Están bien frescas en mi memoria las incontables veces que he presenciado el intento de muchos desarrolladores por “escapar” hacia el paraíso del management. Muchas veces por tener un mejor salario, otras porque no les gusta programar pero quizás la mayoría de la veces es por una combinación de mal salario, poca satisfacción por lo que hacen y poco valor social de la especialidad; entre otras cosas.

Pero, ¿por qué ninguno de estos TLs quiere seguir la carrera de dirección de proyecto?, ¿no saben que $20.000* es mayor que $10.000**?, ¿acaso nunca escucharon eso de que dirigir es mejor que ser dirigido? Creo que la respuesta no viene por ese lado, la explicación es que existe una carrera técnica paralela a la de administración, que sus conocimientos técnicos son valorados de igual manera que los de aquellos que administran los proyectos, que tener la responsabilidad técnica de un proyecto contribuye al éxito del mismo de igual manera que la responsabilidad de aquellos que administran los recursos.

No sé lo que pensaré en 10 años pero si lo que pienso hoy: así debe ser.

* y ** son solo números inventados.

¿Querés trabajar en Globant?

Lucas Ontivero — Sat, 19 Nov 2011 17:47:00 GMT

Actualmente trabajo en Globant. Globant es la empresa líder de América Latina en la creación de productos de software innovadores orientados a una audiencia global y una de las características más impresionantes que la distinguen es que está en constante crecimiento y expansión tanto de sus operaciones y clientes como así también en cuanto a lo geográfico. Hoy Globant está en muchas ciudades de Argentina (Buenos Aires, Tandil, Bahía Blanca, La Plata, Córdoba, Rosario y Chaco) , en Uruguay (Montevideo), Colombia (Bogotá) y oficinas en Boston, San José y Londres.

Ese crecimiento y la necesidad de superar las expectativas de clientes internacionales (para nombrar solo algunos: EA, LinkedIn, Deloitte, JPMorgan, Google, British Standards, Sun, Sony, IBM, Telefónica, Dell, Citibank, Telecom, Southwest Airlines… y sigue y sigue) hace que Globant se encuentre en la búsqueda permanente de talentos donde quiera que estos se encuentren.

Por eso, si te interesa trabajar en Argentina, Uruguay o Colombia, en una empresa de primera; Globant es para vos.

Juniors por siempre

Lucas Ontivero — Wed, 24 Aug 2011 03:49:33 GMT

Al menos en mi país, a los principiantes de esta industria se los llama juniors. Esa es la categorización con la que se ingresa a una empresa si no se cuenta con experiencia y conocimientos demostrables que justifiquen una categoría superior. La idea es que con el tiempo y luego de ir adquiriendo los conocimientos necesarios, un junior va a ir progresando paulatinamente transitando por las distintas categorías hasta convertirse en un senior o similar. La verdad es que en muchos casos se espera que esa metamorfosis ocurra de manera mágica simplemente con el paso del tiempo, cosa que rara vez sucede.

Nadie contrata a un principiante para formarlo, muy por el contrario, se los contrata con la idea ponerlos a producir “código real” en “proyectos reales” para “clientes reales". Y así sucede, a poco de entrar ya están codificando como pueden, en muchos casos sin guía alguna y en el mejor de los casos con algún que otro referente al que le pueden consultar algún que otro tema puntual, pero no mucho más. Por esto es que muchos desarrolladores van aprendiendo distintas tecnologías (las que les demanda el proyecto de turno), frameworks, estilos, modas y demás pero nunca pueden dar el salto ya que nadie, ni la universidad ni las empresas los preparan para ello.

Si al igual que yo, te pasas varias horas a la semana explicando una y otra vez el por qué tragarse las excepciones es una mala idea, sabrás bien de que hablo. No obstante, esas explicaciones, por mejor intencionadas y didácticas que sean resultan siempre insuficientes y tardías. Simplemente esa no es la manera de enseñar ni de aprender y en la cabeza del principiante, todas esas enseñanzas parecen conformar más una serie de tips disconexos que una estructura sólida de conocimiento sobre el estado del arte.

Por eso, en mi experiencia, y salvo contadas excepciones, la única manera de adquirir los conocimientos necesarios para nuestra profesión es con la ayuda de un buen maestro y luego sí, leyendo (algo así como hacer la tarea). Sin un maestro, y en lo posible uno bueno, muchos de los principiantes terminan siendo juniors por siempre.

¿Tenés una lista de correo para los desarrolladores?

Lucas Ontivero — Thu, 09 Jun 2011 21:06:55 GMT

La dinámica de una empresa puede evaluarse quizás por el número y diversidad de los canales de comunicación que ofrece a su gente. Así, en empresas en las que la comunicación tiene canales formales bien definidos, la cooperación entre equipos y áreas siempre es más difícil que en aquellas con diversidad de canales horizontales.

Uno de esos canales los constituyen las listas de correo (viejo pero actual, todavía). Y ayer he tenido una muestra de ello. Resulta que en la semana he tenido que realizar muchas llamadas a miembros de la empresa en la que trabajo y cada vez que necesité llamar a alguien tuve que abrir un browser, loguearme en el sitio de la empresa donde se encuentra el directorio, buscar a mi contacto para luego discar su número de extensión en x-lite. Hacer esto una y otra y otra vez fue tan frustrante que escribí dos aplicaciones de consola (xcall y whois) de modo que si quería llamarme a mí mismo, por ejemplo, solo debía escribir:

C:\>xcall lucas.ontivero

Y x-lite me llamaba inmediatamente. De existir más de una persona con ese patrón simplemente me mostraba sus datos para intentarlo nuevamente.

Por otro lado si recibía un mail o un llamado de alguien desconocido simplemente escribía:

C:\>whois fulano.detal

Y me mostraba quien era, proyecto asignado, seniority, área, departamento, email, teléfonos, etc.

Como me resultó tan útil, decidí compartirlo en la lista de correo “Developers” en la que nunca había participado por si a alguien le servía. Los resultados fueron inmediatos e impresionantes. Solo un par de horas después alguien lo había portado a Ruby y subido a Github para los que no tenían Windows, solo una hora después de eso ya había sido portado a PHP para ser usado también con ekiga. Y más tarde, y puesto que los resultados de las búsquedas se muestran por consola, ya había quienes mostraban como podía usarse para consultar información de los empleados. Yo simplemente mostré como podríamos consultar quienes eran los arquitectos de la empresa filtrando los resultados con un findstr mientras que otro mostró como obtener otros dato interesantes filtrando los resultados con grep.

Tampoco faltaron los que tomaron el código para mejorarlo o proponer una GUI para el mismo y quienes propusieron ideas o plantearon sus dudas sobre la utilidad de esas herramientas.

Para mi toda la movida fue simplemente sorprendente. ¿Y vos, tenés un canal para estas cosas?

De Oráculos y MSProject

Lucas Ontivero — Thu, 02 Jun 2011 15:18:00 GMT

Hoy he recibido un cronograma en un archivo .mpp que no tenía una aplicación asociada para abrirlo así que busco en Google “.mpp file extension” ¡Y claro!!! Es un project!

Juro que no lo recordaba. Creo que hace 6 o 7 años que no veo uno así que me puso nostálgico. Lo que más me gusta del project es que tiene información muy útil como que el 24 de Enero del 2012 vamos a estar todos festejando la culminación exitosa del proyecto o que el módulo XXXX va a comenzar el 10 de Octubre y que luego de 4,3 semanas el cliente nos va a dar el Ok.

¡Esta información SÍ que es valiosa!

Nota: Sí, estás en lo correcto, es una sobredosis de sarcasmo.

Resultados con TDD en Microsoft, IBM, HP y Ericsson

Lucas Ontivero — Sat, 21 Aug 2010 13:08:52 GMT

Las recientes experiencias en la industria confirman que para obtener mejoras sustanciales mediante pruebas unitarias es necesario incorporar TDD (Test-Driven Development) como práctica integral del desarrollo. Aunque TDD no es una práctica nueva, solo experiencias recientes en Microsoft, IBM, HP y Ericsson comprueban la efectividad y factibilidad de ésta en proyectos reales y de reputación mundial. Los números de los resultados en realmente asombrosos. Les recomiendo leer las siguientes publicaciones...(read more)

¿Te ves como un verdadero profesional?

Lucas Ontivero — Mon, 31 May 2010 05:52:05 GMT

Tanto se los he dicho que ya están empezando a darse cuenta de que realmente no entienden las necesidades del negocio. Al parecer ellos se meten en la programación desde chiquitos y el mundo se les achica tanto que no comprenden que hay compromisos asumidos y que el cliente está esperando el producto. Pero bueno, yo sigo explicándoles y varios lo entienden bien pero hay un par que verdaderamente no parecen estar muy convencidos. Lo peor de todo este asunto es que cada vez trabajan más lento y cada...(read more)

[Unit Tests] Contras de implementar test unitarios

Lucas Ontivero — Tue, 29 Sep 2009 00:46:21 GMT

He querido compartir en este video de 7 minutos mis experiencias con la implementación de test unitarios cuando la inversión en capacitación es escaza. Que peligros encierra una pobre capacitación y ante que escenario nos podemos encontrar es de los objetivos de este video. Lucas Ontivero...(read more)

[Productividad] Parálisis por Emails

Lucas Ontivero — Mon, 17 Nov 2008 13:32:00 GMT

El correo electrónico es una de las herramientas más importantes de trabajo, todos tenemos un cliente de correo que chequeamos varias veces al día ya sea en nuestro trabajo o en nuestros hogares. Es tanto un medio de comunicación como un sistema para recibir alertas y recordatorios, todos los sistemas se comunican con nosotros mediante correo electrónico, " se te ha asignado un nuevo ticket ", " quedan 3 días para renovar las licencias ", " inscríbete para el curso de seguridad...(read more)

[MISC] Masajes en la oficina

Lucas Ontivero — Fri, 22 Aug 2008 23:20:41 GMT

Una buena para recursos humanos! Esta entrada es para compartir una experiencia muy buena. Es que en la empresa ahora... en realidad hace ya un par de meses, tenemos el servivio de chair massage disponible para todos los empleado. La cosa es que estaba bastante tensionado y estresado por temas relacionados a lo proyectos, los deadlines, los clientes y las bolsas de bugs de los productos que mantenemos que me decidí a sacar un turno para unos masajitos, cosa que hice con bastante temor a la burla...(read more)