Steve Bishop. 1 de octubre de 2024. Medium.
Desarrollo de software. Ingeniería de software
Problema:
La gente se describe a sí misma como desarrolladores de software e ingenieros de software, pero no parece haber una forma clara de identificar la diferencia.
Solución:
Este artículo. Ojalá.
Las definiciones de palabras son una cosa
Entonces, ¿qué es un desarrollador de software y qué es un ingeniero de software? Analicemos algunas definiciones de los términos desarrollador e ingeniero que podrían ayudarnos a comprender la esencia de la distinción entre estas profesiones.
Desarrollador: Persona o cosa que desarrolla algo.
Ingeniero: Persona o cosa que diseña algo.
Uh… vale. Gracias. Internet muy útil.
¿Qué tal si entonces buscamos desarrollo e ingeniería?
Desarrollo: crecer y volverse más maduro, avanzado o elaborado. (Oxford Languages)
Ingeniería: el uso de principios científicos para diseñar o desarrollar estructuras, máquinas, aparatos o procesos de fabricación, o trabajos que los utilicen individualmente o en combinación. (Consejo de Acreditación de Ingeniería y Tecnología)
Ah, mucho más útil. Mejor internet. ¡A trabajar!
Revelador
Así que, según la definición de desarrollador y desarrollo, un desarrollador de software debe ser alguien que hace que el software crezca, madure, avance o se elabore. Eso parece bastante descriptivo.
Los sistemas de software tienden a ser más complejos y a volverse significativamente más elaborados a medida que surgen nuevos requisitos. Estos pueden ser problemas tecnológicos o de comportamiento. Los problemas tecnológicos suelen incluir aspectos como lenguajes de programación, frameworks, infraestructura, herramientas, buses de mensajes, contenedorización y CI/CD. Los problemas de comportamiento son los que solemos asociar más comúnmente con las necesidades del usuario: nuevas funciones, nuevos temas, nuevos diseños, etc.
La complejidad es más que un simple término para describir las relaciones entre los componentes de un sistema. También es un corolario de la carga cognitiva. Por eso, la mayoría de las aplicaciones requieren más de una persona para su mantenimiento. Cuanto más grande es una aplicación, mayor es su complejidad. A mayor complejidad, mayor es la carga cognitiva. Cuando la carga cognitiva supera la capacidad del responsable del mantenimiento, es necesario que nuevos participantes se incorporen para asumir parte de esa carga. Cómo distribuir esa carga cognitiva de la manera más eficaz es un tema de gran interés, pero habrá que esperar a otro artículo.
La forma en que un desarrollador gestiona la complejidad y la carga cognitiva es probablemente muy diferente a cómo lo hace un ingeniero.
Ingeniero
Según la definición de ingeniero e ingeniería, un ingeniero de software debe usar principios científicos para diseñar y desarrollar software. Por lo tanto, si bien las tareas son similares para desarrolladores e ingenieros (es decir, desarrollo), los ingenieros tienen la restricción adicional de que deben usar la ciencia para hacerlo. Me gusta llamar a esto la distinción FAFO. La diferencia no radica en que uno se entretenga y descubra, sino en cómo lo hace.
El método científico
Para aquellos que no están iniciados, el método científico se reduce a tres pasos básicos:
- Crear una hipótesis mediante razonamiento inductivo
- Probándolo mediante experimentos y análisis estadístico
- Ajustar o descartar la hipótesis en función de los resultados.
- Repetir.
Técnicamente hay más, pero esto es lo esencial: formular una hipótesis, probarla, ajustarla y repetirla.
Entonces, ¿cuál eres tú?
Entonces, ¿cómo se aplicarían los principios científicos al software?
Bueno, aquí es donde aproximadamente la mitad de ustedes me van a criticar duramente, maldiciendo mi pasado y a mí. La otra mitad sonreirá y me agradecerá el razonamiento claro que finalmente les trajo la claridad que buscaban.
En resumen, TDD es el método científico.
Lo sé. Soy un cabrón. Soy un hereje. Soy un inútil que limpia comederos de animales. No votaste por mí. Lo entiendo. Pero piénsalo. ¿Qué es TDD?
- Fase roja: Escribe una prueba que describa tu hipótesis de cómo se comportará el código.
- Fase verde: Experimente con el flujo de control y la gestión del estado hasta que pueda pasar la prueba o demostrar que es inalcanzable (sí, esto sucede ocasionalmente).
- Refactorizar: ajustar el código y/o las pruebas para representar mejor su nueva comprensión del dominio.
- Repetir.
TDD ayuda a los ingenieros a gestionar la carga cognitiva al descomponer la complejidad de la aplicación en pequeñas partes de funcionalidad verificable. Los desarrolladores deben utilizar otras formas de gestionar dicha complejidad.
Entonces, si no haces TDD, ¿significa que eres desarrollador y no ingeniero? Bueno, no tan rápido.
Vamos a intentarlo de nuevo
Bueno, o te encanta esta distinción o la odias. Quizás tengas otra forma de describir la escritura y gestión de código de forma científica que no requiera TDD. No hay problema. Hay otra distinción que vale la pena explorar y que quizás te guste más. Emplea una analogía con la que la mayoría deberíamos estar bastante familiarizados: la construcción de edificios.
Normalmente soy el primero en decir que desarrollar software no es lo mismo que construir una casa. Hay muchos aspectos que diferencian claramente ambos ámbitos. Sin embargo, en el ámbito de la construcción de edificios hay ingenieros, desarrolladores y constructores. Podrían proporcionar una base útil para comprender cómo se usan estos términos en general.
En la construcción de edificios, los ingenieros seleccionan los materiales, gestionan la implementación de las metodologías de construcción, supervisan el proceso de construcción, gestionan las fases de planificación y diseño, aportan experiencia técnica a los planos y diseños arquitectónicos, y actúan como enlace entre las distintas partes interesadas, contratistas y proveedores. Esta experiencia técnica debe basarse en principios científicos.
Mientras que cuando se trata de desarrolladores en la construcción de edificios, proporcionan menos experiencia técnica pero más adquisiciones, gestión de fondos y supervisión de los contratistas y proveedores que realizan el proceso de construcción real (los constructores).
Aquí la distinción entre un desarrollador y un ingeniero tiene que ver con la división entre la experiencia técnica y la implementación del diseño que se ha realizado.
Traduciendo esto al desarrollo de aplicaciones de software, parece que tenemos ingenieros que eligen la infraestructura y las herramientas, identifican qué patrones arquitectónicos tienen más sentido, supervisan el desarrollo del software, aportan experiencia técnica al diseño y actúan como enlace entre las partes interesadas y los desarrolladores.
Los desarrolladores escriben el código con la guía de los ingenieros, administran su tiempo de forma económica (idealmente) y se aseguran de que la construcción de la aplicación siga las pautas establecidas por la arquitectura y la ingeniería.
Conclusión
Entonces, ¿qué hemos aprendido? Que la ingeniería es una disciplina que requiere la aplicación de principios científicos.La forma más segura de aplicar el principio científico es mediante el uso de TDD. Sin embargo, mientras diseñemos pruebas que validen el comportamiento y el estado, incluso a posteriori, podríamos considerarnos ingenieros. Las etapas de hipótesis y experimentación simplemente se invierten.
También aprendimos que la ingeniería tiene más que ver con el diseño y la experiencia técnica, mientras que el desarrollo tiene que ver con la gestión de recursos durante la implementación del diseño.
Quizás esta sea la fuente de gran parte de la confusión. La mayoría de los desarrolladores tienen que investigar y descubrir tanto que han recurrido a la ingeniería inversa. Han experimentado tanto con las cosas que, sin querer, han adoptado un conjunto de principios científicos, incluso si no son TDD. Pero una cosa es segura: si haces TDD, puedes considerarte ingeniero.
