{"id":94,"date":"2012-02-26T20:21:02","date_gmt":"2012-02-26T19:21:02","guid":{"rendered":"http:\/\/dev.qualilogy.com\/es\/?p=94"},"modified":"2013-01-04T20:23:09","modified_gmt":"2013-01-04T19:23:09","slug":"deuda-tecnica-dessarolladores-vs-marketing","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/deuda-tecnica-dessarolladores-vs-marketing\/","title":{"rendered":"Deuda t\u00e9cnica &#8211; Dessarolladores vs. marketing"},"content":{"rendered":"<p><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-full wp-image-1192\" title=\"Qual_TechDebt1\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/02\/Qual_TechDebt1.jpg\" alt=\"\" width=\"239\" height=\"360\" \/><\/a> Tengo que hacer una confesi\u00f3n: siempre desconfi\u00e9 de la noci\u00f3n de deuda t\u00e9cnica. Siempre me ha parecido un concepto de marketing.<\/p>\n<p>Es como si decides comprar un coche, el vendedor te da las llaves y a\u00f1ade con una sonrisa: \u00abUsted debe ya $ 10 000\u00bb. Y \u00e9l no habla del cr\u00e9dito para el auto, no, simplemente quiere decir que el coche que acabas de comprar tiene ciertos defectos que van a volverse cada vez m\u00e1s aparentes con el tiempo, cansar\u00e1n el motor, la carrocer\u00eda, incluso probablemente el conductor.<\/p>\n<p>\u00bfC\u00f3mo reaccionar\u00edas si un vendedor te dijera esto? \u00bfComprar\u00edas este coche?<\/p>\n<p><!--more-->De acuerdo, s\u00e9 que la compra de un coche, de una casa, de todos bienes costosos y complejos se acompa\u00f1a de gastos de mantenimiento. En este sentido, me gusta el poder explicativo de la analog\u00eda de la deuda t\u00e9cnica. Y por otra parte, el desarrollo software a menudo ha sido comparado \u00e1 la construcci\u00f3n de una vivienda.<\/p>\n<p>Pero todo el mundo conoce la historia: cuando Ward Cunningham invent\u00f3 este concepto en 1992, pas\u00f3 relativamente inadvertido, por lo menos fuera de la comunidad de los desarrolladores, hasta estos \u00faltimos a\u00f1os cuando, bing bang boom, la deuda t\u00e9cnica se transforma en una verdadera explosi\u00f3n de los medios de comunicaci\u00f3n y realmente, da miedo. Seg\u00fan Gartner, alcanzaba 500 mil millones de d\u00f3lares en 2010 y deber\u00eda doblar de aqu\u00ed a 2015. Con tal inflaci\u00f3n, ser\u00e1 superior a la deuda soberana de Rusia en 2020. \u00a1Qu\u00e9 angustia!<\/p>\n<p>La deuda t\u00e9cnica es un sue\u00f1o para los \u00abmercadost\u00e9cnicos\u00bb debido a que:<\/p>\n<ul>\n<li>Es t\u00e9cnico, pues es probable, y pone en experto al que habla de eso.<\/li>\n<li>Llama la atenci\u00f3n: debes dinero &#8211; mucho &#8211; y no lo sab\u00edas.<\/li>\n<li>Se presta a todo tipo de ejercicios muy creativos: techo de la deuda, c\u00e1lculo de los intereses, estimaci\u00f3n de punto muerto, reducci\u00f3n del riesgo sist\u00e9mico, etc. Muy inventiva: la noci\u00f3n de c\u00f3digo o de aplicaci\u00f3n t\u00f3xica. Me pregunto si proporcionan una m\u00e1scara antig\u00e1s a los desarrolladores.<\/li>\n<\/ul>\n<p>As\u00ed como lo explica Ward Cunningham (<a title=\"Ward Explains Debt Metapho\" href=\"http:\/\/c2.com\/cgi\/wiki?WardExplainsDebtMetaphor\" target=\"_blank\">Ward Explains Debt Metaphor<\/a>), el utiliz\u00f3 la met\u00e1fora de la deuda t\u00e9cnica para justificar a su jefe el refactoring realizado sobre el producto financiero que desarrollaban. Pidiendo prestado al principio permite ir m\u00e1s r\u00e1pidamente, pero debemos luego pagar los intereses. Como la expansi\u00f3n de un negocio: si puedes conseguir un prestado, puedes contratar a m\u00e1s gente, investir en m\u00e1s puntos de venta, disponer de un presupuesto publicitario, etc. Crecer\u00e1 m\u00e1s r\u00e1pidamente pero no puedes pedir prestado de forma continua porque los intereses y el reembolso de tu deuda se convertir\u00e1n en el principal puesto de gasto e impedir\u00e1n todo crecimiento.<\/p>\n<p>Ward tambi\u00e9n explica que sus palabras han sido repetidas de manera confusa, para no decir err\u00f3nea. \u00c9l insiste en que un c\u00f3digo debe ser escrito correctamente desde el principio para permitir la refactorizaci\u00f3n m\u00e1s tarde. Un prestamo no significa escribir c\u00f3digo de calidad pobre con el fin de sacar la aplicaci\u00f3n en el tiempo a pesar de los retrasos del proyecto o de los errores de planificaci\u00f3n, sino desarrollar r\u00e1pidamente versiones frecuentes (Extreme Programming) e introducir el refactoring del c\u00f3digo en el ciclo de vida del proyecto.<\/p>\n<p>Ward Cunnigham es un desarrollador que, como \u00e9l mismo lo explica, utiliz\u00f3 el concepto de deuda t\u00e9cnica como met\u00e1fora. Existen 2 tipos de met\u00e1foras:<\/p>\n<ul>\n<li>Las con un poder descriptivo, que permiten comprender un concepto por la ilustraci\u00f3n, la comparaci\u00f3n con otro concepto.<\/li>\n<li>Las con un poder de predicci\u00f3n, que permiten predecir un cierto comportamiento y descubrir nuevas leyes.<\/li>\n<\/ul>\n<p>Por ejemplo, te piden explicar lo que es un \u00e1tomo. Puedes hacer una analog\u00eda con una planeta que gira alrededor de su sol, tal como los electrones alrededor de su n\u00facleo. Ser\u00eda una analog\u00eda del primer tipo.<\/p>\n<p>Ahora, si decides construir una modelizaci\u00f3n de un sistema solar como un conjunto de objetos (planeta, sol), de atributos (masa) y de relaciones (atracci\u00f3n), y si lo utilizas para deducir una nueva modelizaci\u00f3n entre los electrones y su n\u00facleo que permita predecir su comportamiento, entonces se tratar\u00e1 de una analog\u00eda del segundo tipo.<\/p>\n<p>La met\u00e1fora de Ward Cunnigham es una herramienta explicativa muy poderosa, pero no se trata de una modelizaci\u00f3n de la que se podr\u00eda extraer nuevas leyes. Su inter\u00e9s principal reside en la idea de incorporar el refactoring de manera continua en el ciclo de vida de una aplicaci\u00f3n. Pretender que es posible cifrar la deuda t\u00e9cnica, de calcular su coste a la l\u00ednea de c\u00f3digo, de evaluar los intereses de esta deuda con el fin de considerar hasta qu\u00e9 punto de la curva se vuelve demasiado pesada, es Marketing.<\/p>\n<p>Por otra parte, esto no es inocente si las cifras son generalmente horrorosas y en crecimiento de un a\u00f1o al otro. \u00bfPor qu\u00e9 crees que tu aplicaci\u00f3n de 300 000 l\u00edneas de c\u00f3digo presenta una deuda t\u00e9cnica de 1 mill\u00f3n de d\u00f3lares incluso antes de que verla para conocer realmente su nivel de no-calidad? \u00bfCu\u00e1nto estar\u00edas dispuesto a gastar para reducir esta deuda? \u00bf$ 100 000? \u00bf$ 200 000?<\/p>\n<p>Los desarrolladores lo han bien comprendido. La deuda t\u00e9cnica representa :<\/p>\n<ul>\n<li>La idea que el c\u00f3digo debe regularmente refactorisarse con el fin de limitar la pobre calidad \u00e1 un nivel aceptable.<\/li>\n<li>Un indicador interesante que introduce una noci\u00f3n de esfuerzo y de coste de correcci\u00f3n.<\/li>\n<\/ul>\n<p>Si tienes la elecci\u00f3n entre corregir un defecto cr\u00edtico a un coste muy bajo y corregir un defecto que importa poco a un coste elevado, evidentemente no vas a dudar mucho. Como tal, la deuda t\u00e9cnica puede constituir una ayuda a la decisi\u00f3n, pero sin jam\u00e1s olvidar que no se trata de un verdadero coste financiero y sabiendo interpretarlo correctamente. Algunos ejemplos.<\/p>\n<p>Puedes utilizar la deuda t\u00e9cnica como un indicador (KPI) dentro de un SLA (Acuerdo de nivel de servicio) para un proveedor, pero de manera diferente seg\u00fan el tipo de desarrollo:<\/p>\n<ul>\n<li>Nuevo desarrollo: una deuda t\u00e9cnica cero no tendr\u00eda sentido. Toda nueva aplicaci\u00f3n, hasta muy bien escrita, implica necesariamente un m\u00ednimo de componentes o muy grande o complejo o con muchos enlaces entre ellos. Simplemente hay que procurar que sus n\u00fameros siguen siendo razonables. Pues definir\u00e1s con tu proveedor un nivel de deuda t\u00e9cnica que no debe sobrepasar.<\/li>\n<li>Mantenimiento: tu proveedor no es responsable de la deuda t\u00e9cnica existente en una aplicaci\u00f3n desarrollada por alguien que no sea \u00e9l. Simplemente debes evitar que esta no se vuelva m\u00e1s importante. Aqu\u00ed, no se trata de fijar un umbral de deuda t\u00e9cnica que no sobrepasar sino evitar que crezca la taza acutal. Hasta puedes incitar con bonificaci\u00f3n a tu proveedor a disminuirla.<\/li>\n<\/ul>\n<p>Alinear la deuda t\u00e9cnica en los objetivos TI, ellos mismos alineados con los objetivos de la empresa. Ya lo hemos visto en el post \u2018<a title=\"Best of both worlds\" href=\"http:\/\/qualilogy.com\/es\/best-of-both-worlds\" target=\"_blank\">Best of both worlds\u2019<\/a>, una pol\u00edtica de tolerancia cero para violaciones de rendimiento no tiene sentido cuando m\u00e1s importa no sobrepasar los presupuestos. Por el contrario, si el dinero no es un problema, pero la aplicaci\u00f3n debe funcionar correctamente a la fecha planificada, los defectos en materia de rendimiento y de robustez y el time-to-market se vuelven cr\u00edticos. Construye tus planes de acci\u00f3n con arreglo a los objetivos, y luego solamente con arreglo a la deuda cr\u00edtica, no lo inverso.<\/p>\n<p>D\u00e9jales bastante latitud a los equipos de proyecto para decidir por s\u00ed mismos acciones de refactoring, pero define con ellos un objetivo en materia de deuda t\u00e9cnica e incl\u00fayelo en un Quality Gate. En general, los desarrolladores ser\u00e1n eficaces en cuanto a que optimizar\u00e1n sus acciones de refactoring corrigiendo los defectos m\u00e1s graves pero menos costosos en esfuerzo. Esto supone sin embargo que sean equipados con una herramienta de an\u00e1lisis de c\u00f3digo para poder evaluar la deuda t\u00e9cnica. Sobre este punto, ver nuestro post &#8216;<a title=\"10 to 20 metrics\" href=\"http:\/\/qualilogy.com\/es\/10-a-20-metricas\" target=\"_blank\">10 to 20 metrics&#8217;<\/a>.<\/p>\n<p>Estos son s\u00f3lo algunos ejemplos simples, basados \u200b\u200ben nuestros posts anteriores. Hay muchos, y quiz\u00e1s tendremos la oportunidad  de detallarlos en el futuro.<\/p>\n<p>La deuda t\u00e9cnica es una medida interesante que permite objetivar la relaci\u00f3n con los proveedores y los equipos de proyecto. Es un indicador de un orden de magnitud en t\u00e9rminos de esfuerzo para mantener la no-calidad en un nivel razonable.<\/p>\n<p>En cambio, evita considerar la deuda t\u00e9cnica como un coste financiero real a tomar en cuenta en tus decisiones de proyecto y de inversi\u00f3n. Es un concepto de desarrollador para los desarrolladores, no para los de marketing.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Tengo que hacer una confesi\u00f3n: siempre desconfi\u00e9 de la noci\u00f3n de deuda t\u00e9cnica. Siempre me ha parecido un concepto de marketing. Es como si decides comprar un coche, el vendedor te da las llaves y a\u00f1ade con una sonrisa: \u00abUsted debe ya $ 10 000\u00bb. Y \u00e9l no habla del cr\u00e9dito para el auto, no, [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-94","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/94"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=94"}],"version-history":[{"count":2,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/94\/revisions"}],"predecessor-version":[{"id":96,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/94\/revisions\/96"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=94"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=94"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=94"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}