Tácticas y Estrategias en el Desarrollo de Software: Cómo Alcanzar un Software Exitoso

Hoy no se trata de hablar sobre mi estilo de vestir, si es que tengo uno, no estoy seguro, sino de hablar más sobre el éxito. Todos quieren tener éxito en el software, ¿verdad? Y la pregunta es cómo lograrlo. Y tengo que hacerlo en solo 20 minutos. Así que no tengo idea de cómo puedo hacerlo. Y para ser honesto, mi día es mucho más largo que eso. No sé por qué, pero lo que se supone que debe ser más corto no lo es. Pero de todos modos, hagamos todo lo posible para convencerte de que tener una estrategia y tácticas en la ingeniería de software es bueno para nosotros. Es una buena manera de lograr el éxito cuando se trata de ingeniería de software. Y naturalmente, como dije, todos quieren tener éxito en el software, ¿verdad?

Quiero hacer un buen software, quiero entregar un buen software. Vamos, la industria del software está aquí desde hace casi 100 años. Pero ¿cómo medir un buen software? ¿Cómo tener una idea para entender si estoy haciendo un software bueno o no bueno? Y durante mucho tiempo, hemos intentado diferentes estrategias para hacerlo posible. Naturalmente, intentamos medir por la cantidad de tareas que hacemos en un día, en un mes, en semanas. Y naturalmente, no funciona. Y luego tenemos la métrica de data, hacemos implementaciones más rápidas y más rápidas y más rápidas, pero de todos modos no funciona. Y la última que intentamos, y desafortunadamente fallamos, fue medirnos por la cantidad de confirmaciones y luego la cantidad de code. Entonces, si hago más code, eso significa que estoy haciendo un buen trabajo. Y desafortunadamente, eso no es cierto tampoco. Así que cuando vamos a varios informes, revistas, podemos ver ese resultado, desafortunadamente. Como este aquí que pertenece a Forbes, 16 obstáculos para tener éxito en el software. Puedo resumir los 16 en solo cuatro. Básicamente, tenemos muchas reuniones, muchas discusiones para entregar lo que el cliente no quiere. Es triste. Es como si fuera a una panadería aquí en Inglaterra, pidiera un street food, creo que ese es el nombre correcto, o tal vez fuera a una pizzería y pidiera una pizza vegetariana, esperara tres, cuatro horas porque la cocina está teniendo varias reuniones, y luego me dieran una ensalada.

Así que es terrible. Es horrible, ¿verdad? Así que estamos teniendo varias reuniones. Estamos discutiendo varias cosas para entregar lo que el cliente no quiere. ¿Y qué triste es eso? Especialmente porque estamos teniendo varias discusiones, estamos teniendo varias reuniones, varios planes, en lugar de entregar lo que el cliente quiere, estamos entregando más complejidades. Sí, a veces pasamos más tiempo discutiendo microservicios que los requisitos comerciales. Y la consecuencia de eso es naturalmente la colaboración deficiente entre los equipos y el producto. Así que estamos discutiendo mucho desde la perspectiva de la arquitectura de software, pero olvidamos por qué lo estamos haciendo, la razón significativa para hacerlo, para lograr esa razón. Y puedes ver eso en una segunda revista, este código común. Es común que los desarrolladores entreguen un producto que no se alinea con las percepciones del cliente.

Así que estamos teniendo muchas reuniones, entregando complejidad y no entregando lo que debemos entregar con el software. Y no importa el lenguaje, ¿verdad? Puedo cometer errores con Java, puedo cometer errores con JavaScript, Rust, o incluso con una nueva tecnología. Muy a menudo, las personas vienen a mi oficina para discutir, OK, Otavio, en este momento nadie entiende ese code. Y para hacerlo posible, se me ocurrió una idea increíble. Tomaré mi code, lo moveré a una nueva tecnología, porque después de eso, todo estará bien. Y tristemente, no es cierto, porque después de tres años, adivina qué? Nadie es capaz de entender el lenguaje nuevamente. Nadie es capaz de entender y hacer avanzar el producto nuevamente. Así que no importa el lenguaje. Lo que importa para nosotros es la metodología, ¿verdad? Por eso estamos aquí. Necesitamos discutir más sobre la estrategia y tácticas en torno a la ingeniería de software. Y naturalmente, cuando hablamos de ingeniería de software, el hermano menor de la ingeniería es natural que lo comparemos con la historia, especialmente la historia militar en la ingeniería.

Tomemos esto como ejemplo. Tenemos a Julio César, quien quiere cruzar un río. Y para hacerlo posible, encuentra una forma de construir un puente en menos de 10 días. Y basado en ese puente, él podría cruzar a más de 40,000 soldados. El objetivo aquí no es construir un puente, sino cruzar a mucha gente hacia el río para atacar a Alemania. Esto también lo tenemos en la ingeniería de software. Es importante para nosotros comprender qué es la estrategia y qué es la táctica en la ingeniería de software.

Y cuando profundizamos en varias tecnologías en torno a la ingeniería de software, la primera pregunta es, Aran, ¿qué es la ingeniería de software? ¿Cómo podemos lograr el éxito en algo que no entendemos qué es eso? No se trata solo de code. Afortunadamente, no lo entiendes. La ingeniería de software va mucho más allá del code. Por lo tanto, hay varios términos. Mi favorito proviene de este libro aquí, `The Modern Soft Engineering` de David T. Foley. Y menciona que la ingeniería de software es la aplicación de un enfoque científico empírico para encontrar soluciones económicas eficientes a cualquier problema, por supuesto, utilizando software. No se trata de escribir code. Se trata de resolver problemas. Y naturalmente, cuando hablamos de ingeniería de software, hablamos de estrategia y táctica de otra manera.

La mayoría de las veces, cuando hablamos de arquitectura, estamos hablando de estrategia. Y cuando hablamos de táctica, estamos hablando de diseño. Y eso es divertido, especialmente porque no tenemos una terminología sustancial o una definición única de lo que es la arquitectura de software o qué es el diseño. Toma aquí, por ejemplo. Tengo un par de libros como puedes ver, y cada libro tiene una definición única sobre la arquitectura de software, una definición única sobre el diseño de software. Así que mi libro favorito aquí es `Just Enough Software Architecture`. Y para este libro, la arquitectura de software es una colección de diseño de software. Aquí tenemos un libro de Simon Brown, el creador del modelo C4. Y la arquitectura de software, para él, es una cosa o un diseño de software que es realmente difícil de cambiar. Entonces, incluso con una definición clara de lo que es la arquitectura de software y el diseño de software, podemos ver que la mayoría de las veces, cuando hablamos de la arquitectura de software y hablamos de lograr el éxito con eso, estoy hablando más de estar cerca del negocio. Estoy hablando más de cómo puedo lograr que las personas del negocio se acerquen a mis objetivos lo más posible.

Y cuando entramos en esa discusión, también podemos ver varias definiciones. Esta aquí es mi favorita. Pertenece a los fundamentos de la arquitectura de software. Y es por eso que creo que la arquitectura de software es más la razón y la estrategia de tener una forma de desarrollar. Entonces, aquí tenemos dos leyes sobre la arquitectura de software. La primera es que todo en el software es un compromiso. No hay una solución mágica en el desarrollo de software. Si eliges una tecnología, te enfrentarás a aspectos positivos y negativos. Si eliges otra tecnología, lo mismo. De hecho, esa es la razón principal por la que cuando hablamos de la arquitectura de software, no hay malas prácticas. Especialmente porque, puedo decir que si tengo múltiples ifs en mi código, puedo reemplazarlos con un patrón de estrategia. Pero no puedo decir que el microservicio es un mal patrón o que el monolito es una mala práctica, porque lo que determina eso es el contexto. Todo tiene un compromiso. El microservicio tiene un compromiso, el monolito tiene un compromiso. Y el siguiente paso es la razón para hacerlo, la estrategia para crearlo, la estrategia para construirlo es más importante que el cómo. Si entiendo la razón para crear una tecnología, un software, es más importante que cómo estoy construyendo ese software. Y para hacer una métrica en torno a eso, es por eso que creo en los modelos de madurez en nuestro desarrollo de software. Entonces, el modelo de madurez puede ayudarnos a tener dirección de dónde estamos y a dónde queremos ir. Podemos lograr métricas para las organizaciones que es muy importante para nosotros. Y podemos establecer objetivos, podemos establecer requisitos para hacerlo posible.

¿De acuerdo? Y eso es lo que creo acerca de la ingeniería de software. Así que tenemos nuestro contexto, y nuestro contexto se trata más de cómo podemos estar cerca del negocio, cómo podemos cumplir con los requisitos del negocio. Y luego tenemos cuatro puntos para tener en cuenta. Naturalmente, solo tengo 20 minutos. No cubriré el contexto aquí, cómo medir los requisitos del negocio, especialmente porque estoy hablando más desde la perspectiva de la ingeniería de software. Pero el punto es asegurarse de que tu code esté lo suficientemente cerca del negocio. Y en base a eso, podemos revisar el code design, las tareas, la documentación y finalmente la gobernanza. ¿De acuerdo? Y cada vez que hablo de documentación, la gente comienza a abandonar sus habitaciones, especialmente porque es algo que no disfrutamos lo suficiente, ¿verdad? Odiamos escribir documentación para nuestro code, pero especialmente porque la presentación no se compila. La presentación no es suficiente, ¿verdad? Así que la presentación, la documentación es algo que no disfrutamos. Sin embargo, si no haces ninguna documentación, ¿cómo puedes hacer que tu equipo sea escalable? Quiero decir, piensa más en el proceso de incorporación si no tienes ninguna documentación. Piensa en la cantidad de reuniones que necesitas hacer, porque no soy un Jedi. No puedo leer la mente de las personas, ¿verdad? Entonces, la documentación ayuda en este tipo de escalabilidad dentro de tu proyecto. Y por supuesto, debemos entender que necesitamos llegar a un punto justo de documentación. Demasiada documentación es un dolor de cabeza, pero tampoco tener ninguna documentación es un problema. Hay varios informes sobre cómo y por qué tener documentación. Sin embargo, no tenemos ningún informe sobre los costos de tener documentación. Pero tenemos un caso sobre cómo una empresa se arruinó en 45 minutos porque no tenían documentación. Y probablemente, conoces este caso, la saga de la novena capital. Y por supuesto, tuvieron varios problemas. Tuvieron varios problemas, incluyendo, desafortunadamente, la falta de documentación para hacer la restauración. Y eso es difícil, ¿verdad? Quiero decir, si le preguntas a tu novena capital cuánto cuesta la documentación, te responderían, `Bueno, la documentación nos costó más de $400 millones en 45 minutos`. Y por eso es importante la documentación. Y cuando hablamos de documentación, naturalmente, podemos abarcar la táctica y la estrategia en torno a la documentación. Así que escribe documentación dentro de tu code. Asegúrate de tener un registro de cambios para tu repositorio. Por ejemplo, en una nueva versión, puedes ver claramente qué cambió, qué se incluyó, y así sucesivamente. Dentro de tu archivo readme, explica los objetivos de este repositorio, cómo usarlo y cómo instalarlo. Y finalmente, como hablamos más sobre las API REST, asegúrate de utilizar algún tipo de documentación de API abierta. Piensa más en la escalabilidad. Cuanta más documentación tengas, menos reuniones tendrás que enfrentar.

Así que vas a ahorrar tiempo a las personas haciendo documentación. Y como dije, la táctica dentro del código y la estrategia principalmente en torno a tu perspectiva. Así que el modelo C4 de Simon Brown, que lleva el TechRadar al mapear la tecnología que utilizamos dentro de nuestras organizaciones. Adjunta tus registros de decisiones. De esta manera, puedes asegurarte de que tomaste la decisión, conoces la razón, puedes medir esa decisión mediante compensaciones. Y el último es naturalmente hacer una comunicación clara con foros, canales de Slack y cosas así. Recuerda, menos reuniones, a veces es código.

Y cuando hablamos del modelo de madurez, necesito hablar rápidamente aquí. Por lo general, comenzamos con la documentación conocida, y luego puedes avanzar para hacer la documentación del código, luego la documentación de la etapa del repositorio, adjunta tu documentación, y finalmente explora más el DocOps. ¿Qué significa DocOps? Básicamente, tan pronto como fusiono mi documentación, mi documentación está disponible para ver y leer. Por ejemplo, puedes usar AskDoc dentro de tu archivo Readme para ayudar a las personas a comprender cómo usar y cómo dar estilo a ese código. dentro de tu organización. De acuerdo, pasemos al siguiente tema, en torno al código y al diseño del código.

Hay este increíble libro llamado La Filosofía del Diseño de Software, y tiene una buena definición sobre la principal diferencia entre un programador que se enfoca más en lo táctico, lo que significa trabajar para lograr que las cosas se hagan, y la forma estratégica. Así que el libro llama a esa persona un tornado táctico, porque puede hacer un código más rápido y más rápido, pero nadie entiende más el código que esta persona toca. Así que se convierte en una pesadilla. Y a largo plazo, es imposible leer y comprender cualquier código relacionado con eso. Entonces, ese es el objetivo principal de evitar la complejidad dentro de tu repositorio, dentro de tu arquitectura. Así que es natural que comencemos con patrones, queremos aprender, queremos aplicar tanto como sea posible, pero al final, nuestro objetivo debe ser luchar por obtener cada vez más simplicidad en nuestro código.

De acuerdo, en cuanto a la madurez del diseño del código, tendré que ir rápido aquí, así que a veces no me importa. Y luego puedo pasar a la simplicidad o la etapa final de sofisticación de Leonardo Da Vinci. Entonces, la simplicidad es el camino a seguir, escribir un buen y simple código tanto como sea posible. Luego tenemos las tareas, es una cosa que puedes hacer y explorar como profesor dentro de nuestra organización. No se trata solo de la cobertura de tareas, porque es importante, es crucial, pero debes medir qué tan eficiente es esa tarea. De acuerdo, puedes combinar eso con las pruebas de mutación. Como desarrollador de Java, mi experiencia es en Java, así que estoy usando PyTask, pero naturalmente, en tu herramienta, puedes usar lo que quieras, pero mi consejo para ti es combinar la cobertura de tareas con las pruebas de mutación. No se trata solo de la cobertura, sino, por supuesto, de qué tan eficientes son esas tareas. Y hablando rápidamente sobre el modelo de madurez de las tareas, así que tareas conocidas, desafortunadamente, sucede, así que puedes pasar a las tareas unitarias, tareas de integración, cobertura de tareas, y finalmente, las tareas optimizadas. Eso significa la combinación de la cobertura de tareas con las tareas de mutación. De esta manera, puedes definir el requisito mínimo para avanzar con tu código.

Así que solo puedo fusionar este code si tiene al menos un 18% de cobertura con mi code. Y esta tarea debe ser eficiente. El último que voy a cubrir hoy es sobre la gobernanza. Sí, a veces lo vemos como una señal de alerta para nosotros, no nos gusta, pero es necesario, incluso para las startups. Y la razón es principalmente a largo plazo, porque dejamos la organización, pero la organización debe seguir haciendo este code. No tiene sentido recrear o rediseñar el code cada vez. Así que para la consistencia, la reespecificación, la eficiencia y naturalmente para trabajar con colaboración.

La eficiencia en torno a... ¿Este es el padre de ChartTPT, verdad? El objetivo principal de la gobernanza aquí es utilizar varias herramientas para facilitar tu vida. Este es un ejemplo simple de gobernanza optimizada. El SAS, por lo tanto, el Análisis Estático de Seguridad. De esta manera, puedes evitar la inyección de SQL, la inyección de HTML y demás, solo utilizando herramientas automatizadas. Por lo tanto, utiliza algunas herramientas para actualizar tus dependencias, especialmente para evitar cualquier violación de CVE, y naturalmente, verifica el estilo. Entonces, si estoy utilizando algún alineamiento faltante, si estoy utilizando algunas herramientas que no debería usar, o estoy utilizando alguna API que está obsoleta, puedes evitar todo este tipo de cosas con la gobernanza.

Y la madurez de la gobernanza, ninguna. Luego pasa al code, al repositorio de code, al inner source. Y la gobernanza evolutiva, donde todos pueden participar, unirse, y ayudar a crear la gobernanza dentro de la organización. Porque los puntos principales del desarrollo de software para lograr el éxito son, naturalmente, uno, acercarse al negocio, y el segundo punto es hacerlo con simplicidad, porque los requisitos cambian. Pero necesito poder y estar preparado para cambiar con el propio negocio. Eso es todo por hoy. Mi nombre es Otavio Santana, principalmente Java, y espero que lo disfruten, y nos vemos por ahí.

Y la primera pregunta es, en muchas empresas, los productos están documentados, pero esta documentación no tiene sentido porque es de baja calidad. ¿Puedes recomendar algunos principios para mejorarla? Sí, es un buen punto. Mi primera recomendación es estar cerca del negocio. Primero, naturalmente. Y existen varias metodologías para hacerlo posible. Por ejemplo, puedes hacer la tormenta, donde tú, el equipo de ingeniería, y el equipo de producto pueden escribir la documentación juntos, especialmente al principio. Y también, comienzan a contar el dominio, donde las personas juntas, también, pueden definir la tecnología empresarial dentro del propio producto. Así que esos dos son increíbles. Mi favorito es comenzar a contar, especialmente porque cuando hablamos de la humanidad, disfrutamos contar historias a alguien más. Así que si vas a Amazon ahora mismo, puedes ver el libro, Comenzar a Contar el Dominio, donde puedes ver la metodología y cómo puedes aplicar eso con DDD, Diseño Dirigido por el Dominio. Así que para los desarrolladores de software, Comenzar a Contar el Dominio es el mejor y está muy cerca del código, también. Basado en eso, puedes definir el contexto de delimitación. Puedes definir el contexto de mapeo y también definir las entidades y cosas así. Gracias.

La segunda pregunta es, ¿no deberíamos enfocarnos en la necesidad esencial de un cliente en lugar de en lo que están pidiendo? De lo contrario, siempre piden un caballo más rápido. Esa es una buena discusión. Pero a veces, lo que hacemos, es tratar de adivinar lo que el cliente quiere y olvidamos preguntarle al cliente mismo. Así que tomé estos datos de Phobos, de Gartner también. Y la mayoría de las veces, no hemos logrado entender lo que el cliente quiere. Así que los 16 obstáculos, como mencioné, se trataban de hacer algo que el cliente no quiere. Así que realmente no podemos trabajar juntos con el producto, pero debemos prestar atención porque lo que hacen es hacer un caballo más rápido en lugar de, no sé, comida en lugar de caballo, ¿de acuerdo? De acuerdo.

¿Qué crees que es la mejor arquitectura para bibliotecas como React a medida que se vuelve complicado, a medida que escala? ¿La mejor arquitectura para bibliotecas como Reactiva? Bueno, no lo soy. Soy principalmente un ingeniero de backend, así que mi recomendación es que la mejor arquitectura es la más simple basada en tu contexto. ¿Y qué quiero decir con eso? Entonces, si estás comenzando un proyecto, ve por el monolito. Va a funcionar en cualquier tecnología. Soy desarrollador de Java la mayor parte del tiempo. También lo hice con Kotlin. Y cada vez que la gente comienza a ir directamente a los microservicios, nos encontramos con una pesadilla enorme porque generalmente es un sobreingeniería de lo que se supone que debemos hacer. Así que ve simple, pasos pequeños, y sigue evolucionando con eso. Sí.

¿Cómo gestionar las decisiones de arquitectura de frontend frente a las decisiones de arquitectura de backend cuando las soluciones de frontend son mejor comprendidas por la gestión? Porque son visibles. Es hora de pedir visibilidad dentro de tu equipo. En América, la mayoría de las veces, tenemos a una persona que es el puente entre la gestión y el equipo de ingeniería a la que llamamos personal más ingeniero. Este personal más ingeniero es el ingeniero que tiene la tarea de ser un líder y pedir eso, especialmente porque si el equipo de ingeniería no comprende lo que deben hacer, estamos fallando como ingenieros de software. Es un gran error. Así que mi recomendación es pedir a alguien que sea capaz de ser el puente. Pide a esta persona de personal más ingeniero que se encargue de eso, pregúntale. Así que alguien estará allí para asistir a algunas reuniones aburridas y tener este tipo de discusiones y traer más de la gestión al interior. De lo contrario, vamos a programar a ciegas, así que no tiene sentido. Siguiente pregunta sobre startups. ¿Cuál sería la cantidad recomendada de documentación y procesos para startups? Bueno, es una buena pregunta. Para mí, un buen comienzo es la documentación del código, el repositorio de documentación, el registro de cambios y los ADR, registros de decisiones adjuntos. Esos cuatro son suficientes para ver qué está sucediendo dentro de tu código, dentro de tus decisiones adjuntas y cómo puedes medir eso con el tiempo. Por ejemplo, como dije, puedes crear el primer ADR explicando por qué elegimos el monolito en lugar de los microservicios o viceversa. Entonces, ¿por qué elegiste los microservicios en lugar de ir al monolito? Y puedes ver la historia de esa decisión. Así que a veces esa decisión se vuelve obsoleta, así que necesitas revertirla por alguna razón, así que puedes usar los microservicios en este momento porque tu equipo es mucho más grande ahora que antes o puedes volver al monolito porque rompiste las reglas y el límite está equivocado, así que necesitas volver al monolito y luego desmantelarlo nuevamente. Con esos cuatro es suficiente para comprender qué está sucediendo dentro de tu equipo desde la perspectiva de la ingeniería de software. Sí, tal vez la última pregunta de mi parte. ¿Crees que el primer tipo de documentación debería estar en inglés para todos? En mi equipo, sí, porque tengo equipos distribuidos con personas de Brasil, personas de Irlanda, personas de Polonia, así que naturalmente para mí es en inglés, pero si el equipo está en un solo idioma como Brasil, entonces solo tengo brasileños en el equipo, puedes hacerlo en portugués o si lo estás haciendo solo en los Países Bajos, puedes hacerlo en flamenco y así sucesivamente. Pero luego viene alguien que no habla neerlandés o portugués y... Sí, todo en neerlandés. Así que muchas gracias Otawe. Gracias por responder nuestras preguntas. Así que puedes hacer más preguntas a Otawe en la zona de preguntas y respuestas. Muchas gracias.