Enviarlo o morir (¿con o sin calidad, aunque?)

Una de las ideas que me intrigan es la mentalidad de "envíalo o muere". Con respecto a cómo se llama, hay variaciones de la misma, pero la idea detrás de la frase es simple:

Si tiene una idea, hágala pasar del concepto al producto lo más rápido posible.

Claro, la idea de llegar al concepto de un producto también puede llamarse "concepto a efectivo", pero nunca hay una garantía de que generará efectivo, ¿verdad? Sin embargo, hay una garantía de que puede convertirlo en un producto tangible.

Y en los círculos de desarrollo de software, siempre hay muchas cosas que una persona puede argumentar a favor o en contra de la idea. En mi cabeza, los dos pros y contras que me vienen inmediatamente a la mente son:

1. profesional _ Hacer algo rápido que funcione y que [potencialmente] genere ingresos.
2. estafa _ Arquitectura débil, mantenimiento, escalabilidad, capacidad de prueba, etc.

En resumen, puede haber una compensación entre la rapidez con la que puede enviar algo para un mercado y la arquitectura detrás del proyecto. A veces lo hay, a veces no lo hay. Sin embargo, en términos generales, creo que es seguro asumir lo primero.

Además, algunos pueden ver lo primero como la salida fácil, algunos pueden ver lo segundo como un ejercicio de YAGNI o, más simplemente, que el problema puede abordarse cuando surja.

Pero, ¿qué tiene esto que ver con nada en este momento?

¿Enviarlo o morir?

Toda la razón por la que estoy dedicando tiempo a escribir sobre esto es que es algo en lo que yo, y sospecho que otros en nuestro campo, pensamos al menos un poco. Todo esto está muy bien cuando se habla de ello en un sentido abstracto, pero permítanme tratar de relacionarlo con algo un poco más realista.

Érase una vez…

Hace unos años, el desarrollo front-end consistía en envolver el contenido en elementos en línea o de nivel de bloque y diseñarlos con CSS básico.

Teníamos herramientas avanzadas para trabajar con nuestro código de back-end, pero el front-end era relativamente simple, aparte quizás de los estándares de codificación impuestos por la empresa o el equipo con el que trabajábamos.

Pero entonces…

Nuestros dispositivos avanzaron (lo que, para que conste, considero algo bueno e incluso natural en tecnología). Junto con dicho avance, ahora tenemos herramientas de compilación específicas para el desarrollo front-end que son tan avanzadas en algunos aspectos como las que usamos para el software back-end.

Claro, tenemos algunos que son "desarrolladores de pila completa", pero estoy feliz de admitir que me siento mucho más cómodo trabajando en el lado del servidor que en el front-end. Si trabajo en la parte delantera, tiendo a ceñirme a las herramientas con las que estoy familiarizado y trato de mantenerme dentro de las barreras definidas por el carril en el que opero.

Ayuda a mantener el desarrollo enfocado, rápido y consistente en todos los proyectos.

Bien, entonces, ¿cuál es el punto?

En sí misma, esta sección podría ser una publicación larga, pero no me interesa ir tan lejos. En su lugar, tomaré una porción de cómo funciona el desarrollo front-end en este momento y veré si puedo usarlo para aclarar mi punto.

poniéndose descarado

Tomemos, por ejemplo, en qué se ha convertido CSS. Tenemos lenguajes encima de otros lenguajes (como Sass que se sienta encima de CSS básico o se suma a él).

Y tenemos procesadores que compilan, minifican, filtran y evitan que veamos nuestro trabajo antes de que se corrijan ciertos errores y advertencias por el bien de la calidad. (No lo considero algo malo, pero muestra el creciente nivel de complejidad, o quizás madurez, de nuestras herramientas de front-end).

El desarrollo front-end es demasiado fácil, hagámoslo más complejo para que podamos sentirnos más inteligentes entre aquellos de nuestros pares que aparentemente están lidiando con aspectos más "críticos" del negocio. Recuerda que esto es una competencia.

Este artículo tiene una versión humorística de todo el asunto.

Un grado razonable de calidad

Para ser claros, no estoy diciendo que esto sea algo malo, pero estoy diciendo que las cosas que antes estaban relegadas al lado del servidor oa los lenguajes compilados ahora se están extendiendo a través de toda la pila de desarrollo de una aplicación web.

Para ser lo más claro posible: estoy a favor de la calidad. Enviar cosas sin ningún grado puede verse como un ejercicio de irresponsabilidad.

Pero también creo que se debe lograr un equilibrio entre escribir el código más óptimo, funcional y de mayor rendimiento posible bajo las limitaciones de tiempo y presupuesto.

No creo, sin importar cuánto intentemos forzarnos a nosotros mismos, que vivamos en una utopía de desarrollador donde podemos optimizar, diseñar e implementar sistemas prístinos en cada proyecto.

Sin embargo, parece que nos hemos esforzado al máximo para crearlo, ¿no es así?

Pero en algún momento, ¿no vale la pena preguntarse si todas las herramientas que estamos creando y todas las cosas que estamos agregando a nuestros proyectos eliminan lo que nos metió en la industria en primer lugar? Por supuesto, para algunos de nosotros, esto es probablemente diferente. ¿Es justo preguntar que tener una idea, escribir un código para darle vida y verlo resolver un problema es lo que nos trajo al redil?

En este punto, sin embargo, hemos introducido tantas herramientas que poner en marcha un entorno de desarrollo para una aplicación web que se ejecuta desde la base de datos hasta el navegador es una tarea intimidante.

Tantas cosas tienen que suceder antes de que estemos realmente listos para comenzar a escribir código que puede volverse tedioso e incluso un poco agotador simplemente dando los pasos iniciales para hacerlo.

Una opinión personal y final

Me inclino por aplicar herramientas y prácticas sólidas orientadas a objetos en muchos de los proyectos en los que trabajo con mi equipo y que envío para otros porque sé, por experiencia, el tiempo, el dinero y los datos que se pueden perder si algo no es t abordado desde todos los lados.

Esto no quiere decir que enviar algo rápidamente niegue nada de eso. Pero el proceso y la organización del código detrás de un proyecto es algo que me resulta muy difícil ignorar, tanto que parece casi paralizante enviar algo que no ha sido probado y examinado en el mayor grado posible (e incluso entonces, hay problemas).

Sin embargo, por otro lado, hay una parte de mí que quiere experimentar con una idea o dos detrás de la mentalidad de "enviarlo o morir" solo para ver qué tan rápido se puede construir, enviar y generar cualquier tipo de ingresos, independientemente de cuán prístino sea. el código base es.

Y tal vez lo intente con algunos próximos proyectos.