No sé vosotros pero yo casi siempre me alegro de los errores que voy encontrando. Bueno, venga, estoy mintiendo. No es algo tan sencillo como, uy mira un error, que alegría. Al menos en mi interior sucede lo siguiente:
- Primero: Cabreo. Lo reconozco, yo soy testarudo, y no me gusta equivocarme. Tampoco me gusta que se equivoque la gente con la que trabajo. Soy bastante exigente en eso. Así que mi primera reacción es cabreo, conmigo o con los demás.
- Segundo: Alivio. Alivio por haber encontrado ese error. Si no encuentras errores, no es posible solucionarlos. Cuantos más errores encuentres, mejor será tu producto. Había alguien, no recuerdo el nombre que decía algo así como: "¿Quieres triunfar? Entonces, dobla tu tasa de fallos".
- Por último alegría. Alegría por haber encontrado el error y haber hecho una solución. Alegría por haber creado una prueba que reproduzca el error, y haber sido capaz de reproducirlo y solucinarlo. Alegría porque ese error no volverá a suceder.
Por cierto, recupero este post en pingdom con 10 bugs que tuvieron consecuencias graves. Seguramente los autores de los programas se habrían alegrado bastante de haber encontrado los errores a tiempo.
Todo esto me vino a la cabeza a raiz de un artículo que leí hace poco, donde comentaban lo siguiente:
At a major software corporation, the CEO regularly holds parties to give out a valued award, shaped as a full-size life preserver, to individuals who have created "learning opportunities" by introducing a problem into the design. Of course, the CEO acknowledges that the problem wasn't introduced intentionally. But, because it made it into the design, the organization learned important lessons they can use going forward. Receiving the life preserver award from the CEO has become a high honor within the company.
Hombre, tampoco se trata de hacer fiestas, claro. Eso solo pueden permitírselo las major corporations. Pero bueno, quizás si sería para celebrarlo si de pronto tu servicio se cae, y descubres que no es demasiado escalable, pero todo se debe a que la gente está accediendo y comprando como loca porque tu campaña de marketing ha sido muy exitosa como comenta el artículo. Descubres el error, pero por una buena razón.
Mi aproximación ante un error siempre es la misma. Analizar el error, tratar de crear un test ya sea unitario, de integración o funcional que lo reproduzca. Solucionar el error. Muy al estilo de TDD pero para bugs.
Pero bueno, cotilleando un poco, ¿Vosotros como reaccionáis a los errores?
comments
6 Respuestas a "Alegrarse al encontrar errores"11:31
Bueno, yo no me he hecho ese tipo de planteamientos ...
La mayoría de las veces es algún despiste, con lo que me apresuro a cambiar un par de líneas para responder enseguida "ya está" y (no se lo conteis a nadie) espero la palmadita en la espalda por haberlo arreglado enseguida (planteamiento ligéramente erróneo y paradógico, primero parece que el error 'debería no haber sucedido' pero al mismo tiempo también refleja que para mi su existencia es algo normal, pero bueno, mayormente, si se ha arreglado rápido es que era una tontería y no debería haberla cagado ni mucho menos esperar que vean como algo genial que lo arregle rápido, pero es mi forma de ser).
Luego, los que realmente me joden a rabiar (y me ha pasado recientemente), es cuando llevas una semana repitiendo "eso no se puede solucionar", escuchando todo tipo de propuestas dispares, rebatiendo (y educando) el porqué no se puede, ... y de pronto aparece una idea genial, funcional, sencilla, rápida, y te das cuenta que si hubieras mirado el problema desde otro punto de vista, en vez de estar en esa vorágine de ideas locas y obcecado en tu planteamiento, se te podía haber ocurrido a ti también.
Respecto al alivio y la alegría que comentas, a veces siento preocupación pq veo que un proyecto que parecía complejo ha salido a la luz sin demasiados problemas, y como -volviendo atrás- consideramos que la existencia de los fallos es algo natural, pues piensas que están ahí esperando el momento ... preocupante.
Desde luego, si falla un listado de viviendas y no se vende un piso de 300.000 euros por mi culpa, no me siento especialmente mal (soy un covarde, y desvio la culpa hacia cosas como que no pude estar suficientemente concentrado o que no se testeo bien, testear tb es parte del proceso de desarrollo y responsabilida de terceros), pero si encuentro un error en una TPV virtual y alguien podría haber comprado sin pagar o similar, entonces sí noto alivio, mucho, aunque no es nada comparado con lo que he sudado (metabólicamente hablando) mientras me apresuraba a solucionarlo. Quizás no veis la diferencia, pero no es lo mismo perder pasta que dejar de ganarla.
Participio poco, pero siempre te escribo un chorizo, perdona :D
12:32
En mi caso el nivel de cabreo depende de en qué fase se haya descubierto (desarrollo, validación o producción) y también del tipo de cliente.
Pej, cuando el cliente era Telefonica prefería que el defecto se descubriera en producción porque si lo descubría el de QA en validación nos llevabamos una penalización.
También, para mi, el nivel de cabreo es inv. proporcional a la complejidad del defecto. Los que más me cabrean son los más tontos y que demuestran una falta de compromiso en el desarrollador.
Sobretodo cuando previamente has preguntado: ¿Lo has probado?
Y responden: sí, claro.
Pero en realidad sólo han hecho la prueba más tonta y rápida que han podido, por lo que en cuanto haces cualquier prueba decente explota todo.
13:44
Resignación. Somos humanos y fallamos hasta en las tareas más tontas. Programar es casi siempre muy exigente en el plano intelectual que requiere mucha concentración. La verdad es que la probabilidad de que alguien pueda escribir un programa de alguna relevancia sin errores antes de unas cuantas sesiones de depurado es prácticamente cero, sin importar la metodología que sigas. David Parnas lo deja muy claro: "as a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications".
En mi caso, no es para ponerse a bailar tampoco, pero estoy 100% con la perspectiva de que los errores son muy útiles para aprender y descubrir. Lo malo es cuando no se descubren. Yo desarrollo software científico. En general dicho software en las universidaded es de muy baja calidad. En un mundo donde sólo se consideran valiosos los resultados y la gente trabaja a contrareloj presionada por la exigencia de publicar, los beneficios de una buena arquitectura y un buen estilo de desarrollo no son juzgados con inteligencia. Así la gente tiende a no enseñar su código (por vergüenza más que otra cosa) y esos resultados que aparecen en publicaciones científicas no pueden ser, como poco, reproducidos, y lo peor, no son fiables. Y claro como todos esos programas son "one-shot" y nadie los vuelve a usar, resultados erróneos, frutos de errores en el código, permanecen como válidos por mucho tiempo. Me sucedió una vez que encontré uno de esos errores tontos en mi software, por pura casualidad, cuando un artículo estaba a punto de ser publicado; como las conclusiones cambiaban radicalmente (es increible lo que puede hacer un solo typo en 10000 líneas de código) tuve que mover Roma con Santiago para parar la publicación y poder envíar una versión revisada (y mucho más interesante) de dicho artículo. Sucedió también que, por casualidad, dicho error me llevó a una línea de investigación muy interesante y nuevas publicaciones (espero).
16:29
Pienso como tú, si no se encuentran errores... malo, porque haberlos siempre los hay. Además me jode la gente que no entiende eso, que cuando para cumplir plazos metes horas, programas a toda caña y al acabar dices: "habrá que testearlo bien, porque tal y como lo hemos hecho tienen que salir errores seguro"... te oye el jefe y se indigna.
23:38
Muchas gracias por los comentarios ¡Qué interesantes!
@albin, si verdad, lo más difícil es siempre llegar a las soluciones simples!
@julio, eso que comentas da mucha rabia. Todo está siempre bien probado :)
@Santi, que interesante! Ya te veo ahí explicándole a los irlandeses que eso no puede ser y que hay que dar marcha atrás. Te mirarían raro, como que estos españoles ya están mareando...
@Abel, si yo te contara sobre horas y testers. 30 y pico testers y 16h extra cada semana... En fin, eso es otra historia.
14:27
Pues sí, es la alegría de "joder, la que se hubiera liado, menos mal que esa línea temporal no la vamos a vivir".
Esto me ha recordado una frase que alguien me dijo en mi primer trabajo y que me ha perseguido desde entonoces: "si compila a la primera es que tu función no hace lo que debe hacer". Bueno, los tiempos han cambiado y con los lenguajes nuevos / IDEs nuevos ya se ha perdido la gracia de lanzar el compilador con ese brillo en los ojos para ver qué pasa.
Pero es un principio básico que nunca hay que olvidar: somos humanos, por mucho protocolo de pruebas y defensas que nos inventemos, algunos errores siempre van a estar ahí.
Lo importante más bien es quién da con ellos, cuánto cuesta corregirlos, y si aprendemos de nuestros errores o siempre caemos en la misma piedra. O lo que es más probable, como la rotación es la que es (bueno, este año no), cuántas veces personas distintas que han pasado por tu equipo han cometido el mismo error una y otra vez.
No se me entieda por el lado equivocado, esto no justifica ser chapuceros o "¿ves? no sirve de nada hacer un plan de pruebas"... nuestro trabajo como profesionales es intentar que no ocurran, pero
Publicar un comentario