Suggestions
đź‘‹ Vicenç GarcĂa-AltĂ©s
Software Developer
Vicenç GarcĂa-AltĂ©s is a seasoned software developer with over 14 years of experience in both academic and private sectors. He currently works at Cooltra, a company based in Sant Esteve de Palautordera, where he applies his extensive knowledge and skills in software development.
Professional Background
- Experience: Vicenç has a rich background in software development, having worked in various environments that include academia and the tech industry. His expertise spans multiple programming languages and technologies.
- Current Role: At Cooltra, he contributes to developing innovative solutions, enhancing the company's software capabilities.
Community Involvement
Vicenç is also active in the tech community, notably as an organizer for the BilboStack tech conference, which focuses on sharing knowledge and networking among professionals in the field.
Online Presence
He maintains a professional profile on LinkedIn under the username vgaltes, where he shares insights related to software development and engages with other tech enthusiasts. Additionally, he runs a personal blog at vgaltes.com, where he discusses various topics related to technology and programming.
Highlights
El otro dĂa comentaba por Twitter ( o X, o como se llame ) que si una empresa se dedica a vender un producto de software, algo bastante importante es hacer medianamente bien el software.
Creo que la (mal-llamada) excelencia tĂ©cnica es la base para que una empresa de producto funcione. Para mi es una condiciĂłn necesaria pero no suficiente para el Ă©xito de una empresa. Es decir, si no hacemos bien el software es muy difĂcil que la cosa nos vaya bien (y si nos va un poco bien, nos podrĂa ir muchĂsimo mejor), pero si lo hacemos bien no quiere decir que estemos acertando en lo que hacemos. Espero que se me entienda.
Pero ÂżquĂ© es hacer bien el software? Pues si nos centramos solo en la parte tĂ©cnica sin tener en cuenta la parte de producto, para mi serĂa algo como: poder desplegar software fácil de modificar a producciĂłn de manera continua y confiable.
Software fácil de modificar: que tenga el mĂnimo de complejidad accidental posible. Como le leĂa a Kent Beck el otro dĂa, que tenga el mĂnimo de acoplamiento posible para que un cambio en un sitio no signifique cambios en 12 otros sitios.
Desplegar a producciĂłn de manera continua: que desplegar a producciĂłn sea algo que no cause dolor. Que lo podamos hacer desde un commit o apretando un sĂłlo botĂłn. Que no cause una caĂda del servicio cada vez que lo haga. Que lo pueda hacer tantas veces al dĂa como sea necesario.
De manera confiable: que sepa enseguida si lo que estoy desplegando es correcto o no. Es decir, que tenga buenos tests y una buena observabilidad.
Obviamente todo esto depende del producto que estés haciendo y posiblemente del estado en el que esté tu empresa.
Seguramente me dejo cosas. Qué piensas tú?
Failure demand es la demanda extra de trabajo que tienen las organizaciones debido a errores generados por ellas mismas y sus productos. Por ejemplo, si tu sistema no se entera de que un usuario tiene una tarjeta caducada, esto puede llevar a tener que realizar un montĂłn de acciones manuales para paliar el error.
Cuantas organizaciones tienen equipos enteros dedicados a "mantenimiento" de las aplicaciones? Cuantos equipos enteros de Customer Service se podrĂan dedicar a otras cosas que no a paliar problemas generados por nuestros productos?
Como siempre, una mezcla correcta de una buena gestión de producto y el buen hacer técnico hará que tu failure demand se reduzca y puedas dedicar tu tiempo a aquello "realmente importante" ™ .
