El cuadrante de la deuda técnica

BombaLa Deuda Técnica es una excelente metáfora (creada por Ward Cunningham) que nos ayuda a pensar sobre algunos problemas del desarrollo de software. Según la metáfora, hacer las cosas rápido y mal nos incrementa las deuda técnica, la cual es similar a la deuda financiera. Al igual que la deuda financiera, la deuda técnica tiene pago de intereses, que vienen en la forma del esfuerzo extra que será necesario hacer en el futuro por una elección rápida y mala de diseño. Podemos decidir seguir pagando el interés, o podemos pagar el capital al hacer un refactor del diseño hacia un diseño mejor. Aunque hay un costo de pagar este capital, nos ahorramos el pago de intereses en el futuro.

Leer más...

Cuantificando los beneficios de TDD

MedirSegún un estudio reciente, el uso de Test Driven Development (TDD) incrementa el tiempo de codificación en un 15-30%, y resulta en un 40-90% menos de defectos. El estudio se hizo en 4 equipos de desarrollo diferentes (1 de IBM y 3 de Microsoft). Esto confirma lo que cualquier practicante de TDD te puede decir: se gasta un poquito más de tiempo en escribir las pruebas, pero la calidad del código resultante es muy superior.

Leer más...

Cómo determinar el costo y tiempo de un proyecto

Diagrama de GanttDeterminar el costo y tiempo de un proyecto de software es uno de los temas más importantes en el desarrollo de software. Mi opinión seguramente va a ser polémica, y acá está: es imposible determinar cuál será el costo y el tiempo de un proyecto de desarrollo de software. Más aún, es muy mala idea intentar usar la planificación como si fuera un contrato con nuestro cliente.

Leer más...

Cómo se genera el "mal código"

SelloEn general nadie crea código inmantenible de forma intencional (ignorando los casos de algunos consultores que escriben mal código para forzar a quedarse con el contrato). Sin embargo, el mal código va creciendo de forma lenta y segura a lo largo del ciclo de vida del producto.

Vamos a ver dos formas de pensar (de "jefe" y "desarrollador") que llevan a la aparición del mal código en nuestras aplicaciones.

Leer más...

Antipatrón ágil: el sobre-esfuerzo

Reloj¿Alguna vez se sintieron como malabaritas con el trabajo, haciendo las cosas apurados a contra reloj? Sí, yo también. Trabajar después de hora apesta. Siempre sentí que debido a la mala planificación yo tenía que lidiar con un día eterno, o noche, o fin de semana (y a veces los 3!). Para los equipos ágiles, trabajar después de hora es malo de tantas maneras distintas que se hace dificil enumerarlas.

Leer más...

Aceptar (y aprender de) los errores

pizarronComo programador, no te va a salir todo bien todo el tiempo, y no siempre vas a entregar a tiempo lo prometido. Quizás subestimaste. Quizás no entendiste los requerimientos. Quizás el framework que elegiste no era el indicado. Quizás supusiste cosas en vez de recolectar datos. Si probás cosas nuevas, hay probabilidad de que falles de vez en cuando. Sin probar, no aprendés. Y sin aprender, no podés ser efectivo.

Leer más...

Te tiene que importar el código

ProgramaNo hace falta ser Sherlock Holmes para descubrir que los buenos programadores escriben buen código. Y los malos programadores... no. Los malos programadores crean monstruos que el resto de nosotros tiene que limpiar. Querés escribir buen código, ¿no? Querés ser un buen programador.

Leer más...

La velocidad mata

CronometroSos un programador. Eso signifca que tenés una presión tremenda por trabajar rápido. Hay fechas que cumplir. Hay bugs que arreglar antes de la gran demo. Hay calendarios productivos a los que llegar. Y tu trabajo depende de cuán rápido vayas y qué tan confiable seas para cumplir las planificaciones. Y esto significa que tenés que tomar atajos, compromisos, ser rápido y desprolijo.

Que estupidez.

Leer más...

10 consejos para crear un buen espacio de trabajo

Pintura azulEs dificil construir un buen espacio de trabajo para un equipo de desarrollo. Hay que balancear muchos factores: humanos, sociales, ambientales, económicos y personales. No existe una solución universal, pero si podemos compartir algunas lecciones aprendidas durante los años.

Hay que tener en cuenta que las siguientes reglas sólo tienen sentido cuando sea de máxima prioridad crear un equipo productivo. Lamentablemente, en muchas organizaciones hay otros factores que terminan estando primero.

Leer más...

Por favor, ¡mantenelo simple!

MartilloMientras más simple, mejor. Esto es algo que a menudo olvidamos cuando desarrollamos software: nos vemos tentados por usar patrones de diseño, frameworks, tecnologías, herramientas... sin considerar otras opciones más simples aunque menos populares. Si hay dos formas de implementar algo y son funcionalmente equivalentes y no añaden ninguna repetición al sistema, hay que elegir la solución más simple.

Leer más...

Qué documentos escribir en un proyecto ágil

DocumentoUna y otra vez aparece el tema de la documentación, durante y después de los proyectos. ¿Qué documentación deberíamos crear? ¿Por qué necesitamos documentos de diseño? ¿Cómo podemos asegurarnos de estar construyendo el software indicado si no tenemos un Documento de Diseño Funcional? Y si el Documento de Diseño Funcional no está alineado con el software que se está construyendo, ¿cómo podemos comprobar que obtenemos lo que pagamos? Y más...

Leer más...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw