MITOS EN EL SOFTWARE
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.
S 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
Hay gente que aún piensa que los DESARROLLADORES solo han de programar.
Bien, un desarrollador al 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? No va sobre
creatividad
La creatividad, por otra parte, es algo que normalmente es ignorado en el lo que
se entiende generalmente por programación. Es una parte esencial de ser
programador. Los programadores se enfrentan a muchos problemas y buscan
maneras de encontrar la mejor solución posible.
Tienen que ser rápidos, elegantes y no ser propenso a cometer muchos errores.
Hacer frente a esos problemas requiere pensar fuera de lo convencional. Además
el diseño y el layout también son normalmente parte del trabajo del programador.
Por ejemplo, si haces páginas web, el diseño va a ser de los trabajos más
importantes que hagas. Y eso es de lo más creativo que hay.
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.
7) Usando TDD se escribe código de más calidad
Uno de los pilares de la profesión es que usar la técnica de Test-Driven
Development o TDD nos hace programar más calidad. Con menos fallos y, por
tanto, con mayor productividad a la larga.
Cuando alguien se ha atrevido a poner en duda esta afirmación siempre se ha
contrargumentado que si no se consigue es por falta de práctica con la misma. No
se cuestiona la técnica sino la pericia del que la emplea. Sin embargo, cuando se
ha intentado probar científicamente esa supuesta mejora, no se ha obtenido
ninguna evidencia de que escribir tests antes del código nos haga más
productivos que escribirlos después.
Desarrollo guiado por pruebas de software, o Test-driven development
(TDD) es una práctica de ingeniería de software que involucra otras dos
prácticas: Escribir las pruebas primero (Test First
Development) y Refactorización (Refactoring). Para escribir las pruebas
generalmente se utilizan las pruebas unitarias. En primer lugar, se escribe una
prueba y se verifica que la nueva prueba falla. A continuación, se implementa el
código que hace que la prueba pase satisfactoriamente y seguidamente se
refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es
lograr un código limpio que funcione. La idea es que los requisitos sean traducidos
a pruebas, de este modo, cuando las pruebas pasen se garantizará que el
software cumple con los requisitos que se han establecido.
8) Cualquiera puede ser analista
• Saber que el “cliente” usualmente no es una sola persona, son varias, con
distintas expectativas del proyecto.
• Aterrizar la idea general del cliente a una definición clara y viable.
• Poder ofrecer escenarios posibles, dentro de las limitaciones tecnológicas y
de tiempo.
• Apoyar a que los interesados del proyecto entiendan cuál será el alcance y
limitaciones del proyecto (alinear expectativas).
• Respetar sus conocimientos del negocio y demostrar nuestro genuino
interés por ayudar.
9) Todos los informáticos son programadores.
Realidad: Actualmente se tiene la falsa creencia de que quien estudia informática
en la universidad (o por medio de un aprendizaje autodidacta recurriendo a otras
fuentes de contenido) es por obligación programador, a pesar de esto, se debe
considerar la informática en sí misma es muy extensa y contempla un abanico de
múltiples áreas que van desde el análisis de sistemas, administración de
servidores, desarrollo de software, bases de datos, hasta redes y gerencia de
proyectos.
Los profesionales de las carreras de sistemas, tecnología o software en algún
momento pueden llegar a tratar lo largo de su aprendizaje todos los contenidos
mencionados, pero, enfocándose a los ingenieros de software, ellos son personas
que suelen poseer un conocimiento técnico profundo y selecto puesto que
necesitan captar conocimientos muy puntuales que fomenten el desarrollo de la
lógica y la resolución de problemas, por lo cual es normal que una persona con
este rol no suela manejar temas de redes, soporte o administración de servidores,
ya que no son de su área de formación ni se desempeñan día a día en esas
actividades.
10) Para programar hay que ser un experto en matemáticas.
Para dedicarse a la programación, el conocimiento matemático adquirido en la
educación básica y secundaria puede llegar a ser suficiente. Solo áreas
específicas, como el desarrollo de juegos, la inteligencia artificial o la creación de
algoritmos de machine learning pueden requerir habilidades más avanzadas, pero
no es un requerimiento excluyente para programar, y aun así, siempre está la
posibilidad de implementar herramientas y bibliotecas (porciones de software que
otras personas ya escribieron y resuelven parte de los problemas que se
presenten a lo largo del proyecto) las cuales evitan tener que realizar expresiones
matemáticas complejas dentro del código y enfocarse en lo verdaderamente
importante. En resumidas cuentas, los conocimientos sobre matemáticas no son
directamente proporcionales a las habilidades que se tengan o se puedan llegar a
desarrollar para desenvolverse como ingeniero de software.
11) Si se quiere programar, hay que aprender el lenguaje que esté de moda
o el que mejor oferta económica brinde.
Realidad: Cada lenguaje tiene su propósito específico y se adapta mejor o no en
los diferentes proyectos de una compañía. De todas formas, diferente no es
equivalente a ser mejor o peor, por lo tanto, la verdadera pregunta que un
ingeniero de software debe realizarse no es: «¿Cuál es el mejor lenguaje de
programación?», sino: «¿Qué lenguaje es el más adecuado para solucionar los
requerimientos planteados dentro del proyecto?».
Ahora bien, el pensamiento de “¿qué lenguaje de programación es el mejor
remunerado económicamente?” provocará frustración al desarrollador llevándolo
nuevamente a la idea de que la programación es difícil, lo primero por aprender es
la lógica de la programación y el razonamiento para la resolución de problemas de
ese índole, y sólo después de eso, escoger el primer lenguaje de programación el
cual debe ir orientado especialmente a los gustos e intereses del profesional, lo
anterior ya que a algunos de los profesionales se les da bien el frontend, a otros el
backend, el big data, el machine learning, entre muchas más áreas en las que se
requiere implementar una solución de software.
12) Necesitas tener un título universitario
Realidad: Puedes convertirte en un desarrollador de software autodidacta sin un
título de cuatro años.
La programación es una de esas habilidades donde la educación formal no es
imprescindible. Puedes aprender por ti mismo a convertirte en un gran
programador al:
• Ver (o leer) tutoriales
• Tomar cursos en línea
• Unirte a comunidades en línea
• Construyendo tus propios proyectos
Cuando se trata de buscar trabajo, no es necesario ser un desarrollador
certificado. En cambio, necesitas tener muchas habilidades y pasión.
En mi opinión, tener un candidato que demuestre su experiencia con un montón
de proyectos geniales es más impresionante que un título sin ningún proyecto.
13) Un título universitario es una pérdida de tiempo
Realidad: Si bien un título universitario no es estrictamente necesario, puede
ayudar.
Las ventajas de tener un título incluyen:
• Las universidades y los colegios pueden ofrecer grandes oportunidades
para establecer contactos. Podría ser donde conozcas a tus futuros colegas
o cofundadores.
• Tienes profesores que pueden orientarte y guiarte en la dirección correcta.
• Los cursos universitarios marcan el ritmo, lo que puede ser útil si no eres
bueno en el autoaprendizaje o el aprendizaje a tu propio ritmo.
• La ayuda está disponible constantemente.
• Aprendes sobre una variedad de campos en informática.
• No te pueden quitar un título.
14) La documentación no es de valor, pero al mismo tiempo creemos que el
cliente revisará lo que hagamos
• Es cierto que aún sigue sin tener tanta importancia para nuestros clientes
como el código, pero se están sensibilizando de la importancia de la
documentación de los requerimientos y del proyecto.
• Estamos trabajando para que los procesos de validación sean más ligeros y
en consecuencia sí nos revisen el trabajo.
15) Los verdaderos programadores usan C o C++
Realidad: Todos los lenguajes son válidos y tienen una gran demanda.
De hecho, aprender C o C++ es mucho más difícil que aprender Python, pero el
hecho de que un lenguaje sea desafiante no significa que sea más valioso. Eso
sería como decir que el bádminton no es un deporte porque es más fácil de
aprender que el tenis. (No sé si eso es cierto o no; no me insulten, solo trato de
hacer una analogía).
Dicho esto, si bien Python es más fácil de aprender, eso significa que hay más
competencia en el mercado laboral.
De cualquier forma que lo mires, C, C++ y Python son habilidades valiosas
que tienen una gran demanda.
Independientemente del lenguaje que elijas aprender, la curva de aprendizaje será
empinada y la competencia será dura.
16) Pedir ayuda es vergonzoso
Realidad: pedir ayuda es esencial para ser un desarrollador eficaz.
A veces pedir ayuda será la única forma de superar los obstáculos que entorpecen
tu proceso.
Hay tantas cosas para recordar en la programación que no es factible hacerlo todo
por tu cuenta.
Es por eso que existen grandes comunidades construidas en torno a diferentes
áreas de desarrollo de software. Están allí para buscar soluciones colectivas y
ayudarse unos a otros. Si hay un error en tu código, reflexiona sobre ello durante
uno o dos minutos. Si no se te ocurre nada, entonces, cuando todo lo demás falla,
puedes buscar en Google el error para obtener ayuda.
Sería ineficiente desarrollar software sin pedir ayuda y tratar de resolverlo todo tú
mismo. Si estás trabajando como desarrollador de software, siempre deberías
poder pedir ayuda a aquellos que tienen más experiencia.
En mi opinión, un desarrollador hábil es alguien que sabe pedir ayuda pronto para
maximizar el progreso y que no se avergüenza de usar Google en el trabajo.
17) Todos los programadores son iguales
Los programadores son personas y todas las personas son diferentes, dentro de
los estilos de programadores que hemos ubicado están:
Según algunas empresas, a un desarrollador principiante le lleva 5 veces una
actividad, en comparación con un experto.
18) Programación Orientada a Objetos vs Programación Estructurada
Todo lenguaje de programación tiene un paradigma o paradigmas múltiples sobre
los que opera. Estos proporcionan diversos conceptos a través del cual los
elementos de un programa pueden ser representados y manipulados
En pocas palabras, la programación orientada a objetos es un estilo que trata
los datos como objetos con atributos y métodos que pueden aplicarse a estos
objetos y también ser heredados por otros objetos. La programación
estructurada, por otro lado, es un tipo de programación imperativa, donde las
declaraciones se ponen en procedimientos, que se pueden volver a llamar cuando
sea necesario. C usa programación procedimental.
19) Fallas en la medición
Es posible medir los principales atributos que forman o caracterizan a un software
de buena calidad. La idea aquí es que la calidad del software se caracteriza por
ciertos atributos: fiabilidad, flexibilidad, robustez, comprensión, adaptabilidad,
modularidad, complejidad, portabilidad, usabilidad, reutilización, eficiencia...., y
que es posible medir cada uno de ellos, y por consiguiente, caracterizar o medir la
calidad del software en cuestión.
Se puede termminar midiendo la altura de un tanque de agua cuando lo que se
desea medir es su volumen.
20) si el proceso de fabricación es de calidad, el software resultante debe ser de
calidad
En disciplinas antiguas (fabricación de bisagras, curtido de cueros, fabricación de
vino, cocinar alimentos) don- de hay experiencia de cientos de años, que además
están apoyadas en ciencias sólidas (Física, Química...), es posible diseñar un
proceso que garantice la calidad del producto (un proceso que produzca cueros de
buena calidad, digamos). Y también es posible me- dir (objetivamente) la calidad
del producto resultante. Y adaptar el proceso, modi- ficándolo, para corregir
errores en la calidad, por ejemplo, hacer un cuero más elástico.
El problema es que no es posible hacer esto en software, porque no se sabe qué
procesos son buenos para producir software de buena calidad, y porque no se
sabe qué parte del proceso cambiar para, digamos, producir software con menor
complejidad, o con mayor portabilidad.
21) La complejidad de un programa (qué tan fáicl es entender el código) se mide
contando el número de anidaciones en expresiones o postulados (“complejidad
ciclomática”).
La estructura, indexación del código, el tipo de notación para definir y llamar
variables, la complejidad del proyecto, los recursos disponibles, el tiempo y el
presupuesto, así como las preferencias y experiencias del equipo de desarrollo
entre otras, son aspectos a tener en cuenta
22) La facilidad de uso (ergonomía) caracteriza a los programas que no cuesta
traba- jo aprender, que se amoldan al modo intuitivo de hacer las cosas. Se mide
ob- servando la cantidad de pantallas que interaccionan con el usuario, y su
sofisti- cación.
