Programadores, rendimiento de aplicaciones y ego

En esta entrada, me gustaría compartir y comentar alguna opinión personal respecto a ciertos hábitos del programador con respecto a la programación y el rendimiento de aplicaciones cuando codificamos.

Aspectos, algunos de los cuales me he encontrado.

Podemos discutir sobre calidad y rendimiento de aplicaciones desde diferentes planos y puntos de vista. El que yo voy a tratar aquí es bastante genérico (porque me llevaría a escribir bastante entradas para tratar con detalle cada uno de los aspectos que trataré), pero igualmente válido.

Comparativas odiosas

Hay multitud de comparativas cuando se trata de discutir entre cuál es el mejor lenguaje de programación y cuál es el peor.

Mucha gente cae en el error de indicar que el mejor lenguaje de programación es el más rápido.

Podríamos poner como ejemplo, la comparativa entre C# .NET Core y Java o si lo prefieres, entre C# y C++, o mejor entre C# y F#.

Y quizás no tuviéramos una respuesta bien formada, ya que aunque existen diferencias entre los benchmarks a usar para medir ciertos detalles, lo cierto es que afirmar qué tecnología, lenguaje, etc. es mejor, va a depender (por lo general y cuando no es evidente) de otras variables, algunas cuantitativas y otras cualitativas.

Un ejemplo de esto, para que se entienda mejor, es indicar que vamos a comprar un automóvil de alta gama, por ejemplo un BMW último modelo, mejor que mi querido Citröen C5.

Desde un punto de vista generalista, yo mismo admitiría que el BMW es mejor que mi querido C5 (corre más, tiene tecnología más avanzada, etc), pero si resulta que mis viajes son por carreteras secundarias y algún que otro camino rural, quizás lo que parecía una respuesta evidente, ya empiece a no serla o al menos, nos transmita alguna que otra posible duda, porque a lo mejor el rendimiento que ofrece mi C5 en esas vías, es mejor que el que me pueda ofrecer el BMW.

Como vemos, siempre vamos a tener una incógnita a despejar que nos hará dudar de qué es mejor que.

Dejarnos llevar por la moda de tecnologías, lenguajes, etc., es algo en lo que caemos frecuentemente todos (programadores, arquitectos, gerentes… etc).

Internet propaga muy rápido estas modas, y hace que estemos dando muchas veces bandazos de un lado al otro.

Las comparativas son por lo tanto odiosas, y a veces nos dejamos influenciar por aquella persona a la que admiramos o aquellos comentarios que nos han hecho en la oficina, o aquella persona que al hablar recita como un loro lo que ha leído y parece que sabe mucho cuando afirma categóricamente y sin fisuras ciertas frases que parecen entrecomilladas de un libro.

Rendimiento y ego

Pero centrándonos en una tecnología y lenguaje de programación único, obviando todo lo demás comentado anteriormente.

Al hablar de rendimiento uno puede pensar también que ganar unos pocos milisegundos no nos debería importar, pero no estoy para nada de acuerdo. De hecho, nunca lo he estado, y soy consciente que en mi vida como programador he llegado a modificar pequeñas porciones de código de otros compañeros en proyectos (siempre con buena intención) que han molestado a otros colegas programadores.

Sospecho (y por eso nunca me ha molestado que algunos no vean el porqué de hacer esto) que algunos habrán pensado alguna vez que estaba dilatando los tiempos de desarrollo haciendo cosas que asumían que no eran importantes o que incluso podrían llegar a considerar ridículas.

Los que me han preguntado siempre porqué hacía algunas cosas cuando cambiaba algo en el código, se lo explicaba y compartía con ellos mis conocimientos, incluso cuando ante una respuesta que yo consideraba evidente se me hacían más preguntas, terminaba casi siempre haciendo pruebas prácticas de rendimiento con esa persona para demostrar lo que argumentaba, pero creedme cuando digo que esas ocasiones lamentablemente han sido las menos.

Lo que nunca he hecho es dar respuesta a los que viendo que hacía cambios o modificaciones, no me preguntaban nunca, ya que entiendo que o lo saben y por eso no preguntan, o si no lo saben es porque no les interesa o simplemente por ego, porque el árbol que tienen delante no les deje ver el bosque que hay detrás.

En nuestra profesión, lo que hay en exceso es ego, y lo que falta es humildad.

Rascar dentro de un proyecto que puede tener decenas de proyectos unos milisegundos de un sitio y de otro, y luego de otro, y así unos pocos más, hace al final que la cantidad de milisegundos sea realmente apreciable.

Quitar medio segundo en un proceso, le puede parecer a muchos programadores ridículo, pero es una auténtica barbaridad. Quitar menos milisegundos de proceso, sigue siendo por lo general, algo a considerar y a reducir siempre.

Muchos se escudan en la velocidad de procesador, la memoria RAM, los tiempos, etc., para indicar que hacer esto no es útil o productivo, o que es poco práctico.

Deberíamos tender a reducir los tiempos, consumos, etc. siempre, pero en proyectos críticos con más ahínco como es lógico. Si como programadores estamos acostumbrados a ello, nos costará menos adoptar la mejor solución siempre o a recibir por parte de otro compañero o programador más experimentado, ciertos cambios que mejore el funcionamiento global.

Todo el rendimiento que podamos mejorar, hará que la respuesta de los procesos sea más ligera, el consumo de recursos y/o memoria y/o CPU más bajo, el número de peticiones de entrada al sistema más ágil, y la respuesta más eficiente.

Nuestra profesión no debería estar enfocada únicamente a hacer que algo funcione, sino a que funcione con la mejor solución posible, buscar la excelencia.

Muchos programadores tendemos a escribir código que haga lo que tiene que hacer, sin importarnos si tenemos Tests que lo cubran, o sin interesarnos si podemos hacer más eficiente o mejor nuestro código (no sólo covertura, naming, etc).

Hay empresas que quieren funcionar como una fábrica. Hay clientes que quieren resolver un problema lo antes posible sin importarle nada más. Pero hay empresas y clientes comprometidos con la calidad, asumiendo que la calidad tiene un precio pero muchas ventajas y ahorros.

Por otro lado, los programadores tendemos a creer que las líneas de código son nuestros hijos, y sólo nuestros, no del equipo. Este ego por creerte poseedor de un bucle, una función o una clase, es el error más grande que en mi opinión tenemos los programadores cuando trabajamos en equipo. Otro muy habitual es no admitir que alguien con supuestamente más o menos experiencia que tú, te puede enseñar algo que desconocías.

En muchos eventos, mucha gente dice que la calidad no es opcional.

Pero siento decirles que la calidad es opcional, otra cosa diferente es que no debiera serlo.

Hay muchos árboles (no uno sólo) ocultando el bosque que hay detrás, cambiar esto en nuestra profesión es complicado, pero para cambiarlo y transmitir las razones, tenemos que conocer y entender primero bien el porqué de lo que nos rodea, ser conscientes y tratar de poner encima de la mesa las mejores respuestas y soluciones posibles a los problemas con los que nos enfrentemos.

Si nos dejan o no… es otra lucha, pero no debemos bajar los brazos nunca por intentar hacer las cosas lo mejor posible.

¡Happy Coding!