Buenas prácticas y tutoriales

¿Pueden los desarrolladores reducir el coste total de propiedad del software con la IA? 

Atrás quedaron los días en los que comprabas un cartucho de Nintendo y nunca actualizabas su software. El mundo ha cambiado y el software también.

En lugar de vivir en su propia y diminuta (impresionante) caja gris y negra, el software vive en máquinas interconectadas. Tiene que reaccionar al cambio, tiene que adaptarse y por diferentes razones. Ya sea una actualización de seguridad ante un nuevo ataque o una actualización de funciones para mantenerse al día en este ecosistema cambiante. Hay que actualizar el software, hay que mantenerlo. Hay que reescribir el código, actualizar las dependencias y volver a desplegar las aplicaciones.

Esto no es gratis. Hay un coste continuo para mantenerlo desplegado de modo que siga aportando valor. Y cuanto más código haya que mantener, mayor será el coste, razón por la que a menudo se elimina código. Ahora la pregunta es: ¿Por qué eliminar un código que aporta valor? ¿Dónde está el valor en el código?

Evolución del código y del ecosistema de desarrollo

Para entender el valor del código, tenemos que hablar de abstracción. La mayoría de los desarrolladores no codifican con 0 y 1, ni siquiera de 0 a f (algunos todavía lo hacen). En cambio, los lenguajes de programación han evolucionado para permitir a los desarrolladores utilizar palabras reales en lugar de 0 y 1. El hardware ha evolucionado para abstraer en silicio lo que los desarrolladores habrían tenido que escribir. Los lenguajes de programación han evolucionado con el tiempo y siguen evolucionando hacia niveles superiores de abstracción para facilitar la vida a los desarrolladores. Hemos pasado de lenguajes de máquina de bajo nivel (lenguajes de primera generación o 1GL) a lenguajes ensambladores (de segunda generación o 2GL), a lenguajes de alto nivel más abstractos (3GL) como C o Java, a lenguajes más específicos (4GL) como R, SQL o PL/SQL, y a lenguajes basados en restricciones/lógica (5GL) como Lisp, OPS5 o Mercury. La cuestión es que cada generación abstrae más complejidad del desarrollador. Los 5GL se basan en la IA para crear solucionadores basados en problemas y condiciones establecidos.

Los ecosistemas de desarrollo han evolucionado a la par que los lenguajes de programación. Los desarrolladores no parten de cero al iniciar un nuevo proyecto. Utilizan bibliotecas, dependencias, bases de datos, plataformas de datos, sin código/con poco código. Utilizan software existente e interactúan con él. Cualquier cosa que permita abstraer código, cualquier cosa que signifique que al final siguen ofreciendo el mismo nivel de prestaciones con menos código escrito.

Reducción del coste total de propiedad (TCO) y mejora del mantenimiento

Empezar de cero sería prohibitivamente caro. Siempre recuerdo esto historia de la tostadora. Thomas Thwaites decidió crear una tostadora desde cero, sin ninguna de las abstracciones existentes. Lo hizo todo él mismo, desde extraer el mineral hasta fundirlo, pasando por todo lo que hay que hacer para construir una tostadora. Al final, la tostadora no funcionó y costó una cantidad absurda de tiempo y dinero. Se necesita toda una civilización para construir una tostadora. El software es lo mismo (aunque puede que aún no hayamos llegado a ese punto). Si quieres aportar valor, utilizas abstracciones. Menos código escrito significa menos código que mantener, lo que se traduce en menos dinero que gastar en mantenerlo, lo que se traduce en un menor coste total de propiedad.

El trabajo de un desarrollador es escribir código "heredado". Si tienes código heredado aún funcionando en algún sitio, enhorabuena, has aportado y sigues aportando valor. Una de las mejores formas de hacerlo es elegir sabiamente tu ecosistema de herramientas y dependencias o tus abstracciones. Utilizar una plataforma de datos en la nube moderna que admita múltiples tipos de cargas de trabajo y siga proponiendo otras nuevas, es una buena apuesta. Porque cambiar las bases de datos por el camino es costoso. No se trata tanto de mover los datos, sino de reescribir el código y mantener cosas nuevas. Y todos sabemos ya que cuanto más código se escribe, mayor es el coste de mantenimiento.

Impacto de la IA en el desarrollo de software

¿Qué tiene que ver con la IA? Ha habido mucho entusiasmo por los grandes modelos de lenguaje (LLM), y hemos visto aparecer nuevas herramientas que prometen escribir código por ti. Aunque esto podría reducir el coste inicial del desarrollo de software, ¿es esto realmente lo que quieren los desarrolladores/organizaciones/equipos? ¿Cuál es el coste de tener más código escrito que puede o no hacer exactamente lo que pedimos, que no ha sido escrito por nadie del equipo? ¿Cómo de difícil sería mantenerlo cuando podría haberse abstraído mediante la herramienta adecuada, la biblioteca adecuada? ¿Hasta qué punto será caro?

Considere ese código IA generativa son generadores de deuda técnica para 3GL, por ahora. Esto puede cambiar en el futuro a medida que se haga más preciso, y se mejore en el uso de las abstracciones existentes y los ecosistemas circundantes. Pero ahora mismo no está generando valor añadido, sino todo lo contrario. Tienes tantas formas de escribir código Scala como desarrolladores Scala (con 3GL estarías generando un montón de código "glue" o boilerplate - código que ayuda a interconectar las abstracciones que estás usando, o incluso que reemplaza lo que podría/debería haber sido otra abstracción, otra dependencia).

Ahora mismo es más interesante buscar en las 5GL existentes o utilizar la IA generativa para las 4GL, especialmente las de dominio restringido como SQL. SQL se adapta muy bien a la IA generativa porque su sintaxis es más sencilla. SQL es SQL. No es necesario mantener el código SQL tanto como con 3GL. Y al generar código SQL, el valor es directamente valor de dominio, valor de negocio. Eso es lo más importante. SQL es un punto intermedio entre 3GL y 5GL. Sigue siendo un lenguaje de programación como 3GL. Puedes seguir expresando lo que quieras, en lugar de los problemas y restricciones que tienes con 5GL. Hay una razón por la que todos los almacenes de datos acaban recuperando SQL. Y por qué SQL se sigue actualizando con nuevas características como estamos haciendo en Couchbase.

Conclusión

Si buscas reducir tu TCO, elige las abstracciones adecuadas. Y si buscas que la IA generativa reduzca tu TCO escribiendo código por ti, piénsatelo dos veces y asegúrate de utilizarla con 4GL.

Para reducir TCO y dispersión de datos, muchos las empresas eligen Couchbase. Pruebe Couchbase hoy mismo con nuestra aplicación gratuita ensayo.

Comparte este artículo
Recibe actualizaciones del blog de Couchbase en tu bandeja de entrada
Este campo es obligatorio.

Autor

Publicado por Laurent Doguin

Laurent es un metalero empollón que vive en París. Principalmente escribe código en Java y texto estructurado en AsciiDoc, y a menudo habla sobre datos, programación reactiva y otras cosas de moda. También fue Developer Advocate de Clever Cloud y Nuxeo, donde dedicó su tiempo y experiencia a ayudar a esas comunidades a crecer y fortalecerse. Ahora dirige las relaciones con los desarrolladores en Couchbase.

Deja un comentario

¿Listo para empezar con Couchbase Capella?

Empezar a construir

Consulte nuestro portal para desarrolladores para explorar NoSQL, buscar recursos y empezar con tutoriales.

Utilizar Capella gratis

Ponte manos a la obra con Couchbase en unos pocos clics. Capella DBaaS es la forma más fácil y rápida de empezar.

Póngase en contacto

¿Quieres saber más sobre las ofertas de Couchbase? Permítanos ayudarle.