Esto incluye decisiones de arquitectura, opciones de plataforma o cualquier situación en la que una mala elección haya tenido consecuencias negativas.
Esto incluye decisiones de arquitectura, opciones de plataforma o cualquier situación en la que una mala elección haya tenido consecuencias negativas.
Respuestas:
Hace años, era el desarrollador principal de una aplicación centrada en la base de datos que comenzó a arrojar errores. Lo rastreé hasta el hecho de que había valores duplicados en un campo de base de datos que no deberían haberlos permitido.
Me estaba castigando por olvidarme de establecer una restricción única en la base de datos cuando la había puesto en producción porque era tan obvio que este campo necesitaba una. Me compadecí de uno de mis compañeros desarrolladores que me corrigió ...
Otro desarrollador : "Oh, no lo olvidaste, había una restricción única en ese campo. Simplemente la eliminé".
Yo : "¿Por qué lo quitaste?"
Otro desarrollador : "Lo hice hace unas semanas. Estaba obteniendo archivos de datos del cliente y no me importaban porque la restricción única estaba bloqueando los nuevos datos. Así que eliminé la restricción para poder terminar de importarla".
Yo: "¿Dejaste de considerar que tal vez había un problema si recibíamos datos nuevos que se superponían con los datos existentes y pensaste en mencionarlo a alguien antes de importarlo?"
Otro desarrollador : (mirada en blanco)
Yo : Facepalm.
No estoy seguro de si esto cuenta como una decisión tecnológica , pero fui responsable de un sitio web de gestión de documentos similar a CMS escrito en PHP durante cuatro años. A lo largo de estos años, intenté varias veces hacer que las personas (gerentes, usuarios, solicitantes de funciones) tal vez, posiblemente, como, tal vez , consideren la posibilidad de sentarse juntos y pensar en los requisitos y la dirección futura de la cosa. Nunca sucedió. Siempre fue "agregar esta función", "agregar esa función", y todos ignoraban felizmente las diferentes formas en que todos los demás usaban el sitio web. Cuando me fui, se convirtió en un gran desastre de características interconectadas pero no relacionadas, y yo era el único en toda la compañía que conocía todas las características. Ahora nadie lo hace. Mwahaha
Reescribiendo un sistema de correo de voz de grado Telco.
El sistema anterior se ejecutaba en Unix y, a finales de los 90, apareció la tecnología COM de Microsoft. Muchos desarrolladores estaban trabajando en este nuevo sistema basado en NT. Después de mucho esfuerzo, su rendimiento aún no era tan cercano al del sistema Unix y un gran cliente que compró este nuevo sistema estaba enojado. La empresa tuvo que ser vendida y algunas personas tuvieron que dejar la empresa.
Fue feo. Todo esto sucedió unos dos años antes de que Joel escribiera su artículo: Cosas que nunca debes hacer, Parte I
Adoptar una biblioteca externa (en este caso, Spring RCP ) antes de su primera versión de lanzamiento, basada en una instantánea SVN. Está prácticamente garantizado que el proyecto terminará más o menos muerto y te encontrarás atado al cadáver. Bueno, en nuestro caso podría haber sido peor. Sigue siendo un gran riesgo.
Recuerdo que un ejemplo implicaba comprometerse con un servidor de aplicaciones Java en particular desde el principio a pesar del hecho de que aún no tenía las características requeridas para el proyecto, solo una hoja de ruta para cuándo se implementarían. Naturalmente, el proveedor no entregó tan rápido como se indicó originalmente, lo que debería haber sido un gran problema, pero en realidad fue solo uno de los muchos problemas en el lento camino hacia el fracaso.
La mayoría de los casos de este tipo de problemas con los que me he encontrado se han comprometido con una tecnología no probada / inmadura, a menudo porque alguien influyente en el aspecto técnico es un defensor del desarrollo impulsado por el currículum.
Hace tres años, nuestro departamento de BusDev dijo que tenían que construir su sistema de gestión de contenido en Documentum porque las compañías farmacéuticas a las que intentaban llegar conocían el nombre y se sentían cómodas con la tecnología. Así que gastamos mucho dinero para construirlo y luego lo archivamos 12 meses después.
En febrero de este año anunciaron que el nuevo sistema se basaría en Sharepoint 2010. ¿Quiere adivinar por qué? ¡Porque, de repente, ESTE era el nombre conocido por Pharmas y con el que se sentían cómodos!\\ uSlackr
Escritura de sistemas operativos modernos en C / C ++. Hemos sabido desde Morris Worm (finales de los 80) que es un lenguaje completamente inadecuado para construir software en red, pero eso no ha impedido que nadie lo haga, lo que básicamente equivale a negligencia criminal de la OMI.
std::string, pero funciona, y junto con las plantillas de clase de contenedor pueden eliminar una gran clase de posibles errores.
Lo que vi....
En la década de 1980, había una compañía llamada Prime que producía computadoras con una versión de la base de datos Pick y BASIC. El departamento de usuarios del lugar en el que trabajaba en el momento en que compró uno estaba absolutamente convencido de que esto les ahorraría muchísimo dinero, que obtendrían el procesamiento y los resultados que querían con un analista comercial en un trimestre. No pasó mucho tiempo antes de que hubiera cuatro analistas programadores a tiempo completo y un trabajo atrasado.
Gran error al estimar lo que la tecnología haría por ellos.