El COSTE OCULTO del desarrollo de SOFTWARE 

Consigue NordVPN en el siguiente enlace! 👉👉 nordvpn.com/bettatech Qué sorpresas os habéis encontrado a la hora de mantener software? Contar vuestras anécdotas!

Totalmente de acuerdo. En mi vaga experiencia; la deuda técnica, el mantenimiento y el testeo son tres cosas que se ignoran muchas veces por cumplir con deadlines aparentemente inaplazables.

Genial el video, como siempre. Tuve un compañero que siempre que ofrecían duplicar el equipo para acortar la entrega de un proyecto decía "Nueve mujeres no hacen un bebe en un mes". ;-)

Hola 😄 0:28 - El equipo estima el costo del requerimiento 01:06 - Aparece una nueva funcionalidad. 01:48 - Aparecen preguntas como: ¿ésto no estaba ya terminado? 02:03 - Cada pieza de software que se hace, se debe mantener para siempre 03:33 - No solo el requerimiento consume tiempo, también el mantenimiento 04:08 - En grandes empresas una gran parte de desarrolladores está dedicada a mantenimiento 06:02 - Funcionalidad tras funcionalidad requiere mayor guardias/alarmas 08:03 - Para evitar estos problemas, tener en cuenta el tiempo de deuda técnica

Trabajé en una empresa donde existía un área dedicada sólo a dar soporte a desarrollos una vez finalizados. Es lo idóneo, aunque el ambiente de trabajo era tan malo que eso daba lo mismo.

Tengo un proyecto que tiene 4 fases, luego de extenderme mucho en la Fase 3, al cliente se le ocurrió hacer una fase 3A y me ha tocado trabajar en producción, corrigiendo errores de la fase 3 y la fase 3A y si, la pregunta que más me hacen es "Por qué esto está fallando si ya funcionaba?"

Acabas de poner en palabras super asertivas y ordenadas, toda la frustación que acumulamos la mayoría de desarrollos de software (en mi caso, del mundo analítico). Las empresas siguen dirigiendo sus objetivos estilo vieja escuela, y muchas de ellas usan metáforas del Scrum (todos conocemos la del patinete que tiene que convertirse en coche) para justificar deadlines ajustadas como pruebas de concepto, pero que luego no evolucionan y el mantenimiento es mayor. Eso si, el refactor nunca entra en la planificación de coste, ya que, "no aporta valor" al negocio. En fin, gracias por compartir un sentimiento que muchos vivimos dia a dia 😉

Qué buen tema. En mi empresa tenemos un sistema web que sirve para manejar todo tipo de operaciones de las distintas áreas. Somos 2 desarrolladores y nos piden funcionalidades nuevas bastante seguido. Tenemos que planificar y destinar un tiempo interesante solamente a reducir la deuda técnica derivada de sacar cosas nuevas y que funcionen rápidamente

Yo he escuchado a mucha gente comentar que la solución a este tipo de problemas es scrum y extreme programming, pero creo que siempre habrá esta problemática independientemente de la metodología de gestión de proyectos. Que complicado es hacer las cosas bien y planificar algo tan abstracto.

Cuando pasa eso en infraestructura es un dolor 😞 Te piden nueva infraestructura y mientras tanto la que ya estaba cuesta de mantener media vida, tocas una cosa y ale, todo roto. Y encima algunas veces no está documentado 😞

Buenas, lo de meter mas ingenieros para reducir los tiempos (un clasicazo), se le conoce como "La horda mongoliana", y resumiendo, la idea es que una embarazada gesta a un bebé en 9 meses, pero 9 embarazadas no gestan a un bebé en 1 mes. Saludos.

Eramos tres ingenieros y construimos un feature en 3 sprints de 3 semanas c/u, la empresa levantó una ronda y triplicaron la cantidad de ingenieros, ahora solo hemos sido capaces de mantener, porque el coste de la curva de aprendizaje de esos nuevos ingenieros es algo que no se tomó en cuenta. PS: más personas !== más velocity

Buen Video. En verdad muy identificado, algo también suele pasar con esa forma de trabajo es que en si la base de código es muy frágil cualquier mísero cambio explota el proyecto...

Muy buena la barra de debajo del vídeo indicando la duración de la publicidad para el patrocinador del vídeo. Muy creativo y útil.

Cuando entré con mi primer trabajo como desarrollador, me pusieron a programar en una versión de angular vieja, y si cambiaba algo, todo se caía en cascada, el código espagueti creo que es uno de los verdaderos problemas, tuve que migrar a las nuevas versiones y tenia que entregar avance el primer mes, no dormí bien, pero lo logré, agradecido con DDD y arquitectura hexagonal.

Como ha subido la calidad de los videos, crack!

una ves tome un trabajo de una aplicacion donde estaba bastante iniciado en el mundo y la hicimos entre dos, uno mas novato que el otro pero funcionaba y aparentemente no tenia bugs.. 6 meses despues la empresa de esta app nos llama y nos contrata como un equipo para generar nuevas aplicaciones; todo genial aprendimos en base a literatura y testeo propio y generamos muy buenos productos solo entre dos pero cada ves que nos tocaba hacer algun cambio a esta aplicacion inicial era un dolor de cabeza... pues al final nos toco reservar tiempo y generar una nueva aplicacion que a nivel visual se viera igual y la anterior llevarla al Dias Suprimir y shhhh nada mas que dos persona lo sabemos...

¡Buenísimo el vídeo! Si fuera inversor de startups obligaría a todos los equipos de producto de mis participadas a ver este vídeo todas las semanas, porque qué fácil de entender y obvio es lo que cuentas y qué fácil de olvidar es... 😅 Siempre pensamos que la solución es construir cuando quizás sea mejor destruir, la verdad que se destruyen pocas funcionalidades.

Lo que se cuenta en el video obviamente que sucede, no lo vamos a negar, pero también es debido en muchos casos a problemas como por ejemplo, el intrusismo profesional, al uso de tecnologías de dudosa reputación, el ejemplo que se ha puesto de NodeJS es claro como toda la mierda de frameworks que han proliferado en los últimos tiempos basados en JS, Vue, React, Angular... Antes de todo esto, tenias desarrollo web basado en en poquitas cosas con un back de verdad como .NET o JAVA que si que dan la talla. Ahora bien, que además no se tenga en cuenta en la actualidad mas que el Time To Market es respuesta la sociedad consumista que tenemos. Es decir, sucede como con la ropa LOW COST, que cuesta poco, aporta poco y dura poco.

4:52 Programador de RM Cobol en Modo Dinosaurio... "Yo ese problema no lo tengo"

Tan cierto y real como la vida misma Martín. Muy acertado el vídeo, muchas gracias!

Me llama muchísimo la atención el gasto económico que tiene él "pásate a internet" a una empresa, me imagino que muchas veces no compensa para nada. Acá en Suiza un Ingeniero mediocre te va a costar más de 10.000 Euros al mes (130K), solo en lo que él se lleva, más los aportes y la impresión es que si pasas de tener 4 a tener 8 se dice muy fácil, pero para la empresa tener 4 ingenieros más le cuesta más de 50.000 Euros al mes. Lo pienso así porque he tenido varios negocios y algunos de ellos negocios online. Muchas gracias por el video, ahora tengo una visión más clara de el por que de muchas cosas y también ahora entiendo el por que he visto que me he quejado de cosas que no funcionan bien en una App o de un extra que veo que necesita una App y luego veo pasar meses y no se agrega la funcionalidad o demorar meses en solucionar un problema que está dando. No es tan fácil y económico para la empresa el solucionar en tiempo y forma los "nuevos problemas" que vienen con las nuevas tecnologías online. Saludos 🇨🇭

Gran video, buena explicación!

Totalmente de acuerdo. En mi trabajo hay un producto de 20 años de antigüedad, con tanta deuda técnica en sentido de mala organización de código, archivos de miles de líneas, code smells y demás, que arreglar un simple bug, lleva días y no se diga de una feature porque uff.

Experiencias en mi empresa a la española: - test? Que es eso?, nada demasiados recursos, vamos a pelo. - cliente : quiero esto; los jefes: hecho, en 2 semanas; contexto: aplicación con 12 años y un equipo de 3 y un par de becarios; desarrollo: nadie aguanta más de 2 años, pero aprenden a hacer malabares - no es una startup, de hecho por tamaño es gran empresa, pero se le dedica muy poca atención al desarrollo porque no es la actividad principal de la empresa y por tanto se subestima y devalúa mucho el desarrollo por falta de líderes técnicos

Es interesante que lo llames coste oculto. Yo llevo un tiempo haciendo investigación sobre este tema y si bien lo que dices es mas o menos correcto, hay mucho mas que explica por que pasa lo que pasa. La única parte con la que no estoy de acuerdo es lo que llamas el coste de mantener la aplicación. Usar ese término implica entender la aplicación como un sistema inerte, lo cual, como has explicado, no es correcto. La gente acostumbra a considerar el desarrollo de software como sistemas inertes por que están acostumbrados a comprar, no a crear. La mayoría de los problemas que mencionas en el video tienen su origen en esa confusión.

Totalmente de acuerdo, lo veo a diario, pero además, estás teniendo en cuenta que el equipo no tiene rotación, que no se va nadie, por lo que no hay tiempos para formación de nuevos desarrolladores. En cuanto empieza la rotación, porque parte del equipo se va, aumenta la carga de trabajo al resto del equipo, aún entrando nuevos desarrolladores, ya que lleva un tiempo el formarlos y que estén al 100% integrados con el resto del equipo. Muy buen vídeo!!! Gracias

Para una estimacion de tiempo de desarrollo de un proyecto.. haz un analisis con la estimacion de tu trabajo en todas las tareas y multiplicalo por 2. eso te dara un tiempo mas realista. Ya que necesitaras el tiempo para pruebas, tiempo para correcion de errores y tiempo para implementar casos no contemplados. Con la experiencia ese tiempo estimado sera cada vez mas preciso.

Mas cierto imposible, esto es mas problemático si tenes una puesta en producción en semanas, y tenes que priorizar estabilización por sobre las tareas del sprint, luego tenes a los PM quejándose que la productividad bajo, o de porque recién se están descubriendo escenarios nuevos no contemplados y tenes que darles solución al instante. Y si a eso le sumas un cliente enorme y burocrático, que tiene que pasar por varios procesos para una decision ufff te la regalo

Has descrito totalmente mi dia a dia, a eso añadele a la presion del jefe de proyecto diciento ¿No lo has probado? ¿No estaba funcionando?.....y ademas pone tiempos de proceso muy cortos sabiendo que la velocidad de programacion de cada persona es distinta (entendimientos de conceptos, del codigo, lenguaje). Yo soy de poner un poco más de tiempo para asegurarme y si lo hago antes se ocupa ese tiempo en futuros arreglos o mejoras.

En android, en flutter, en todo haha siempre es un pain in the ass cuando el proyecto se abandona por más de 15 días, en ios las políticas cambia cada rato

Súper, súper identificat amb el què expliques!! Faig la segona app per la mateixa empresa i el manteniment de la primera és una bestiesa d'hores i, clar, el timing no s'està podent cumplir. És un aprenentatge per futurs projectes! 💪🏻

Que video tan bueno. Acabas de retratar la empresa donde trabajaba que siempre nos decian exactamente estas mismas cosas, con la Palabras exactas que has usado. Hasta el punto de que llegue a pensar que éra ineficiente y mal programador. Me has devuelto toda la confianza. Gracias crack

Estoy super deacuerdo con todo! aunque le agregaría algo que poco se habla y es capacitar a los nuevos y evaluar que pongo a hacer al que llega nuevo, obvio esto depende del nivel de la persona, pero como tu bien dice siempre como se mete gente se cree que eso acelara el proceso pero depende, muy bueno video, igual que los demás te sigo de hace tiempo y eres un grande, gracias por tu contenido!

Coincido totalmente, en mi empresa la gestión de los proyectos es un caos, los jefes tienen la ilusión de que lo tienen todo bajo control cuando la verdad es que planifican la semana un lunes, y no dan ni una de lo que va a pasar, lo que comentas es cierto, suele haber mucho problema con los tiempos ya que un proyecto se come el tiempo de otro, en mi empresa llevan la filosofia del "copia pega todo lo que puedas", para amortizar costes de lo ya desarrollado... Claro, eso conlleva que muchas veces llevemos a nuevas aplicaciones código hecho con prisas o con dependencias desactualiazadas. Es un jaleo

Excelente muchas gracias me sirvió muchísimo para diagramar un proyecto nuevo y estimar los puntos de historias de usuario !!! gracias bendiciones !

Gracias beta me motiva saber que hay mucho trabajo en esta area

100%. Ahora mismo me encuentro en un equipo que por tener deadlines para un ecosistema de productos, estamos un equipo de pocos desarrolladores corriendo haciendo varias aplicaciones. Si preveo que en un futuro cuando entreguemos todo, va a ocurrir un desastre a nivel de mantenimiento si los directivos no comienzan a ver el problema que esto supone. Estamos intentándonos como buena gente que somos estimar estos tiempos y hacerlos ver pero normalmente no los ven como algo que "imprescindible" o a lo que tengamos que destinar demasiado tiempo.

Si, es cierto, lo he visto en muchas formas, pero creo que un buen liderazgo y organización se puede lograr MVPs de mantenimiento y de funcionalidades, teniendo en cuenta que el mantenimiento es igual que la funcionalidad

la frase de los clientes que mas odio es: "se ve igual, no has hecho ningún cambio"....

en donde trabajo pasa mucho con las pruebas.... y pos se trata de trabajar con lo ya establecido no se piensa en actualizacion, lo cual es un problema a largo plazo y un gran problema...

Por situaciones como las descritas en este video, creo que estoy estudiando la carrera equivocada.

👋🏻 Hola me gustaría que hicieras un video de que sugieres estudiar para tener un trabajo como el tuyo, es decir saber que se necesita para prepararte para un empleo de ese tipo y como poder aplicar a una vacante de ese tipo, saludos 🖖

uno de los mayores problemas es, la cantidad de actualizaciones, por ejemplo net core, dios es una pesadilla, no como tecnología sino lo rápido que cambia, a eso le sumas la mantenibilidad , es casi imposible entregar un producto 100% actualizado, lo terminas en la versión 5 cuando entregas a producción ya hay una versión o dos nuevas .... es terrible.

La verdad es que sí. Nunca se considera el mantenimiento de funcionalidades anteriores o el costo de modificarlas para que no se rompa. De ahí sale el dicho "si funciona no lo toques". Muchas veces agregar una nueva feature es un dolor de cabeza, ya que debes modificar la arquitectura anterior, refactorizar código, etc.

Ufa yo quería una receta milagrosa! De todas formas muchas gracias por hacerlo visible!

Desarrollé software en una empresa por 14 años, tuvimos en desarrollo de un producto que solo le faltaba la caja. Cada vez que mi jefe vendía cerraba un negocio, la condición es que el cliente quería una nueva funcionalidad El producto se convirtió en algo inmanejable, y que tenía acumulado mantenimiento y deuda técnica Y terminé odiando la palabra "listo". Porque si algo está "listo", entonces no hay que mirarlo otra vez, porque está listo. De lo contrario no está "listo", no se puede entregar, y alguien miente... Y sí, al principio las solicitudes se despachaban rápidamente, pero luego esos costos ocultos arrastraban el desempeño ¡casi a cero!

Equivoxado: Las grandes empresas se la pasan desarrollando "actualizaciones de seguridad". ¿Cual es la Mayor O Inseguridad? Pues que un chichipío pueda realizar el trabajo que ellos cobran miles de dólares. POR LO TANTO LAS NUEVAS VERSIONES CON LAS QUE LOS DESARROLLADORES PEQUEÑOS TIENEN QUE TRABAJAR NO SON MEJORAS SINO "EMPEORAS", que consisten en restringir funcionalidades, de manera de sacar gente del partido.

Hermoso contenido, se fue directo al jefe. Gracias!

Cuando estás en una empresa sacando proyectos como churros tanto nuevos como mejoras la presión es horrible....

Gran video.! Es mi dia a dia.

Y que cliente va a querer pagar eso....??? No todos entienden... 😓

Y como tener una mejor planeación para disminuir la deuda técnica? Justo me encuentro con ese problema en mi empresa actual, somos alrededor de 50 ingenieros divididos en varios equipos y encontramos que aún no terminamos el soporte de viejas funcionalidades, cuando llegan nuevos requisitos y chocan con lo que ya está en producción.

Depende del tipo de desarrollo que se haga, antiguamente sobre todo en juegos al estar en cartucho olvidate de actualizar nada, se testeaba bien y san se acabo. Ahora con internet es un proceso eterno de mantenimientos parcheados, reparcheados, releases etc, etc, etc. En cuanto a las sorpresas pues tambien de todo desde funcionalidades ocultas que hay que desactivar porque se dejo para debuggin y siguen ahi, hasta garruladas maximas como definir mal el interface y tener que redibujarlo entero porque no se ve en el TPV... Un dolor de muelas los parchecitos de marras.

Bueno, primero lo primero, no se tarda más, se suman nuevas tareas, y en cuanto a lo de la deuda técnica y mantenimiento, las herramientas serias tienen plazos de 2 a 3 años en actualización. Que decirte, volver a hacer todo con C++ no suena tan mal después de todo

Completamente de acuerdo... Creo que el verdadero problema de eso es que no se diseña correctamente y se va un poco a lo loco, se buscan resultados rapidos... Y aunque si se necesita más personal en según qué casos, falsamente creemos que: si una mujer puede parir en 9 meses, pues contratas a 9 mujeres y que paran en 1 mes.

Todos los jefes deberían ver este video

Bien explicado. Requerimientos funcionales y no funcionales. El problema es que la mayoría del sector trabaja directamente con lo que le mandan, así que la perspectiva es funcional.

pienso lo mismo, por eso a veces se retrasan las entregas

Buen video, te queremos calvito!

Hola Martin, yo también soy backend NodeJS como vos, y estoy utilizando TS, que consejo me brindarías para seguir como backend (estoy aprendiendo microservicios y serverless) porqur quiero más experto en la materia, gracias y saludos.

Cuando fue que empezó tu alopecia? Ya desde tu etapa de universitario? Saludos topotech

Completamente de acuerdo!

Esto se aprende con sangre :)

Siempre se habla de los desarrolladores pero que pasa con QA Manual?.

Aun peor cuando la funcionalidad esta mal pensada desde negocio y hay que modificar todo (sin voverlo a hacer claro, por que "Lo que tenemos nos sirve")

Totalmente identificado con este video... Es un tema complicado para hacer entender a un usuario, no puede explicarse mejor. PD: Creo que hare un copy y paste xD

Genial y valioso video, gracias

muy bueno el video

Me pasa, debo construir un algo que no tiene un punto de partida, solo tiene un fin aparente que es muy vago. Se quiere de todo pero sin especificar el como

La empresa donde trabajo

Las actualizaciones de las librerías... Que pesadilla😓

Muy real.

Hi, l looking for my first job, thanks

Que va, si eso ensancha la industria pues mejor, mas trabajo

Clean Architecture, clean code y diciplina chicos! haha

Buen setup

El testing automatizado ayuda a reducir el coste así como el clean code.

Basal cost

eso pasa en todos los trabajos del mundo, bienvenido a la realidad

Hola

Cuidao con los sponsors Betta. NordVPN no es querida entre la comunidad haxor ❤️

Esa es mi vida

true story...

Hablas de meses... en las empresas donde he trabajado hablamos de dias u horas. (un desastre vamos)

Eshte tio

Menudo infierno

No eres tú al único que le ha pasado esto. 😉

Vpn? Jajajja. Sorry pero no... Configurar tor circuit, proxyxhains, nyx..... Te puedes config tus propios nodos de la DeepWeb... Y no hace falta instalar tor browser, solo tor. Service..... Es mejor q cualquier vpn.. Puesl as vpn te ls sirve un proveedor... Confiar en un proveedor???... No000.... Luego hay dbs por ahi con user y passwd filrradas.... Ahi lo dejo... Un saludo... Yo sin embargo, jamas recomendariauna vpn... Es como sentirse a salvo usndo Timofonica jjbabababab

la respuesta se llama scrum

@