Luis Lira, escribiendo en su nuevo blog:

Over Engineering es cuando nos gusta complicarnos la vida, algo como ser masoquistas, pero programando. Cuando estamos creando un proyecto y queremos sufrir por voluntad propia porque para un problema sencillo usamos una solución compleja. De hecho, este sitio es una muestra de eso.

En mi pueblo hay un dicho: salió más caro el caldo que las albóndigas.

Continúa:

Este Portafolio/Blog que hice aproximadamente en 10 días — aunque aún le falten cosas — pude haberlo hecho en unas horas y solo con unos cuantos clics, comandos en una consola o simplemente pagando una suscripción en algún sitio que me diera todo esto listo.

En vez de irse por la solución “integrada”, Luis decidió experimentar ensamblando su blog manualmente.

Se dice que algo está over-engineered (o diseñado de más) cuando la solución tiene cuesta más (tiempo, recursos, esfuerzo) que el problema mismo. Pero existe una distinción importante que me gustaría recalcar: construir algo desde cero cuando existe ya un paquete que resuelve el problema no es hacer over-engineering.

El término over-engineering es inherentemente negativo. Expresa que el diseño de tu solución está over, o de más. Es inútil, extra. Te lo pudiste haber ahorrado.

Lo que está haciendo Luis es algo sumamente positivo: tomar un problema que pudo haber resuelto con unos cuantos clics, desmenuzarlo y explorar creando una solución que se adapte exactamente a lo que él quería. Eso no es over-engineering, eso es engineering. 

A través de este ejercicio, Luis no solamente está aprendiendo y explorando nuevas herramientas de desarrollo, sino que está razonando un dominio de problema al que no estaba expuesto anteriormente. Este razonamiento seguramente le ayudará a comprender mucho mejor 1) la complejidad real del problema, y 2) la toma de decisiones que juegan un papel importante en hacer que WordPress, Ghost, Tumblr, etc., sean exitosos.

Eso es verdadero aprendizaje.

La cultura de desarrollo de software actual empuja a las personas a creer que entender las premisas básicas de los problemas que resuelven es algo negativo. ¿Para qué invertir tiempo en eso, si ya hay un paquete de JavaScript que lo resuelve? Sin embargo, es refrescante ver que aún hay personas que intentan comprender el problema antes de obviar el entendimiento del mismo y correr a implementar soluciones sin fundamentos.