Cuando la libreta ya no era suficiente - La evolución de MakerERP

Cuando la libreta ya no era suficiente

En el artículo anterior contaba cómo empezó MakerERP. No empezó con una aplicación. Ni con una idea de crear una empresa. Ni siquiera con el nombre MakerERP. Empezó con una pregunta bastante sencilla:

¿Cuánto cuesta realmente hacer una pieza en una impresora 3D?

Y antes de escribir una sola línea de código, aquella pregunta terminó llenando una libreta. Una libreta con números, ideas, flechas, preguntas y cosas que probablemente hoy me harían sonreír. Pero funcionó. Porque aquella libreta me permitió pensar en el problema antes de intentar solucionarlo.

El problema es que llegó un momento en el que la libreta ya no era suficiente.

Una pregunta empieza a convertirse en muchas

Al principio todo parecía bastante sencillo. Quería calcular el coste de una impresión: filamento, electricidad, tiempo, desgaste, un poco de mantenimiento... y listo.

O eso pensaba. Porque en cuanto intentas hacer el cálculo de verdad aparecen preguntas:

Y entonces aparece otra pregunta todavía más interesante: ¿Qué pasa si quiero guardar todo esto para poder consultarlo después?

Ahí es donde la cosa empezó a cambiar. Ya no quería hacer una cuenta. Quería guardar información. Y cuando empiezas a guardar información, empiezas a necesitar organizarla.

La libreta empieza a llenarse

No recuerdo exactamente cuántas páginas terminé utilizando. Lo que sí recuerdo es cómo empezó a cambiar la forma de pensar en el proyecto. Al principio eran listas. Después aparecieron tablas. Después relaciones.

Una impresora tenía unas características. Un material tenía otras. Un proyecto utilizaba materiales. Una producción utilizaba una impresora. La producción consumía material. Y todo aquello terminaba formando parte de un coste.

Ya no estaba pensando solamente en una pieza. Estaba intentando representar todo lo que ocurría alrededor de esa pieza. Y eso es un cambio bastante importante, porque cuando intentas representar algo en papel empiezas a descubrir rápidamente qué cosas dependen de otras. Una flecha lleva a otra. Una decisión obliga a tomar otra. Y de repente tienes media página llena de conexiones.

Entonces apareció el problema de siempre

La idea empezaba a crecer. Y cuando una idea empieza a crecer aparece una tentación muy peligrosa: añadir cosas.

Cada nueva idea parece tener sentido. Si puedo guardar impresoras, también puedo guardar materiales. Si puedo guardar materiales, puedo controlar el stock. Si controlo el stock, puedo saber cuándo queda poco. Si tengo proyectos, puedo guardar sus costes. Si tengo costes, puedo comparar proyectos. Y si puedo comparar proyectos... bueno, ya sabemos cómo funciona esto 😂.

Cada nueva posibilidad hace que aparezca otra. Y en algún momento tienes que parar. No porque las nuevas ideas sean malas, sino porque si intentas construirlas todas desde el principio, probablemente no construyas ninguna.

Empecé a separar lo necesario de lo que simplemente era interesante

Creo que esta fue una de las primeras decisiones realmente importantes. No todo lo que podía hacer tenía que formar parte de la primera versión. Había cosas que eran interesantes, útiles, o que incluso me apetecía programar. Pero eso no significaba que fueran necesarias.

Y aprender a distinguir esas tres cosas fue bastante más difícil de lo que parece. Cuando desarrollas algo tú solo existe una ventaja enorme: puedes hacer prácticamente lo que quieras. Pero también existe una desventaja: nadie te dice que no. No tienes a alguien que te diga: "Eso puede esperar". Así que tienes que aprender a decírtelo tú mismo.

Volví otra vez a la pregunta original. ¿Qué quería solucionar? No quería construir un software enorme porque sí. Quería saber cuánto me costaba fabricar. Y para poder responder a esa pregunta necesitaba determinadas piezas: Impresoras, Materiales, Proyectos, Producciones, Costes, Stock. Y una forma de relacionarlo todo.

Eso empezaba a ser suficiente para construir una primera versión. No perfecta. No completa. Pero sí útil. Ahí empezó a aparecer realmente el proyecto. No cuando tuve todas las funcionalidades imaginadas, sino cuando entendí cuáles eran las mínimas que necesitaba para resolver el problema original.

Y entonces llegó el ordenador

Hasta ese momento había estado pensando. Ahora tocaba construir. Y aquí es donde empieza una parte de la historia que probablemente resulte mucho más familiar para cualquier desarrollador.

Abrir el ordenador. Crear el proyecto. Empezar a preparar la estructura. Elegir cómo guardar los datos. Pensar en las pantallas. Y descubrir que una cosa es tenerlo perfectamente claro en una libreta y otra completamente diferente conseguir que un ordenador haga exactamente lo que tienes en la cabeza.

Porque en la libreta puedes dibujar una flecha. El ordenador necesita saber exactamente qué significa esa flecha. Y ahí empiezan los problemas de verdad.

La primera versión nunca es la que imaginas

Cuando tienes una idea en la cabeza todo parece limpio. Todo encaja. Todo funciona. Hasta que intentas construirlo. Entonces aparecen los detalles:

Son preguntas que no aparecen cuando estás imaginando una aplicación. Aparecen cuando intentas hacerla funcionar. Y cada una obliga a tomar una decisión.

Empezar a programar también significa empezar a equivocarse

Esta es una de las cosas que más me gusta del desarrollo. Puedes pasar horas convencido de que una determinada estructura es la correcta. Y después descubrir que no lo es. Construyes algo, lo pruebas, te das cuenta de que no funciona como debería, vuelves atrás, lo cambias y empiezas otra vez.

Desde fuera puede parecer que has perdido el tiempo. Pero realmente estás aprendiendo algo que antes no sabías. Y eso ocurre constantemente. En MakerERP ha ocurrido muchas veces. Y seguirá ocurriendo.

Lo difícil no era hacer una pantalla

Otra cosa que descubrí bastante pronto es que desarrollar una aplicación no consiste en hacer pantallas bonitas. Un formulario, un botón, un listado... la parte visible es solamente la punta del iceberg.

Detrás de ese formulario hay datos, relaciones, reglas, validaciones, cálculos, errores que hay que controlar y decisiones que alguien tiene que haber tomado antes. Esa es probablemente una de las cosas que más cambia cuando pasas de pensar en una idea a intentar convertirla en software: empiezas a ver problemas que antes ni siquiera sabías que existían.

MakerERP empezó a dejar de ser una idea

En algún momento ocurrió algo que, aunque pueda parecer una tontería, para mí fue importante: aquello empezó a funcionar. No digo que fuese perfecto. Ni mucho menos. Pero algunas de aquellas cosas que estaban dibujadas en una libreta empezaron a existir en una pantalla.

Una impresora podía existir. Un material podía existir. Un proyecto podía existir. Y podía empezar a relacionarlos.

El código te obliga a enfrentarte a la realidad. Y la realidad siempre encuentra una forma de romper tus planes 😂. Pruebas una cosa y falla. Descubres que una decisión de hace una semana ya no tiene sentido. Aparece una necesidad imprevista. Por eso cada vez estoy más convencido de que construir un proyecto no es seguir un plano; es más parecido a ir dibujando el plano mientras construyes.

De una calculadora a algo más

La pregunta original seguía ahí: ¿Cuánto cuesta realmente fabricar una pieza? Pero ahora podía responderla utilizando información real.

Y eso empezaba a abrir otras posibilidades. Si puedo calcular el coste de una pieza, puedo calcular el coste de un proyecto. Si puedo registrar proyectos, puedo saber cuánto he producido. Y poco a poco, aquella pequeña herramienta para calcular costes empezaba a convertirse en algo diferente. Algo que podía ayudar a gestionar un pequeño taller. Ahí el nombre MakerERP empezó a tener todavía más sentido.

Pero todavía faltaba algo

Hasta ese momento había estado construyendo para mí. Y cuando tú utilizas algo que has creado, sabes dónde está todo. Sabes qué significa cada campo y por qué has colocado un botón ahí.

Otra persona no tiene ninguna de esas ventajas. En el momento en que alguien más entra en tu aplicación aparece la pregunta definitiva: ¿Entenderá esto alguien que no soy yo?

Construir algo que funciona es una cosa. Construir algo que otra persona puede utilizar es otra completamente diferente.

Y esa será la siguiente historia

Hasta aquí MakerERP todavía era, principalmente, un proyecto mío. Mucho código, muchos cambios y bastantes decisiones tomadas sobre la marcha. Pero todavía faltaba dar uno de los pasos más importantes: dejar que otra persona lo utilizara.

Significa exponerse. Descubrir problemas que tú no habías visto. Aceptar que, hasta que alguien que no eres tú lo utiliza... realmente no sabes qué has construido. Ese momento llegaría después. Pero antes tuve que terminar de hacer que aquella primera versión fuese suficientemente real como para poder enseñársela a alguien.

Y esa es precisamente la parte que contaré en el siguiente capítulo. Porque una cosa es construir MakerERP. Y otra muy diferente es atreverse a ponerlo delante de alguien y decir: "Pruébalo".