{"id":2568,"date":"2024-09-19T17:42:37","date_gmt":"2024-09-19T22:42:37","guid":{"rendered":"https:\/\/zidrave.net\/?p=2568"},"modified":"2024-09-19T17:42:38","modified_gmt":"2024-09-19T22:42:38","slug":"vio-que-podia-ganar-dinero-arreglando-bugs-y-empezo-a-crearlos-a-proposito","status":"publish","type":"post","link":"https:\/\/zidrave.net\/index.php\/2024\/09\/19\/vio-que-podia-ganar-dinero-arreglando-bugs-y-empezo-a-crearlos-a-proposito\/","title":{"rendered":"Vio que pod\u00eda ganar dinero arreglando bugs\u2026 y empez\u00f3 a crearlos a prop\u00f3sito"},"content":{"rendered":"\n

En la gesti\u00f3n empresarial, especialmente en el \u00e1mbito del desarrollo de software, los incentivos juegan un papel crucial. En teor\u00eda, est\u00e1n dise\u00f1ados para motivar a los empleados a alcanzar sus metas con mayor eficiencia y productividad. Sin embargo, cuando los incentivos est\u00e1n mal formulados, pueden generar efectos contraproducentes y fomentar comportamientos que, lejos de beneficiar a la empresa, la perjudican. Un ejemplo paradigm\u00e1tico es el de un programador que, al ver que ganaba dinero solucionando errores (bugs), comenz\u00f3 a crearlos a prop\u00f3sito para luego corregirlos y, de esta manera, maximizar su ingreso.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Esta situaci\u00f3n refleja un problema com\u00fan en muchos entornos laborales: los malos incentivos<\/strong>. Como afirm\u00f3 el economista Gary Becker, quien gan\u00f3 el Premio Nobel en 1992, \u00ablas personas responden a incentivos\u00bb. Pero cuando estos est\u00e1n mal dise\u00f1ados, los empleados adaptan su comportamiento de formas inesperadas y, a menudo, da\u00f1inas para la organizaci\u00f3n.<\/p>\n\n\n\n

Veamos cinco ejemplos concretos de c\u00f3mo los incentivos mal planteados pueden derivar en malas pr\u00e1cticas entre los programadores y otros profesionales del desarrollo de software.<\/p>\n\n\n\n

\n\n\n\n

1. Incentivar la correcci\u00f3n de bugs a cambio de bonificaciones<\/strong><\/h3>\n\n\n\n

Imaginemos que una empresa decide pagar una bonificaci\u00f3n a los desarrolladores por cada bug que corrijan. Aunque la intenci\u00f3n es buena (mejorar la calidad del software), el incentivo mal dise\u00f1ado puede llevar a un comportamiento pernicioso. Al saber que cada bug solucionado aumenta sus ingresos, algunos desarrolladores pueden caer en la tentaci\u00f3n de crear bugs intencionalmente<\/strong> o dejar errores menores sin solucionar<\/strong> para corregirlos m\u00e1s tarde y as\u00ed ganar m\u00e1s dinero.<\/p>\n\n\n\n

Esto convierte un proceso que deber\u00eda estar orientado a mejorar la calidad del producto en una carrera por \u00abfabricar\u00bb errores que posteriormente ser\u00e1n resueltos por los mismos programadores que los crearon.<\/p>\n\n\n\n

\n\n\n\n

2. Pagar por l\u00edneas de c\u00f3digo escritas<\/strong><\/h3>\n\n\n\n

En algunos proyectos de software, especialmente en sus inicios, se ha premiado a los programadores en funci\u00f3n del n\u00famero de l\u00edneas de c\u00f3digo que escriben. La l\u00f3gica es que m\u00e1s c\u00f3digo significa m\u00e1s trabajo y, por lo tanto, m\u00e1s valor aportado. Sin embargo, este tipo de incentivo promueve la ineficiencia en la codificaci\u00f3n<\/strong>, ya que los desarrolladores se ven impulsados a escribir m\u00e1s l\u00edneas, incluso si se trata de c\u00f3digo innecesariamente largo o complicado, en lugar de optar por soluciones m\u00e1s eficientes y elegantes.<\/p>\n\n\n\n

En lugar de buscar la simplicidad y claridad en el c\u00f3digo, los programadores que trabajan bajo este esquema de incentivos pueden caer en la trampa de escribir c\u00f3digo innecesario, lo que a largo plazo complica el mantenimiento y disminuye la calidad del software.<\/p>\n\n\n\n

\n\n\n\n

3. Premiar a los programadores que cumplen estrictamente con las fechas de entrega<\/strong><\/h3>\n\n\n\n

Las fechas de entrega son importantes, pero si el incentivo se centra \u00fanicamente en la puntualidad<\/strong> y no en la calidad<\/strong> del trabajo, pueden surgir problemas. Algunos desarrolladores, ante la presi\u00f3n de cumplir con el plazo establecido, pueden priorizar la velocidad sobre la precisi\u00f3n, entregando c\u00f3digo incompleto o mal testeado solo para evitar penalizaciones o ganar bonificaciones por puntualidad.<\/p>\n\n\n\n

El resultado puede ser software plagado de errores que luego requerir\u00e1 costosos parches y retrabajo, lo que termina siendo mucho m\u00e1s perjudicial para la empresa que haber extendido el plazo de entrega en primer lugar.<\/p>\n\n\n\n

\n\n\n\n

4. Incentivos ligados a m\u00e9tricas de productividad superficiales<\/strong><\/h3>\n\n\n\n

Un error com\u00fan es basar los incentivos en m\u00e9tricas superficiales<\/strong> como la cantidad de commits realizados, la cantidad de tickets cerrados o el n\u00famero de pull requests enviados. Si bien estas m\u00e9tricas pueden ofrecer una idea del ritmo de trabajo, no necesariamente reflejan la calidad o el impacto del trabajo realizado. Incentivar a los programadores en funci\u00f3n de estas m\u00e9tricas puede llevar a un comportamiento como cerrar tickets de forma r\u00e1pida sin resolver completamente los problemas o enviar peque\u00f1as actualizaciones de c\u00f3digo divididas en varios commits innecesarios solo para inflar las m\u00e9tricas.<\/p>\n\n\n\n

Este enfoque no solo es ineficaz, sino que puede generar una falsa sensaci\u00f3n de productividad, donde la cantidad de trabajo no se traduce en valor real para el proyecto o la empresa.<\/p>\n\n\n\n

\n\n\n\n

5. Bonificaciones por proyectos completos sin importar la deuda t\u00e9cnica<\/strong><\/h3>\n\n\n\n

Cuando las empresas ofrecen grandes bonificaciones por completar proyectos r\u00e1pidamente, sin prestar atenci\u00f3n a la deuda t\u00e9cnica<\/strong> acumulada, los programadores pueden sentirse incentivados a sacrificar la calidad del c\u00f3digo<\/strong> por el cumplimiento de plazos. La deuda t\u00e9cnica se refiere a los atajos que se toman en el desarrollo de software para cumplir con un objetivo a corto plazo, pero que generan problemas a largo plazo, como c\u00f3digo dif\u00edcil de mantener, bajo rendimiento o fallos de seguridad.<\/p>\n\n\n\n

Este enfoque premia la velocidad sobre la calidad, lo que puede llevar a un software insostenible que, eventualmente, requerir\u00e1 mucho tiempo y esfuerzo adicional para ser mantenido y corregido.<\/p>\n\n\n\n

\n\n\n\n

El Desaf\u00edo de los Incentivos Correctos en el Desarrollo de Software<\/h3>\n\n\n\n

Dise\u00f1ar incentivos efectivos es un arte. Los incentivos deben alentar comportamientos deseables, como la mejora de la calidad, la eficiencia en el trabajo y la colaboraci\u00f3n entre equipos, sin caer en trampas que generen efectos adversos. El desarrollo de software es una actividad compleja que no puede ser reducida a m\u00e9tricas simplistas ni a soluciones r\u00e1pidas.<\/p>\n\n\n\n

C\u00f3mo Evitar Malos Incentivos<\/h3>\n\n\n\n
    \n
  • Focalizaci\u00f3n en la calidad<\/strong>: Incentivar la calidad del trabajo en lugar de la cantidad o la velocidad es crucial. Evaluaciones de c\u00f3digo, pruebas exhaustivas y revisiones por pares son m\u00e1s eficaces para garantizar la calidad que bonificaciones por correcciones r\u00e1pidas o por cantidad de l\u00edneas de c\u00f3digo.<\/li>\n\n\n\n
  • Reconocer el trabajo colaborativo<\/strong>: En lugar de premiar solo a los individuos, se debe fomentar el trabajo en equipo, especialmente en proyectos que requieren la colaboraci\u00f3n de varios desarrolladores.<\/li>\n\n\n\n
  • Evitar m\u00e9tricas superficiales<\/strong>: Es importante no basar los incentivos en n\u00fameros que no reflejan el impacto real del trabajo. Los incentivos deben estar alineados con los resultados tangibles y la satisfacci\u00f3n del cliente o usuario final.<\/li>\n<\/ul>\n\n\n\n
    \n\n\n\n

    Conclusi\u00f3n<\/h3>\n\n\n\n

    La historia del programador que empez\u00f3 a crear bugs a prop\u00f3sito para ganar m\u00e1s dinero es un ejemplo extremo, pero real, de c\u00f3mo los incentivos mal dise\u00f1ados pueden generar comportamientos indeseados en el desarrollo de software. Las empresas deben ser cautelosas al establecer sus pol\u00edticas de incentivos, asegur\u00e1ndose de que fomenten la excelencia en el trabajo y no la complacencia, la ineficiencia o incluso el enga\u00f1o. Dise\u00f1ar incentivos que realmente promuevan la productividad y la calidad es un reto, pero es clave para el \u00e9xito a largo plazo de cualquier organizaci\u00f3n de desarrollo de software.<\/p>\n","protected":false},"excerpt":{"rendered":"

    En la gesti\u00f3n empresarial, especialmente en el \u00e1mbito del desarrollo<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[4441,2379],"tags":[6305,6310,6312,6033,142,6308,6311,6314,6306,6307,6309,859,6315,6313],"class_list":["post-2568","post","type-post","status-publish","format-standard","hentry","category-programacion","category-software","tag-bugs-intencionales","tag-calidad-del-codigo","tag-colaboracion-en-equipos","tag-correccion-de-errores","tag-desarrollo-de-software","tag-deuda-tecnica","tag-efectividad-de-incentivos","tag-eficiencia-en-el-desarrollo","tag-incentivos-en-programacion","tag-malos-incentivos","tag-metricas-superficiales","tag-productividad","tag-revisiones-de-codigo","tag-software-sostenible"],"_links":{"self":[{"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/posts\/2568","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/comments?post=2568"}],"version-history":[{"count":1,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/posts\/2568\/revisions"}],"predecessor-version":[{"id":2570,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/posts\/2568\/revisions\/2570"}],"wp:attachment":[{"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/media?parent=2568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/categories?post=2568"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/tags?post=2568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}