La build y la botella

En nuestro trabajo tenemos una botella como la de la foto. Bueno, en realidad es muuuuucho más grande. De un metro más o menos. Es de publicidad de Heineken, de esas de plástico. Tenemos implantado un Cruise Control bastante básico, pero que cumple su cometido. Cuando alguien rompe la build porque ha hecho commits de funcionalidad inacabada, o funcionalidad que rompe los tests existentes, o se ha olvidado de configurar dependencias, pues tiene que poner un euro en la botella.

La verdad es que esta medida tan simple tiene unos efectos muy curiosos. El más obvio y evidente es que nadie quiere romper la build, ya que aunque sólo sea un euro, nadie quiere regalarlo. Así que los desarrolladores somos mucho más cuidadosos con lo que subimos y con no romper nada de lo que hay ya hecho.

Otro efecto muy beneficioso es la cura de modestia. A nadie le gusta ser el que rompe la build. Hoy, un chico nuevo ha roto la build por primera vez, y le tocó poner el euro correspondiente. El hombre fue cabizbajo a depositar el euro ante la guasa general que se suele montar. No es que este hombre sea inmodesto, ni mucho menos, pero es que la sensación que tuve yo la primera vez que rompí esta build es de cura de modestia. Los desarrolladores tendemos a que se nos suba el ego muy rápidamente. Y siempre viene bien que alguien nos baje los humos, aunque sea el Cruise Control, y que tengamos que darnos un paseito ante la guasa general del resto del equipo mofándose (amistosamente) de que te toca apoquinar.

Además la gente es muy legal y hoy otro chico dejaba un euro por la build que había roto ayer. Y es que a uno tampoco le gusta quedar debiendo nada, aunque sea a la botella.

La verdad es que para la cantidad de gente que estamos trabajando en el equipo, y siendo diferentes equipos trabajando en diferentes componentes interconectados, yo personalmente tengo clarísimo que la salud de la build se debe en gran medida a los efectos de esa botella.

¿Estáis usando integración continua en vuestro equipo? Mi consejo, usar una botella. Hará de la build algo más estable y además añade un toque de diversión al día a día. Ah, y a final de año, pues siempre se puede hacer una cena con el dinero de la botella. ¡Faltaría más!

Foto by ^Vanessa^@Flickr

Cuando los premios son al trabajo bien hecho

El post de hoy no va sobre la Web 2.0, ni sobre lo último del Cloud Computing, ni sobre la última inversión de algún serial entrepeneur, ni de nada por el estilo. El post de hoy trata del trabajo. Del trabajo bien hecho.

En esto de la informática y el desarrollo de software es muy fácil acomodarse. Has estado trabajando con unas tecnologías durante muchos años, y eres ya un experto. Los problemas se resuelven rápidamente, y hay pocas cosas que no puedas solucionar. Es lo que comúnmente se denomina comfort zone.

Y así uno se puede echar años, ¿y por qué no? Estos días viene a la empresa un experto en DB2. Con sus 59 años tiene más de 20 de experiencia en DB2. Cientos de historias a sus espaldas y varios libros. Nadie le puede descubrir nada sobre este gestor de bases de datos. Lo sabe absolutamente todo, y con toda esta experiencia lo cierto es que uno puede llevar una muy buena y tranquila vida como consultor.

Es muy difícil salir de la zona de confort. En mi opinión personal, hacen falta dos cosas fundamentales: valentía y pasión por esta profesión. Valentía para apartarse de lo obvio, de lo que ya conocemos, para desviarse del camino sencillo y meterse por ese sendero oscuro y sombrío que nos lleva a lo inseperado; Y pasión. Pasión por aprender cosas nuevas, por descubrir nuevos modos de hacer las cosas, por reencontrarse con aquello que te hizo el profesional que eres hoy en día.

Si a esa valentía, y a esa pasión, le sumas esfuerzo, dedicación, y trabajo bien hecho, tanto da a lo que te dediques porque siempre obtendrás frutos. Y yo no me cansaré de decir que a los chicos de Linking Paths les sobran todas esas cualidades, y muchas más.

¿Cuántas personas conocéis, y no voy a decir en España si no que digo en el mundo, que hayan pasado, de ser referencia dentro del mundo de Java, a ser referencia de Ruby on Rails? Quizás vosotros conozcáis a alguien, pero yo sólo conozco a los chicos de Linking.



Me parece que aún fue ayer cuando estos chicos estaban organizando lo que en su momento fueron los eventos más importantes de Java en España, o ayudando a miles de personas a aprender, creando una comunidad que todavía persiste y que sigue siendo referencia. Y con ese recuerdo todavía fresco, la semana pasada me llevaba la alegría de ver que esta misma gente recogía el premio a Proyecto del año 2008 por Tog en la conferencia Rails.

No sé vosotros lo que pensáis, pero yo creo que este tipo de cosas no pasan por suerte. Alberto, Roberto y Aitor, para mi, este premio es mucho más que un préstamo, es un reconocimiento al trabajo. Un reconocimiento al trabajo bien hecho.

¡Enhorabuena!

FOWA 2009 @ Dublin

Vaya sorpresa me llevé ayer al leer este post de Fergus Burns en el que anunciaban que este 6 de Marzo se celebrará una edición de FOWA 2009 (Future of Web Applications) en Dublin.

Por lo que veo en la lista de Speakers viene gente como Mike Butcher de TechCrunch, Blaine Cook ex-Twitter, David Heinemeier de 37 Signals/RoR, Simon Willison co-creador de Django, Matthew Ogle de Last.fm, y los chicos de Contrast, una empresa local que tiene muy buena pinta. No está nada mal.

Todo esto por el módico precio de 115 euros. ¿Por qué diablos tienen que pasar estas cosas cuando uno está pensando en volver a casa?

SpringSource compra Groovy y Grails (i.e. G2One)

Ayer me quejaba de que en Grails se deberían centrar más en la integración con Spring y Grails. Pues justamente hoy apuntaban en la lista a esta noticia en TheRegister donde comentan que SpringSource ha comprado a G2One, la empresa detrás de Groovy y Grails.

Enhorabuena a los premiados! Y a ver si así el proyecto sigue tirando hacia adelante.

Las cinco cosas que menos me gustan de Grails

Hace unos días comentaba las cinco cosas que más me gustaban de Grails y avisaba de que habría un post de continuación con las cinco cosas que menos me gustaban. Pues aquí está ese post. Creo que coincidí bastante con otros en las cosas que me gustaban (salvo GORM) pero me imagino que no coincidiré tanto en las que no me gustan. Es más difícil coincidir en lo que no te gusta, en parte porque quizás esté equivocado en algunas cosas y existan soluciones. Lo mejor de esto último es que espero comentarios que me hagan ver la luz :) Pero bueno, al grano:

• La falta de herramientas serias para soportar el trabajo de creación de aplicaciones: Esto es de largo lo que menos me gusta, y sinceramente una de las razones por las que quizás no volviese a empezar un proyecto con Grails. Porque seamos sinceros, Grails apenas tiene soporte de herramientas serias para desarrollo.
  
  Es cierto que existe la posibilidad de instalar un plugin para Eclipse, y soporte nativo en IDEA y en NetBeans. Pero la cruda realidad es que hoy por hoy estas herramientas no son más que un conjunto de scripts para ejecutar los comandos de grails, más reglas de coloreado, síntaxis, autocompletado y todas estas cosas. Poco más.
  
  Quizás aquí la frustración venga a raiz de usar Eclipse. También lo intenté con IDEA pero la verdad es que es bastante frustrante ver como comienzas a utilizar una tecnología y ves que desde hace casi un año apenas ha habido progresos en cuanto a herramientas de soporte. Uno se esperaría algo más de atención hacia esos aspectos. Aquí no se trata ya de trivialidades como coloreado o autocompletado, sino de hacer fáciles las cosas que son realmente más complicadas como son la integración con Java, la integración con builds existentes, el facilitar la depuración de aplicaciones tanto local como remota, el facilitar integración con JUnit y/o Spring o la ejecución de tests unitarios y de integración en el IDE, el detectar errores difíciles (ver último punto) de encontrar o el ofrecer refactorizaciones. Y en todo esto, Grails (aunque me atrevería a añadir "y compañía") hace agua.



• La obsesión por "pluginizar" y "grailsificar" Java: Grails está lleno de plug-ins. A fecha de escribir este post hay más de 100 plug-ins diferentes. Los hay de todos los tipos y colores: testing, gráficas, scheduling, búsquedas, etc. Todos estos plug-ins básicamente le dan a librerías existentes en Java un aspecto mucho más 'grails-friendly'. A parte de estos plug-ins, si echamos un vistazo al roadmap de Grails podemos ver que prácticamente todo el esfuerzo planeado se centra en acercar tecnologías ya existentes en Java a Grails, como por ejemplo el soporte de JCR, de JPA, de Portlets, JSP tags, etc.
  
  En todo esto, según mi opinión, hay una contradicción bastante importante. Veamos, el principal punto a favor y argumento utilizado desde siempre a favor de Grails frente a otras alternativas es que nos permite utilizar Java, se integra bien con Spring y Hibernate, y podemos reusar lo que ya hemos creado estos años atrás. Pues bien, partiendo de estas premisas y teniendo en cuenta que la mayor parte de las tecnologías ya se integran con Spring. ¿Por qué no investir en mejorar la integración Java/Grails y Java/Spring en lugar de perder el tiempo reinventando la rueda en forma de plugin o sopporte nativo en Grails?
  
  Por poneros un ejemplo, ¿de qué me sirve un plug-in de Quartz que no funciona bien y que tiene muchos conflictos con el modo en que Grails gestiona las sesiones de Hibernate si símplemente ya lo tengo y lo puedo utilizar desde Spring? Me contesto: me sirve de nada, para perder tiempo en bugs y más bugs de 'grailsificación' de la librería. Lo mismo pasa con por ejemplo Searchable, que a algunos les funciona y a algunos no (como nos pasó a nosotros), pero que sería mucho más fácil simplemente aprovechar Spring y su integración con Compass.
  
  Y ese es el gran problema. La mayoría de plug-ins que hay en el repositorio o bien funcionan para unos casos concretos o triviales, o bien se han quedado obsoletos y nadie los mantiene, o bien tienen conflictos con proyectos híbridos (java+groovy). Los menos, es decir los tres o cuatro más usados (como JSecurity, Searchable, ...), sí que van evolucionando y mejorando, pero al mismo tiempo van apareciendo plugins como Background Thread que nacen para solucionar problemas de otros plugins. El plug-in del plug-in :) Sea como sea, todos estos plug-ins comparten una característica: ya estaban implementados en Spring y funcionaban perfectamente.
  
  Yo aprecio realmente el esfuerzo de toda esta gente. Pero en mi opinión es una estrategia insostenible, y sería muchísimo más razonable el mejorar la integración con Spring y Hibernate y el centrar sus esfuerzos en la parte del cliente. Yo mantendría los plugins, pero sólo los relacionados con la parte del interfaz+controladores (como GrailsUI que sí es realmente útil) y me centraría mucho más en dicha parte y en facilitar la creación de RIAs. Eso sí que realmente iba a mover Grails hacia adelante.



• Los servicios: Al hilo del punto anterior, no le acabo de coger demasiado el punto a los Services en Grails. Nuestra aplicación Grails empezó con pocos servicios, que fueron aumentando a unos 10 o 15, y ahora se han vuelto otra vez 3 o 4. ¿A dónde se han ido? Pues de vuelta a Java. Los hemos tenido que migrar debido a las razones expuestas en los puntos anteriores, y sinceramente ahora al menos yo me siento muchísimo más productivo ya que no hay más bugs debidos a la integración con Grails y podemos usar nuestros IDEs productivamente. Personalmente creo que a fecha de hoy en cuanto a Grails, y en el caso de los servicios, es mucho más simple hacer el backend en Java, ya que hoy por hoy todo está prácticamente hecho y el soporte de los IDEs es sobresaliente y hay montones de herramientas y frameworks que reutilizar. ¿Hacer el backend en grails utilizando plug-ins en estado más que dudoso? No, gracias.
  



• El sistema de build y su falta de integración con Maven: Grails se construye con scripts escritos con Gant, que es como Ant pero para Groovy. A fecha de hoy la integración con Maven es prácticamente inexistente (aunque sí que hay un plugin para ejecutar tareas de grails desde Maven), y eso convierte en algo bastante engorroso el modularizar tu proyecto aprovechando todas las ventajas que Maven ofrece para esto. Para mi (y esto es una opinión muy personal), utilizar Ant, y por consiguiente Gant, es un atraso importante.
  
  Aunque eso sí, parece que hay buenas noticias en este frente, ya que justamente la semana pasada publicaban en la lista de Grails algunos avances respecto a "Mavenizar" Grails, y la verdad es que tiene mucha mejor pinta que lo que tenemos ahora. Han creado un nuevo arquetipo para crear aplicaciones Grails, lo que supongo que significará que podemos importar dependencias desde nuestro proyecto Grails, o utilizar nuestro proyecto como dependencias lo que ayudaría muchísimo en cuanto a la modularización e integración con otros proyectos.



• Todas esas cosas que no están escritas y que al final te acabas encontrando: Esto más que un problema exclusivo de Grails, es más un problema de cualquier tecnología nueva. Grails, como framework novedoso, está lleno de cosillas y particularidades (y sólo hay que echarle un vistazo a la lista de correo para darse cuenta) que te pueden dejar atascado durante un buen rato. A esto también contribuye que el lenguaje sea dinámico y que ofrezca ciertos "adelantos" para incrementar la productividad lo que inevitablemente establece determinadas restricciones en como se hacen ciertas cosas.
  
  Por poner un ejemplo, uno de los problemas con los que me encontré un día es que tenía una excepción rarísima al desplegar la aplicación, y en realidad no había hecho apenas ningún cambio. Lo poco que había cambiado era realmente inocente. ¿O no es inocente el añadir un atributo llamado lastUpdated a tu clase Java e intentar persistir eso en Hibernate con su correspondiente columnilla en base de datos? Pues sí, seguramente es muy inocente, pero en Grails no se puede porque dateCreated y lastUpdated son dos propiedades que se utilizan para hacer automatic timestamping. Este es el típico ejemplo de problemilla que te puede dejar atascado unas cuantas horas, o días, intentando descubrir que diablos pasa. Pero, no todo es malo, por suerte la lista de correo es muy activa, y es fácil recibir respuestas bastante rápidas.
  
  Otro ejemplo más. Las aplicaciones de Grails se pueden desplegar en ficheros .WAR que más tarde se pueden soltar en cualquier servidor de aplicaciones, como por ejemplo Tomcat. Al mismo tiempo, las vistas en aplicaciones Grails se crean mediante ficheros .GSP que son como ficheros .JSP pero en Grails. Lo natural para un desarrollador Java sería pensar que una vez desplegada tu apliación en Tomcat podrás editar tranquilamente los ficheros .GSP en tiempo real y ver los cambios sin reiniciar el servidor. Pues.... NO. Sorpresa, sorpresa. Por defecto no funciona así, y a no ser que reinicies el servidor no verás tus cambios actualizados, algo que nuevamente te tendrá ocupado un buen rato imaginando que puede estar pasando.
  
  Por cierto, que existe la posibilidad de habilitar la recarga de clases en tiempo real, pero curiosamente no la recomiendan demasiado porque degrada el rendimiento. Parece que la gente comenta en la lista de correo que esta degradación de rendimiento no es realmente demasiado terrible, pero a mi todo esto me suena un poco a letra pequeña, especialmente cuando es algo que no se comenta en la documentación. Claro, porque a fin de cuentas, ¿a quién le va a interesar eso de que se puedan modificar las clases sin reiniciar el servidor? Si total, todo el mundo puede reiniciar el servidor...

Bueno y estas serían las cinco cosas que más me molestan. La verdad es que, aunque no todo es malo, lo cierto es que me parecen problemas importantes. ¿Me arrepiento de haber utilizado Grails? No, porque es un concepto diferente que está muy bien para aprender nuevas formas de hacer aplicaciones. ¿Lo utilizaría de nuevo? Depende de la aplicación. Sigo creyendo que es muy productivo para un determinado tipo de aplicaciones, para prototipado rápido, y realmente muy bueno si nos centramos en vista+controlador. Pero lo cierto es que después de haber trabajado bastante con el, se me antoja como un framework algo limitado para proyectos más importantes que necesiten de todo los puntos que he comentado arriba.

¿Opiniones?

Configurando Hudson para proyectos Grails

Como parte del desarrollo de Jobsket, una de las cosas que hemos hecho es el preparar un servidor de integración continua para intentar mantener nuestras builds lo más estable que sea posible.

Grails, no tiene ningún plug-in ni soporte específico para ningún sistema de integración continua así que decidimos descargarnos e instalar Hudson. La principal razón para instalar este sistema de integración continua es que es muy sencillo de instalar y administrar, ya que toda la configuración se realiza desde el UI de la propia aplicación, con sus bonitos componentes AJAX, sin necesidad de andar tocando ficheros de configuración.

Hudson está por defecto preparado para trabajar con Java, pero configurarlo con otros lenguajes o frameworks no debería dar ningún problema. Aquí no os voy a aburrir con los pasos para instalar y configurar Hudson, sino que comento simplemente los cambios necesarios para integrar un proyecto de Grails son tan sólo dos y son realmente muy simples:

Primeramente configuramos nuestra build para ejecutar un shell script. Este script contendría los pasos necesarios para la ejecutar nuestros tests o la build o lo que queráis. En nuestro caso el script es realmente sencillo ya que simplemente estamos interesados en ejecutar los tests, pero si tenéis otros requisitos podéis ejecutar directamente cualquier script de Ant o Gant, lanzar Maven, o lo que sea.



Lo segundo es simplemente hacer que Hudson lea nuestros informes de test. Por defecto Grails los coloca en el directorio test/reports, así que simplemente le decimos a Hudson que los busque ahí:



Una última cosa importante que no he comentado es que no os debéis olvidar de ajustar todos los settings necesarios para ejecutar grails, como por ejemplo:

export PATH=$PATH:/opt/grails-1.0.1/bin
export JAVA_HOME=/opt/java/jdk1.6.0_03
export GRAILS_HOME=/opt/grails-1.0.1

Hudson te permite configurar desde el UI la JAVA_HOME pero el resto lo tendréis (creo) que añadir vosotros en alguna otra parte. Yo por ejemplo tengo todo esto en el script que se arranca al loggearse el usuario, pero vosotros lo podéis poner donde queráis, como por ejemplo en el script que vimos antes que ejecuta los tests.

Pues eso es todo, no debería llevar más de 10 minutillos. Rápido y sencillo.

Scrum: Me encantan las Sprint demos

La verdad es que cuanto más trabajo con Scrum, más me gustan las Sprint demos. Como la mayoría sabéis, Scrum se basa en la ejecución de pequeñas iteraciones de varias semanas denominadas Sprints donde se va implementando funcionalidad que se ha decidido al comienzo de cada una de esas iteraciones. Durante los diferentes Sprints se pueden ir lanzando releases, y una vez finalizados todos los Sprints hemos terminado el desarrollo.

Una de las partes más críticas en Scrum es el fin de Sprint. Una vez terminado una iteración se suele hacer una demostración del producto. Estas demostraciones teóricamente deberían incluir a los clientes, pero todo depende realmente de cómo y para qué se está utilizando Scrum en la compañía.

Una de las cosas más curiosas de la demo de final de Sprint es que, al menos en nuestro caso, el desarrollo se para completamente. La gente pasa a centrarse durante una semana completa en sacar la demo adelante, y durante este tiempo pasan muchas cosas. Esto abre la cuestión sobre si es realmente valioso el parar a los desarrolladores durante cinco días completos poniendo esfuerzo en preparar algo que puede que en el futuro cambie, o algo para lo que hay que poner un montón de parches que después habrá que recodificar. Mi opinión es que es tremendamente valioso, básicamente por todo lo que pasa en ese proceso de preparación de la demo:

• Se realiza un esfuerzo por integrar toda la funcionalidad creada durante las últimas semanas en un formato compacto y demostrable al cliente final lo cual revela numerosos bugs y problemas imprevistos. Lo más importante aquí es que estos problemas se detectan por adelantado en las primeras fases de desarrollo, mientras que en una metodología de software tradicional estos errores se detectarían al final y serían mucho más complejos de resolver.
  
  Los desarrolladores somos muy vagos en cuanto a end-to-end testing se refiere. A menudo diferentes equipos trabajan en diferentes componentes y funcionan como islas independientes unas de la otras. Descuidar la interación entre componentes puede traer problemas a largo plazo, y las demos ayudan a forzar la integración frecuente de dichos componentes evitando posibles riesgos.
  


• Irremediablemente se crearán soluciones temporales, o hablando más claro: parches. Estos parches estarán ahí en la demo, pero su presencia obliga a preparar y planificar soluciones reales para el siguiente Sprint. El equipo se ve obligado a reservar el tiempo necesario para solucionar estos problemas, y eso ayuda a no encontrarse sorpresas no planificadas de última hora y el tener que hacer esos sobreesfuerzos de los que siempre nos estamos quejando.


• Las demos obligan al pragmatismo y a la creación de artefactos distribuibles. Otro aspecto que yo considero importante es que los desarrolladores no pueden ser "mega-creativos" y crear soluciones que les lleve meses ver la luz (caso aún posible, pero que de darse estaríamos ante proyectos en si mismos y requerirían Sprints propios). El desarrollador se debe centrar en implementar funcionalidad de manera pragmática y siempre pensando en tener algo que entregar, algo que distribuir, algo que se pueda demostrar.
  
  Esto abre otro debate sobre como integrar en un Sprint funcionalidades no tan fácilmente demostrables como puedan ser cambios internos en la arquitectura, refactorizaciones, etc. Pero eso ya es un tema diferente.
  
  
• Involucración por parte de los desarrolladores. Personalmente creo que la demo no debe ser realizada por única persona, sino que aquí el Scrum Master debe actuar como simple maestro de ceremonias. Obligar a los desarrolladores a participar en la demo les obliga a involucrarse más en la misma. El esfuerzo inevitablemente será mayor ya que no es lo mismo poner tú mismo la cara que el que la tenga que poner otro por ti.


• El efecto moral de ver que el proyecto avanza. En nuestro caso por ejemplo hacemos la demo para toda la compañía. Vosotros ya sabéis como es el desarrollo de software. A menudo la mayoría de equipos trabajan de manera independiente, y prácticamente sólo tienen contacto para conocer los problemas que unos tienen con el trabajo del otro. "¿Oye, qué tenía que pasar en este escenario?", "¡Este caso de uso está mal, estamos perdidos.", "¡Change Request", ...
  
  Me atrevería a decir que es común que la sensación cross-team de las personas ajenas al desarrollo de una aplicación al terminar cada iteración sea más pesimista que cuando el Sprint había comenzado, ya que el único input que han tenido estos equpos han sido problemas. El presentar una demo y mostrar que los objetivos marcados a principio de Sprint se han cumplido, y que no todo está tan mal como la gente se piensa, es una fenomenal forma de mostrar que el trabajo se ha realizado, que todo va bien, y de ayudar a recuperar esa moral que se pueda haber perdido durante el esfuerzo de desarrollo.



• Visibilidad para el cliente. Teóricamente las demos deberían incluir al cliente. En muchos casos esto no es posible físicamente, pero lo ideal es hacerlo. En nuestro caso por ejemplo, las demos internas se trasladan a otro equipo que se encargará de repetirla con el cliente final, ya en sus oficinas. Con la demo el cliente puede comprobar que se está progresando, lo cual en el mundo del software no es tan común, además de poder validar todos sus requisitos y sugerir cambios cuando sea necesario.

Y esto sería más o menos el resumen de lo que pasa durante esos días que se prepara la demo, al menos en nuestro caso. ¿Cómo son vuestras demos? ¿Las hacéis? ¿Se diferencian mucho sobre esto?

Dos blogs sobre escalabilidad en español

Desde hace semanas vengo siguiendo un par de blogs muy interesantes que se centran en el tema de la escalabilidad de una manera directa o indirecta.

Por una parte está Nubeblog, que viene posteando bastante frecuentemente sobre el tema de cloud computing y todo lo relacionado. Por otra parte tenemos el blog de Diego Mariño, CEO de abiquo, Externalidades que mezcla temas de emprendedores y Grid Computing, lo que lo hace doblemente interesante.

Este blog es muy modesto como para que vaya a crear un "efecto pensamientos ágiles", pero personalmente no conozco muchos más blogs en castellano dedicados a este tipo de temas, así que merece la pena mencionarlos. Yo estoy enganchado a sus posts así que si los desconocíais, quizás alguno los encuentre también interesantes.

Por cierto, ¿alguna otra recomendación en castellano sobre estos temas?

La importancia de decir NO a tiempo.

Ayer mantenía una conversación muy interesante con algunos amigos y uno de los temas que salió, como casi siempre, es el tema laboral en España. Las diferentes historias que se iban contando estaban siempre relacionadas con equipos de desarrollo con estrés, jefes incompetentes, jefes competentes que no tenían poder y que estresaban todavía más, etc.

Todas estas historias tenían algo en común. En ningún momento nadie decía NO.