Así no se hacen las cosas por Ernesto Kiszkurno

He probado muchas herramientas. Tal vez he probado [casi] todas las herramientas. He elegido una y luego he cambiado y esto no ha ocurrido una, sino cientos de veces.  La próxima/nueva herramienta siempre parece mejor que la que usamos, como  cuando estamos haciendo una fila y las otras parecen más rápidas . Nos enamoramos de las herramientas . Todas tienen algo distinto. Tal vez alguna característica que simplifica nuestros procesos y rutinas de trabajo. Pero también tienen cosas que no se ajustan a nosotros.  Las herramientas son herramientas, no son un fin en si mismo. Usémoslas, juguemos con ellas, exploremos y experimentemos. Hacer eso nos permitirá descubrir nuevas formas de organizarnos y ser más productivos. Pero sabiendo que lo que realmente importa a la hora de manejar nuestro tiempo son las rutinas de trabajo . Seguimos pensando.. Si querés ver todos los productips podés ir aquí . Foto de  Suzy Hazelwood  en  Pexels .

Me cuesta bastante decidir si un texto está bien o mal escrito, mucho más complicado es decir si alguien escribe bien o mal. Hay honrosas excepciones por supuesto pero hasta en eso la cosa termina siendo subjetiva. Me gusta más pensar en si el texto es útil o no [para mí]. Me ahorra mucha discusión. Luego de esta intro quisiera llamar la atención del amigo lector sobre el blog de UALA . Lo sigo desde hace un tiempo y me gusta. Tienen un estilo de escritura piola y, a grandes rasgos, los temas que tocan suelen invitarme a leer. En particular me gusta cuando aparecen artículos relacionados con la problemática de armar equipos de trabajo multidisciplinarios para construir producto (o debería decir software o será  indistinto en este caso). Hace un tiempo hablaban sobre lo que ellos buscan en un científico de datos , ahora hablan sobre experiencia de usuario , tema por el que me estoy interesando otra vez en este último tiempo y que por cierto es tan necesario en estos días tan digital...

Sigo publicando aquí notas de Perspectiva Digital . La cuarentena me ha permitido despuntar un poco más el vicio. La situación actual sin precedentes está obligando a las empresas a acelerar los planes en su  camino hacia la nube  (journey to the cloud).  Vemos esta aceleración en dos tendencias que existían con anterioridad pero que ahora se han vuelto cruciales (decisivas para mantener el funcionamiento). Por un lado y pensando en el corto plazo,  facilitar el trabajo remoto de toda la fuerza laboral que esta cumpliendo con el distanciamiento social.  Por el otro, y más de mediano plazo,  ampliar las plataformas y canales digitales de la compañía , tanto para su trabajo operativo como para la generación de ingresos digitales. No hay duda de que los tiempos apremian pero debemos cuidarnos de que el apuro no nos haga caer en errores comunes y conocidos. Un primer error común es empezar a caminar sin definir claramente qué es lo que est...

Qué importante es tener gente que analice bien. En este mundo inmediato en el que todos quieren pasar a la acción es importante pensar antes. Los buenos analistas [funcionales, de negocio, de procesos o de lo que sea] son difíciles de encontrar y de bancar. No cualquiera tiene la paciencia para pensar las cosas y explorar opciones antes de elegir una estrategia o un curso de acción. Tal vez experimentar esas opciones prototipando o armando un MVP (un mínimo producto viable en inglés), como se dice ahora. No cualquiera tiene la mezcla de visión macro, con ojo para los detalles y desde distintos ejes (negocio, funcional y/o técnico). A su vez, no siempre aparecen de repente, a veces tardan un poco en revelarse o en demostrar su valía. Por eso es que digo que hay que bancarlos, darles tiempo. Con buenos analistas todo es más fácil, más fluido y más eficiente. Seguimos pensando..

Todos sabemos que las decisiones se toman con la mejor información disponible a ese momento. Con el diario del lunes es fácil decir que alguien se equivocó. Muchas decisiones que parecen obvias a posteriori no lo son a priori. Esto, que es válido en general, es particularmente cierto para los temas relacionados con el software. He visto muchas situaciones donde una mala decisión tecnológica desencadenó retrasos, sobrecostos, etc. Pero el punto de esta entrada no es hablar de aquellos que decidieron sobre algo y luego la realidad mostró que se equivocaron. Aquí quiero hablar de los que acertaron. En los últimos días me tocó formar parte de algunas reuniones donde se discutía la necesidad de hacer cambios profundos en una determinada infraestructura tecnológica, con varios años de funcionamiento exitoso . Fue interesante ver que un común denominador en ellas era evaluar las decisiones tomadas hace tiempo en el contexto actual. Las frases eran algo así como "hicimos mal ...

"El problema de construir software es que hay que lidiar con personas" decía yo al comenzar una materia que daba por ahí sobre gestión de proyectos y procesos relacionados con software.  Los chicos de la audiencia me miraban escépticos pues a cierta edad creemos que los problemas son sólo técnicos  y que con un poco de cabeza todo se solucionará.  Yo sé que no hay otra que dejarlos avanzar. En unos años van a entender que algunos problemas son adaptativos   y que los cambios en las organizaciones se activan con "otros resortes". Inclusive van a ver que hay organizaciones que nunca van a cambiar ciertos rasgos pues los tienen incrustados en su cultura, en sus valores y en sus personas. Cambiar la forma en que una organización construye software no tiene que ver con enseñar metodologías nuevas o implementar herramientas. Esas son acciones parciales, que pueden ser necesarias, pero seguramente no serán suficientes. Cambiar la forma en que construimos ...

Días atrás conversaba con clientes sobre un desafío grande que habían pasado con éxito sus sistemas: el  hotsale .  Me decía que una de las medidas que habían tomado era la de hacer un freeze de sus sistemas tiempo antes del evento. A lo que yo contestaba que esta medida, acertada en el corto plazo pues permitía pasar el hito, no debería ser tomada como una práctica común. Lo que deberíamos hacer es todo lo contrario. En lugar de poner menos en producción para disminuir los momentos de dolor, deberíamos hacer que poner en producción nos duela menos y para eso hay que hacerlo continuamente  (como dice DevOps). En ambos casos tratamos de disminuir nuestros dolores pero de forma distinta. Hoy me llegó por aquí  un breve video del mejor guitarrista de blues de todos los tiempos ( Sevie Ray Vaughan ) que muestra exactamente a lo que deberíamos aspirar a la hora de introducir cambios en producción. Espero lo disfruten. Seguimos pensando..

Así como los grandes proyectos de consultoría se "agilizaron", para pasar de años o meses a semanas o días, o los grandes data warehouses cedieron espacio a herramientas más pequeñas pero que dan poder de análisis a los usuarios finales y "agilidad" para hacer más rápido las cosas, el mundo de las grandes desarrollos de software y productos va a ceder espacio también . ¿Por qué desarrollar aplicaciones complejas, si podemos lograr lo mismo mediante microservicios y APIs? Son más fáciles entender y rápidos de evolucionar. Podemos reusarlos como building blocks para construir soluciones más grandes o complejas. Podemos usarlos internamente y externamente. Podemos combinar múltiples nubes. ¿Alguien no cree que esto sea así? Lo podemos convencer mostrándole el crecimiento que vienen teniendo ( ProgrammableWeb ). O el ecosistema de tecnología en el que nos movemos actualmente. Las APIs y micro servicios permiten el armado de verdaderos mashups  ...

En la parte 1 de una interesante saga llamada 5 Disruptions to Marketing , Scott Brinker me hizo notar un fenómeno interesante. Así como, cada vez más, el presupuesto de IT está siendo desviado a áreas de Marketing, las actividades de desarrollo (las más básicas obviamente) también estarían siendo tomadas por lo que Scott llamó "los ciudadanos del departamento de Marketing": "I use the phrase “citizens of the marketing department” quite intentionally, because these wizard-like capabilities that marketers are acquiring align with three big IT-democratization movements: CITIZEN DEVELOPERS — who use no-code or low-code tools to create web apps, mobile apps, interactive content, bots, and other kinds of functional experiences for staff, prospects, and customers CITIZEN INTEGRATORS — who use iPaaS and other workflow automation tools to create business processes on-the-fly, intelligently routing data and triggering activities across multiple teams CITIZEN ANALYST...

Hace muchos años, en medio de un enorme proyecto de desarrollo, tuve un contrapunto importante con un cliente sobre cuál  era el verdadero problema a la hora de construir un gran sistema core. Él decía que el mayor desafío estaba en construir los módulos y como ya estaban terminándose , lo peor había pasado. Yo sostenía que la integración de todos esos módulos era un desafío aún mayor que la construcción individual. Hace unos días me encontré con una encuesta de Dell donde se concluye que: "Integration is a struggle for organizations in the US – most (87%) respondents admit that their organization has experienced drawbacks because of poor integration, with two thirds (67%) acknowledging that they have missed business opportunities." "For almost three quarters (74%) of surveyed CIOs, successful integration will be crucial if their organization is to remain competitive over the next five years. This is perhaps because 70% of respondents expect their organiz...

Me encuentro muy seguido con gente que piensa la calidad como un firewall que limita todo lo que pasa hacia producción, en lugar de pensarla como un proceso continuo en el que hacemos las cosas cada vez mejor, colaborando a lo largo de la cinta infinita de la imagen. Mejorar la calidad es movernos por esta verdadera cinta de Moebius  cada vez más rápido y en forma más fluida (sin detenernos). Cuando entendemos esto es que, por ejemplo, empezamos a apostar por otras formas de automatización que van más allá de lo obvio o empezamos a pensar en el next step as a customer  para facilitar las cosas. Seguimos pensando..

Leo en este post de CIO Insight que el 59% de los profesionales de IT que entrevistan dicen que están construyendo sus propias aplicaciones para satisfacer los requerimientos del negocio. Como si los problemas para integrar sistemas en forma fluida no fueran suficientes, el 59% quiere sumar los problemas de construir software. Entiendo que debamos desarrollar ciertas   piezas de software por muy específicas o particulares (las mismas integraciones sin ir más lejos) pero no todo. Miremos un poco para afuera a ver si nos podemos ahorrar el problema. Luchemos contra esa deformación profesional que tenemos nosotros los informáticos de querer construir todo. No estamos en los '90. Ahora está todo hecho! Invertir algo de tiempo en investigar para no reinventar la rueda es útil, aún en el escenario de tener que construir, porque lo haremos con mayor sabiduría. Seguimos pensando..

Trabajar tanto tiempo haciendo testing puede hacerte perder la perspectiva y creer que lo único que podemos hacer para mejorar el software es testing pero lo cierto es que no es así.  Testear es sólo una de las formas de controlar calidad. No es la única y ni siquiera es para mejorar realmente pues sabemos que el testing es básicamente como el termómetro del código. Lo usamos para ver si el software (o su código) está enfermo. En el blog de testing de Google salió hace unos días un artículo llamado Code Health donde cuentan las cosas que hacen para mantener la buena salud de ese código que tanto nos costó generar. Revisiones de código, ejercicios de refactoring, mejoras en las librerías, automatizaciones, formateadores automáticos de código, son algunas de las prácticas que usan. A no olvidarse, la salud no sólo se cuida tomándose la fiebre seguido. Hay que hacer otras cosas (comer bien, ejercitarse, etc.). De hecho hay que armar un ecosistema de prácticas que, in...

Hacía tiempo que no leía o escuchaba a Joel. Para los que no lo conocen Joel Spolsky entre otras cosas es el autor de Joel On Software , un sitio que se dedicó durante muchos años a escribir sobre desarrolladores de software . En este caso les dejo un video de una charla que dio hace poco. Es interesante su abordaje al tema de la responsabilidad y el impacto que tiene el software en nuestra vida (la real, no la virtual!). Seguimos pensando.. Nota aparte: El formato del escenario donde presenta me parece un poco incómodo para el presentador y creo que le quita un poco de punch a la charla. Me hace acordar a un capítulo de Black Mirror.

Hace un tiempo decía que el problema no es construir el software sino lidiar con personas . El otro día el amigo Bruce Dickinson dijo aquí algo parecido: "El gran mensaje que intento explicar es que si bien esto es sobre tecnología, en verdad no es así, es sobre personas, como todo lo que sucede en el mundo." Seguimos pensando..  

Hace un par de años daba una materia relacionada con proyectos y procesos de software en una afamada facultad en la que los alumnos valoran mucho más las habilidades académicas y/o algorítmicas y mucho menos las blandas (la ingeniería de software por ejemplo). Por suerte la materia era optativa de modo que nadie debía comparecer obligado a ella.  Traigo este recuerdo del pasado porque usualmente yo abría esa materia diciendo algo desafiante muy parecido al título de este post. Lo decía para provocar debate pero también porque en gran medida lo pienso.  Llevar adelante proyectos tecnológicos tiene sus complejidades técnicas , obvio. Pero lo que veo en general es que lidiar con ellas es mucho más fácil que lidiar con las otras, las complejidades humanas . Tal vez esta diferencia tiene que ver con que las complejidades técnicas son más claras: se puede o no se puede hacer algo, sirve o no sirve para resolver el problema, pasa o no pasa. El problema a resolver y/o el ...

Si usted es un proveedor de servicios de testing, usted está en el negocio de proveer números confiables. Imagine que está en un proyecto de desarrollo de software de alta exposición y tiene el rol de testear el software. Imagine que le han pedido que emita un reporte periódico del estado de los defectos que el software tiene. Imagine que el proyecto tiene reuniones periódicas de seguimiento del proyecto. ¿Qué pasaría si el reporte se demora y llega luego de la reunión de avance del proyecto? No sirve. Para la siguiente reunión se requerirá un reporte actualizado. Timeliness (que el dato este actualizado a tiempo y con la frecuencia correcta) es una dimensión crítica en Calidad de Datos . ¿Qué pasaría si el reporte no refleja la realidad? Es decir, por ejemplo, la cantidad de defectos consignada en el reporte es distinta a la que hay realmente. No sirve. La validez del reporte será cuestionada, la palabra del equipo de testing será cuestionada. Correctness es otra dimensión crítica...

“No es posible que nueve embarazadas tengan un bebé en un mes” es una frase que ha repetido hasta el cansancio en más de 20 años de carrera profesional para hacerle entender a gente de todo tipo que, en proyectos de software, hay cosas que no se pueden acelerar metiendo más gente. Para entender mucho sobre la naturaleza de los proyectos complejos de software es necesario leer un pequeño libro llamado The Mythical Man-Month de Fred Brooks . Bien escrito, en forma de ensayos independientes que permiten lectura y relecturas fragmentadas, cuenta las experiencias del autor relacionadas con la conducción de grandes proyectos de software y hardware allá por los ‘70. Pero no se engañen, que el libro sea viejo no significa que no tenga mucho para decirnos de la dinámica de proyectos de hoy en día. Seguimos leyendo..

En la novela "El poder de los nombres" Úrsula Le Guin destaca la importancia de conocer los nombres para poder llamar y usar a los objetos. Aquel que conoce su nombre verdadero, podrá invocarlo. En el post What do you call something - Name matters !!! , Shrini Kulkarni reflexiona sobre lo fácil que es para las organizaciones tomar ciertos nombres, hacerlos propios (con una semántica específica) y usarlos, muchas veces incorrectamente. Así como Shrini menciona el ejemplo del testing de unidad, yo tengo ejemplos propios. Por ejemplo hay organizaciones que hablan del área de QA para referirse al área de testing y cuando hablan de testing, en realidad hablan de testing funcional (y manual). Es por ello que resulta sumamente importante entender, cuando empezamos a conocer una organización con la idea de ayudarla, cómo llaman a cada cosa. Esto evitará malos entendidos y facilitará la comunicación con sus miembros. Seguimos pensando..

Hay mucha gente que piensa que Dr. House o Sheldon Cooper son personajes originales. Irritantes, inteligentes y originales. Yo creo que no. Para mí son variaciones de una persona que existió en la vida real: Edsger W.Dijkstra .  Encuentro en el escrito The pragmatic engineer versus the scientific designer diversas pruebas de que mi afirmación podría ser verdadera. Por ejemplo esta consideración sobre los ingenieros: "The typical engineer is an a-cultural illiterate, unable to absorb or appreciate carefully written prose, equally unable to express himself well, a socially deficient bore, whose primary role in life is to make new gadgets with his hands." O la forma en que cree que los ingenieros demuestran por inducción: "The pragmatic engineer believes in the correctness of his design until it has failed to work properly; the scientific designer believes in the correctness of his design because he has understood why it must work properly. And in order to drive home ...