Una de las promesas del software es entregarlo en el período de tiempo más corto posible. Hay un dicho en la industria: cuando surge un requerimiento nuevo, la entrega es “para ayer”. Habitualmente, eso incrementa el nivel de estrés; en esa circunstancia, la Ingeniería es inmediatamente arrojada por la ventana y el equipo se concentra en crear el código, producir los ejecutables y distribuirlos.

Sutil, pero continuamente, se ha desestimado la Ingeniería de Software. Frecuentemente, gerentes, líderes y otros desarrolladores dicen frases como:

• No haremos la documentación, solo nos quita tiempo.
• Ya haremos esa especificación para cuando haya tiempo.
• Urge entregar, lo único importante es hacer el código para empezar a probar cuanto antes.

Es decir, la Ingeniería se percibe como hacer un montón de páginas, que quitan tiempo y no son importantes“porque nadie las va a leer”. El resultado lo conocemos: deadlines perdidos, incontables bugs y defectos y ver muy pocas funciones nuevas a lo largo del año.

Subscribe now

La Ingeniería de Software es mucho más que “un montón de páginas y diagramas”. Es el camino que conduce a producir un resultado que deleita a los usuarios lo más rápido. Como decía Watts Humphrey: la forma más rápida de hacer el software, es hacerlo bien a la primera. Eso solo se logra con la Discilina de la Ingeniería.

Equivocarse no es opción

Hay una filosofía muy difundida en la actualidad: fallar rápido (fail fast) y frecuentemente (fail often). Es muy mal entendida en el gremio del software, pues a lo que esta filosofía se refiere a que encuentres y descartes rápidamente todo lo que no funciona para resolver el problema (todo lo que falla) y recolectes lo que sí ha funcionado para continuar.

En el software, esto se emplean como justificante para la mala calidad con tal de entregar rápido y repararlo después. Esto es peligroso, porque afectamos a personas, a veces catastróficamente. Por eso, equivocarse no es opción, y esto lo logramos principalmente con la Ingeniería.

Presta atención a lo que es importante y siempre debes mantener.

Matemáticas como fundamento

En muchas fuentes veo, con frecuencia, la siguiente queja respecto a ramas de la disciplina, como el cálculo y el álgebra: ¿para qué me sirve esto en la vida? ¿Cuándo voy a usarlo en mi trabajo? ¡Nunca he requerido de resolver una integral para hacer un programa! Tristemente, en varias instituciones han atendido las quejas y han removido muchas asignarturas de matemáticas de los programas de Computación en Informática. Si “no sirve” entonces no lo aprendemos.

Debo contarte que yo tuve muchas dificultades con las matemáticas durante mis años universitarios. Estuve cerca de reprobar las dos materias de cálculo y una que usaba métodos estocásticos. Es verdad: no resuelvo ecuaciones todos los días en mi trabajo, pero sí uso diariamente todas las herramientas que me enseñaron las matemáticas:

• Abstracción
• Lógica
• Análisis de alternativas
• Sustituciones
• Pruebas de escritorio
• Algorítmica

Todo eso es Programación y necesitas saber hacerlo bien. Las matemáticas logran crear en ti esa capacidad para llevar el mundo real al mundo abstracto, que es la computadora.

Modelos como herramienta de evaluación

Hay una serie en Marvel (tanto en comic como en TV) titulada “What if?”, en la que plantean escenarios hipotéticos con los personajes que ya se conocen: qué tal si Spider-Man tuviera los poderes de Captain Marvel o qué tal si Bruce Banner y Hulk fueran dos seres separados.

Esa es la base: “qué tal si”, y desarrollar las posibilidades desde ahí.

A eso se refiere la creación de Modelos, algo que te permite entender un problema, explorar posibilidades y responder a las preguntas “y qué tal si”.

Conversaciones como “y qué tal si usamos React en lugar de Angular” deben estar basadas en Modelos del problema o de la solución.

Aquí, entran nuevamente las Matemáticas y disciplinas hermanas, como la estadística y la probabilidad, y herramientas como UML.

Documentar como práctica de buena comunicación

Suele decirse que el software no necesita más documentación que el código (limpio y bien organizado). Pero si existen quejas para leer documentos, imagínate tener que leer decenas de miles (o millones) de líneas de código.

Documentar significa dejar plasmadas las decisiones importantes que se han tomado y el razonamiento detrás de ellas, no crear una página en el procesador de textos. Así como hay varios niveles de decisiones, también los hay en la documentación. No se tiene que documentar todo, solamente lo que es necesario para el equipo en cada nivel y usando la herramienta que lo comunique mejor.

Por ejemplo:

• Las herramientas que se usan, la versión y la razón por la que se emplean.
• Los objetivos del producto y los stakeholders.
• La lista de componentes y cómo se conectan entre ellos, con un diagrama.
• Ciertos patrones de implementación, que quedan bien con diagramas de secuencia.
• Problemas comunes y su solución.

Es difícil que todo eso sea fácil de encontrar en el código, ¿verdad?

 

 

Testing desde el día 1

Saber hacer pruebas es tan importante como saber programar. Recuerdo cuando inicié mi trabajo de programador, que me enojaba mucho porque los testers encontraban muchos defectos en mi código y estaba en conflicto constante con ellos.

Todo era porque yo no sabía hacer software que resistiera las pruebas o que fuese fácil de probar. No dedicaba tiempo a analizar y entender cosas que podrían fallar o las situaciones extremas a las que se vería sometido y lo romperían. Era como si quisiera construir un puente sin entender todo lo que podría pasarle y esperar, con fe, que no se cayera.

Nuevamente, modelos y matemáticas son necesarios aquí, pero es más importante la colaboración entre personas para este aspecto: hacer el trabajo de requerimientos, diseño e implementación pensando en las pruebas a las que se debe someter el software y no dejarlas para el final.

¡Hazlo todo en un día!

La razón principal, por la que muchos Ingenieros no quieren hacer Ingeniería, es que parece que esto los retrasa, pues toma demasiado tiempo. La verdad es que no. Eliyauh Goldratt, en su libro “La Meta”, propuso que el trabajo se debe dividir en la unidad más pequeña posible; esto mantendrá un flujo constante, disminuirá los cuellos de botella y el tiempo muerto en ciertas áreas.

En Software, es posible que todas las actividades se hagan en un día y por una persona, sin omitir ninguna y con disciplina. También, que el equipo pueda determinar cuándo es necesario hacer más de un trabajo y cuándo menos, según la necesidad. Cuándo es necesario un proceso intensivo y cuándo una libertad de hacerlo con menos pasos.

Mi recomendación es esta:

• Domina la Ingeniería de requerimentos, pues todo parte de ahí.
• Haz modelos de la solución para ti, a mano en papel o en pizarras.
• Documenta solo lo que es necesario para todos y lo demás deséchalo.
• Divide el trabajo al tamaño de un módulo, programa o función.
• Crea modelos con el equipo para cosas como la Arquitectura, la forma de trabajo o el análisis del negocio.
• Usa estándares (como los Ingenieros lo hacen)

La Ingeniería no es una carga; es tu mejor compañía. Una muy sexy, por cierto.

¡Nos vemos en la siguiente entrega!