About goedecke
Posts by :
Deuda Técnica
La primera referencia al concepto “deuda técnica”, en el contexto del desarrollo software, viene del año 92 (aquí tienes el enlace a aquel primer documento en que se citó la idea). Otra evidencia más de que muchos temas y términos de moda hoy… llevaban ya muchos años con nosotros.
El creador del término fue Ward Cunningham, nombre poco popular en el sector, pero tras el que están, más allá del concepto deuda técnica, aportaciones como el desarrollo de la primera wiki, ser uno de los firmantes el manifiesto ágil, ser uno de los pioneros en introducir el concepto patrón, y los primeros catálogos, en el mundo del desarrollo software, las antiguas tarjetas CRC, contribuciones a eXtreme Programming, etc.
Cunningham introdujo el concepto de deuda técnica como eufemismo que refiere al coste e intereses que una organización tiene que pagar por hacer mal las cosas. El sobre esfuerzo a pagar para mantener un mal desarrollo software, malos diseños, malas prácticas de programación, altas complejidades ciclomáticas, etc..
Aunque el concepto, originariamente, se aplicaba a malas prácticas de programación, con el tiempo su uso se fue extendiendo a otras áreas, como la deuda técnica del Testing, la deuda de equipos, deuda de la arquitectura, etc.
Deuda técnica, esas cosas mal hechas que no se ven “desde fuera”…
Con el tiempo, muchos otros han ido perfeccionado y ampliado el concepto de deuda técnica. Por ejemplo, Fowler con sus cuatro cuadrantes de deuda técnica. O, en 2004, Joshua Kerievsky, que en Refactoring to Patterns introducía un concepto similar llamado “negligencia arquitectónica”. También Kruchten aportaba su definición, contextualizando, entre otros, en una matriz, que te dejo más abajo, a qué refiere deuda técnica.
La matriz muestra como a diferencia de los bugs o caídas de las aplicaciones, la deuda técnica refiere a esas cosas negativas que no se ven (desde fuera). Vamos, que cuando hablamos de deuda técnica hablamos de “caja blanca” frente a “caja negra”.
Otro autor destacado que se ha referido al término es Steve McConnell, con su taxonomía de deuda técnica, en la que hablaba de que cuando hay deuda técnica puede ser de dos tipos (I) Deuda incurrido involuntariamente debido a trabajos de baja calidad o (II) Deuda incurrida intencionalmente.
Los generadores de deuda técnica: desconocimiento e intentar recortar tiempos haciendo cosas mal (o saltándose tareas que había que haber hecho)
La deuda técnica se genera por:
- Definición previa insuficiente. Ocurre cuando los requerimientos continuan siendo definidos durante el desarrollo y el proceso de construcción da inicio antes de ser diseñado.
- Presión del área de negocio. Cuando el área de negocio considera que se debe liberar el desarrollo antes de que todos los cambios necesarios sean completados, generando así una deuda técnica.
- Falta de procesos o entendimiento. Cuando el área de negocio desconoce el concepto de deuda técnica y toman decisiones apresuradas sin considerar las implicaciones.
- Componentes fuertemente acoplados. Ocurre cuando las funcionalidades no son modulares y la solución no es lo suficiente flexible para adaptarse a las nuevas necesidades de negocio.
- Falta de una batería de pruebas, que propicia el uso de parches improvisados y riesgosos para corregir errores de código.
- Falta de documentación, cuando se escribe código sin la documentación adecuada de soporte. El esfuerzo que representa la generación de documentación representa una deuda que debe pagarse en algún momento.
- Falta de colaboración, cuando el conocimiento no es compartido dentro de la organización y la eficiencia del negocio se tambalea o los desarrolladores junior no están capacitados adecuadamente.
- Desarrollo en paralelo en dos o más ramas incrementa la deuda técnica ya que el trabajo requerido para fusionar los cambios en una sola línea base de código. Entre más cambios se realicen de manera aislada más incrementa la deuda.
- Posponer la refactorización. A medida que los requerimientos del proyecto evolucionan las partes de código que se han vuelto ineficientes y dificiles de editar deben ser mejorados (refactorizados) para poder soportar futuros requerimientos. Entre más tiempo se posponga la refactorización y más código sea agregado más grande será la deuda.
- Falta de alineación a los estándares, ocurre cuando los estándares de la industria, las tecnologías y los marcos de trabajo son ignorados.
- Falta de conocimiento, cuando los desarrolladores simplemente no saben cómo escribir código elegante.
- Falta de pertenencia, cuando los esfuerzo del desarrollo de software realizado por terceros necesita ser refactorizado o reescrito por los desarrolladores internos.
- Liderazgo técnico pobre, ocurre cuando se toman decisiones mal pensadas y éstas se transmiten a través de la cadena de mando.
- Cambio de especificación de último minuto, estos tienen el potencial de filtrarse a lo largo de un proyecto, pero no hay tiempo ni presupuesto para llevarlos a cabo con la documentación y los controles necesarios.
McConnell, coincidiendo con prácticamente todos los autores que ha hablado de ello, marcaba ahí las dos principales causas de que se genere la deuda técnica: desconocimiento de cómo se deben hacer las cosas y/o buscar atajos para entregar las cosas antes. El desconocimiento está claro, no saber programar con unos mínimos de calidad, no saber unos mínimos de diseño, etc. Los atajos, un clásico, frente a la presión de clientes, gerentes, usuarios, presupuestos bajos, etc., muchos gerentes fuerzan a los equipos a “saltarse” cualquier cosa que no sea tirar líneas de código.
Así, cosas como dedicar tiempo a pensar un buen diseño, las pruebas, dedicar tiempo a dejar lista la integración continua, etc., salen del proyecto, “consumen tiempo” y, a corto plazo (repito, corto plazo) a ojos de mucho, con visión cortoplacista… parecen frenar a la hora de lograr llegar a la fecha de entrega.
Deuda técnica a corto y largo plazo
El mayor peligro viene de esa deuda técnica que no se paga y va quedando ahí, de esa deuda técnica que lleva ahí años, esa por la que ya han pasado muchos veranos.
Decía Cunningham que “un poco” de deuda técnica, esa deuda técnica a corto plazo, acelera el desarrollo, siempre que se page con prontitud y no pase a ser deuda técnica a largo plazo. El mayor peligro viene de esa deuda técnica que no se paga y va quedando ahí, de esa deuda técnica que lleva ahí años, esa por la que ya han pasado muchos veranos.
Esa acumulación de deuda técnica de años es la que a día de hoy tiene frenada a un numero demasiado alto de organizaciones, que viven hoy bajo la presión de tener que ofrecer sus productos y servicios más rápido y el freno de una tecnología copada de deuda técnica de años. Y esto te lo digo por experiencia porque, porque este problema me lo encuentro día sí y día también, demasiados años haciendo las cosas mal para salir al paso y parece que ha llegado el bloqueo para muchos, que incluso intentan a la desesperada solucionarlo, intentando aplicar, por ejemplo, modelos ágiles, que se derrumban al enfrentarse a la deuda técnica.
¿Y cuanto es corto plazo en deuda técnica?
Henrik Kniberg, autor de “Scrum and XP from the trenches”, que en su experiencia las cosas mal hechas solo debería aguantar ahí unos cuantos días.
Otra popular regla es, si utilizas Scrum, “limpiar” en cada Sprint, lo que implica, ojo, dejar explícitamente tiempo para ello (hay incluso patrones de Scrum que hablan de ello, como el Teams that Finish Early Accelerate Faster).
Y, no en vano, no olvides nunca que el ciclo de vida ágil es incremental… pero también iterativo y el concepto iterativo está relacionado con ir “limpiando” en cada iteración. Mucho ojo con el riesgo de olvidarse del iterativo y quedarse solo con el incrementar.
Esa visión cortoplacista, que es como vender el alma al diablo
Hay muchas causas por las que se general deuda técnica, desconocimiento, no querer mirarlo, etc. Pero hay uno que para mi es mucho más preocupante: una visión de negocio (ya no hablo técnica) cortoplacista.
Salir al paso, entregar algo, acallar clientes, facturan antes, hacerlo lo más rápido posible aunque esté muy mal hecho, que viene a ser, tirando aún más de símiles, esta vez de terror (te dejo unas diapositivas en slideshare resumiendo el concepto deuda técnica con símiles de terror), como esas aquellas películas y novelas en las que el protagonista vende su alma al diablo para salir al paso de un problema, el diablo le salva…. pero tiempo después vendrá a por tu alma.
Y terminando con un símil económico más… estoy deseando que algún “famoso” del sector ponga de moda también la “prima de riesgo” técnica de las empresas.
Los KPI’s de la industría
Hay términos técnicos que se convierten en conceptos difusos con el paso del tiempo y, por su propio “éxito”, ven perderse la idea original que los sustentaba, de modo que acabamos usándolos como una “muletilla” que nos sirve a modo de refuerzo de cualquier opinión que tengamos.
Los consultores somos quizás los principales culpables de este fenómeno y, como miembro del ese gremio, voy a intentar aclarar uno de esos términos que en management usa todo el mundo y muy poca gente entiende. Me refiero a los famosísimos KPI o Key Performance Indicators, en la lengua de Cervantes: “Indicadores Clave del Desempeño” o del “rendimiento”, si preferimos una traducción alternativa.
Definición de KPI
Es una métrica enfocada a aquellos aspectos relativos al desempeño de la empresa que resultan clave para lograr el éxito de la misma, tanto hoy como en el futuro.
En otras palabras, los KPI nos indican qué debemos hacer para incrementar de un modo extremadamente significativo el desempeño de nuestra empresa.
No hay herramientas más potentes para un directivo que los KPI. Son la base del management actual, ya que nos indican si vamos por el camino correcto de la ejecución de la estrategia de nuestra empresa y, como veremos más adelante, no lo hacen desde el punto de vista de la contabilidad financiera.
Los KPI miden “inductores” del éxito, nunca “resultados”, y es que las métricas asociadas al desempeño nos indican qué hacer, mientras las de resultado nos dicen lo que hemos hecho (las primeras causan las segundas). Por ejemplo, una cosa es el número de reuniones con nuevos clientes que haya tenido esta semana nuestro departamento de ventas (inductor) y otra es el beneficio neto obtenido con las ventas de determinado producto (resultado).
Hay que tener muy claro que no todas las métricas de desempeño tienen por qué ser KPI, ya que pueden ser útiles pero no tienen por qué ser “clave” para el éxito de la empresa. Se puede decir que los KPI están directamente relacionados con los denominados Factores Clave de Éxito, que son aquellos que permiten sobrevivir y prosperar a la empresa y que, por lo general, son difíciles de replicar por la competencia, como por ejemplo, la capacidad para lanzar nuevos productos rápidamente.
De igual manera no todas las métricas de resultados serían clave para verificar dicho éxito, así que podríamos hablar de KRI o Indicadores Clave de Resultado,que es lo que buena parte de la gente identifica erróneamente como KPI.
En una empresa los KPI siempre han estado ahí, otra cosa muy distinta es si los hemos descubierto o, si conociéndolos, no los aprovechamos.
Mitos asociados a los KPI
Y ahora me toca destruir algunos mitos sobre los KPI. El primero de dichos mitos es que las empresas tienen que calcular un buen montón de KPI para tener controlada la ejecución de su estrategia.
La verdad es que una pyme no debería tener que controlar más allá de 10 KPI. Muchas pequeñas empresas de éxito (y otras no tanto) vigilan entre 5 y 7 KPI, no hay que olvidar que estamos hablando de indicadores “clave”.
El segundo, es que KPI son aquellos indicadores que el software de gestión (aquí hablamos de ERP, CRM o incluso de Google Analytics) identifica como tales en su configuración por defecto. Pues no puede haber error mayor. Una cosa son las métricas que los fabricantes de software nos propongan y otra muy pero que muy distinta los KPI de tu negocio.
No me cansaré de repetir que las métricas y los KPI en general siempre debemos establecerlos específicamente para el caso de nuestra empresa y, aunque lo hagamos así, hemos de ser conscientes de que este tipo de indicadores han de revisarse periódicamente, pues hay que evitar convertir determinadas métricas en “sagradas”, ya que si las circunstancias competitivas cambian, los KPI han de cambiar también.
El tercer mito es que los KPI más importantes son de tipo financiero o asociados a la contabilidad de costes, pues me temo que este es el mito más peligroso de todos. Los KPI son métricas de rendimiento casi siempre operativo, por lo tanto, no se miden en términos monetarios, no hay KPI denominados en euros como, por ejemplo, el resultado antes de impuestos de una empresa.
Las 7 características fundamentales que debe tener todo KPI
- Como he comentado antes, son métricas que nunca se refieren a dinero.
- Los medimos muy frecuentemente, no como los indicadores de resultado, que están asociados al ciclo de los cierres contables. Es normal medir los KPI diariamente o semanalmente.
- El director general y el equipo directivo de la empresa son quienes actúan en función de los KPI. Estos directivos toman decisiones y hacen preguntas a sus equipos a partir de los mismos.
- Los KPI determinan claramente qué es lo que deben hacer dichos equipos, y todo el personal involucrado debe entender claramente el indicador en cuestión.
- Los KPI exigen un claro compromiso y responsabilidad, tanto de directivos como de cargos intermedios o incluso de otros profesionales sin subordinado. Igualmente, se pueden usar como una poderosa herramienta asociada a la retribución variable.
- Tienen un impacto significativo en los denominados Factores Clave de Éxito de la empresa.
- Los KPI siempre promueven acciones que supongan un impacto positivo en el desempeño de la empresa. Hay que evitar situaciones en las que una métrica mal definida provoque comportamientos disfuncionales en la organización.
Un ejemplo de KPI
Uno de nuestros clientes, una empresa de transporte de viajeros por carretera, tiene como uno de sus KPI fundamentales la puntualidad de sus vehículos en las líneas interurbanas de las que es titular.
Este indicador se controla desde la Dirección General y desde la Dirección de Operaciones todos los días (cada cambio de turno en concreto) y se comunica a los inspectores de las líneas y a sus conductores.
Este indicador es un KPI que tiene un impacto en:
- La reducción de costes (menos combustible, vehículos de refuerzo, etc..).
- La satisfacción de los clientes, que tendrán en cuenta el autobús frente a medios de transporte alternativos y a la competencia.
- El ambiente laboral de los conductores, ya que no tendrán que soportar las quejas de los viajeros, alargar sus turnos y, además, cobrarán incentivos.
- La capacidad de planificación de las operaciones de la empresa,evitando inversiones innecesarias.
Niños de 12-13 años razonando (o no) un problema de matemáticas
En un rebaño hay 125 ovejas y 5 perros. ¿Cuál es la edad del pastor?
En este vídeo se presenta un problema de matemáticas a 32 estudiantes de octavo curso (el equivalente en España sería más o menos 2º de ESO, 12-13 años). El vídeo muestra cómo razonan y cómo calculan, incluyendo en ocasiones algunas preguntas que se les hace al respecto.
La mayor parte es un poco repetitivo, por eso va a cámara rápida con un incesante conteo de ¡bzzzzzzs! (fallos) y ¡dings! (aciertos) que por desgracia acaban en lo peor: tan solo la cuarta parte dan una respuesta correcta(8 de los 32) .
Robert Kaplinsky, que es quien ha realizado la prueba y el vídeo, concluye que hay tres factores clave para que los estudiantes puedan encontrarle el sentido a los problemas. Según él todo estudiante debería
- Entender el significado del problema.
- Planear la forma de solucionarlo en vez de pasar directamente a intentar resolverlo con operaciones.
- Preguntarse continuamente si las cosas tienen sentido.
Quien haya tenido que ayudar a algún estudiante a resolver problemas de este tipo no habrá podido evitar asombrarse cuando dan respuestas sin sentido alguno, incluyendo valores estrambóticos (camiones con longitudes de varios kilómetros de largo, piscinas que tardan años en llenarse en vez de horas o días o personas que viven más de 200 años). Esto se debe a que ignoran una variante del tercer factor: «preguntarse si la respuesta tiene sentido», algo que los adultos tendemos a evitar – quizá de de forma automática, quizá por costumbre. (Bueno: quiero creer que al menos la mayoría de los adultos.)
Los otros factores diría que tienen que ver con el lamentable nivel de comprensión lectora que precisamente es lo que da sentido a las palabras de un texto: hay que comprenderlo y sobre ello reflexionar, tras lo cual las palabras y datos se pueden hacer equivaler a números o incógnitas a las que aplicar diversas técnicas para dar con una solución.
Y para cerrar esto con algo un poco más complicado, ahí va un problema que ha circulado mucho en las últimas semanas por ahí y que tiene su intríngulis (pero no trampa, ni es un acertijo):
Si una gallina y media pone un huevo y medio en un día y medio, ¿cuántos huevos pondrán siete gallinas en seis días?
Los 10 algoritmos más frecuentes que surgen en entrevistas de trabajo de programación
Dijkstra, Burbuja, Knapsack… Todos son términos relacionados con algoritmos de programación de algún tipo, pero también son los que surgen más frecuentemente en entrevistas de trabajo como parte de los testsque hay que superar. Que no todo es explicar cuál es tu mayor defecto o qué tal ese nivel de inglés.
En GeeksforGeeks han recopilado una lista con los diez algoritmos más frecuentes en entrevistas de trabajo. De hecho más que diez son 80 porque han listado el «top 10» de ocho temas de programación principales. Pueden servir como repaso antes de ese «momento clave» que es la entrevista – o simplemente para aprender.
Los ocho temas principales incluyen grafos, listas enlazadas, búsqueda, teoría de números, cadenas, matrices y otros. Y para cada uno de ellos se muestran los diez algoritmos más frecuentes – junto con enlaces, explicaciones acerca de por qué y cómo funcionan y normalmente algo de código de ejemplo (normalmente en C, C++, Python, Java, JavaScript o varios de ellos).
En búsquedas por ejemplo lo más habitual por la que se pregunta es algo que se resuelve mediante búsqueda binaria. También puede surgir la necesidad de comprobar la primalidad de un número entero y el Método de Fermat suele ser el más conveniente. Otras preguntas suelen estar relacionadas con las representaciones binarias de un número.
Estos consejos no son una bala de plata que sirva para superar todos los tests aunque ayudar, ayudan. Lo importante, como suele decirse es entender bien las preguntas, preguntarse a cada paso si la solución tiene sentido y hacer otro tanto al terminar. Identificar cuál de los algoritmos es el apropiado para cada problema (o si hay que utilizar otro o ingeniárselas sobre la marcha) es la clave del asunto.
Método Heap Sort: Ordenamiento método Heap Sort.php
El siguiente post pertenece al topic: Métodos de Ordenamiento codificados en PHP.
El código realiza un Ordenamiento de datos numéricos haciendo uso del Método Heapsort:
<?php
function heapsort($A,$n)
{
for($k=$n-1;$k>=0;$k--)
{
for($i=1;$i<=$k;$i++)
{
$item=$A[$i];
$j=$i/2;
while($j>0 && $A[$j]<$item)
{
$A[$i]=$A[$j];
$i=$j;
$j=$j/2;
}
$A[$i]=$item;
}
$temp=$A[0];
$A[0]=$A[$k];
$A[$k]=$temp;
}
return $A;
}
function main()
{
$VectorA=array(5,4,3,2,1);
$VectorB=heapsort($VectorA,sizeof($VectorA));
for($i=0;$i<sizeof($VectorB);$i++)
echo $VectorB[$i]."\n";
}
main();
?>
Método de Selección: Ordenamiento método Selección.php
El siguiente post pertenece al topic: Métodos de Ordenamiento codificados en PHP.
El código realiza un Ordenamiento de datos numéricos haciendo uso del Método de Selección:
<?php
function selectionsort($A,$n)
{
for ($i=0; $i<$n-1; $i++)
{
$min=$i;
for($j=$i+1; $j<$n; $j++)
if($A[$min] > $A[$j])
$min=$j;
$aux=$A[$min];
$A[$min]=$A[$i];
$A[$i]=$aux ;
}
return $A;
}
function main()
{
$VectorA=array(5,4,3,2,1);
$VectorB=selectionsort($VectorA,sizeof($VectorA));
for($i=0;$i<sizeof($VectorB);$i++)
echo $VectorB[$i]."\n";
}
main();
?>
Método Inserción Binaria: Ordenamiento por inserción Binaria.php
El siguiente post pertenece al topic: Métodos de Ordenamiento codificados en PHP.
El código realiza un Ordenamiento de datos numéricos haciendo uso del Método de Inserción Binaria:
<?php
function insercionBinaria($A,$n)
{
for($i=1;$i<$n;$i++)
{
$aux = $A[$i];
$izq=0;
$der=$i-1;
while($izq<=$der)
{
$m=(($izq+$der)/2);
if ($aux<$A[$m])
$der=$m-1;
else
$izq=$m+1;
}
$j=$i-1;
while($j>=$izq)
{
$A[$j+1]=$A[$j];
$j=$j-1;
}
$A[$izq]=$aux;
}
return $A;
}
function main()
{
$VectorA=array(5,4,3,2,1);
$VectorB=insercionBinaria($VectorA,sizeof($VectorA));
for($i=0;$i<sizeof($VectorB);$i++)
echo $VectorB[$i]."\n";
}
main();
?>
Método Inserción Directa: Ordenamiento por inserción Directa.php
El siguiente post pertenece al topic: Métodos de Ordenamiento codificados en PHP.
El código realiza un Ordenamiento de datos numéricos haciendo uso del Método de Inserción Directa:
<?php
function insercionDirecta($A,$n)
{
for ($i = 1; $i < $n; $i++)
{
$v = $A[$i];
$j = $i - 1;
while ($j >= 0 && $A[$j] > $v)
{
$A[$j + 1] = $A[$j];
$j--;
}
$A[$j + 1] = $v;
}
return $A;
}
function main()
{
$VectorA=array(5,4,3,2,1);
$VectorB=insercionDirecta($VectorA,sizeof($VectorA));
for($i=0;$i<sizeof($VectorB);$i++)
echo $VectorB[$i]."\n";
}
main();
?>
Método quick sort: Ordenamiento por método Quick Sort.php
El siguiente post pertenece al topic: Métodos de Ordenamiento codificados en PHP.
El código realiza un Ordenamiento de datos numéricos haciendo uso del Método Quicksort:
<?php
function quicksort($A, $izq, $der )
{
$i = $izq;
$j = $der;
$x = $A[ ($izq + $der) /2 ];
do{
while( ($A[$i] < $x) && ($j <= $der) )
{
$i++;
}
while( ($x < $A[$j]) && ($j > $izq) )
{
$j--;
}
if( $i <= $j )
{
$aux = $A[$i]; $A[$i] = $A[$j]; $A[$j] = $aux;
$i++; $j--;
}
}while( $i <= $j );
if( $izq < $j )
quicksort( $A, $izq, $j );
if( $i < $der )
quicksort( $A, $i, $der );
return $A;
}
function main()
{
$VectorA=array(5,4,3,2,1);
$VectorB=quicksort($VectorA,0,sizeof($VectorA)-1);
for($i=0;$i<sizeof($VectorB);$i++)
echo $VectorB[$i]."\n";
}
main();
?>