¿Cuáles son ejemplos de ingenieros de software que complican demasiado las cosas?

Desarrolladores de aplicaciones que no entienden el diseño de la base de datos y ponen todos sus datos en una tabla cuando debería estar en 20. Luego lo extraen de la base de datos a la aplicación usando select * de myTable y lo recorren en la aplicación, en lugar de usando la consulta SQL adecuada para extraer ese valor que necesitan.

Desarrolladores de bases de datos que creen que entienden el desarrollo de bases de datos, pero no lo hacen, y usan 8 tablas cuando 3 lo harán.

Desarrolladores de bases de datos que entienden el diseño de bases de datos relacionales pero piensan que van a mejorarlo abstrayéndolo a otro nivel, colocando todo en una tabla y representando todos los datos como pares de nombre-valor. Parece genial para todos los novatos que lo hayan pensado, y es una tortura absoluta en la práctica. Escribir SQL para eso es un desastre.

Escribir una herramienta para hacer cualquier tarea menor. A veces, realmente necesita realizar una tarea solo una o dos veces.

Escribir su propia biblioteca en lugar de utilizar la biblioteca perfectamente depurada y útil de otra persona, solo porque le gusta programar.

Evitar herramientas porque están debajo de ti. “No uso Excel: soy programador”.

Encontrar el equilibrio puede ser difícil. A los programadores se les enseña a pensar a largo plazo y manejar casos que no son evidentes de inmediato. Pero esto también podría significar que un programador pasará una inmensa cantidad de tiempo “pensando fuera de la caja” para posibles casos extremos. El resultado es un montón de cosas que * pueden * suceder en un sistema, pero es poco probable que sucedan.

Un ejemplo absurdo que usaré solo para ilustrar el punto es el mundo físico. Solo tenemos 3 dimensiones de las que realmente debemos preocuparnos al colocar objetos. Crear un sistema para manejar la colocación en más de 3 dimensiones sería una locura (a menos que hagamos algunos avances en física …). Ningún programador haría esto.

Hay muchos ejemplos menos extremos, pero ser menos obvio aumenta las posibilidades de que un programador intente dar cuenta de ello. A veces, un caso puede tener sentido para un programador, pero el gerente de producto sabría que va en contra de la visión del producto y, por lo tanto, nunca sucedería. Es una de las muchas razones por las que los desarrolladores y gerentes de producto necesitan comunicarse a menudo. Tener en cuenta los teóricos que nunca sucederán complicará demasiado un sistema.