Hace pocos días leí un artículo que me pareció muy útil y cierto sobre algo que podemos reconocer fácilmente como "pecado cometido" en nuestros propios proyectos: lo difícil que resulta determinar cuándo llegamos a un punto en que estamos haciendo sobre-ingeniería o agregando features que no siempre son imprescindibles.
La visión que tiene el autor - Aneesh Karven - y los consejos que da para reconocer y afrontar este problema son muy directos y pueden ser de gran ayuda para empezar a observarnos internamente.
Les comparto aquí un resumen en español del artículo (original en inglés):
Un primer punto a destacar de la nota es que el autor entiende que el problema de muchos profesionales del software es que tienen un "exceso de confianza en la herramienta que usan y les es familiar" (por eso lo relaciona con la Ley del Martillo) lo que hace que piensen que aquello que puede ser la "solución al problema" en realidad resulta ser una exacerbación del problema. Esto hace que se generen features y fixes que dañan más que lo tienen que curar debido a las consecuencias inesperedas que suelen provocarse.
Otra de las cosas que me pareció interesante es lo que Karven sugiere como solución a estos casos de sobre-ingeniería en los que se suele caer. Como punto de partida nos dice que es fundamental un cambio de mentalidad.
Y a partir de este cambio sugiere implementar estos 2 consejos prácticos:
Esta otra frase dentro del artículo expresa muy bien lo que nos quiere decir "mirar en todos los rincones antes de empezar a intervenir.".
Personalmente encontré en este artículo muchos puntos clave con los que podemos identificarnos quienes trabajamos en este ámbito desde hace tiempo y creo que la mayor dificultad está en poder entender claramente que un cambio de rumbo en estas prácticas (a veces no vistas como un problema) pueden mejorar muchísimo el resultado de nuestro trabajo. Es muy común pensar que cuanto más agreguemos y tengamos contemplado dentro de nuestro código, mejor va a ser para el cliente. Pero me pareció muy clara la visión totalmente opuesta que Karven expone sobre esta creencia.
Como dice mi maestro de pintura: "una obra no se termina, simplemente se abandona", lo difícil es tener claro cuál el punto justo para hacerlo.
Este es el artículo original en inglés When the solution is the problem - How to prevent over-engineering & useless features
En el mismo sentido de este artículo, este otro artículo del autor puede ser de utiilidad How to cut features and enjoy it
Twittear Seguir a @3p_ar
La visión que tiene el autor - Aneesh Karven - y los consejos que da para reconocer y afrontar este problema son muy directos y pueden ser de gran ayuda para empezar a observarnos internamente.
Les comparto aquí un resumen en español del artículo (original en inglés):
Un primer punto a destacar de la nota es que el autor entiende que el problema de muchos profesionales del software es que tienen un "exceso de confianza en la herramienta que usan y les es familiar" (por eso lo relaciona con la Ley del Martillo) lo que hace que piensen que aquello que puede ser la "solución al problema" en realidad resulta ser una exacerbación del problema. Esto hace que se generen features y fixes que dañan más que lo tienen que curar debido a las consecuencias inesperedas que suelen provocarse.
Otra de las cosas que me pareció interesante es lo que Karven sugiere como solución a estos casos de sobre-ingeniería en los que se suele caer. Como punto de partida nos dice que es fundamental un cambio de mentalidad.
Y a partir de este cambio sugiere implementar estos 2 consejos prácticos:
Preguntarse 3 cosas
Cuestionarse varias cosas antes de escribir una sola línea de código. El autor recomienda tener en cuenta estas 3 preguntas de Baumer and Silverman (en su libro When the implication is not to Design)- Podría la tecnología ser reemplazada por un enfoque igualmente viable pero no tecnológico?
- Una intervención tecnológica puede resultar en más problemas o daños que los que podría provocar la situación actual ?
- Es la tecnología (en este caso) un sustituto "menor" de la solución real a aplicar?
Cambiar la cultura de la compañía
Según Karven los siguientes valores culturales pueden ser útiles para prevenir la expansión descontrolada de features:- Valorar el "no hacer algunas cosas" (o "no hacer cosas"): aquí sugiere instalar conversaciones dentro de la compañía sobre "MENOS ES MÁS". Considerar qué features se pueden eliminar para mejorar el producto Esta frase que Karven cita en su artículo me pareció muy apropiada: "La perfección es finalmente alcanzada no cuando ya no hay más para agregar sino cuando ya no hay más para sacar." (Antoine de Saint Exupéry)
- Documentar los caminos NO explorados: para superar la mencionada Ley del Martillo nos sugiere documentar lo que NO SE ESTÁ HACIENDO y por qué no lo hacemos, o sea, tener bien visibles las soluciones NO TOMADAS.
Continuar creciendo
A lo que se refiere en este caso es a lograr un cambio de perspectiva. Practicar esto es "practicar la humildad y precisión". El software, la gente que lo usa y las situaciones que crea pueden ser más complejas de lo que podemos imaginar. Debemos esperar sorpresas y resultados no lineales de cada intervención."Esta otra frase dentro del artículo expresa muy bien lo que nos quiere decir "mirar en todos los rincones antes de empezar a intervenir.".
Personalmente encontré en este artículo muchos puntos clave con los que podemos identificarnos quienes trabajamos en este ámbito desde hace tiempo y creo que la mayor dificultad está en poder entender claramente que un cambio de rumbo en estas prácticas (a veces no vistas como un problema) pueden mejorar muchísimo el resultado de nuestro trabajo. Es muy común pensar que cuanto más agreguemos y tengamos contemplado dentro de nuestro código, mejor va a ser para el cliente. Pero me pareció muy clara la visión totalmente opuesta que Karven expone sobre esta creencia.
Como dice mi maestro de pintura: "una obra no se termina, simplemente se abandona", lo difícil es tener claro cuál el punto justo para hacerlo.
Este es el artículo original en inglés When the solution is the problem - How to prevent over-engineering & useless features
En el mismo sentido de este artículo, este otro artículo del autor puede ser de utiilidad How to cut features and enjoy it
Twittear Seguir a @3p_ar
