¿Qué es lo más simple que se necesita?
Hay una cita a menudo atribuida a Albert Einstein que me gusta bastante (y estoy seguro de que a la mayoría le gusta):
Todo debe hacerse lo más simple posible, pero no más simple.
Hay alguna investigación sobre si lo dijo o no, pero el punto permanece independientemente de quién lo haya dicho.
Es fácil tomar esta idea y aplicarla a las cosas que hacemos en la vida cotidiana que no queremos hacer, ¿verdad?
- No quiero limpiar mi habitación, así que la ordenaré lo suficiente.
- Haré el trabajo suficiente para satisfacer a los clientes, y eso es suficiente.
- Cumpliré [cualquier responsabilidad] en [el menor grado posible] y porque Einstein [supuestamente] lo dijo, quién soy yo para discutir.
Aunque no estoy de acuerdo con eso (y la discusión sobre eso está fuera del alcance de esta publicación), considero esta idea dentro del contexto del desarrollo web.
Y para ser claros, no estoy hablando de diseño web. No soy diseñador. No quiero hablar en nombre de algo de lo que no soy parte. Pero con respecto a brindar soluciones para personas que usan software o, más bien, desarrollo web, estoy mucho más inclinado y posicionado para hablar sobre esto.
Estrictamente hablando, a menudo me pregunto si hemos hecho que el desarrollo web sea más complicado (y por qué lo hemos hecho) y si usar lo más simple que se necesita es todo lo que realmente se necesita al crear soluciones para otros.
Lo más simple que se necesita
Recientemente escribí sobre los diversos aspectos del desarrollo front-end solo (dentro del contexto de sacar algo de la puerta rápidamente) y cómo ahora tenemos herramientas de construcción estrictamente para ese aspecto de la pila de desarrollo web.
Cuando se trata de herramientas como esta, independientemente del nivel de la pila en el que estemos trabajando, me pregunto:
¿Es esta utilidad necesaria para facilitar de manera efectiva y positiva el desarrollo de la solución para otra persona?
Por ejemplo, encuentro que Composer es algo que es muy útil. Me permite administrar fácilmente bibliotecas de terceros, actualizarlas según sea necesario e incorporarlas a mis proyectos.
De manera similar, encuentro útiles las herramientas que examinan mis confirmaciones antes de enviarlas a GitHub porque me permiten detectar problemas de calidad del código que, de lo contrario, tomarían más tiempo durante el proceso de revisión del código.
Sin embargo, tome como ejemplo algunas de las herramientas de compilación front-end como Grunt, Gulp, Yarn, Node, Mix, etc. Para ser claros, algunos de estos hacen lo mismo que otros, mientras que otros tienen un propósito diferente.
El punto en el que estoy trabajando es este:
¿En qué momento las herramientas que usamos para el desarrollo obstaculizan nuestra capacidad para construir algo y entregar algo de manera efectiva?
Hay algo en nuestro campo que nos obliga a sentir la necesidad de permanecer a la vanguardia de la tecnología. Pero creo que hay que hacer una distinción importante: una cosa es ser consciente de una herramienta, pero una cosa es usarla.
Conciencia
Lo mejor de saber que algo está disponible es tener la capacidad de investigarlo y determinar si es de alguna utilidad para nosotros.
Esta no es una idea innovadora o nueva, pero es algo que creo que algunos de nosotros pasamos por alto. En lugar de investigar y evaluar, a menudo lo saltamos y vemos qué tan rápido podemos usarlo.
Poniéndolo en uso
La ventaja de poner algo nuevo en uso es que obtenemos los beneficios, o los beneficios esperados, que se supone que proporciona dicha utilidad.
El peligro en esto es que la herramienta puede no estar disponible en seis meses, un año o incluso dos años y las tecnologías que pretende mejorar pueden cambiar mientras no sigue el ritmo.
Por eso es importante mantenerse al tanto de dicha utilidad y, al mismo tiempo, determinar si es útil o no.
Acerca de esta cosa de la simplicidad
Sin embargo, volviendo a mi punto original, es este: si la cantidad de tiempo que le toma configurar, aprender, desarrollar, implementar y usar una nueva herramienta dentro de su flujo de trabajo, creo que vale la pena considerar si realmente vale la pena o no. tiempo en su pila de herramientas.
A los clientes no les va a importar si estás usando o no cualquier herramienta que estés usando. Están confiando en que usted será un buen administrador de la solución que le están pagando para implementar y parte de esa responsabilidad de ser sabio y diligente con su tiempo.
Si la utilidad que está utilizando obstaculiza dicha responsabilidad de alguna manera, es posible que no valga la pena usarla para un proyecto determinado.
Y eso es en última instancia a lo que me refiero: si lo que estoy usando me ayuda a crear la mejor solución posible sin hacerlo a expensas del cliente, entonces probablemente valga la pena usarlo. Con ese fin, el conjunto de herramientas más simple suele ser todo lo que se necesita y nada más.
De lo contrario, podría valer la pena examinarlo para usarlo en un proyecto futuro, pero no en el momento de su cliente.