4. Steve McConnell
… en el area de negocios piensan que podemos cargar deuda
técnica porque nunca ven realmente las consecuencias. Pero
esas consecuencias existen …
solo que nunca expresadas un una manera que ellos puedan
comprender.
10. La deuda técnica se refiere a las consecuencias una
arquitectura o un sistema diseñado pobremente dentro del
código de un proyecto.
11. La deuda puede verse como trabajo que necesita realizarse
antes que el proyecto pueda considerarse como completo.
12. Si la deuda no se paga, continuara incrementando interés
haciendo difícil implementar cambios en el futuro.
13. • La deuda técnica se refiere a las consecuencias una arquitectura o un sistema
diseñado pobremente dentro del código de un proyecto.
• La deuda puede verse como trabajo que necesita realizarse antes que el proyecto
pueda considerarse como completo.
• Si la deuda no se paga, continuara incrementando interés haciendo difícil
implementar cambios en el futuro.
37. PROPÓSITOS DEL MVP
• Posibilidad de probar un producto con el
mínimo de recursos.
• Acelerar el aprendizaje sobre la utilidad del
producto.
• Reducir el desperdicio de horas de ingeniería.
• Liberar el producto a los usuarios lo mas pronto
posible.
46. VOLUNTARIOS
• Agile and Scrum.
• Extreme Programming.
• Kanban en el desarrollo de software.
• Ubiquitous Computing and Internet of Things.
• Computer Vision Applications.
• Design Patterns.
• A/B Testing
En esta presentación,
ustedes aprenderán una de las principales causas
de proyectos fuera de tiempo,
fuera de presupuesto.
Codigo que no puede ser mantenido,
ni escalado.
También conocerán
formas para combatir
este mal.
Se trata de la deuda técnica.
Les comparto esta frase
atribuida a benjamin franklin:
“Preferible ir a dormir sin haber cenado,
que levantarse al dia siguiente
con una deuda”
Definitivamente nadie queremos
vernos en la situación
de deber algo a alguien mas
especialmente si cobra intereses.
Como veremos,
la deuda tecnica
se genera de esa clase de prestamos
que generan un interes,
es decir,
mientras mas pides,
la cantidad a pagar
se incrementa exponecialmente.
Y si esperas demasiado
puedes termiar en la ruina.
Este es Steve McConnell,
el autor del libro Code Complete.
entre otras obras maestras,
en una entrevista para el sitio web "On Technical Debt"
Steven C. McConnell es el autor de muchos libros de ingeniería que incluyen Code Complete, Rapid Development y Software Estimation. En 1998, McConnell fue nombrado como una de las tres personas mas influyentes de la industria de software por la revista Software Development, junto con Bill Gates y Linus Torvalds.
En el desarrollo de software,
las consecuencias de sacrificar la calidad
son malentendidas por managers no-tecnicos.
Dado que los managers no técnicos
no poseen experiencia
de primera mano
creando software,
hacemos uso de las analogias…
Esta es una frase de Sigmund Freud:
“Uno es dueño de lo que calla
y esclavo de lo que habla”
El problema aqui es que
las palabras dueño y esclavo
son utilizadas en un contexto
totalmente nuevo,
y la interpretación depende de
quien escucha.
Por eso, pretendo dar un explicación
mas completa sobre lo que es la deuda técnica.
Deuda es lo que resulta
de adquirir algo ahora
por el compromiso de pagar
en el largo plazo.
Si no pagas a tiempo,
generas intereses
y aunque te rehuses a pagar
la deuda solo se incrementa
con el tiempo.
Y si ignoras la deuda
por demasiado tiempo …
Se convierte en impagable
y por lo tanto estarás en bancarrota
Todo empieza cuando el equipo
a escribir una aplicación
y no hay necesidad para roles de usuario.
Cualquier usuario puede hacer cualquier cosa.
En algún punto se plantean
dos permisos de usuario distintos,
un tipo de usuario
puede ver un reporte
y los demás no.
El equipo técnico
considera si crear
un sistema completo de permisos,
usando una serie de patrones de diseño para lograrlo.
Pero a este punto
esto se ve realmente como
un ovekill, sobre-ingenieria …
Un método en el controlador
y un par en la interfaz gráfica serán suficientes.
Algún tiempo después
hay un nuevo requerimiento
que necesita de la diferenciación de usuarios,
y luego otra y otra …
En este punto
los desarrolladores se dan cuenta
que el código está empezando
a volverse enredoso
y la solución es un “refactoring" del código
que es básicamente,
reestructurar el código fuente,
sin alterar el funcionamiento del software
para ahora si,
tener un sistema de permisos decente.
Hacer esta refactorización
tomara mucho mas tiempo
que solo agregar un nuevo método,
pero simplificara el código
y hará que agregar futuros permisos
sea tan simple como agregar
solo una línea de código
o solamente
agregando una fila en la base de datos.
El problema es
que existe una necesidad del negocio
que requiere del sistema actual de permisos
uno o dos días mas,
pues cinco clientes muy importantes
firmaran un contrato con la empresa
esta misma semana,
y no queremos hacerlos esperar
hasta la próxima semana,
ya que necesitan un nuevo permiso
pero quizás nunca firmen,
si no les gusta el hecho,
de que la compañía
no les cumplirá su única petición
para esta semana.
En este punto es
donde la decisión de tomar un "prestamo"
puede hacerse.
Toda la información relevante
para tal decisión es clara.
Al principio,
agregar un permiso tomo
3 story points.
Ahora toma 4.
Pronto tomara 5, 6 …
no se puede predecir.
La refactorización completa toma 21 ahora.
Así que la decisión, hoy,
no es entre 4 y 21.
Es entre tres posibles escenarios:
I.
4 story points ahora (el permiso),
22 story points después (la refactorización, que ahora será un poco mas complicada por el nuevo permiso)
y algo cerca de 0 story points
por cada nuevo permiso depuse de esto,
seguido de un incremento general
en la productividad del equipo;
En este escenario la compañía a añadido
5 clientes al portafolio y
el dinero del contrato llega pronto;
II.
21 story points ahora (la refactorización),
0 después (el nuevo permiso);
En este escenario la compañía
no pudo agregar
los 5 clientes al portafolio por ahora,
así que el dinero por los contratos vendrá después;
III.
4 story points ahora (el permiso),
sin refactorizar nada,
y luego 5 para el siguiente permiso,
y luego 6, 7…
hasta el punto
que una nueva refactorización sea propuesta,
pero ahora costanto mas de 50 story points;
En este último escenario
el dinero llega pronto,
pero la próxima vez que sea requerido
algo especifico para
agregar permisos
tomará mucho mas tiempo;
Dato el tiempo total,
siempre es mejor elegir
el mejor diseño posible.
Justo como el mejor escenario
para una compañía es ser capaz
de invertir en nuevas cosas
sin tener que ir al banco.
Pero como están las cosas en la historia,
el primer escenario
es la manera mas sabia de proceder.
Solo una advertencia: incluso este tipo de estrategia
no puede ser implementada constantemente.
En cada proyecto toca analizar para encontrar la mejor solución.
Algunos ejemplos encontrados en brasil
nos pueden ilustrar las consecuencias
de la construcción sin diseño alguno
ni cuidado por la calidad.
Esto es lo que se llama en portugués un “puxadinho"
y se trata de una construcción hecha sin
ninguna supervision, materiales precarios e ilegalmente.
O el siguiente ejemplo que viene de la misma area.
En el desarrollo de software esto es exactamente
lo que sucede cuando un manager la programación
no tiene un diseño mínimo definido.
Y no es solo una falla de diseño,
lo que hacemos es dañar código anterior,
on incluso destruirlo.
Esta tan enredado que puede hacer imposible
correr la app. Y esta construido de una manera
que hace virtualmente imposible una reconstrucción.
Aquí, si quisieras arreglar la disposición de los cables,
tendrías que tirar todo y empezar de nuevo con un plano.
Y ahora pasamos a un tema complicado
Porque evoca nuestros mas profundos temores.
El codigo heredado puede convertirse en
un grave problema pues, aunque en teoria
un código fuente debería estar bien comentado y documentado
la triste realidad es que casi nunca es así.
La industria aun tiene camino
por recorrer cuando se trata de código heredado.
Existen técnicas especificas que involucran
pruebas unitarias, patrones de diseño y refactorizacion.
Sin embargo es un trabajo delicado, donde el mas minimo error
puede dejar inhabilitadas partes de la aplicación sin explicación aparente.
Lo que nos lleva al siguiente tema:
Esta es una solución por default
para muchos desarrolladores
cuando se encuentran
con un proyecto mal diseñado.
Pero, desafortunadamente
cuando los managers preguntan
si toda la funcionalidad se mantendra,
es muy complicado y virtualmente imposible
asegurar tal cosa.
Otra cosa casi imposible es estimar
el tiempo que llevara esta reparación general.
Ademas, si se trata del mismo equipo
que creo el proyecto inicial y mal diseñado
nada asegura que esta vez
la reestructuracion sera exitosa o bien planeada.
Muchas veces vamos a escuchar
de los clientes o el area de negocios
que lo mas importante para un proyecto
es la rapidez de entrega.
Sin embargo, hay que tener en cuenta que
muchos proyectos y empresas quiebran
por falta de calidad en sus productos.
Todo se trata de llegar a un equilibrio
entre nuestras decisiones de diseño
y para eso existen ciertas estrategias como
el Minimum Viable Product y la mas reciente
el Minimum Lovable Product
Minimum Viable Product
tiene solo las características fundamentales
para que un producto pueda ser creado, no mas.
El producto puede ser orientado
a los primeros usuarios en adoptarlo,
quienes regularmente son mas comprehensivos
y dispuestos a devolver retroalimentación.
Iteracion tras iteración logran
que el producto se acerque
a lo que el usuario final necesita.
The Intel Web Tablet connected wirelessly to a PC to allow a user to browse the Web.
It had a touchscreen display, was powered by an ARM processor, featured a built-in MP3 player and it let you surf the Internet on your couch. Sound familiar? Think again. This was the Intel PAD or, as it was known internally at the time, the IPAD. It was officially branded the Intel Web Tablet, but it never made it to market.
1959: The Henney Kilowatt turns heads but not enough for people to buy it.
The Eureeka Company manufactured 100 Kilowatts between 1959-1960, but was only able to sell 47 of them.
Despite the lag in sales, the Kilowatt was a promising electric automobile for its time. It traveled 40 miles on a charge and hit a top speed of 40 miles per hour. The improved 1960 model pushed this to 60 miles per charge and a zippy 60 mile-per-hour top speed.
Archie (1990):
Archie.
The first search engine created was Archie, created in 1990 by Alan Emtage, a student at McGill University in Montreal. The original intent of the name was "archives," but it was shortened to Archie.
Luego vienen los promotores
del Minimum Lovable Product.
Ellos dicen que las ventajas del MVP no son tales
en un mundo tan competitivo como en el que vivimos.
La idea es que los usuarios finales ya no se conforman
con productos que ofrecen solo lo mínimo posible.
Y que el camino esta
en lograr la aceptación
desde la primer iteración
Tratando de dejar una impresión favorable
con ese mínimo de características.
Cuando la meta a largo plazo
involucra calidad en el producto
la rapidez puede dejarnos en desventaja.
Y finalmente,
si deseamos mantener y atraer
a los mejores desarrolladores
debemos tomar mas en cuenta
la calidad en el código y el producto.
A group of computer programmers from the Poznan University of Technology (PUT) have triumphed in Hello World Open, the world coding championship. They defeated 2,500 teams from across the globe.