faco escribió:todo eso que contais está muy bien, pero yo llevo 6 años en el mundillo y os puedo garantizar que muchas veces los propios analistas no quieren hacer las cosas de forma elegante, porque no hay ni tiempo, ni dinero, ni recursos y se conforman con la chapuza y el código sucio. Al final acabas aplicando parches sobre parches.
Cuando ni el cliente es serio con las especificaciones (ahora te pide una cosa y a los cinco minutos le pica un huevo y te pide lo contrario) es imposible ser serio. Cuando el cliente no cumple con los plazos pero a ti te los exigen acabas haciendo lo que buenamente puedes.
Y es bastante común los proyectos donde los requisitos se firman sin leerse siquiera, o directamente se aprueban DIAS DESPUES DE LA FECHA DE ENTREGA (no exagero). Y las broncas que te comes por estar dos días sin picar código y escribiendo en el cuarderno (básicamente analizando el problema y diseñando una solución) Proyectos planificados para 6 meses que a mitad del desarrollo se modifica el alcance y se alargan 4 años (o viceversa, que es peor)...
O cuando te reducen los plazos de entrega y no te da tiempo a hacer pruebas de integración (y luego la aplicación peta por todos lados), o cuando no hay documentación, o cuando nadie tiene ni idea de que narices hay que hacer...
Por muy buen programador que seas, en ninguna formación te preparan para el "metodo de trabajo" español. Lo mas importante es saber adaptarte a cada situación, hacer horas extras y saber mandar a tomar por culo a jefes y usuarios sin que se sientan ofendidos...
Práctica común derivada de la poca idea empresarial que en general se tiene en españa, donde se quiere todo para ayer, pero no eres ni capáz de especificar el qué quieres, unida al desconocimiento del coste de un desarrollo informático.
Si a mi me ha pasado, tener apps que vas metiendo cosas según los diferentes clientes lo piden, y por supuesto todos lo piden para dentro de un mes.... pero luego cuando les quieres soltar 7000 euros por una modificación a medida en tiempo record se quedan flipando. ¿Planificación? ¿Idea de producto? ¿Para qué? No se llega a ninguna parte con una idea de producto verdad ¿37 signals? ¿twitter?
País.
Eso si, la mayoría de la gente que conozco tampoco hace nada por evitarlo, que no hace falta mandar a los jefes a tomar por culo, muchas veces basta con justificar un poco las cosas.
Por ejemplo tengo un colega en una empresa que desarrolla una intranet y todos trabajan contra una base de datos de pruebas remota para desarrollar, lo que es a todas luces la grandísima chapuza:
- si alguien jode la BD (bastante probable ya que estás desarrollando) se joden todos. No es la primera vez que pierden 7 horas mientras levantan otra vez el servidor y restauran la bd
- Estas trabajando sobre una red: hooola latencia
- Entre compañeros se pisan los datos
Dime tú cuánto pueden tardar en instalar una bd local y hacer copia de la bd de desarrollo. ¿Dos horas? Integras las BDs todas las semanas y vas a ser mucho más productivo hombre. Eso lo muestras en un informe con un par de datos: simplemente con medir cuanto tarda la gente de media en depurar en remoto y local, tomar nota de los tiempos de downtime o del tiempo que pasas arreglando lo del resto, y les presentas un informe de 3 páginas en un segundo.
Si luego se limpian el culo con el, al menos ya sabes que hay que ir buscando otro curro.
Y más cosas, que tardaron 2 semanas en montarles un servidor de subversion, para luego mal usarlo ya que todo el mundo trabaja contra la rama principal. Hace bien poco uno marchó de vacaciones subiendo las cosas, se olvidó de meter algunos ficheros y cambió otros, y rompió la build entera. Un día trabajando a ciegas hasta localizaron al chaval para hacer que su código compilara, porque por supuesto, cada uno programa lo suyo y de la manera que le sale de las pelotas, sin convenciones de código, de nombres ni de trabajo. Y que veas que tu te esfuerzas en hacerlo bien mientras otro lo único que hace es cortar y pegar trozos de código repitiéndolo en mil lugares en vez de parametrizar, ya cuando no modificas métodos comunes para tu propia convenciencia jodiendo a los demás (modificar un método de enviar mail para que dentro del cuerpo accedira a la bds, genial!)
Pues yo ahí lo que haría sería proponer soluciones, no quejarse, además sería una manera cojonuda de ir destacando entre la mediocridad, y ni caso
después de sacarme la última asignatura (que se me había quedado colgada durante ya 3 años)...
. Lo que pasa es que claro... en el momento que me surje la necesidad de replicar cierto código en otra clase y cosas de esas... me planteo de inmediato que hay algo que no estoy haciendo bien, y me tiro 20 minutos modificando código cuando pienso que podría tirarme 1 minuto borrando bocetos en papel... Pero claro, esas contradiciones no se te presentan en el papel...
