Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas Barahona (00:00)
future proofing, que es preparar tu aplicación para el futuro, que estés lista para el futuro o que pueda aguantar por muchos años.
Juan (00:01)
CC
Douglas Barahona (00:10)
lo más que pueda dar la tendencia actual, la tecnología actual, la versión actual, etcétera. Una cosa es future proofing y otra cosa es over engineering. Over engineering son funcionalidades que no vas a necesitar nunca.
Juan (00:21)
Exacto.
Muy bienvenidos sean todos a un nuevo episodio de nuestro podcast favorito Dev & Ops. Este es nuestro segundo episodio del año 2026, así que es un episodio muy interesante, muy bonito para nosotros porque de nuevo estamos arrancando después de las fiestas y todo, todas las celebraciones. Aún estamos un poco llenitos de lo que hemos comido, ¿no Douglas? Para los que nos están escuchando.
me está acompañando mi buen amigo Douglas, quien siempre nos trae a la mesa mucha información y muchas reflexiones que podemos hacer. ¿Cómo has estado Douglas en estos días de regreso a nuestra vida cotidiana?
Douglas Barahona (01:17)
Juan, ¿qué tal? Bueno, como siempre bien, la gracia de Dios, los días feriados que tuvimos durante las fiestas, Navidad y Año Nuevo, en donde yo...
en field nos dan libre esa semana entre las fechas del 24 y la fecha del año nuevo, entonces pude desconectarme del trabajo por esa parte, verdad, sin embargo, en otros aspectos siempre hay que trabajar, siempre hay que estar pendiente de otras cosas, este podcast, este proyecto en particular, y lo que mencionaste, de aprovechar con esa comidita navideña, con esa comidita festiva, el recalentado,
Y bueno, ya esta semana volviendo a la realidad, desde la semana anterior en realidad, pero como que la resaca nos queda, Juan? Y a veces uno siente que toma más tiempo que lo que antes tomaba volver a la realidad, pero aquí estamos, eso es lo importante.
Juan (02:15)
excelente si aquí estamos y bueno este proyecto es el que estamos tratando de llevarlo semana a semana
Bien, vamos a entrar en materia para no perder mucho tiempo y no aburrir a nuestra audiencia. El día de hoy vamos a hablar sobre un tema que ya lo hemos mencionado en episodios anteriores. Es bueno, de hecho es un tema que siempre sale a la luz en cualquier conversación, ¿verdad Douglas? Es algo que siempre está en nuestra mente y es algo que siempre tenemos que estar cuidando de no sobrepasarnos. Me refiero al famoso, ya famoso, overengineering. Básicamente es sobre
realizar una ingeniería excesiva en nuestro trabajo, las soluciones que estamos dando y esto pues conlleva ciertas situaciones, ciertas problemitas que vamos a ir explorando poco a poco el día de hoy. Realmente es algo Douglas que definitivamente con el tiempo he ido dejando de hacerlo.
siento que a medida iba iniciando en el mundo de tecnología, si lo pusiéramos como en una gráfica, inicié muy arriba en cuanto al overengineering y con el tiempo he ido bajando. Sin embargo, ha sido un trabajo muy, muy fuerte y muy difícil porque siempre nuestro, por algún motivo, nuestro impulso es el de crear cosas que son excesivamente complejas. Y antes de pasar a esto, me gustaría como definir Douglas,
una definición bastante simple de a qué nos vamos a estar refiriendo con el overengineering y por aquí lo tengo anotado Douglas, básicamente el overengineering es diseñar una solución de manera más complicada de lo que realmente necesita, resolviendo esto nos lleva a resolver problemas que aún no tenemos y que probablemente no lo vamos a tener nunca
A eso nos estamos refiriendo con overengineering. ¿Te ha pasado Douglas? Aquí viene la pregunta del millón. ¿Te ha pasado? ¿Lo has experimentado? Es una pregunta retórica, obviamente.
Douglas Barahona (04:32)
Sí, bueno, la respuesta corta, por supuesto que me ha pasado. Y de hecho, ahorita que estabas hablando me reía un poco porque tal cual te ocurrió a vos, me ocurrió a mí, que es al inicio de mi carrera o...
ir transicionando en los diferentes puestos en los que estaba mi carrera. Me ocurría el over engineering en las soluciones que yo daba, una curva donde al principio era altísimo el porcentaje de soluciones con over engineering, pero a medida pasan los años y a medida, por gracias a Dios, se va agarrando experiencia, es hasta ahí donde uno comienza a entender y como que realmente aprovechar el esfuerzo, verdad, y sacarle el jugo a cada hora de
trabajo y no hacer de más cuando no es necesario. Aparte que ahí lo vamos a ir hablando también hay otros aspectos, el entender tu equipo, la empresa, presupuestos, clientes, todas esas cosas en realidad afectan, es un problema más serio lo que parece el over engineering one. Entonces también a medida se van entendiendo esas cosas uno comprende y va aprendiendo cada vez más a implementar la solución necesaria.
al cual lo dice la definición que nos acabas de leer, la solución necesaria y no la solución que me gustaría, a pesar de que sean cosas que no se van a utilizar a mí, me gustaría implementarlas, no como alguien técnico. Pero sí, me ha pasado, me ha pasado y probablemente me sigue pasando todavía por ahí, no me doy cuenta, Nadie me lo ha hecho saber en los últimos años, pero aunque no me pasa, creo yo, no sé, en la actualidad, siempre toca lidiar con ello.
ya sea otras personas que están haciendo overengineering, en mi caso como alguien en el área de sistemas, desarrolladores que están queriendo implementar una solución con overengineering y nos están pidiendo de más a nosotros de sistemas, verdad, para algo que nos parece simple, o a veces, y este es el chistoso, a veces toparme con cosas que yo hice.
Juan (06:34)
No,
Douglas Barahona (06:40)
Hace cinco o seis años que fueron over-engineered, una solución muy excesiva y que ahora me toca mantenerlas o tratar de modernizarlas y en realidad resulta más complejo de los beneficios que yo creía que iba a tener.
Juan (06:41)
No,
¿Quién hizo este código? Perdón, fui yo. Sí, pasa. Bueno, tengo aquí unos puntos que me gustaría hablar porque...
Douglas Barahona (06:58)
Sí, así.
Juan (07:07)
Ok, estamos cayendo en una sobre ingeniería cuando estamos haciendo una solución que es más excesiva de lo necesario. Pero esta es la parte difícil y que creo que solo con la experiencia uno va adquiriendo un ojo para identificarlo. sea, cuando tenemos que parar y cuál es la solución necesaria. Esa es la parte. Pero me gustaría traer unos puntos que nos van a ayudar a identificar estos Douglas en,
no son puntos descritos en piedra y va a variar de caso a caso pero pues nos pueden dar como una idea y de hecho como para que la gente lo vaya interiorizando me gustaría dar un pequeño ejemplo antes de que iniciemos que me sucedió y algunos podrían argumentar que no era sobre ingeniería y otros podrían decir que sí aquí sí queda como a la interpretación en mi caso en mi equipo de trabajo
sí fue una sobriingeniería porque no era necesario.
te explico rapidamente, básicamente tenía que al momento de enviar la información de un formulario el backend tenía que recibir el nombre de una compañía sin embargo para que este nombre de compañía tuviese que estar enlazado y poder seleccionarlo desde el frontend lo que se suele hacer es tener un drop down bien ese drop down para yo poder recibirlo entonces que es lo que yo estaba haciendo
yo lo que estaba haciendo es ahora yo recibí el ID de la compañía y te iba a crear una tabla intermedia que me pudiera hacer el match y hacer la relación entre esa compañía y lo otro información que quería hacer y muchas cosas. Un dato extra, esto era una implementación para una base de datos vieja que ya tenía información dada. Entonces yo empecé a hacer todo esto que te estoy relatando.
múltiples tablas y relaciones bilaterales entre diferentes IDs, foreign keys en la base de datos, todo esto. Y cuando lanzo el PR, pues lo que me escribió en mis compañeros es, creo que no es necesario todo esto. Y si en vez de hacer todo esto de las relaciones, simplemente en el drop down, la persona elige la compañía y envía directamente el nombre de la compañía.
Y eso es que reciben en la base de datos porque así es como estaba la base de datos vieja. De nuevo, la base de datos vieja solamente iba a guardar el nombre. Yo en el backend iba a hacer todo un montón de pasos intermedios que iban a extraer el nombre y verificar que no estuviera, muchas cosas. Pero de nuevo me dijeron, bueno...
Creo que por como estamos lanzando el producto y por que es una base de datos antigua, legacy, todo esto, mejor simplemente recibir el nombre y que el front-end se encargue de extraer el nombre. Y listo, me ahorré el hecho de lanzar nuevas migraciones en la base de datos, tablas que ahora tenía que mantener en el futuro y todo esto. Son cosas que se van, que al inicio parece que es lo correcto. Como digo, podría ser debatible si es lo
correcto no? pero pues no era necesario en su momento es bien complicado Douglas identificar esto porque pues mi reacción inicial fue la de bueno voy a hacer todo con normas perdón con normalizando la base de datos y todo esto
pero tal vez no era lo necesario. Entonces por eso me gustaría pasar a estos puntos que tengo Douglas que nos pueden ayudar a identificar y van a ir viendo que con este ejemplo que les di vamos a ir viendo este tipo de estos puntos y el primero que tengo Douglas ⁓
Douglas Barahona (11:01)
con eso Juan perdón y disculpa solo
quiero agregar antes de que de los puntos para identificarlo que en mi opinión personal eso que te ocurrió es el momento más difícil para uno en si estar haciendo over engineering o no porque estamos acostumbrados a implementar las mejores prácticas que aconsejamos a todos a que lo hagan y que no corten esquinas como se dicen entonces cuando viene una tarea pequeñita verdad o una tarea
Juan (11:29)
Sí.
Douglas Barahona (11:31)
de algo legacy, esos son los momentos en mi opinión más difíciles de lograr balancear, hacer la solución correcta contra over engineering, verdad, es ejemplo que diste, entonces lo quería mencionar antes de que comencemos con los tips para que lo tengamos en mente.
Juan (11:51)
tenés razón porque la verdad es que de nuevo muchas veces se nos explica y se nos enseña a hacer las cosas de cierta manera que están bien pero de nuevo va de casos a casos y hay muchos más detalles que tal vez no puedo revelar por obviamente no porque son cosas del trabajo pero hay muchos detalles que realmente hacían que implementarlo de esta manera iba a traer más conflictos y dificultades a futuro y por eso por eso lo que doy
Douglas Barahona (12:08)
Claro.
Juan (12:21)
el dato de que eso no hace datos legacy, entonces ya con eso...
Douglas Barahona (12:24)
Pero ese es el punto,
¿no? Perdón, que normal, muchas veces, perdón, ya cuando estás en un ambiente profesional y ya tienes algo de experiencia, el overengineering, la mayoría de las veces es con la mejor intención. O sea, no es por querer hacer de más. Y ese es el momento cuando es complicado. Yo creo que tal vez eso lo que quiero transmitir. En realidad es con la mejor intención de querer hacer bien las cosas, de no cortar esquinas. Pero por eso ahí es donde cuesta más identificarlo.
Juan (12:37)
Es cierto,
Sí.
Exacto, bien difícil, es muy difícil y de nuevo estoy contando una anécdota que es relativamente reciente, o sea a pesar de todos los años de experiencia que tengo pues aún pasa y por eso es muy importante que ya lo he mencionado en otros episodios yo siempre hablo muy a favor del co-review en equipo
No considero que tiene que haber una persona encargada de hacer code review o un partner. No, todos tienen que hacer code review. Esa es mi visión actual sobre este tema porque nos permite identificar estas cosas cuando alguien más está, pues está yendo por ese sendero. Bien, en base a esto, tengo un primer punto que...
Douglas Barahona (13:34)
Gracias.
Juan (13:42)
que nos va a ayudar, Y es cuando empezamos a pasar más tiempo configurando lo que es la arquitectura de la programación o de la solución que estamos dando más que en la propia lógica de negocio de lo que estamos tratando de solucionar. O sea, lo que quiero decir es que para solucionar algo tenemos que hacer una lógica, pero aparte tenemos otra lógica que es muy compleja para llegar a la solución misma. Entonces, cuando empezamos
a pasar más tiempo en eso por eso menciono que yo tenía como que múltiples tablas y luego en el backend tenía que extraer la información y tenía que hacer muchos pasos para luego simplemente guardar el nombre de la compañía
entonces cuando empezamos a pasar más tiempo en eso que en la misma lógica ya ahí es la primera bandera roja no necesariamente que esté mal pero es como empezar a ver ok estoy haciendo de más estoy haciendo algo que no debería qué tanto se puede simplificar ahí donde tenemos que empezar a preguntarnos
Estoy seguro que en sistemas Douglas, tienen muchas configuraciones que son inherentes de los ambientes que están lanzando y configurando servicios, etc. Pero no sé si tienen ese tipo de situaciones donde tenés más configuraciones para las mismas configuraciones. No sé si se suele dar eso.
Douglas Barahona (15:11)
Sí, fíjate que sí, a veces sí, definitivamente que a veces sí. Yo lo que quiero expandirle a la idea que está dando o al tip es si nos va a tomar más tiempo que lo que es la implementación como tal, si lo queremos poner en palabras simples.
la implementación más lo que va a ser el mantenimiento una vez que esté implementado. que considerar eso. Tal vez alguien puede decir, se tardó más en arquitectarlo, en hacerle en el tiempo de ingeniería que en el tiempo de implementación.
pero no te estás dando cuenta que un mantenimiento que tal vez antes iba a requerir, no sé, ponerle 15 horas al mes, 20 horas al mes, ahora se hacen 2 horas al mes. Entonces, ahí fue una implementación correcta. Entonces, solo quiero mencionar que hay que incluir la implementación y luego el mantenimiento en esa balanza, ¿verdad?, en esa balanza. Entonces, pero sí, fíjate que pasa bastante donde a veces tengo que configurar
Juan (16:05)
Sí.
Douglas Barahona (16:14)
cosas en mi local para conectarme y luego al llegar allá tengo un montón de recursos en Kubernetes que tengo un secret que tengo un config map que tengo un deployment y un cluster todo esto son recursos de Kubernetes y estoy corriendo un cron job entonces verdad por favor porque tomó más tiempo configurar todas esas cosas y termino con 6 8 diferentes manifestos archivos distintos y al final lo que agregué es un cron job más
probablemente eso fue un over engineering. Ahora, si tengo todo eso porque estoy manejando 20, 50, 100 o más scrum jobs, ahí entonces tal vez era una solución correcta, ¿no? Pero para responder a tu pregunta definitivamente pasa...
Como decía antes, normalmente con las mejores intenciones, con las mejores de las intenciones porque queremos que todo tiene que estar en código, en el caso de sistemas, queremos que todas las configuraciones estén en un repositorio, estén en código, entonces tal vez sea un cambio pequeño y para que pueda estar en el repositorio y como ya tenemos una estructura en el repositorio de cómo se manejan las configuraciones, hacerlo encajar en la otra estructura y me hizo hacerle ese overengineering.
Yo creo que ahí podemos buscar alternativas. ⁓ Y si nuestra forma de trabajo, nuestros best practices, procesos internos no nos permiten ajustar esas tareas pequeñitas, dediquemosle el tiempo entonces para tratar de ajustar proyectos pequeños, tareas pequeñas que se salgan de la norma en cuestión del tiempo o el esfuerzo que toma.
verdad, la complejidad que va a tener manteniendo cosas base que sean, yo no sé si esto está entre tus tips Juan, pero que sean, identificamos esas cosas que no son negociables, que las configuraciones estén en código, ejemplo, que sea repetible fácilmente, o identificamos esas tres, cuatro cosas que esas no se tengan que romper y las demás las podemos variar cuando sean proyectos simples o tareas simples, por ahí puede ser una de las cosas que yo
Juan (18:07)
mmm
Douglas Barahona (18:25)
les puedo aconsejar que normalmente intentamos hacerlo pero sí es fácil caer en ese remolino de situaciones en las que empezamos a seguir best practices y una tarea nos lleva la otra la otra la otra la otra y de repente hicimos un montón de código para algo que era simple
Juan (18:46)
hay en ciertos momentos la complejidad es inevitable porque estamos tratando de dar una solución a un problema que ya de por sí es complejo
pero por eso aquí estamos hablando de lo que quiero decir es que tenemos que tener en cuenta que es lo que estamos tratando de solucionar por eso por ejemplo el segundo punto que quiero mencionar es cuando sabes que estamos cayendo en el sobre ingeniería cuando es necesario realizar muchos pasos o múltiples pasos para completar una tarea que de por sí debería ser sencilla
de nuevo, parte es, admito que puede ser un poco ambigua porque qué es sencillo, cuánto son muchos, cuántos son muchos pasos. Bueno te doy un ejemplo, en el mundo de microservicios es muy común que realizas una tarea en un servicio, el dispara un evento, ese evento se ejecuta en otro servicio y ese otro servicio también dispara otro evento y se realiza una reacción en cadena.
¿es eso demasiado o no? y aquí pues sí es necesario que nosotros apliquemos nuestro criterio en base al proyecto que estamos en el que estamos trabajando también en base a nuestra experiencia como bien me decías hay que pensar en el mantenimiento futuro hay que pensar en qué pasa si lo aplicamos de esta manera qué tan fácil va a ser luego crear más features sobre lo que tenemos entonces cuando estamos notando que tenemos una tarea que de por sí
es
simple pero tiene demasiadas abstracciones, demasiada pasos de nuevo es bandera roja no estoy diciendo que ya con eso hay que cambiar todo y simplificarlo no simplemente es una bandera roja y hay que empezar a analizar lo que tenemos a ver si se puede simplificar a ver si podemos cortar ramas de lo que ya teníamos porque como bien decía es difícil identificarlo así que es necesario tener estos pequeños
como indicadores para saber cuándo tomar acción y cuándo no.
Douglas Barahona (21:05)
que fíjate Juan que y soy de acuerdo no pero donde se nos vuelve complejo a nosotros es como no pensamos en esas cosas o sea para mí no es complicado abrir la terminal y correte comandos para otra persona y le resulta complicado y preferir hacer clic un montón de veces y tapiar un montón de veces y para mí me resulta más fácil ejecutar un comando entonces
Yo puedo estar creyendo que eso es simplicidad porque vivo en ese mundo. Es como que le digas a un futbolista de la talla de tope mundial que hacer la bicicleta, el recorte y colocarla en la esquinita para él es simple. Para él tal vez no fue over engineering el gol, pero para un futbolista amateur como yo ya es mucho. Entonces, ese tipo de cosas, no sé si me logro explicar.
Juan (21:52)
jajaja
Douglas Barahona (22:00)
nos hacen que nos cueste encontrar o darnos cuenta, identificar que son pasos de más, que en realidad pudo haber sido más simple, que solo porque para mí es simple no significa que en realidad era simple. Y ayuda mucho, Juan, también ver quiénes más van a estar manteniendo la solución y quiénes la van a utilizar. Te quiero dar un ejemplo simple que me ocurrió a mí.
en noviembre creo del año anterior o sea hace unos cuantos meses un cliente quería una solución simple para poner una página de mantenimiento live verdad cuando quieren hacer mantenimiento a su sitio web
Juan (22:37)
Ok
Douglas Barahona (22:40)
desplegar una página de mantenimiento para los usuarios, pero internamente que no se miren. Entonces hice la funcionalidad, esto estaba en AWS con un Cloud From Distribution y el sitio está hosteado en WordPress, entonces Cloud From directamente tenía que desplegar la página de mantenimiento. Hice las configuraciones, hizo una script que lo hacía, entonces ahora vienen ellos y decían...
¿Cómo lo podemos correr nosotros mismos? Pues yo ejecuto el script fácilmente desde mi local, ¿no? Pero ellos no pueden ejecutar un script fácilmente. Entonces la solución que se daba a nivel del equipo de ingeniería era instalar Rundeck para que no sepan Rundeck es una aplicación para ejecutar tareas. Así de sencillo, ¿no? Es una aplicación escrita en Java, por cierto. No es relevante para la conversación, pero para quienes no han escuchado de Rundeck, para quienes no han escuchado de Rundeck,
Juan (23:11)
No,
Claro que sí.
Douglas Barahona (23:34)
te da una interfaz gráfica, haces proyectos, tenés permisos y podés ejecutar diferentes tareas y es perfecto para que le dejas a tu project manager que corra tareas de QA o que corra tareas para limpiar el caché después de un deployment para darle al cliente que ejecuta una tarea pequeña. Entonces me dijeron, ¿sabés qué hacer? Me dijo el equipo de ingeniería. Instalarles un RONDEC y que corra la tarea desde ahí.
y
Juan (24:04)
Ok
Douglas Barahona (24:04)
yo ok que más tareas van a correr a futuro no hay algún plan de más tareas no empecé a investigar con otros equipos hay alguna manera que les demos más poder al cliente con esta instancia de ronda para que ejecuten más tareas no no hay nada más y yo puxa vamos a levantar una instancia de ronda solo para esta tarea solo para correr un script entonces yo decía puxa capaz que mejor les enseñó a correr el script manual desde su local
Pero viéndolo un poco, en realidad que la solución que les pude presentar al final fue por medio de GitLab, un pipeline. Ellos ya tienen acceso a GitLab porque muchos de ellos son developers. Por medio de un pipeline, ¿qué ejecutar el script? ¿Verdad? Tenía sus otras cositas ahí. En realidad un pipeline en general está hecho para automatizar builds y deployments.
Juan (24:48)
Ok
Douglas Barahona (24:57)
pero al final automatiza procesos, ¿verdad? Entonces, me tomó minutos crear un repositorio con el script y el pipeline para que ellos estuvieran ejecutando el script, activando y desactivándolo cada vez que lo necesitaran. Entonces, en esa ocasión yo siento que estuve a punto de hacer un overengineering para una solución de algo que en realidad para el uso que ellos tienen no iba a crecer más y terminé utilizando un pipeline que alguien puede argumentar
me preguntaría, ¿no es para eso? En realidad que funcionó perfecto. Y solventó lo que ellos necesitaban.
y algo que me iba tomar horas, sé, seis, ocho horas probablemente configurar, asegurar, es un servidor más que hay que estar actualizando, manteniendo, ¿no? Y configurando, algo que me iba a tomar seis, ocho horas más unas cuantas horas de mantenimiento al mes, lo puede hacer en qué, dos horas a lo mucho tomando el tiempo que les expliqué a ellos cómo utilizarlo y todo el asunto.
Juan (25:54)
No,
Douglas Barahona (25:59)
Pero eso llegó al ponerme a pensar, al tratar de ponerme a pensar quiénes lo van usar, quiénes le van a estar dando mantenimiento, porque para mí de hecho de entrada lo que yo pensaba era darles el script y que ellos lo estuvieran ejecutando desde local. Entonces por ahí ese tipo de ideas, ¿cuán son las que nos crean confusión a nosotros y luego crean inconformidad con la persona que está recibiendo la solución?
Juan (26:24)
Si, yo creo que ahí esta dando un punto clave en todo esto y es el hecho de pensar también en nuestro equipo Pensar en quien lo, como decías, quien lo va mantener, quien lo va ejecutar Que tantas veces se va a realizar esa tarea al mes, al año, etc. Son esas preguntas que, desgraciadamente al inicio van a ser muy difíciles de contestar para nosotros porque si no tenemos la experiencia, o sea, si no lo hemos vivido va a ser complicado pues llegar a esta
conclusiones pero pero bueno para eso estamos aquí nosotros para ayudarles en este proceso no cuando no lo han pasado vamos a tratar de explicarlo con lo que nosotros ya hemos vivido
y bueno el último punto que tengo aquí creo que se siente que se está repitiendo porque ya lo hemos mencionado pero bueno lo mencionó y es cuando la lógica de nuestro código o de la solución que estamos dando es extremadamente complicada para el problema que en sí tiene que ser simple
y bueno, de nuevo, siento como estoy repitiendo pero en sí la idea es siempre tener en mente que tanto es lo que estamos solucionando y que tanto esta tarea nos está sirviendo o nos está complicando la vida a futuro porque bueno, Tula ya nos dice que le ha pasado en carne propia el hecho de regresar a su misma solución y ni siquiera uno ya no sabe cómo fue
funciona y bueno son esas banderas rojas que tenemos más las que también Dula nos ha dicho que tenemos que tener en cuenta y no está de más realmente no está de más en dar un paso atrás y empezar a analizar nuevamente lo que estamos haciendo yo te comento que llevaba como dos tres días realizando una tarea que bueno esta tarea si era muy compleja
Empecé a trabajar mucho con la tarea y con... también utilizo AI últimamente, ¿no? Y siento que la inteligencia artificial me empezó a llevar por un rumbo que... a pesar de que yo estaba guiando, ¿no? Entre comillas lo que estaba sucediendo, las mismas soluciones que me estaba tirando la IA, me empezó a llevar por un rumbo que, de hecho, hoy tuve que deshacer todo lo que había hecho y volver a empezar. Y... como ya tenía...
ya tenía el contexto de lo que había hecho antes más lo que ya había podido ver las cosas que no me gustaban fue más fácil volver a empezar y simplificar mucho las cosas en vez de realizar múltiples tareas no puedo decir muchos detalles de lo que estaba haciendo pero era una tarea compleja y la solución que estaba dando estaba exponenciando esa complejidad
ojo no no hablo tanto de lo que va a suceder sino la complejidad para mi equipo de trabajo cuando les toque a ellos revisar o parchar un book o agregar nuevas funcionalidades yo estaba seguro que si lo dejaba como estaba les iba a crear mucho mucho problema y es lo que vos mencionabas no de tener en cuenta nuestro equipo y que lo va
a dar el mantenimiento a futuro. En mi caso pues todos damos mantenimiento a las mismas cosas así que cualquiera lo iba a poder agarrar y esa es la métrica que yo tengo. Estoy haciendo algo que cualquiera de mis compañeros va poder revisar y entender o es algo que sí o sí me van a tener que preguntar a mí.
y me refiero no tanto a la lógica, es inevitable que, como dije, hay cosas que inevitablemente son complejas pero si a eso le agregamos más complejidad porque estamos desarrollando una solución que tiene mucha abstracción y estamos preparándonos para futuro y estoy agregando múltiples repositorios para que sea un código que hoy trabaja con Postgrese y mañana yo puedo seleccionar MySQL
en la vida real eso no va a suceder entonces estamos cayendo en la sobre ingeniería ya hemos lo hemos mencionado en lo que estamos hablando Douglas pero me gustaría mencionar las desventajas de esto
Douglas Barahona (30:59)
gustaría
si te parece antes de que dé las desventajas con lo que dijiste de considerar el equipo yo quisiera agregar algo porque recordé una anécdota ahorita que lo mencionabas porque hay que considerar el equipo no sólo al momento de decir bueno quiénes más lo van a mantener pero muchas veces también al momento de estar
Juan (31:03)
Sí, sí, sí.
Douglas Barahona (31:19)
haciendo la arquitectura, de pensar en la solución, preguntar, hey, ¿cómo harías esto vos? o ¿tengo esta idea? Preguntar de antes y considerarlo, porque de repente por ahí nos pueden venir ideas interesantes o que nos pueden dar claridad a ver de qué tipo de herramientas, tecnología o solución van a poder mantener todos también. Entonces, preguntar antes. La anécdota que se me vino a la mente la comparto rápido. Como siempre hago referencia a esta empresa donde vos y yo nos conocimos, esto no me pasó a mí.
Pero había una situación donde estaban trabajando en una re-arquitectura de la base de datos principal, una re-arquitectura bien grande.
por algo y no recuerdo todos los detalles a cabalidad, pero por algo que parece pequeño. La persona que estaba compartiendo el problema dijo, cuando estaban diseñando la base de datos, recordemos esto es una empresa que maneja hoteles en el Caribe, en muchos países, países tiene, cada país tiene sus regiones y por cada región tiene hoteles.
Juan (32:20)
Bueno,
recordemos, pero creo que nunca hemos hablado de la empresa como tal.
Douglas Barahona (32:27)
la empresa, yo creo que yo lo he mencionado, parece a mí, pero bueno, la empresa tiene hoteles de lujo en el Caribe, en varios países del Caribe, cuando la persona que estaba planteando el problema por el cual se tenía que re-equitectar la base de datos y es una cuestión, un cambio bien fuerte en realidad, en su momento dice que él...
Juan (32:31)
bueno.
Douglas Barahona (32:46)
sugerió agregar un campo de país a la base de datos, sea una tabla de país, ¿verdad? Y de ahí, por país, luego agregar las regiones y luego los hoteles. Y entonces, quien estaba diseñando la base de datos dice que le dijo, no, ¿para qué? No, porque en algún momento vas a querer agrupar para... No, si es que todos los hoteles tienen las mismas cosas, todos los hoteles tienen lo mismo, pero ¿y si en el futuro? No, pero es una tabla, no, no quiso.
Entonces, pasaron los años que fue en ese momento donde yo lo escuché, yo era parte un poco de la conversación por estar pendiente de si había un cambio en el sistema, pero él estaba en realidad hablando con otra persona, resulta que se ocupaban hacer promociones y cosas por país ahora y no tenían un problema. Y cuando ya tenés infinidad de información, querer agregar esa tabla en medio resulta que no era un cambio fácil, un cambio sencillo. Entonces...
se me vino a la mente eso ahorita que voy a decir de escuchar a los compañeros porque cuando y lo quiero combinar con este otro consejo cuando implementar algo en realidad me va tomar poco tiempo me va a incrementar el tiempo no sé ponerle no más de un 10 % tal vez
Y el beneficio que va traer al futuro, grande, yo no lo consideraría over engineering. Si a vos te dicen, mira, nunca van a haber países, pero vos decís, nunca van a haber, pero los best practices me dicen que agrego una tabla de países, ¿no? Que haga la, las best practices te dicen que hagas agrupaciones lo más pequeñas posibles, obviamente sin afectar, sin afectar cosas, ¿no? Entonces.
lo peor que puede pasar es que tenga una tabla con un solo récord que diga Honduras, ya que estamos nosotros hablando de Honduras, Y eso es todo, y eso es todo. Entonces, si lo que nos va agregar de tiempo en hacer la solución es no más de un 5 o 10 % del tiempo para un beneficio a futuro, yo creo que pudiéramos tal vez no considerarlo over engineering en ese caso, ya si es algo que me va agregar 20, 30, 50 % más de tiempo,
por algo que creemos nunca usar, pues yo creo que ahí así sería Overengineering. Pero se me vino a la mente esa situación, la recorrute justo ahorita, fíjate, porque tiene que ver con escuchar el equipo y con que pongamos en la balanza en realidad cuánto tiempo le estamos agregando a la solución.
Juan (35:18)
Si es correcto, verdad es que hay ciertas tareas o soluciones que vamos a dar
y que no son sobre ingeniería, estamos preparándonos a futuro y es válido, en el caso de que mencionas, una tabla de países normalmente se va llenar una vez al momento de crearse y listo, ya no se vuelve a hacer nada más con eso también no estamos agregando complejidad tan grande porque pues una tabla de países es muy muy intuitivo de manejar
Así que sí, sí, creo que tenés totalmente la razón con eso de donde no estamos cayendo en sobre ingeniería. Yo creo Douglas que también a veces lo que pasa es que tenemos un cierto ego nosotros en el área de sistemas o de tecnología donde queremos realizar tareas o dar soluciones que son bastante complejas porque pareciera que eso nos hace ver como
más mejores profesionales o de alguna forma.
Lo puedo entender, sea, puedo entender que crear una solución que tiene muchas partes movibles y que está preparada para todo al futuro y todo esto pues se siente bien, ¿no? Lograr hacer algo como eso. Sin embargo, aquí estamos hablando de un ambiente empresarial, estamos hablando de un ambiente profesional donde tenemos que priorizar mucho los recursos que estamos utilizando. Entonces, yo creo que a veces entra en conflicto nuestro
ego yo diría te parece si avanzamos un poquito más y me gustaría hablar Douglas de las desventajas que como mencionaba la verdad creo que ya las hemos hablado pero pues las vamos a puntualizar más más concretamente
por qué es malo la sobre ingeniería que ya lo hemos hablado pero un punto del por qué es malo es porque agrega o nos hace tardarnos más en entregar soluciones o sea tal vez un feature o algo que debería tomarnos un par de días ahora nos va a tardar una semana dos semanas o hasta meses
y eso es porque estamos preparándonos para hacer algo. Hace poco estuve viendo una entrevista de un desarrollador de videojuegos y él está lanzando su nuevo juego que le tomó 10 años de desarrollo. El mundo del gaming se da esa situación en donde hay gente que se tarda 10, 5 años.
pero me llama la atención porque para lograr hacer su juego, el primero tuvo que hacer un lenguaje de programación tuvo que crear su propio motor de juegos y aquí venían las preguntas en la entrevista de por qué un motor nuevo, no utilizar lo que ya está en la industria Unity, Unreal, por qué un nuevo lenguaje de programación, por qué no utilizar C-charp, C++ o todo esto
Y bueno, él tiene sus motivos. de nuevo, esto lo que me lleva es a veces al agregar una sobriingeniería lo que estamos haciendo, empezamos a agregar complejidad extra y empezamos a hacer para llegar a la solución que tenemos, que es simple, empezamos a hacer otro montón de cosas que están alrededor de la solución que realmente tenemos que dar. Y bueno, eso creo que es una gran desventaja, no Douglas, el hecho de tardarnos demasiado en el mundo empresarial.
en el mundo profesional la verdad es que sí importa mucho el hecho de hacer despliegues rápidos. Ojo, tampoco hay que apresurarnos y llegar a hacer las cosas a la carrera, pero no tardarnos más de lo que deberíamos. Esa es la clave, lo que deberíamos tardarnos.
Douglas Barahona (39:19)
si y el beneficio aun despues no realmente no se cual es el caso particular que estas contando con este videojuego o que beneficios en realidad le trajo a el un lenguaje completamente nuevo solo para este juego si el piensa hacer juegos a futuro y ahora los puede sacar nuevos juegos en un año en lugar de 10 la verdad que no se no se me viene
Juan (39:45)
ojalá
Douglas Barahona (39:46)
tal vez no se me viene a la mente el caso de linux turbo el creador de linux que tenía problemas con svn para manejar el código del kernel de linux no y él les decía a la gente de svn que hicieran cambios no quisieron entonces él dijo bueno voy a hacer mi propio version control y así nació git y entonces pero la la el uso que ha tenido git no me refiero a la comunidad por supuesto nos cambió no
la mayoría de que estamos acá usamos Git, si alguien no usa Git, ¿por qué no? ¿Verdad? ¿Por qué usa otra cosa que no sea Git? Pero para lo que él quería, para lograr sus objetivos que es manejar el código del kernel de Linux, ¿no? El beneficio que le ha traído. aparte de que alguien como él lo hizo rápido, no le tardó 10 años, Pero me explico, yo creo que ese es el punto, ¿va? Lo que vos estás diciendo.
Juan (40:21)
No,
Douglas Barahona (40:42)
o lo que hemos venido hablando, la sobreingeniería nos agrega tiempo de más que en realidad no tuvo retorno de inversión. Y tal vez dejemos eso claro, no tuvo retorno de inversión y eso es sobreingeniería. Si al principio, como el ejemplo que yo di la primera vez que me preguntaste, me tarde más en planear lo es la implementación.
pero me ahorró el 80%, el 90 % del mantenimiento, entonces sí hubo un retorno de inversión. Y de hecho va a un retorno de inversión más grande porque termina haciendo más el tiempo que estamos manteniendo una aplicación, a medida que pasado los años, por supuesto, que el tiempo de la implementación. Entonces, si nos toma más tiempo el necesario, sin retorno de inversión, ahí fue un overengineering.
Juan (41:19)
Claro.
Sí, casi un desperdicio, podríamos decir.
si, si, si, actualmente y la otra ventaja que vos nos mencionaste hace poco era el mantenimiento costoso osea hay demasiadas abstracciones para realizar un cambio nuevo ahora tenemos que empezar a tocar múltiples archivos múltiples configuraciones incluso hay librerías que nos empiezan a crear conflicto entonces eso es una de las grandes desventajas de tener una sobre ingeniería
complejo, más de lo que debería, pues al futuro nos da esto. Y esto lo puedo enlazar con la última desventaja que tengo, que es la complejidad cognitiva. Es el hecho de que el código, una arquitectura o una solución va a ser muy difícil de comprender por parte de nuestros compañeros, por el resto del equipo. Entonces, el tener una complejidad muy grande implica un costo en el mantenimiento
y hace que el equipo ya no...
haya mucha fricción con las cosas o las soluciones que estamos entregando y es problemático Douglas y cada feature que lanzamos tiene mucha sobrengenería imagínate que cada vez que lanzas algo pues tenés que revisar las cosas que estamos haciendo me ha pasado donde he tenido ciertos compañeros que yo ya sé o que cuando él o ella o hace algo yo ya sé que cuando voy a hacer code review tengo que sentarme y revisar
porque es un poco más complejo de lo que a lo que yo estaría acostumbrado y nuevamente va de caso a caso no todo porque es complejo tiene sobre ingeniería va de casos a casos pero pues siempre que podamos yo siempre estoy a favor de tener soluciones muy simples que hagan lo que tenemos que hacer
No sé si se te ocurre alguna otra desventaja o te ha pasado alguna de estas cosas a vos Douglas al momento de trabajar en equipo.
Douglas Barahona (43:40)
Yo siento que las desventajas se resumen ahí. Obviamente para empresas como tal agregarles dinero porque más tiempo se traduce en dinero, no, agregarles dinero que resultan en pérdidas y otro tipo de cosas, O lo vemos, es fácil verlo cuando se trata de, ejemplo, obras del estado, por ejemplo, fuera de la programación, Cuando hay cosas que toman más tiempo en burocracia y eso que sería como un overengineering, agregarle pasos de más
a un proceso, eso sería un overengineering, ahí vemos el resultado y resulta y lo primero que alguien dice es pero yo te pago el salario, es lo primero que cuando uno se queja se enoja contra empleados públicos, yo te pago el salario, dice, ahí nos toca el dinero, ahí lo vemos, traigamos ese ejemplo a tecnología, verdad, pero se resumen en lo que hemos hablado y realmente que
Juan (44:12)
Ajá
Douglas Barahona (44:36)
consideremos si no queremos pensar en la empresa, los clientes, el jefe, en el dueño, pensemos en nuestros compañeros de trabajo, ¿verdad? Tal vez eso nos anima a tener esa conciencia. En alguna ocasión, hace tres años casi,
Juan (44:47)
Sí.
Douglas Barahona (44:54)
aquí en Field, antes de stand up, me tocó asistir a un proyecto que tenían de estos que he mencionado antes que estaban, que están en serverless, donde creían que todo funcionaba perfecto hasta que tenían problemas y buscan ayuda de alguien de sistema. Una cuenta de AWS.
corriendo un serverless, tiene lambda con funciones de node.js, elasticsearch para almacenar, application gateway y serverless. Entonces había que hacerle un audit para
ver cómo estaba el estado y crear una rutina, un proceso para estar actualizando. Porque ya tenía como dos años la persona que les dejó eso configurando y corriendo ya no estaba en la empresa del cliente, entonces nos pidió a nosotros hacerlo. Pero ellos querían solamente una o dos veces al año estar actualizando, pero eso es todo. Entonces, en lo que estaba haciendo la actualización me encontré
con que toda la infraestructura fue configurada y fue levantada con CloudFormation, es el Configuration Infrastructure as Code, perdón, de nativo de AWS, Todo está levantado con CloudFormation y...
Juan (46:01)
Ok
Douglas Barahona (46:13)
hace ya muchos años y actualizar ese cloud formation iba a tomar mucho tiempo y luego pues estar diciendo al cliente qué cosita cambiar para correr todo el stack y que hiciera actualizaciones de cosas para lo que el cliente iba a hacer iba a terminar siendo muy complejo. Entonces entre el reporte que yo entregué con mis sugerencias fue decir de este punto en adelante olvídense de ese stack de cloud formation.
y lo que hay, manéjenlo manual. Mira, esto es bien cualquier persona que ha trabajado mucho en el área de sistema, en el área de DevOps, ahorita probablemente se va a rasgar la vestidura, que dice, ¿cómo puede sugerir que lo manejen de forma manual en lugar de seguir con CloudFormation o haber creado otro tipo de automatización, sobre todo cuando es en infraestructura, Juanes? Eso se vuelve una herejía mencionar ese tipo de cosas.
Juan (47:06)
Sí, sí, sí.
Douglas Barahona (47:08)
Pero realmente que el cliente iba a hacer manejar la gran mayoría de eso, personas que no tienen conocimiento en infraestructura como tal y de ese punto en adelante fue tan bueno para el cliente que en realidad renovó contratos, nos pidió que nosotros...
Hagamos esos mantenimientos que se hacen cada seis meses, ¿no? Más bien resultó en más trabajo para la compañía porque ellos vieron que fue claro, simple, reproducible, lo pudieron entender. Si yo me sentaba al momento que les entregaba el reporte y les quiero empezar a explicar un stack de CloudFormation, yo creo que no hubiesen entendido la mayoría y por ende no hay un impacto y es que se nos olvida, Juan, vos decías algo, ¿no? Solo porque es complejo, no necesariamente es que está con overengineering.
pero tampoco solo porque es complejo no significa que es mejor y si le hablamos a alguien y no nos entendió no logramos transmitir el mensaje, logramos jalarnos hacia nuestro nado. Entonces ese es un ejemplo sobre todo en las personas que estamos en sistemas dependiendo del caso, dependiendo qué tan frecuente se va a hacer algo o qué tanto vamos a ir agregando.
Juan (48:00)
Sí.
Douglas Barahona (48:21)
no siempre es necesario automatizar con infraestructuras code o con configuración management. Desde que yo hice ese audit, hace tres años creo yo, en realidad que este cliente solo ha agregado una VM, una VM y que funciona como un proxy ahí rapidito que igual se hizo manual, igual se le configuró NGINX únicamente manual y no ha habido cambios, verdad. Entonces, si yo hubiese trabajado no sé cuántas horas.
en arreglar ese stack de CloudFormation, al pasar de los años, el mantenimiento, la suma de los últimos tres años ha sido no sé, qué, 20 horas, pues tenéle, verdad, me hubiese tomado más, probablemente arreglar el stack.
Juan (49:04)
Uy si, mucho más.
Douglas Barahona (49:06)
ese y siempre actualizaciones te toma tu tiempo correr el estátimo siempre toma algo de tiempo entonces consideremos esas cosas pensemos en la en nuestros compañeros o pensemos en las personas que van a estar manteniendo el producto aparte de nosotros no pensemos en que yo lo voy a hacer siempre porque en este ejemplo que yo te acabo de dar ellos tenían una persona que lo hizo con cloud formation probablemente pensando que él lo iba a mantener siempre y se fue a la empresa y luego el clavo le quedó a los demás entonces por ahí tratemos de considerar la situación
Gracias.
Juan (49:36)
sí sí
sí totalmente le ahí le diste el clavo es de pensar en todos la verdad en el equipo bueno estamos casi terminando y me gustaría hablar de lo que que hacer no para combatir esto pero antes de eso también me gustaría mencionar Douglas en sí pueden haber ventajas del over ingenier y bueno lo que te puedo decir es que no
porque la definición de overengineering es que estamos haciendo algo que está de más. que siempre cuando tengamos el concepto de sobre ingeniería estamos hablando de que estamos trabajando o dando una solución que es mucho más de lo que deberíamos.
pero bien, habiendo dicho eso Douglas lo que sí podemos decir es que hay ocasiones en las que esto puede puede darnos una ventaja a futuro tal vez no era lo ideal en su momento o bueno, nadie dijo nada o sea como decís, al inicio pues queremos hacer todo con las mejores prácticas y todo esto y tal vez un mes de tardanza no sea mucho
Y la verdad es que estuve investigando un poco Douglas sobre este tema y desde mi punto de vista hay dos cosas que siento que pueden ser rescatables. De nuevo, la sobre ingeniería no es buena, pero aquí estoy hablando en los casos donde tener algo complejo puede ser beneficioso.
y las dos cosas que yo he visto Douglas es que nos da una mayor robustez, una robustez extrema básicamente en nuestro sistema porque están pues en teoría tenemos todo muy bien hecho y está preparado para muchas cosas a futuro entonces mucho más robusto y a su vez eso lo que nos otorga es una alta escalabilidad entonces tal vez ahora nuestro por ejemplo en el tema de programación si tenemos una
estructura del proyecto muy bien pensada pues puede escalar muy bien a diferentes múltiples microservicios, aplicaciones, aplicaciones que corren en el background y todo esto pues a futuro puede ser ventajoso la verdad
Las otras cosas que estuve viendo pues en mi breve investigación no me convencían del todo, pero estas dos creo que sí Douglas, el hecho de tener una escalabilidad que tal vez al inicio no le vamos a sacar partido, no le vamos a sacar ninguna ventaja, pero cuando llega el momento vamos a decir, ⁓ se vieron, yo les dije que lo vamos a necesitar y pues sea como sea va, se va a agradecer, ¿no? Pero bueno, eso es lo que yo he visto, Douglas.
No sé, ¿qué opinas vos sobre este punto en específico?
Douglas Barahona (52:35)
Fija.
Mira, voy a discrepar un poco con vos. ¿De qué manera? Para mí, si algo, hay una diferencia entre tal vez, como se le dicen, future proofing, que es preparar tu aplicación para el futuro, que estés lista para el futuro o que pueda aguantar por muchos años.
Juan (52:41)
Uh-huh.
CC
Douglas Barahona (53:03)
lo más que pueda dar la tendencia actual, la tecnología actual, la versión actual, etcétera. Una cosa es future proofing y otra cosa es over engineering. Over engineering son funcionalidades que no vas a necesitar nunca. ¿Qué ejemplos vamos a dar? Voy a volver al ejemplo de la tablita de países. Eso no te agrega ningún tiempo.
Juan (53:14)
Exacto.
Douglas Barahona (53:28)
poco o nada y aunque hubiese agregado, ponéle un 5 % más al proyecto, en realidad está siguiendo best practices de como cosas mínimas a tener. Te estás preparando y aunque no vas a tener países a futuro, por lo menos te deja agrupar mejor luego reportes, ponéle, mínimo reportería en algún momento se va a beneficiar de eso.
Juan (53:38)
te estás preparando al futuro.
Douglas Barahona (53:52)
Si tengo una aplicación pequeña o un script, complejo, decido hacerlo en funciones. Hacer funciones y luego la llamo al final. Es el mismo código reordenado diferente, me le va agregar un 5 % de esfuerzo a lo mucho para analizar cómo las agrupo, pero es el mismo código.
Y a futuro si se le agrega más cosas o si decido de llamarlo en otro lugar, voy a agradecer que lo hice con funciones, pero eso no fue over engineering porque ya era un script algo complejo, solo lo estoy agrupando diferente y pensé en future proofing, pensé en el futuro, Pero no, yo no lo miro a nivel personal eso como una, como trabajo de más o como over engineering.
Juan (54:35)
correcto
Douglas Barahona (54:45)
Entonces, que vos hagas una aplicación y que penses en que pueda escalar, por pequeña que sea, para mí es un requerimiento hoy en día. Vos puedes pensar, ahorita solo necesito una instancia. Lo que voy a hacer es poner dos más pequeñas para tener alta disponibilidad. Ese es el consejo que yo doy. Si solo ocupas dos gigas de RAM, está bien, corre en dos instancias de un giga para que si te cae una, pues por lo menos la otra está un ratito.
Juan (54:56)
Mm-hmm.
solo que ahí
perdón que te interrumpa pero aquí tal vez con escalabilidad a lo que me refiero más que todo es que tu
aplicación o servicio pueda expandirse a futuro o sea puedes irle agregando más cosas sin romper nada y sin y que sea más fácil no de agregarlo más que todo por ahí va pero claro que tienes razón de que tienes que pensar en que tu servicio aplicación pueda escalar no de manera horizontal o vertical o como sea
Douglas Barahona (55:46)
Bueno, pero aún en lo que estás diciendo, hacerlo modular de cierta manera, tu código para mí no es over engineering, es solamente una base sobre la cual debe de venir lo demás. De nuevo, yo así lo interpreto, Juan, y para mí, por eso yo al principio decía, tenés que tener una lista interna de cosas que tienen que ser un sí, sí, cosas que no son reemplazables, ¿no? Como te decía yo, alta disponibilidad.
Juan (56:02)
Ok.
Douglas Barahona (56:16)
vos
escogés que todos tengan un repositorio y vos haces esa lista de cosas que no importa que tan pequeño sea algo va a cumplir esas cosas porque luego yo me voy y viene otro y él lo va manejar entonces desde esa base lo que va arriba de esa base
que no se vaya a utilizar nunca eso es over engineering en mi opinión y de nuevo tampoco nos vamos a matar a que si trabajé cinco horas de más en algo que nunca se ha hecho en la vida ⁓
Dame la espalda y latigarme yo solo, por eso no. Tal vez en su momento creí que sí, nunca se usó, está bien. Pero si le agregué 20, 30 horas de trabajo de más y nunca se utilizó, pues ahí sí fueron recursos realmente mal invertidos. Entonces, en esa es la parte en la que discrepo y es no que estés como tal equivocado, sino que yo no considero esas cosas que vos dijiste, over engineering. Yo las considero como parte del mínimo que debería de tener toda solución hoy en
día.
Juan (57:18)
Si, si tenes razón, por eso menciono que también, osea, si nos vamos a la definición correcta, cualquier situación donde veamos que estamos sobre aplicando overengineering, pues no hay ninguna ventaja en eso, siempre va a ser desventaja. Aquí creo que simplemente como que son estos aspectos que parecen que son overengineering en su momento, pueden ser beneficiosos a futuro, aunque como dije
tal vez en su momento digamos no pero esto simplificármelo mucho y vaya por ejemplo la lista de países que mencionas en vez de tener una tabla tengamos un archivo JSON y listo esa puede ser como una solución pero pues no eso no te permite escalar tanto o ser tan robusto entonces eso lo que yo veo como que puede destacar
con eso que mencionas de gastar muchos recursos, si recuerdo yo trabajar en cierta aplicación en esta empresa donde trabajábamos y le agregué todo lo que pude y era súper configurable, súper amigable con el usuario y nunca se utilizó. No sé qué pasó, no sé qué pasó a nivel gerencial que decidieron no utilizar la aplicación. Siempre recuerdo eso.
Douglas Barahona (58:41)
cambiaba de forma y todo.
Juan (58:44)
hoy me es algo que hasta el día de hoy me siento muy orgulloso de lo que hice pero pues nadie lo vio solo yo lo vi bien por último Douglas qué podemos hacer entonces para
Douglas Barahona (58:49)
Solo vos, solo vos sabés.
Juan (58:59)
para no caer en estos puntos de la sobre ingeniería o over engineering. Bueno, ya mencionamos las banderas rojas que hay que prestar atención, pero pues de nuevo buscando en internet, que dice la gente, a mí me gustaron tres conceptos que se manejan mucho en el mundo de programación y creo que funcionan muy bien a nivel general en el mundo de tecnología. Y son tres que tienen los, bueno, son los nombres, las siglas. El primero es Jackney.
significa en inglés significa you ain't gonna need it no lo vas a necesitar y lo que decías no
hacer algo que nunca se va a utilizar y uno cree no pero es que tal vez y si no está concreto la verdad es que no lo vas a utilizar no lo lo hagamos y eso a mí me pasa mucho yo suelo pelear con algunos developers que intentan agregar algo sabes que suele pasar mucho en programación Douglas el hecho de tratar de tener cosas muy genéricas por ejemplo si yo tengo una interacción con la base de datos bueno entonces agrego
tres capas de abstracción porque así si cambiamos de base de datos, si cambiamos de driver, si cambiamos de librería no hay problema de eso y la verdad es que yo en lo personal estoy muy en contra de eso porque cambiar de base de datos es es muy muy difícil y en el caso en que cambiemos lo que sucede es que no cambiamos agregamos bases de datos a nuestro sistema y ahora vamos tener que agregar dos cosas, dos repositoras, bueno es todo un tema pero bueno el Yagny creo que nos puede
dar una luz, el otro es...
Douglas Barahona (1:00:39)
Ese, perdón, rapidito, Juan, ese Jackne es el que más he visto pasar en el verso que tuvimos recientemente entre Kubernetes contra Docker Swarm, que muchas veces el argumento, yo lo mencioné en ese episodio, de, no, yo estoy preparando la aplicación para cuando necesitemos esto y llevan cuatro o cinco años y no lo necesitamos, entonces ese era Jackne.
Juan (1:00:48)
⁓ sí, sí, Kubernetes. ⁓
jajaja
Correcto.
Douglas Barahona (1:01:07)
En realidad
era que queríamos usar el Kubernetes y se complicaron la vida cuando Dockerson la resolvía.
Juan (1:01:14)
es correcto, cuando tengamos un millón de usuarios y aún siguen con 5 o 10 usuarios, pero bueno no es queja el otro concepto que se suele usar mucho es el de keys, keep it simple stupid
bastante agresivo en mi opinión pero bueno es ese mandamiento de siempre mantenerlo simple yo trato de aplicar mucho este siempre trato de en cada feature tenerlo más simple posible lo que mencionabas de que ya tener una serie de patrones que ya tenemos en nuestros servicios trato de utilizar lo mínimo de cada uno y listo evito mucho crear abstracción sobre abstracción
la verdad es que no trae ninguna ventaja a veces para el unit testing puede ser bueno pero en general yo lo evito con el tiempo me he dado cuenta que es mejor tenerlo muy muy simple y el último autoblast que creo que puede funcionar mucho
es tratar de hacer features en modo MVP. Minimum Viable Product. como el MVP lo que te hace es pensar, ok, ¿qué es lo que yo necesito? Lo mínimo que yo necesito. Y no sé si ya lo he mencionado, creo que ya lo he mencionado en algunos episodios en donde estoy trabajando, el producto con el que estoy inició sin front-end, sin página web. Simplemente se enviaban correos
de las métricas que tenían y así mucha gente empezó a suscribirse al producto ese era el MVP y uno diría bueno pero es que yo necesito tener la página web tener una landing page con animaciones y todo realmente es eso lo que necesitas en mi opinión creo que siempre es bueno mantener
lo mínimo que necesitas para que funcione tu aplicación, tu producto, la solución que estés dando. Con estos conceptos en mente yo creo que uno puede empezar a reducir la carga de complejidad que le vas a agregar al sistema de turno. Pero bueno, básicamente esos son los que tengo, no sé si se te ha ocurrido alguno Douglas.
Douglas Barahona (1:03:36)
Sí.
Juan (1:03:42)
o no sé si nos quisieras compartir o de alguna forma tenés en mente qué haces vos para no caer en la sobre ingeniería al momento en que estás trabajando tenés como alguna lista de reglas que tal vez tratas de seguir o algo como eso
Douglas Barahona (1:04:01)
Es interesante porque ahorita que hemos estado con la discusión y obviamente algunas cosas que mencionaba me traen recuerdos, se me vienen cosas a la mente. Nunca he tenido en mi estrategia pensar no hacer over engineering como tal así estructurado en mi workflow cada vez que hago algo nuevo. Pero mi pensamiento alrededor de cuando trabajo
alguna solución.
Sin darme cuenta, incluye el evitar el overengineering, que son los consejos que hemos venido dando, pensar en tus compañeros, pensar en el mantenimiento, quién le va a dar mantenimiento, aún cuando soy yo quien le va dar mantenimiento, pensar en cuántas horas le voy a dedicar al futuro a este proceso, a esta tarea, al actualizar, voy a hacer algo que para actualizar me toca bajar los servicios y reiniciar servidores o puedo hacer algo que sea más simple de actualizar.
El pensar en arquitectar algo de manera correcta es lo que normalmente me ayuda tener best practices no solo técnicos sino best practices de cultura DevOps. ¿Verdad? Pensemos eso, best practices de cultura DevOps, el developer tiene que entenderlo, el cliente, el stakeholder tiene que entenderlo, el project manager, tengo que trabajar bien con él. El entender ese tipo de cosas realmente me ayuda a no...
hacer ese over engineering en una solución y lo otro es entender la parte del negocio, como siempre le hemos hablado aquí, el entender que las cosas cuestan, que tiene un tiempo, que tiene un costo, que tiene que tener ganancias para la empresa, ese tipo de pensamientos de manera...
Juan (1:05:44)
Sí
Douglas Barahona (1:05:55)
No indirecta porque en realidad de manera directa me lleve ahí, pero sino sin estar pensando directamente en overengineering me han ayudado por los últimos no sé, ocho diez años tal vez en evitar el overengineering, ¿verdad? Entonces eso por ahí es lo que yo pudiera, ese es mi proceso de pensamiento que se los comparto para ver si algo de eso les sirve.
Juan (1:06:20)
Excelente.
Bueno yo creo que también eso habla Douglas de que bueno ya tenés mucha experiencia en este rubro lo cual te hace también tener como una intuición al momento de trabajar y yo creo que eso es algo que se va a dar a todos a los que nos están escuchando si sienten que tal vez bueno vienen empezando y aún no saben muchas cosas no pasa nada con el tiempo uno empieza a tener como cierta intuición en algún momento vamos a tener algún desliz
por decirlo así pero pues por lo general van a tener mayor experiencia para poder identificar estas cosas y poder aplicar las buenas prácticas y identificar los procesos de nuestro sistema
Bueno, sin ánimo de extender mucho más nuestra plática del día de hoy, espero que les haya servido y les haya gustado lo que hemos traído. Douglas, muchas gracias por compartirnos todas tus experiencias el día de hoy. También me gustaría agradecerle a la audiencia por llegar hasta este punto. Si llegaron hasta aquí, por favor comenten alguna situación donde aplicaron
engineering y si los regañaron o no bueno eso ha sido todo nos vemos a la próxima bye