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...

5 consejos para construir software sin defectos

bugLamentablemente, en algunas organizaciones todavía se considera al testing como la última etapa del proceso de desarrollo. Los desarrolladores entonces cruzan los dedos para programar todo lo más perfecto posible, de manera que la etapa de testing sea una formalidad donde a lo sumo se encuentren errores menores. Por suerte ya hace un tiempo que nos estamos alejando de esta utopía ridícula y vamos avanzando hacia un concepto en donde el testing es una parte integrada al proceso de desarrollo.

El artículo How to write good tests nos deja 5 consejos para aprovechar al máximo este nuevo enfoque.

Leer más...

Seguinos en Facebook.

Publicá tus artículos.

Publicar Convertite en redactor para Dos Ideas y compartí tus conocimientos a una comunidad que sigue creciendo!
Quiero publicar

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