El síndrome del programador

Vale. Admítelo. Has caído en la trampa.

Imagina un día típico de tu rutina: tienes que construir un poco de material hardcore, código de algoritmos complejos...Hay un montón de librerías de terceros y herramientas que puedes utilizar, de pago o gratuitas. Tales herramientas pueden ahorrarte tiempo y energía y ayudar a que cumplas con una fecha límite. Podrías haber usado el trabajo de un tercero e irte pronto a la cama. Pero acabas “picando el código” de todo el proyecto por tu cuenta. “You keep coding and coding and coding...”. Hasta que son las 3 a.m.

Según Vangos Pterneas esto es lo que se llama"el síndrome del programador". Si como él, has llegado a construir el software prácticamente solo (y cumpliendo los plazos), la sensación que has sentido seguro es increíble. Has dado horas y horas a la creación de bibliotecas reutilizables con distintas características y aplicaciones. Incluso has contribuido a algunas de ellas en la comunidad de código abierto, por lo que otras personas podrían beneficiarse de tu trabajo de forma gratuita.

La construcción de un software es tu propósito principal, pero como dice mi compañero Miguel Catalan, hay que tener mucho cuidado cuando se trata de reinventar la rueda. En este artículo, vamos a tratar de averiguar cuando utilizar el código de otras personas es una práctica aceptable y cuando necesitas hacer todo el trabajo por ti mismo.

¿Por qué utilizar el código de otra persona?

Ahorras tiempo

Supongamos que quieres construir una tienda online para tu cliente o jefe. El sitio web es una instalación típica de WordPress. Puedes instalar y configurar algunos plugins gratuitos o de pago, o crear tu propio plugin e-shop . En este escenario, la ventaja de utilizar un plugin es bastante obvio: ahorras mucho más tiempo que la creación de toda la funcionalidad por ti mismo. Si los plugins disponibles contienen la lista de características que necesitas, entonces no tiene sentido volver a inventar la rueda.

El código es reutilizable

Hay un montón de soluciones de terceros por ahí, especialmente los de pago, por tanto, podemos integrar una gran cantidad de funciones que se pueden utilizar varias veces. Por lo general, este tipo de soluciones se construyen con la extensibilidad en mente, así que pueden caber en diferentes proyectos.

Evitas errores

La mayor parte de las bibliotecas de terceros son utilizados por una amplia gama de usuarios y desarrolladores, y han invertido una gran cantidad de tiempo para probar el producto. Si necesitas un elemento de gran complejidad para asegurar tus datos y sólo tiene un par de semanas disponibles, confiar en una solución probada podría ser el camino a seguir.

Actualizaciones y soporte

Las bibliotecas gratuitas, de código abierto y los paquetes comerciales suelen ser mantenidos por los desarrolladores individuales, apasionados o ingenieros que se les paga para su ampliación y actualización, asegurando que las soluciones serán viables incluso después de los futuros cambios tecnológicos. Los más importante, es que cuando se tiene un problema, podría haber un ejército de personas que podrían ayudarte inmediatamente. Muchos proyectos también tienen una comunidad fuerte de programadores independientes que te ayudarían sin costes. Los foros públicos, publicaciones de apoyo, e incluso StackOverflow o CodeProject, se pueden utilizar.

¿Por qué no utilizar una solución de terceros?

Las bibliotecas de terceros no siempre podrán salvarte el día, ¿verdad? A veces, tendrás que desarrollar tus propias soluciones, no importa el porqué. Aquí es donde el síndrome del programador viene muy bien:

Burocracia

Es común que en las grandes empresas y organizaciones pidan una herramienta especial para terminar el proyecto. El director del programa informa al gerente de departamento. El gerente del departamento solicita un presupuesto específico desde el departamento financiero. El presupuesto es aprobado, por lo que los administradores pueden proceder con la compra del software. Si todo el proceso toma dos semanas, quizás podrías haber escrito el software por tu cuenta.

Mala documentación

Incluso si descubres una solución que promete resolver tus problemas y acelerar el trabajo, tienes que tener mucho cuidado con la forma en que se puede utilizar. Si pasas más tiempo leyendo la documentación y encontrando la manera de salir de ella para desarrollar tu propia solución, entonces debes comprobar si hay algo más. Lo más probable es que, incluso si haces que funcione, los cambios futuros serán inalcanzables.

No hay soporte

Has encontrado una biblioteca que parece adaptarse a tu trabajo. Antes de usarla, recuerda revisar: ¿Qué tan activa es la comunidad que da soporte? ¿Recibe actualizaciones frecuentes? Hay miles de repositorios de GitHub que no se han actualizado desde el Jurásico.

Solo es necesario un subconjunto de características

Muchas herramientas de terceros y bibliotecas integran varias funciones. Sin embargo, rara vez (o nunca) las necesitas todas. Más características implican un mayor tamaño de archivo. Un tamaño de archivo más grande significa mayor tiempo de carga y más consumo de recursos. Eso podría resultar en mala experiencia de usuario.

El tamaño del archivo también es importante cuando se desarrollan aplicaciones para móviles. Apple permite hasta 50 MB, así que piénsalo dos veces antes de incluir esa biblioteca de 30 MB de la que solo utilizarás un subconjunto de características.

Entonces, ¿qué es lo que tiene que hacer?

He visto start-ups que gastan dinero para construir cosas triviales. ¡Eso es una locura! Cuando eres dueño de una empresa de nueva creación, el primer objetivo debe ser llegar al mercado lo más rápido posible. Si tienes el presupuesto infinito de Facebook, entonces bien, puedes ir por soluciones personalizadas de alta gama. Sin embargo, es probable que no seas Facebook. La creación de productos complejos a partir de cero no es viable cuando se necesita llegar al mercado tan pronto como sea posible. En tales casos, es mejor pagar un poco de dinero para "comprar" algo de código (y tiempo valioso), en lugar de pasar meses desarrollando algo por nuestra cuenta.

Fuente: Traducción de parte de un artículo de Vangos Pterneas.