{"id":171,"date":"2012-10-02T11:11:51","date_gmt":"2012-10-02T10:11:51","guid":{"rendered":"http:\/\/dev.qualilogy.com\/es\/?p=171"},"modified":"2013-01-05T11:12:27","modified_gmt":"2013-01-05T10:12:27","slug":"la-deuda-tecnica-y-los-consultores-de-calidad","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/la-deuda-tecnica-y-los-consultores-de-calidad\/","title":{"rendered":"La deuda t\u00e9cnica y los consultores de Calidad"},"content":{"rendered":"<p title=\"Technical Debt\"><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2357\" title=\"TechDebtConsult\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/10\/TechDebtConsult.jpg\" alt=\"\" width=\"313\" height=\"210\" \/><\/a>\u00bfSabes cual es mi broma favorita respecto a los consultores?<\/p>\n<p title=\"Technical Debt\">Un hombre entra en una tienda de animales y ve a un mono en una jaula con una etiqueta &#8216;Mono C &#8211; $ 2.000&#8217;. El due\u00f1o de la tienda se acerca y el cliente le pregunta: \u00ab Es caro su mono. \u00bfQu\u00e9 tiene de especial? \u00bb. Y el due\u00f1o le dice \u00ab Es un mono que sabe programar en C. Muy bueno, es r\u00e1pido, produce un c\u00f3digo de calidad sin errores. A ese precio, es un buen negocio \u00bb.<\/p>\n<p title=\"Technical Debt\">El cliente mira una otra jaula con una etiqueta \u2018Mono C++ &#8211; $3 000\u2019. \u00ab Oye, este es a\u00fan m\u00e1s caro. \u00bfQu\u00e9 sabe hacer? \u00bb. \u00ab Igual que el primero, pero con C++, un lenguaje Objeto, m\u00e1s complejo, pero tambi\u00e9n un programador muy bueno. Y conoce un poco Java \u00bb.<\/p>\n<p title=\"Technical Debt\">El cliente descubre una tercera jaula con una etiqueta \u2018Mono \u2013 $5 000\u2019. \u00ab Ah, este es tan caro como los otros dos. Debe ser muy bueno. \u00bfQu\u00e9 puede hacer? \u00bb.<\/p>\n<p title=\"Technical Debt\">\u00ab Pues, la verdad que no lo s\u00e9 \u00bb, responde el due\u00f1o. \u00ab Pero \u00e9l dice que es un consultor \u00bb. <em>(1)<\/em><\/p>\n<p title=\"Technical Debt\"><!--more--><\/p>\n<p>\u00bfPor qu\u00e9 estoy contando esta broma? Porque veo m\u00e1s y m\u00e1s consultores tratar de actualizar o completar o precisar el concepto de deuda t\u00e9cnica, pero finalmente lo convierten en una especie de teor\u00eda general, sin aplicaci\u00f3n pr\u00e1ctica, por no decir imposible.<\/p>\n<p>Hab\u00eda escrito hace unos meces un post \u2018<a title=\"Technical debt versus marketing guys\" href=\"http:\/\/qualilogy.com\/es\/deuda-tecnica-dessarolladores-vs-marketing\" target=\"_blank\">Tecnical debt vs. Marketing guys<\/a>\u2019 en el que denunci\u00f3 los hombres (o las mujeres) de marketing que, con gran inventiva, amplian el concepto de deuda t\u00e9cnica para todo tipo de variantes financieros m\u00e1s asombrosos uno que el otro. Por ejemplo, la analog\u00eda con los activos financieros t\u00f3xicos: algunas aplicaciones t\u00f3xicas esperan el peor momento para explotar completamente con la intenci\u00f3n de causar el mayor da\u00f1o posible.<\/p>\n<p>Y veo m\u00e1s y m\u00e1s consultores de calidad que hacen lo mismo, como en este v\u00eddeo &#8216;<a href=\"https:\/\/www.youtube.com\/watch?v=SDlaMgs-oi0&amp;feature=plcp\" target=\"_blank\">Technical Debt A Finer Edge<\/a>&#8216;. Los puntos principales son:<\/p>\n<ul>\n<li>La definici\u00f3n de la deuda t\u00e9cnica introducida por Ward Cunningham en 1992 es arcaica porque se centra demasiado en el c\u00f3digo y los programadores.<\/li>\n<li>Se debe actualizarla para tener en cuenta todos los defectos, deficiencias, errores y negligencias que se producen en el proceso de producci\u00f3n del software y en todas las fases del ciclo de vida del proyecto (dise\u00f1o, pruebas, etc.).<\/li>\n<li>Tambi\u00e9n hay que tener en cuenta los errores de gesti\u00f3n del proyecto y los procesos incorrectos o insuficientes: estimaci\u00f3n incorrecta de las cargas de trabajo, de planificaci\u00f3n, falta de gesti\u00f3n de riesgos, etc.).<\/li>\n<\/ul>\n<p>Este video retoma una articulo de Capers Jones \u2018<a title=\"Technical Debt\" href=\"http:\/\/www.ontechnicaldebt.com\/blog\/the-errors-and-hazards-of-technical-debt\/\" target=\"_blank\">The Errors and Hazards of Technical Debt<\/a>\u2019 en lo cual el define la deuda t\u00e9cnica como el coste de corregir los errores cometidos durante el desarrollo de una aplicaci\u00f3n.<\/p>\n<p>\u00ab The essential idea of technical debt is that mistakes and errors made during development that escape into the real world when the software is released will accumulate downstream costs to rectify. \u00bb<\/p>\n<p>Las desventajas seg\u00fan Capers est\u00e1n en la falta de consideraci\u00f3n de los defectos de calidad: \u00ab In order to evolve from a novelty into an effective metric, technical debt needs to encompass all quality costs and not just post-release code changes \u00bb.<\/p>\n<p>El art\u00edculo concluye que la deuda t\u00e9cnica es s\u00f3lo una parte del coste de la calidad, y que esta \u00faltima medida (Cost Of Quality o COQ) es m\u00e1s apropiado cuando se quiere estudiar la dimensi\u00f3n econ\u00f3mica de la calidad.<\/p>\n<h3><strong>Deuda intencional y deuda involuntaria<br \/>\n<\/strong><\/h3>\n<p>Estoy totalmente de acuerdo con Capers para decir que la deuda t\u00e9cnica es s\u00f3lo una parte del coste de la no-calidad, pero no estoy de acuerdo para ampliar este concepto y incluir a todos estos costes, como se requiere en el video anterior.<\/p>\n<p>El concepto de deuda t\u00e9cnica es entendida e interpretada de maneras muy diferentes y Ward lo explica en este articulo \u2018<a title=\"Dette technique Ward Cunningham\" href=\"http:\/\/c2.com\/cgi\/wiki?WardExplainsDebtMetaphor\" target=\"_blank\">Ward Explains Debt Metaphor<\/a>\u2019 que tiene por objeto aclarar la confusi\u00f3n habitual que la deuda t\u00e9cnica es causada por el c\u00f3digo de mala calidad.<\/p>\n<p>La analog\u00eda utilizada por Ward es que un prestado puede hacer que tu proyecto sea m\u00e1s r\u00e1pido, pero en alg\u00fan momento, tendras que pagar tu deuda. Hacer una primera versi\u00f3n prototipo es el equivalente de una inversi\u00f3n que puede ofrecer algo de forma r\u00e1pida a los usuarios pero se necesitar\u00e1 un esfuerzo adicional para ir desde este prototipo hasta la versi\u00f3n final, y una refactorizaci\u00f3n de unos componentes ya desarrollados para compensar tu inversi\u00f3n.<\/p>\n<p>El concepto original tiene como objetivo promover la metodolog\u00eda de desarrollo &#8216;Extreme Programming&#8217;, utilizando ciclos iterativos para completar nuestro conocimiento de las especificaciones funcionales, adaptar el dise\u00f1o de la aplicaci\u00f3n y adquirir experiencia (el equipo de Ward decidi\u00f3 programar en Smalltalk, un lenguaje Objeto nuevo para ellos).<\/p>\n<p>Como lo explica Uncle Bob en este blog, \u2018<a title=\"Technical debt mess\" href=\"http:\/\/blog.objectmentor.com\/articles\/2009\/09\/22\/a-mess-is-not-a-technical-debt\" target=\"_blank\">A mess is not a technical debt<\/a>\u2019, la deuda t\u00e9cnica es un compromiso voluntario \u2013 entregar rapidamente una versi\u00f3n 1.0 incompleta \u2013 para hacer frente a las limitaciones del proyecto (requisitos incompletos, calendario corto, etc.). Un c\u00f3digo de mala calidad no es una decisi\u00f3n racional, y por lo tanto no se incluye en la deuda t\u00e9cnica: es m\u00e1s bien una p\u00e9rdida.<\/p>\n<p>En todos los casos, son los desarrolladores que se encargan de la refactorizaci\u00f3n. Y por lo tanto, no hay forma de identificar los cambios realizados para mejorar la arquitectura del c\u00f3digo de los para corregir un defecto. Un programador decide dividir una clase en dos porque una funcionalidad adicional necesita especializar las clases o simplemente para reducir la complejidad y mejorar la legibilidad del c\u00f3digo. \u00bfDeuda t\u00e9cnica o no?<\/p>\n<p>Martin Fowler explica en este articulo &#8216;<a title=\"Technical Debt Quadrant\" href=\"http:\/\/martinfowler.com\/bliki\/TechnicalDebtQuadrant.html\" target=\"_blank\">TechnicalDebtQuadrant<\/a>&#8216; que poco importa. La met\u00e1fora es una poderosa herramienta de comunicaci\u00f3n que le permite justificar a los stakeholders y el management la necesidad de refactorizaci\u00f3n del c\u00f3digo y de pagar la deuda t\u00e9cnia sea cual sea su origen, intencional o no intencional. Un buen desarrollador conoce las buenas pr\u00e1cticas de programaci\u00f3n, pero puede omitir alguna o deliberadamente y de manera temporal en la espera de la pr\u00f3xima versi\u00f3n, o por falta de atenci\u00f3n. La perfecci\u00f3n no es de este mundo.<\/p>\n<h3><strong>Diferentes tipos de deuda<br \/>\n<\/strong><\/h3>\n<p>Cualquiera el origen de la deuda t\u00e9cnica, son los programadores que la gestionan. Y es por eso que creo que esta noci\u00f3n no se extiende a otros costes de no-calidad.<\/p>\n<p>Un error, un omisi\u00f3n en una especificaci\u00f3n funcional o en la fase de dise\u00f1o sin duda necesitar\u00e1 que modificar el c\u00f3digo, pero el origen de este cambio no es en la programaci\u00f3n y las decisiones o fallos con buenas practicas de los desarrolladores.<\/p>\n<p>Un plan de pruebas incompleto o insuficiente puede resultar de la decisi\u00f3n del management de entregar lo antes posible un prototipo que permite a los usuarios especificar sus necesidades sin tener que preocuparse de los errores, o puede resultar de la falta de tiempo, de conocimientos o de experiencia del equipo de QA, o de una documentaci\u00f3n incorrecta o de herramientas inadecuadas.<\/p>\n<p>La met\u00e1fora de la deuda puede aplicarse a estos ejemplos, pero en este caso, mejor hablar de deuda funcional o de QA, en lugar de tratar de integrar en la deuda t\u00e9cnica todos los costes de no-calidad.<\/p>\n<p>Otra raz\u00f3n por la que creo que la deuda t\u00e9cnica debe aplicarse a los programadores y el c\u00f3digo \u00fanicamente:<\/p>\n<ul>\n<li>Los bugs que encuentran su origen en el c\u00f3digo son los m\u00e1s numerosos: aproximadamente uno de cada tres.<\/li>\n<li>Estos defectos de c\u00f3digo son los m\u00e1s f\u00e1ciles de detectar y corregir: alrededor de 85% y esta cifra puede elevarse a 95% mediante una herramienta de an\u00e1lisis de c\u00f3digo.<\/li>\n<\/ul>\n<p>Los defectos en la especificaci\u00f3n y el dise\u00f1o son menos frecuentes (pero no mucho) y m\u00e1s dif\u00edcil de detectar y eliminar.<\/p>\n<p>La no-calidad de aplicaci\u00f3n tiene su origen en defectos muy diferentes con riesgos e impactos muy diferentes. Agrupar a todos en el mismo saco de la deuda t\u00e9cnica crea confusi\u00f3n y hace que este concepto sea poco pr\u00e1ctico.<\/p>\n<h3><strong>Deuda t\u00e9cnica y programadores<\/strong><\/h3>\n<p>\u00daltima raz\u00f3n: los defectos de c\u00f3digo son los \u00fanicos que se pueden identificar de manera automatizada, a trav\u00e9s de una herramienta de an\u00e1lisis de c\u00f3digo. Nunca se podr\u00e1 automatizar la detecci\u00f3n de una especificaci\u00f3n ausente, un error o falta de pruebas. Son necesariamente tareas manuales.<\/p>\n<p>Puedes analizar 5 000 clases Java y 100 000 l\u00edneas de c\u00f3digo en pocos minutos y f\u00e1cilmente identificar todas las violaci\u00f3nes. Puede incluso crear autom\u00e1ticamente los planes de refactorizaci\u00f3n que el desarrollador descubrir\u00e1 en su lista de tareas.<\/p>\n<p>Si queremos integrar otros defectos en la deuda t\u00e9cnica, entonces se llevar\u00e1 a cabo una evaluaci\u00f3n manual de riesgos o de pruebas funcionales para cada una de estas 5 000 clases. Imposible.<\/p>\n<p>Los programadores tambi\u00e9n han comprendido el uso del concepto de deuda t\u00e9cnica a nivel operativo, como se muestra en este art\u00edculo \u2018<a title=\"Effective code review with Sonar\" href=\"http:\/\/www.sonarsource.org\/effective-code-review-with-sonar\/\" target=\"_blank\">Effective Code Review with Sonar<\/a>\u2019en el blog de Sonar. Un proceso de Inspecci\u00f3n Continua permite medir el nivel de la deuda t\u00e9cnica y asegurarse de que no crece.<\/p>\n<p>Por lo tanto, estoy de acuerdo con Capers para decir que la deuda t\u00e9cnica no debe confundirse con el coste de la no-calidad (COQ) o este concepto se vuelve impracticable.<\/p>\n<p>Y mientras nosotros consultores discutimos la definici\u00f3n exacta del concepto, los desarrolladores utilizan diariamente la deuda t\u00e9cnica como m\u00e9trica que monitoriza el nivel de no-calidad del c\u00f3digo, independientemente de la definici\u00f3n exacta.<\/p>\n<p>Actualizar o ampliar el concepto de deuda t\u00e9cnica puede ser intelectualmente interesante, pero no sirve de nada sin una aplicaci\u00f3n pr\u00e1ctica y operativa. Como en la broma respecto a los consultores, no se sabe muy bien qu\u00e9 es o qu\u00e9 podemos hacer con el.<\/p>\n<p>&nbsp;<\/p>\n<p><em>(1) <\/em>Variante: \u00ab Pues, la verdad que no lo s\u00e9 \u00bb, responde el due\u00f1o. \u00ab Pero los otros dos lo llaman &#8216;Jefe&#8217; \u00bb. Mejor evitar esta variante con tu jefe o \u00e9l va a pensar que est\u00e1s sugiriendo que no se  sabe lo que hace.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u00bfSabes cual es mi broma favorita respecto a los consultores? Un hombre entra en una tienda de animales y ve a un mono en una jaula con una etiqueta &#8216;Mono C &#8211; $ 2.000&#8217;. El due\u00f1o de la tienda se acerca y el cliente le pregunta: \u00ab Es caro su mono. \u00bfQu\u00e9 tiene de especial? [&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-171","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/171"}],"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=171"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/171\/revisions"}],"predecessor-version":[{"id":172,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/171\/revisions\/172"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=171"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}