¡Eyyy hola que tal dev, muy buenas! Bienvenido al canal, Aitor otra vez por aquí. Y hoy continuamos con los artículos del blog, donde iré dando consejos y cositas que no se pueden encajar en ninguna parte de los cursos.
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.
Cómo sabrás, mi nombre es Aitor y soy desarrollador de software profesional desde 2014 y hoy vamos a ver 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, este es El Círculo. Es mi newsletter donde te puedo enseñar desarrollo de apps móviles, aso y monetización. Por cierto, si te suscribes te regalo mi ebook Duplica los ingreso de tus apps en 5 minutos. No es broma.
P.D: Darse de alta es gratis y de baja, también.
Nota: si el video te gusta/ayuda agradecería que te suscribieras al canal, lo puedes hacer aquí, así sabré que el contenido que voy haciendo gusta a la comunidad y también es bueno para ti, por que te enterarás de cosas chulas dentro del sector, a parte de los cursos gratuitos.
Consultar estructura del artículo
1) Cuanto más rápido mejor
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.
2) Más gente significa más rápido
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.
3) Pensar que existe una solución única
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…
4) El desarrollo es lineal y predecible
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…
5) Los programadores solo han de programar
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?
6) Seguir la planificación al pie de la letra
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.
Información adicional
Si quieres seguir aprendiendo cositas de desarrollo en general, y apps en particular, te recomiendo mucho que te pases por mi canal de YT desde aquí. Hablo de todo lo que tiene que ver con el desarrollo de software y monetización de apps. No olvides suscribirte ?
Por otro lado, también es importante que te pases por “El Circulo” desde aquí. Es una comunidad que estoy montando alrededor del desarrollo de apps en la que te enseñaré a hacerte un sueldo programando apps móviles.
Sin nada más que agregar, me despido ya. Nos vemos en el siguiente artículo. ¡Hasta entonces, que vaya bien!