Aitor Sánchez - Blog - Oct. 26, 2023, 12:32 p.m.
Si alguna vez te has preguntado ¿qué mitos existen alrededor de esta profesión? Es una pregunta extraña, pero yo me la hice en su día, déjame decirte que este artículo es para ti.
Mi nombre es Aitor Sánchez, soy desarrollador de apps desde 2014 y hoy conocerás cuales son los 7 mitos más populares alrededor del desarrollo de software. También te daré unos pocos tips para superarlos si estás sumido en alguno.
Pero antes de continuar, esta es la Flutter Mafia. Es mi newsletter donde aprenderás desarrollo de apps móviles, aso y monetización junto con otros genietes que ya están dentro. Y si te suscribes te regalo mi ebook "Duplica los ingreso de tus apps en 5 minutos" No es broma, quizás te interese.
Por si te gusta más ver que leer, también en video aquí:
Oye, ¿no crees que deberíamos acelerar el desarrollo de nuestro proyecto? Si lo hacemos más rápido, terminaremos antes.
Es posible, que alguna vez se te halla pasado por la cabeza, o a tu jefe más bien, que los desarrollos cuanto más rápido se hagan, mucho mejor.
A ver, hasta cierto punto es así. Es cierto de que se puede hacer un servicio bien hecho en 20 horas y el mismo servicio en la mitad de tiempo.
Peeeeeero! lo que la gente no se da cuenta aquí es que, si el servicio se hace en 10 horas, el coste de mantenerlo será infinitamente mayor que el que se hace en 20. Y ¿por qué? Porque a posteriori te va a tocar rehacerlo cómo habrías hecho el de 20 en caso de que quieras escalarlo.
Para que te hagas una idea, este concepto tiene hasta nombre propio, se llama deuda técnica.
Pero no todo acaba ahí, a eso le tienes que sumar el trabajo que has realizado antes, las 10 horas más otras poquitas que hayas estado haciendo el trabajo con el servicio de 10 que tendrás que cambiar.
Por este motivo, mi consejo es que, aunque tardes un poco más en hacer una app/juego/pagina/servicio, por favor, abstráelo lo máximo posible para así después poder escalarlo e incluso usarlo en otros proyectos.
Debemos acelerar este proyecto. Si agregamos más personas al equipo, terminaremos más rápido, ¿no te parece?
Volvemos a conceptos de velocidad de desarrollo. Qué, en definitiva, es lo que les gusta a las factorías de software. Que saquemos trabajo más rápido y de mejor calidad que la competencia.
Bien, este caso de mito afecta, sobre todo, a las creencias de las empresas que tienen comerciales, o jefes, con un grado muy bajo de conocimiento técnico o prácticamente inexistente.
El pensar que un programa complejo se hará más rápido cuanta más gente meta las manos en él, es totalmente contrario a lo que sucede de verdad cuando se da este hecho.
Es más, hay estudios en los que se refleja que más de 7 personas con un mismo desarrollo, por cada una que esté por encima de este número, afecta de manera exponencial el tiempo de entrega.
Hay mejores formas de agilizarlo, en caso de que queramos meter a más, y mi consejo para estos casos es divide al elefante y después asigna los grupos. Veamos un ejemplo.
Necesitamos un sistema con un backend, frontend, api rest y aplicación móvil. No pongas a 50 personas a hacer todo, sería un error garrafal por que no habría forma de manejar este caso.
Paso 1, separa el elefante: Divide el trabajo general en tareas de menor tamaño que sean proyectos en sí mismos y que ninguno dependa de otro. Separa el backend cómo si fuera un proyecto propio, el frontend igual, la api restfull similar y la aplicación también.
Paso 2, asigna dos líderes de proyecto que se encarguen de manejar al resto de trabajadores y de cuadrar tiempos de desarrollo. Porque, por ejemplo, aunque la api y la app vayan por separado para programar la app hace falta la api.
Paso 3, revisa las capacidades de cada uno de los desarrolladores y ponlos en el lugar adecuado donde mejor puedan desempeñar su trabajo. Esto será cosa de los 2 líderes que hemos puesto en el paso 2.
Te aseguro que, si lo haces así, tardarán bastante menos en comerse al elefante que las 50 personas que hemos puesto en la zona superior. Te lo aseguro.
Estoy seguro de que hay un lenguaje de programación perfecto para todo. Si lo encontramos, podremos usarlo para cualquier proyecto.
Hay quien cree que existe un lenguaje maestro donde se pueda programar de todo, y de manera totalmente eficiente.
Pues déjame que te baje de tu burra si eres uno de los que piensa así, por que la diversidad aquí es máxima y cada cosa es mejor para su “cosa”, valga la expresión.
No existe un lenguaje que nos valga para todo de una manera totalmente eficiente. Lo siento…
Creo que podemos planificar con exactitud cuánto tiempo nos llevará desarrollar esta app. Si organizamos bien, no deberíamos tener retrasos.
Nada más alejado de la verdad, pensar que el desarrollo se puede predecir con exactitud sobre el tiempo que vas a tardar en realizar una tarea es totalmente imposible.
Se puede estimar, muy a groso modo, dicho tiempo. Pero es que no depende 100% de ti esta predicción.
Imagina que te piden una app que necesite un lector de código de barras, por decir algo, y cuando vas a incluir la librería esta ha sido actualizada de versión y no es compatible con, yo que se, con la api de los sensores…
¿Qué haces? No te vas a poner a programar un escáner de código de barras tal cual, sería totalmente inviable, pues te toca buscar una solución alternativa sumando un par de horas al desarrollo final.
¿Entiende por donde voy?
Al final, si no es esto será otra cosa. Qué un desarrollador se va de la empresa, que se ha jodido el server de desarrollo, mil cosas pueden afectarte que escapan a tu control…
Creo que el trabajo de los desarrolladores es solo programar. Si se centran en eso, todo irá bien.
Siguiendo con el artículo, hay gente que aún piensa que los DESARROLLADORES solo han de programar.
Bien, un desarrollador ha día de hoy si no entiende perfectamente lo que está desarrollando. Desde las bases hasta la parte más fina del diseño final, el producto que saldrá no es todo lo bueno que tuviera que ser.
Quizás en un pasado sí, pero eso quedo en eso, en el pasado.
No es necesario que sepas hacerlo todo, pero si salir de la caja y mirar le proyecto completo desde fuera. Por esta misma razón existen los briefing para los proyectos.
Saber, por ejemplo, que el proyecto va a tener aplicación, ya pone de manifiesto que el desarrollador va a tener que programar una api restfull para ella. Entonces cuando esté programando los servicios de la base de datos sabrá que tiene que hacer una api y hará su trabajo en consecuencia ¿Entiendes?
Tenemos que seguir el plan de desarrollo exactamente como está. No podemos desviarnos de los requisitos establecidos.
Continuando con el artículo, hay que decir que existe una creencia que dicta que los desarrollos se tienen que seguir al pie de la letra y ser totalmente inflexibles.
Si en algún momento se te presenta un proyecto con estos requisitos, o estás en una empresa que llevo esto al extremo, te aconsejaría que dejaras de lado ambos.
Más que nada, por que no se puede saber cómo va a ser el camino hasta que no empiezas a recorrerlo. Es muy difícil predecir lo que va a surgir detrás de la montaña si no tienes una perspectiva que te permita verlo.
En el desarrollo es similar, si los requisitos son inflexibles habrá tareas que no podrás realizar y, a parte, el producto final una vez sea expuesto no será, ni por asomo, lo que el cliente/comunidad querían.
"La tecnología avanza tan rápido... ¿Crees que debemos seguir haciendo las cosas como siempre en nuestros proyectos de software?"
A medida que la tecnología avanza, la demanda de mayor productividad y calidad en el desarrollo de software se intensifica. Este aumento es impulsado por el rol esencial del software en alcanzar objetivos comerciales estratégicos.
En el campo de la Informática, adaptarte a estos cambios no es opcional, sino esencial. Las metodologías de desarrollo deben ser ágiles y flexibles, permitiendo una rápida respuesta a las cambiantes necesidades del mercado y expectativas de los usuarios.
La calidad del software ahora implica agregar valor al negocio y mejorar la experiencia del usuario.
Por ello, debes mantenerse actualizado y alineado con las tendencias actuales, comprendiendo no solo las herramientas tecnológicas, sino también las necesidades comerciales para impulsar la transformación y el crecimiento.
Mira, en el momento que tu mejoras el logo de una app que tengas publicada en Google Play, las descargas y los ingresos que esta aplicación genera aumentan. Esto es así. Mejor logo es igual a más dinero.
Basándonos en esto, hemos creado esta herramienta que te permite evaluar, optimizar y mejorar los logos de tus apps para que reciban más descargas. No te quiero espoilear, dentro hay un video explicativo. Entra en el enlace.
Y ahora si geniete, nos vemos en el siguiente artículo. Espero haberte ayudado y hasta ese entonces ¡que te vaya bien!