Barrapunto

Aun recuerdo estas palabras de un profesor en mi primer curso de carrera: "No creais que vais a salir ahi fuera y os van a dar un proyecto desde cero para que hagais desarrollo, el 90% del desarrollo software es parchear el trabajo de otros que a su vez parchearon el de otros" Salvo en contados casos los pasos de creacion y ciclo de vida de los productos software se ven salvajemente alterados y, en muchos casos, ignorados por las prisas que exige la competitividad y, por que no decirlo, las absurdas ideas de la cadena de mando que, a menudo, es gente de perfil netamente comercial que se dedica a vender lo que otros tendran que implementar en un tiempo record (y, por tanto malamente)y muchas veces ni saben los fundamentos de un buen desarrollo software. En fin desastroso... como en todas partes.

O peor todavía, cuando los desarrollos se encargan a "aficionados" (como yo mismo) que vale, si, sabemos programar porque nos gusta y tal y cual, pero tenemos que aprender los rudimentos de la organización y planificación a cabezazos.

¿Y porqué se tienen que hacer las cosas así? Porque si se contacta con el departamento correspondiente de la empresa te envían, con suerte, a un becario mal pagado a hacer el análisis del problema, y el desarrollo de la aplicación se subcontrata a otra empresa que cobrará un chito por un programilla (que escribirá otro un becario igualmente mal pagado) que no vale de nada, pero que es con lo que habrá que tragar (a todo esto pongamos que se tarda un año desde que se pide la aplicación hasta que se empieza a implantar y al menos seis meses hasta que aquello ya "funciona razonablemente")

Por eso muchos jefes de departamento prefieren desarrollar sus propias herramientas "de andar por casa" que ni se ajustan a estándares y dan más pena que otra cosa, pero que resuelven sus problemas.

Mucha, mucha verdad en lo que dices.

Uno sale de la Escuela pensando en que va a mandar cohetes a la Luna -como mínimo- y al final termina embrollado en una función que lee un fichero ASCII en no se sabe qué formato (ya sabéis, scanf's temibles) y encima buscando los errores que cometió algún incompentente... e introduciendo otros de forma inopinada.

La causa de todo esto: aparte de que no se mandan tantos cohetes a la Luna, las presiones a la hora de confeccionar las ofertas generan proyectos malditos antes de nacer, con plazos de entrega imposibles, con "mejoras" que se suponen son triviales y que al final terminan siendo cambios estructurales, y por supuesto con sueldos de risa, jefes que se dedican a todo menos a organizar el trabajo del equipo (no hay nada peor que un jefe que no se acuerde de que ya no programa)...

---

Si el trabajo lo hizo un gilipollas entonces el trabajo debe ser mantenido sólo por el gilipollas porque él sabe mucho de lo que ha hecho y por eso lo cuida bien.

Si el trabajo del gilipollas despedido es para mantener sólo el otro imbécil entonces el imbécil se cabrea porque tiene que empezar a repasarlo desde 0 con la pérdida de tiempo de no hacer nada en la programación, y ahí era lo invisible del trabajo.

Y ademas los "eviadores de becarios" les dirar al los "receptores de becarios" que el recurso (jodia palabra) es experto en eso.
La buena planificacion y diseño se acaba al tercer dia de proyecto, es inmantenible un diseño con todos los cambios que surgen

Llevo casi 6 años trabajando como informático, los primeros 5 desarrollando software y **NUNCA** he visto ningún sitio en el que sigan un método para desarrollarlo: cada uno codifica como le da la gana, cada hace lo que le da la gana y a nadie le viene en gana documentar. El resultado es el que ya han indicado en uno de los comentarios: coges un programa re-re-re-re-re-parcheado que no hay dios que lo entienda, lo descifras (pq el 99.99% de los analistas se limitan a decirte cómo tienen que ser las pantallitas - en el mejor de los casos), te cabreas y te limitas a poner tu parche encima.

¿Trabajo invisible? Puedo decir que, en mi caso, más del 70% del tiempo se invierte en intentar adivinar qué hacen los programas y el 30% restante en meter mi parche y estropearlo un poquito más. Lo realmente lamentable es que si intentas poner un poco de orden casi nunca puedes porque hay que entregarlo para anteayer y (palabras literales) "no quiero una obra de ingeniería, quiero que funcione"..........

Te entiendo, es como que cada programador pone su arcilla al muñeco, y después de haberlo construido se queda el muñeco feo, jeje, no hay quien haga un muñeco de arcilla más bonito.

Hola, Aquí seria donde saldría el fabuloso tema que daría para otra investigación que es el de las empreses de servicios, en donde un supercomercial o un superresponsable te envía y cuando llegas a la entrevista, el pobre cliente que se piensa que ha contratado tal y cual cosa, por lo que va a pagar una millonada al mes (de lo cual, tu, pobre programador, vas a ver como mucha un 30%), y que el cliente se piensa que tu eres un superexperto en, pongamos, la archiconocida por todo el mundo herramienta de IBM NetData, y que si tu te muestras totalmente sincero con el cliente, puedes recibir un mensaje en el móvil diciendote tu jefe, comercial, responsable o como demonios le quieras llamar, que pases por la oficina a recoger el finiquito por comportarte eticamente... O sea, que no hay calidad porque las mismas empresas de desarrollo no lo quieren y los clientes contratan a ciegas... Continuará...

Sabes que tarde o temprano esta situación tendrá que cambiar, es imposible afontar grandes desarrollos de software con este planteamiento.
Actualmente hay técnicas de programación que facilitan mucho la documentación de software, como es el caso de la programación literaria (podéis leer un artículo del señor Manuel Perera en este sitio)
Precisamente esto que comentas es lo que terminó en la famosa crisis del software de los 70.
Con la progresiva implantación de un personal cualificado se solucionará este problema, pero mientras se siga llamando "informático" a cualquiera que se ponga delante del ordenador a teclear un montón de instrucciones sin ninguna planificación estamos perdidos.