La eficiencia en ingenieria de software es principalmente sobre hábitos y buenas prácticas

* Por Juan Pablo Romano

La eficiencia en ingenieria de software es principalmente sobre hábitos y buenas prácticas

¿Qué es lo que hace eficiente a la ingeniería de software?, ¿cuales son los pasos o procesos que aseguran un proceso de creación de software eficiente?

Creo que el principal componente que complementa y es fundamental en ingenieria de software para que sea eficiente son los habitos.

Esto significa que no se trata de tener “el mejor” equipo sino el más consistente o constante, de forma tal que puedan trabajar sobre los problemas hasta resolverlos, para eso compuse la siguiente lista de elementos que son necesarios para asegurar la consistencia de un equipo de desarrollo.

• Apuntar a formar un equipo heterogeneo donde la experiencia de cada integrante se tome como un aporte y se escuchen todas las ideas.
• Planificar, testear y volver a planificar una solución inclusive antes de subir un pull request, conducir reviews y refinamientos del trabajo para dejarlo lo más limpio posible, ser escepticos y especialmente sobre los sesgos propios.
• Elegir siempre lo simple sobre lo facil, en general la forma más facil o “más linda” de construir una solución tecnológica no suele ser la más simple, agregando sobre ingenieria y complejidad que en un futuro va a persistir en la base de código. En resumen, ¡no hagan sobre ingeniería!
• Practicar el feedback continuo durante el ciclo de desarrollo, organizar el código siguiendo un patrón de diseño nos puede ayudar a identificar problemas antes de que lleguen a producción (créanme, es una experiencia horrible que lleguen a producción), entender los resultados del testing y aplicar decisiones correctas de diseño.
• Programar es como escribir, hay que ser concisos, claros y elocuentes, el buen código está bien documentado, esto incluye comentar, comentar, comentar, hay que apuntar a escribir código y comentarlo como si la persona que lo va a heredar es Dexter y está enojado con vos.
• Elegi bien tus abstracciones: “No hay nada que no pueda ser resuelto con otra capa de abstracción” pero las abstracciones tienen un costo propio, ¿cuanto estás dispuesto a acumular?, recorda que simple es mejor que fácil.
• Reforza los limites en las deadlines, es decir, no permitas deadlines que no son realistas.
• Motiva y reforza la comunicación efectiva, un equipo que puede adaptarse a nuevas ideas tiene más probabilidades de llegar a un buen resultado que uno que no, siempre es importante que las cosas funcionen y despues mejorarlas, tener un objetivo superador a esto sin tener tecnologia productiva y funcional no tiene sentido.
• Ser fluido con los lenguajes, frameworks o librerias, y esto creo que es uno de los habitos más importante para la visión a largo plazo de cualquier equipo de desarrollo.
• Pensalo dos veces y hacelo uno, considerar el diseño de la solución con el equipo y el código existente (y las experiencias asociadas de cada uno) antes de cambiar la solución o añadir nuevos features, para evitar deuda técnica.
• Empatiza con los clientes pero más con los miembros de tu equipo, porque los clientes cambian pero los equipos persisten, entender sus necesidades ayuda a trabajar mejor juntos.
• Pensa sobre el objetivo de tu proyecto y porque se esta haciendo, sino lo entendes, pregunta de nuevo.
• Si no estás seguro acerca de algo, busca una segunda opinión externa pero no te apures a actuar en consecuencia sobre eso.
• Enfocarse en la experiencia de usuario entendiendo las necesidades del usuario asegura un mejor porcentaje de exito en llegar a producción y entregar valor.
• Se pragmático e itera sobre los objetivos, mantener una visión acerca de lo que queres lograr con el proyecto es importante pero ser consciente de las dificultades en el mismo es fundamental.
• ¡No te quemés!, inclusive si crees que con más horas de trabajo el equipo puede resolver, no lo permitas ni lo motives, el precio de esto puede traducirse en deuda técnica o refactorización innecesaria previa a salir a producción.
• No intercambies roles en la gestión del equipo, ser empatico y poder colocarse en el lugar del otro no significa que sea una buena idea delegar el liderazgo en roles diferentes al tuyo con responsabilidad menor, por ejemplo, un Scrum Master no puede ni debe dirigir un equipo (ni son necesarios en lo absoluto), en general este tipo de iteración genera un mal ambiente en los equipos y termina por perder el proyecto.
• Convertí tus problemas en posibilidades, y los obstaculos en oportunidades.
• Rompé un problema grande en problemas más pequeños, esto se lo conoce como “desagregación” y su función principal es ayudarnos a enfocarnos en lo que realmente sirve.
• Tomá toda la responsabilidad que puedas manejar y nada más, un centimetro mal y termina mal para tu equipo.
• Encontrá el balance entre crecimiento y desafio para todos los miembros de tu equipo.
• Genera instancias de feedback con el cliente o el Product Owner del proyecto con el fin de iterar sobre la marcha previo a salir a producción, de esta forma nos enfocamos en eliminar la complejidad de los productos que siempre terminan por ser más simples de lo estimado.

Donald Knuth, el escritor de la serie “The Art of Computer Programming“, también conocida como “La biblia del programador” habla de que en programación la optimización prematura es la causa de todos los males, ¿qué significa esto?

“La optimización prematura es la causa de todos los males” es un principio fundamental en la programación que enfatiza la importancia de enfocarse en la eficacia y la funcionalidad antes de preocuparse por la eficiencia y la optimización en las etapas iniciales de desarrollo. Esto se traduce en varios puntos clave:

1. Hacer que funcione primero: El enfoque inicial debe ser lograr que el software funcione de manera correcta y cumpla con los requisitos establecidos. Esto significa que el código debe ser funcional y resolver el problema que se supone que debe resolver.
2. No obsesionarse con la eficiencia desde el principio: Gastar tiempo y esfuerzo en la optimización antes de tener un software funcional puede llevar a decisiones prematuras y complejidad innecesaria. Esto puede resultar en código difícil de mantener y entender.
3. Priorizar la claridad y la legibilidad: Es esencial que el código sea claro y legible para otros desarrolladores, ya que esto facilita su mantenimiento y colaboración en equipo. La optimización temprana a menudo conduce a código más complicado y menos comprensible.
4. Iterar y mejorar: Una vez que el software funciona correctamente, es el momento de optimizar y aplicar buenas prácticas. Esto puede incluir mejorar el rendimiento, reducir el consumo de recursos y hacer que el código sea más eficiente. Es un proceso iterativo en el que se equilibra la funcionalidad con la eficiencia.
5. Buscar un equilibrio: En lugar de buscar la perfección, que a menudo es inalcanzable, se debe buscar un nivel de calidad que sea adecuado para el proyecto y los objetivos. La perfección puede llevar a un desarrollo interminable y a la parálisis por análisis.

Por lo tanto, la frase de Knuth nos recuerda que, en el desarrollo de software, es fundamental comenzar por hacer que el software funcione correctamente y luego mejorar su eficiencia y calidad a medida que sea necesario. No debemos obsesionarnos con la optimización desde el principio, ya que esto puede llevar a problemas y complicaciones innecesarias. En cambio, debemos buscar un equilibrio entre la funcionalidad y la eficiencia, centrándonos en crear software que sea bueno y cumpla con sus objetivos.

Conclusión

Para que la ingeniería de software sea eficiente, es fundamental adoptar hábitos y enfoques que prioricen la funcionalidad y la claridad en las etapas iniciales del desarrollo, evitando la optimización prematura. Luego, a medida que el software evoluciona, se pueden realizar mejoras en la eficiencia y la optimización de manera iterativa. Este enfoque equilibrado permite crear software de alta calidad que cumple con los requisitos y es mantenible a largo plazo.

Es importante siempre tener en cuenta que la ingenieria de software eficiente o “la buena ingenieria de software” se enfoca en el largo plazo mientras libera iteraciones productivas a un ritmo acelerado también conocido como “rolling release” o en español “liberación continua”

Extra

Si te interesa leer más sobre Donald Knuth o aplicaciones de su frase podes leer los siguientes articulos:

• https://dtunkelang.medium.com/premature-optimization-is-still-the-root-of-all-evil-a3502c2ea262
• https://es.wikipedia.org/wiki/Donald_Knuth

* Bio del autor:

Juan Pablo Romano nació en 1994. Matemático, programador, nerd, fanático del mate y el fútbol. Trabaja en la actualidad como Gerente de Ingenieria en Adviters, una software factory nacional. Escribe en su blog y le gusta ayudar a las personas a iniciar su carrera profesional en tecnología o en lo que sea.

Más notas del autor:

• IA y Automatización en el contexto empresarial