Desde que me dedico a esto de la construcción (de software) siempre he envidiado a los otros constructores, los que hacen edificios, presas, carreteras o cualquier otra cosa física. Sean arquitectos, ingenieros de caminos o de obras públicas, todo el mundo tiene claro cómo se hacen las cosas en esas profesiones. Se sabe quien diseña, quien se hace cargo de los problemas estructurales y la forma en que se reparte el trabajo y la responsabilidad.
Visto desde el punto de vista de un ingeniero licenciado en informática solo puedo decir que la ingeniería que se aplica en nuestro gremio es como una top-model, deseada por todos y totalmente inalcanzable para la mayoría. Hay varios hechos que he constatado durante mis años de experiencia que hacen de éste un hecho irrefutable, no solo en España sino en el resto del mundo. Veamos algunos:
- No existe una metodología comúnmente adoptada ni que sea posible adaptarla a todas las necesidades de programación o a todos los lenguajes/entornos de manera sencilla.
- Las necesidades de cambios constantes en el software, junto con un ttm (time to market) más reducido cada vez hace que cualquier procedimiento que retrase el resultado sea imposible de aplicar, o cuando se aplica solo sirve para hacer fracasar el proyecto
- La poca preparación de los gestores, o incluso la creencia de que cualquiera puede dirigir un proyecto de software hace que, incluso con profesionales cualificados en el equipo, el proyecto no use enfoques de ingeniería.
- La falta de regulación profesional y de, entre otras cosas, un colegio oficial, hace muy complicado hacer que normas de desarrollo se estandaricen o se hagan «oficiales»
Aunque hay muchos más motivos (obviando la estupidez humana y la falta de recursos) intentaré describir cada uno de los puntos anteriores según mi experiencia profesional.
La metodología
A nadie se le ocurriría construir un edificio de 15 plantas sin tener planos, ni un estudio de materiales, ni un estudio del suelo, etc. Todas estas cosas son obligatorias por ley o están derivadas de lo que se entiende como un proyecto de arquitectura. Para realizar cada una de estas actividades los arquitectos y/o ingenieros disponen de métodos aprobados y fiables. Se actualizan, se mejoran, pero siempre están ahí y cualquier arquitecto/ingeniero los debe conocer.
En informática eso no es así, no es obligatorio el uso de «planos» para el diseño, o al menos se acepta cualquier tipo de planos y, lo que es peor, estos se cambian sobre la marcha sin ningún pudor. No es nada sorprendente que el cliente, tras ver el resultado de lo que pidió inicialmente exija que se rehaga todo porque no se parece a lo que tenía en mente. ¿Alguien se imagina que tras construir un chalet el cliente pida que le pongan 5 plantas más y un helipuerto en la azotea? Seguro que el arquitecto se mea de la risa, pero es que el jefe de obra le va a decir que esos son los planos que él tiene que construir y que cualquier otra cosa la hable con el arquitecto. ¿Por qué aquí no?
Los cambios constantes
El ejemplo anterior de cambio, inspirado por uno de mis últimos trabajos en los que tuvimos que hacer un sitio web completo cuando lo que estaba ofertado era un sistema de búsqueda y localización de documentos, es una muestra de a lo que lleva el no tener un método que exija una aprobación del cliente de manera que este tenga unos «planos» sobre los que saber qué está pagando y el constructor qué es lo que está haciendo. Pero hay otros cambios, que son inevitables, asociados a la naturaleza misma del software. Estos cambios no son fruto de mala comunicación ni de falta de método, simplemente sucede que algunas cosas se quedan obsoletas antes de terminar el desarrollo.
Cuando la vida de ciertas tecnologías es muy breve, o cuando la construcción de software se basa en paradigmas «con fecha de caducidad» el diseñador se siente tentado de utilizar la última versión de la última tecnología, aún no asentada, de manera que pueda tener más tiempo de vida. (Voy a usar Java 6 con la beta de xxx y el nuevo yyy, así me evito tener que cambiar después)… Craso error, cuando sacamos a producción el producto, las versiones de todas las tecnologías han aumentado, la compatibilidad no es buena y el soporte para las versiones que elegimos está terminando… Así no hay manera. Esto es resultado de la política de algunos productores de software de «Disparar y avanzar«, que consiste en sacar nuevas tecnologías (refritos con nombres nuevos) para ganar tiempo sobre los seguidores que lo perderán intentando ser «compatibles» o adoptar esas tecnologías.
Aún eligiendo la plataforma correcta y teniendo tiempos de desarrollo compatibles con el mantenimiento de las mismas, los requisitos de los clientes son, por naturaleza, dependientes de su negocio. Como el negocio, hoy en día, sufre variaciones importantes que obligan a adaptarse a las empresas, el software que da soporte al negocio en esas empresas ha de adaptarse, el TTM (time to market) de los desarrollos software ha de hacerse más breve cada vez. Esto trae interesantes consecuencias:
- Menos tiempo para la toma de requisitos y requisitos más breves, aunque se cuenta con la ayuda del «requisito diferencial» que consiste en, sólamente, tomar los requisitos que cambian y no los que permanecen.
- Menos tiempo para diseño, generalmente se reutiliza el diseño ya en ejecución y se «parchea» suponiendo que el diseño general es correcto.
- Casi nada para la implantación, o bien se toma tiempo prestado al diseño, codificando según se escribe el mismo o se utilizan plataformas de implantación rápida (php, RoR, etc) que ceden parte del control y de lo que se puede y no se puede hacer a un framework a cambio de un desarrollo más breve.
- Pruebas ¿qué pruebas? generalmente se realizan a la vez que las sesiones de aceptación del cliente, el único requisito es que haya pasado algún tipo de prueba unitaria.
- Usar y re-tirar. Una vez todo en marcha el circulo se vuelve a cerrar ya que la vida de este desarrollo será mínima y gran parte de la porquería que hemos generado tendremos que reutilizarla para el próximo ciclo.
- Documentación, ese gran desconocido. El esfuerzo a dedicar a la documentación se reduce drásticamente (siempre se ha considerado que debe ser una fracción del dedicado al resto de actividades), con lo que, a veces, se reutilizan documentos de requisitos para describir la arquitectura y manuales de usuario como descripciones funcionales.
Total, que al final nos quedamos convertidos en un equipo de bomberos que no hacen más que apagar fuegos aquí y allá. La diferencia entre un equipo competente y uno que no es la misma que entre los bomberos profesionales y la cuadrilla de campo… Unos lo hacen todos los días y los otros solo cuando les arde la casa del vecino. Pero ¿alguien ve la diferencia entre construir y apagar?… Muchos clientes no.
Los gestores
Quizá en este apartado me toque echar piedras sobre mi tejado, pero yo me presento a mi mismo como un técnico (tecnólogo) que se ve obligado a hacer labores de gestión para sacar un proyecto adelante… Se supone que debería haber gente preparada exclusivamente en tareas de gestión que pudiesen sacar adelante cualquier proyecto, sea de ingeniería, de arquitectura o la gala del carnaval de tenerife… Vamos, el «señor lobo» de pulp fiction. La realidad es que, realmente, el señor lobo no es tan eficaz como parece. El gestor de un proyecto software (según una experiencia reciente) se limita a:
- Decirte lo lento que vas y enviarte modificaciones sin sentido para que te retrases más.
- Recordarte que él es el que tiene que hablar con el cliente para, acto seguido, pasarte su teléfono para que le respondas unas dudas «técnicas».
- Olvidarse de revisar el trabajo hasta que no recibe una llamada del cliente quejándose por lo que ha recibido y, claro, luego hay que rehacerlo todo por la incompetencia del resto del equipo.
- Ponerse las medallas ante el cliente, ante el equipo y ante Dios padre. Asegurar que el próximo proyecto lo hará con un equipo mejor y por menos dinero y hacer creer al cliente que la culpa de todo es suya, aunque se hará un esfuerzo para cumplir con sus irracionales peticiones en forma y plazo. (no se como se pueden hacer cuatro proyectos distintos con el presupuesto de uno solo que nada tenía que ver).
¿Alguien ve aquí algo útil? Yo tampoco. Sin embargo este es el perfil medio del «gerente» de empresa de software (luego está el que vende kilos de carne a tanto la hora, pero esos son otra historia). Esto es así porque en las empresas se sigue el principio de «si eres bueno en lo que haces, nunca ascenderás» y, por tanto, solo ascienden los que no son buenos técnicos ni buenos comerciales (eso si, saben usar muy bien el forwared en el correo electrónico).
La falta de regulación profesional
Aunque aquí hay mucha gente que no está de acuerdo y que postula por la no existencia de colegios profesionales, lo cierto es que la responsabilidad de los proyectos software debería estar en manos de algún técnico preparado y llevar una firma última a la que exigir cuentas si algo no va. Si una casa se derrumba por estar mal el proyecto, es muy sencillo saber quien hizo los planos y a quién se le contrató la construcción. En el caso de la informática no. Nadie rinde cuentas, nadie sabe de quién es un diseño, nadie sabe de quien es la responsabilidad de un cuelgue que ha provocado pérdidas inmensas o incluso pérdida de vidas.
La existencia de un colegio profesional de informáticos permitiría que, aún a costa de unas tasas, se siguieran unas mínimas normas para poder desarrollar un proyecto de software (al menos aquellos que tengan cierta envergadura o se contrate con la administración). Se evitaría mucho intrusismo y se fomentaría algún tipo de estándar para la creación de proyectos (al menos los que firmen colegiados) y estaría mucho más regulado el precio de estos servicios.
¿Alguien se imagina que a mi (ingeniero licenciado informático) se me permitiera firmar los planos de un rascacielos… ¿pues porqué un físico si puede decir que es el jefe de proyecto de un sistema de mantenimiento de historiales clínicos para un hospital?
En fin… Me dejo un montón de problemas más, espero que me ayudeis a dejar constancia de ellos con vuestros comentarios.
Pingback: meneame.net
Pingback: Fresqui.com
En pocas palabras:
http://www.ingenierosdeprimera.com
Pingback: Nota Mental » Blog Archive » Problemas en la ingeniería del Software
Tienes razón en todo. Este es un tema de interés creciente.
Nuestra profesión mejorará cuando existan multitud de especialistas (diseñadores gráficos, gestores de bases de datos, programadores, …) y al estar muy especializados en sus tareas, necesiten alguien que sepa de todo un poco y que pueda coordinar y dirigir el proyecto (asignar tareas, distribuir recursos, …).
La escuela de Ingenieros en Informática es vital para la calidad del software y de la profesión.
un saludo ;-)
PD: anímate a escribir más sobre este tema, que esta de rabiosa actualidad con lo del proceso de Bolonia
Perfecto, salvo el último párrafo. Llevo mucho tiempo en esto y he comprobado que los mejores profesionales no tenían la carrera de Ingeniero Informático (!!)
Si tu jefe no es ingeniero informático, ni físico, ni matemático.
Si los jefes de proyecto de tu departamento tampoco en un 80%.
Si dos terceras partes de tus compañeros ni son de tu empresa, y en 20 minutos les cuentan todo lo que han de saber del proyecto.
¿Cómo narices salen bien? Tú ten un nombre de empresa poderoso, y lo demás vendrá solito.
Lo primero es que somos ingenieros, a parte de licendiados, pero primero ingenieros. No quita que ahora no esté regulada la profesión o que haya muchos problemas. Pero todas las ingenierías empezaron así y no por ello dejaron de serlo.
Lo segundo: la culpa la tenemos nosotros. Si cuando el típico jefecillo que no tiene ni idea de nada más que de dar voces y meter presión, nos manda hacer un proyecto protestásemos todos diciendo lo que sabemos y cómo se debería hacer, la cosa sería muy diferente. Pero claro, ¿quién se juega el puesto de trabajo hoy en día?
Nosotros, los ingenieros debemos hacer lo que sabemos hacer sin importarnos un pijo lo que dicen los incultos en la materia. Y la verdad es que sí hay bastantes metodologías para realizar proyectos informáticos. El problema es la elección de la adecuada para el proyecto, pero si se elige bien, un proyecto informático es igual que hacer una casa, con sus planos, con sus trabajadores cualificados para cada parte del proyecto,… para todo.
Pero nadie lo hace. Y no es porque nosotros no sabemos o no queremos, es porque los clientes y los jefecillos antes mencionados no saben de lo que hablan y lo único que saben decir es «¿lo tienes ya? ¿no? pero si eso está tirao…». Y repito, la culpa la tenemos nosotros.
Es cierto que en la ingeniería del software existen multitud de problemas, no te lo niego, pero un colegio profesional no es la solución.
Tus analogias típicas con la arquitectura/construcción no me valen, no es lo mismo, la humanidad lleva construyendo desde antes de aprender a escribir y muchísimo antes de aprender a programar. Y al ser una tecnología tan nueva es imposible su regulación, o ¿también les hubieses impuesto planos y diplomas a los trogloditas para construir sus cabañas?.
Yo creo que la creación de un colegio informático traerá más problemas de los que pueda llegar a resolver.
Quién entrará en ese colegio?
Que tipo de regulación se hara?
Se impondrán algoritmos para ciertas tareas?
Cual será la manera de equiparar y garantizar programas?
Cual será la titulación necesaria para firmar un proyecto?
Cual será el importe añadido en concepto de «tasas»? -Si antes ya era caro, añadamos tasas y además trabas.Etc..
Dices que necesitamos un colegio, pero no dices que hará ese colegio, excepto regular y cobrar. Define ampliamente «regular», por favor.
Existen soluciones a la regulación, -certificados de calidad-.
PD: cambia de trabajo.
Pingback: www.programame.net
Todo muy bonito… salvo por un detalle: los programas los vende la gente de marketing, no los ingenieros.
Ingenieros y gestores pueden decir lo que les dé la gana, que el cliente sólo mira dos cosas:
– qué le prometen
– cuánto debe pagar
Plazos imposibles, promesas infundadas… es lo que al cliente le gusta y a lo que vas a tener que acomodarte. El mercado pide basura, rápido y en cantidad. En esas condiciones, difícilmente veo la relevancia de quién lleve el proyecto. Claro, puedes forzar a los de marketing a que vendan menos y más caro… y puede que a los de China o la India les importe un comino, y acabes de patitas en la calle.
También es una pena que en la carrera -o mejor antes de ella- no te digan estas cosas… pero qué le vamos a hacer, es lo que hay; el mundo académico es un país de fantasía multicolor comparado con el mundo real.
ja que podría comentar amigo es muy cierto lo que dices siempre digo que la informática es una área muy muy cruel donde el que mas sabe es el que menos gana, y el que menos sabe y hace alguna estupidez que le sale bien entonces ese si es el mejor de todos al parecer los tecnologos debemos aprender a movernos mas socialmente que perder el tiempo tratando de desarrollar las skills de nuestros fuertes por que al final el que gana es que el envía mas cadenetas de .pps simpáticos al jefe.
este mundo no es para quedarse …pero es que no hay otro mejor para mudarse :D
Si no hay nadie decente para dirigir proyectos software, como va a existir alguien decente para dirigir un colegio y dar las pautas a seguir para dirigir proyectos software?
La incompetencia va a ser la misma, la diferencia está en el sentido del dinero. Ahora mi jefe me paga a mi. Y no soy yo el que le paga al colegio (por no decir a los 4 «listos a dedo» que lo dirigen en cada provincia).
Cualquier persona decente que pertenezca a una profesión con colegio te hablara mal de ellos, ¿no te dice nada eso?
Lo que desde luego no le hace falta a la informática son políticos. Si queremos echar a los incompetentes, no traigamos políticos.
La solución no es que la Ing Informática tenga un colegio, es que ninguna otra profesión tenga un colegio!
En todo lo demás estoy contigo, salvo en la repetida comparación con la construcción. Sinceramente, todavia estamos muy lejos de ser una ciencia. Ahora mismo somos un servicio con el que ganan dinero algunas empresas, vamos unos ñapas.
Saludos.
De acuerdo con todo.
A mí también me dan envidia los otros constructores, pero mucha.
También pienso que el primer problema somos nosotros mismos los ingernieros, digo licenciados, que no nos lo terminamos de creer.
No nos terminamos de creer que la ingeniería del software sea capaz de implantarse en la construcción de software. Como vamos entonces a convencer al resto.
El primer paso: un colegio de verdad, está claro.
Aunque se exponen unas razones éticas y profesionales de peso, cabría destacar una razón que seguramente esté en la mente de la mayoría de los defensores de la regulación profesional (colegios profesionales): el elitismo y, por consiguiente, el monopolio.
«Soy», ¿o debería decir «me dedico»?.
Bueno llevo programando desde el 1989 y mi titulación sólo alcanza a Técnico Auxiliar Administrativo y, desde el citado año, vengo sufriendo los mismos avatares y penas que se describe en este post. Curiosamente, se han visto agravados desde la entrada en el mercado laboral de graduados y licenciados (sea de la carrera y/o especialidad que sea) que se les contrata por el mero hecho de ser licenciados o graduados (ese me parece el verdadero intrusismo). Cómo normalmente pasa por estos lares, dicho futuro colegiado es hijo, sobrino, nieto, hermano, … de, termina ocupando un puesto de dirección y toma decisiones, justamente aquellas que terminan haciendo el trabajo sin pautas, planos, o como quieran llamarlo.
Bueno, en definitiva y para no enrollarme más.
Se debería hablar antes de un GREMIO PROFESIONAL que de un COLEGIO PROFESIONAL, y defenderlo ante los especuladores con el trabajo ajeno actuales. NO ES un problema de INGENIERÍA, es un problema de la cultura del pelotazo que reina actualmete y de la que, curiosamente, tiene primer acceso los antes citados «hijos de».
Bueno, yo estoy de acuerdo con casi todo. Quizá, por matizar, creo que el Ingeniero nace, no se hace. Es decir, que en este caso el hábito no hace al monje, ni siquiera a los Ingenieros Industriales o Telecos.
Sí estoy de acuerdo con el tema de los colegios profesionales. Podrían regular efectivamente quién debe hacer qué en cada proyecto. Así, podrían exigirse ingenieros para la fase de análisis, ingenieros técnicos para el diseño de arquitectura, al menos FPIII para la construcción y testeo de software, ingenieros técnicos de sistemas para la explotación de dichos sistemas, etc.
¿Que es muy fuerte? Puede ser. Bueno, pues al menos podría regularse de esta forma para:
– Administraciones Públicas
– Contratos de cierta envergadura (según el importe del contrato)
– Sistemas críticos por su repercusión (Sanitarios, servicios de los que dependen vidas, etc.).
Leí hace poco en un blog en inglés (de cuya url quiero pero no consigo acordarme) que los problemas con la ingeniería del software empiezan incluso en el nombre:
Cometemos el error de usar palabras como «ingeniero» y «arquitecto» por la fácil analogía con quienes levantan puentes y edificios, mas las coincidencias entre aquellos y los ingenieros/arquietectos software solo es en el nombre.
Por lo demás, lo que esos hacen, y lo que los informáticos hacemos son cosas diametralmente distintas.
Un arquitecto que diseña un puente sabe de los muchos puentes idénticos al suyo que otros contruyeron en el pasado, mientras que un analista informático se encuentra el 99% de las veces ante la tarea de crear un sistema totalmente específico para un cliente concreto, con casuisticas nunca antes vistas, asi que ¿como estimar los tiempos? (¡la gran pregunta de los jefazos!) Imposible saberlo. Se cruzan los dedos y se dice un plazo intentando taparte las espaldas. Tras eso: látigo a los desarrolladores, que hay que cumplir con el delirio prometido.
¿Y por qué nunca se llega a tiempo?
Buenos días a todos.
Cuando hace un mes aproximadamente Jesús González Gago me comprometió
sin derecho a réplica, a que preparara una explicación sobre mi
trabajo, con la premisa de no sobrepasar bajo ningún pretexto los
cinco minutos de exposición, no pensé que el encargo pudiera ser tan
complejo como finalmente me ha resultado, pues de entrada, he tenido
que preparar mi intervención para leerla, porque de no ser así, seguro
que sobrepasaría largamente el poco tiempo estipulado.
Intentaré pues ceñirme estrictamente al guión. Mi primer oficio,
cuando finalmente conseguí salir vivo de los 14 meses de mili en
Melilla (sin duda los más desagradables y baldíos de toda mí vida),
fue el de consultor, aunque en aquel entonces, en la multinacional
francesa a la que pertenecía, a mi oficio se le conocía como: experto
nuclear, nivel III en ensayos no destructivos. En la actualidad sigo
siendo consultor y, con singular constancia en este oficio que nunca
he interrumpido, creo haber recorrido paulatinamente a lo largo de
estos 25 años todos los peldaños de una evolución profesional bastante
coherente.
Tras pertenecer a varias compañías y desempeñar distintas
responsabilidades funcionales, en la actualidad, probablemente como
último tramo de esa escalera profesional a la que me he referido,
aunque sigo siendo consultor, ejerzo de director general de una firma
que yo mismo fundé hace ya algunos años.
A partir de esta breve introducción, permitidme que hable de mi madre.
. Aún hoy. mi madre sigue estando preocupada porque no entiende bien
como me gano la vida.
. Aún hoy. mi madre sigue sin tener nada claro cuál es mi profesión.
. Aún hoy. mi madre sigue sorprendiéndome frecuentemente con una
profunda reflexión:
– Pero tu hijo mío, ¿realmente en qué trabajas? Ricardo es médico,
Joaquín es arquitecto o Jesús es farmacéutico, y está bien claro como
se ganan la vida. pero contigo, no soy capaz de explicarlo. Cuando me
preguntan en qué trabaja «tu chico», no se muy bien que contestarles
porque yo misma tampoco lo
entiendo. ¿Cómo te pueden contratar bancos, hospitales o fábricas para
que les aconsejes lo que tienen que hacer? ¿Qué puede saber un físico
de esas cosas? No lo entiendo, la verdad, me comenta mi madre al menos
cada
navidad sin mostrar demasiada esperanza en que mis explicaciones de
siempre, logren desvanecer sus dudas de siempre.
Hoy, este sábado de junio, mi madre está de suerte, porque
aprovechando nuestra celebración y este comprometido encargo de
explicar en no más de cinco minutos mi profesión, le haré llegar una
fotocopia de estos folios y dispondrá así de algunos argumentos más
para poder contestar, cuando en los cafés con sus amigas. casi todas
viudas y agraciadas con hijos dentistas o abogados (y en consecuencia
de oficio definido y conocido), le sigan preguntando: Por cierto
Josefina, ¿en qué me dijiste que trabaja el chico?
Como ya os había adelantado antes de acordarme de mi madre, soy y
siempre he sido, consultor. Mi especialidad en este oficio de
aconsejar a organizaciones, empresas y directivos sobre lo que
deberían hacer, es el desarrollo e implantación de modelos de gestión
soportados por metodología TQM.
Como este foro es de total confianza, (y como además mi madre va a
tener una fotocopia de estos papeles), me permito declarar
abiertamente y sin muestra alguna de pudor, que dentro de esta
especialidad soy experto en «el diseño de estrategias competitivas
focalizadas en el cliente». Seguramente, ahora buena parte de vosotros
estéis ya comenzando a comprender muy bien a mi madre.
Especialista en el desarrollo e implantación de modelos de gestión
soportados por metodología TQM, experto en el diseño de estrategias
competitivas focalizadas en el cliente (Hay que ver lo que impresiona
cuando lo ves escrito). Seguramente, ahora buena parte de vosotros no
sólo ya estéis comenzando a
comprender muy bien a mi madre si no que incluso también empezáis a
entender las dudas de sus amigas, y en estos momentos ya os estéis
preguntando:
¿Cómo es posible que alguien se pueda ganar la vida con un oficio,
como este que os acabo de anunciar?
Siento mucho no disponer de tiempo suficiente como para resolveros,
aquí y ahora, esta duda, la verdad es que ya no dispongo de tiempo ni
tan siquiera para intentar justificaros que mi oficio no es ilegal;
ahora, ya solo tengo un minuto para concluir esta breve intervención
respondiendo a otra cuestión, que estimo más importante y que además
estoy seguro que la mayoría de vosotros
(al igual que mi madre desde hace 25 años), también os estaréis
planteando ahora:
¿Qué hace un físico en una profesión como esta?
Os daré mi opinión, lentamente fraguada y repetidamente contrastada a
lo largo de los años.
. Ser físico te capacita para ser un excelente profesional en
cualquier campo al que la vocación o la casualidad te derive.
. Ser físico te proporciona una excepcional preparación universitaria
para poder abordar cualquier proyecto laboral independientemente de la
especialidad de la que se trate.
. Ser físico te cualifica para aspirar a cualquier posición ejecutiva
dentro de cualquier organización y en cualquier sector productivo.
Cuando un crío de 20 años es capaz de comprender la importancia de las
variables complejas expresadas mediante el alfabeto griego. y no se
entrega a la bebida para olvidar.
Cuando un chaval de 20 años es capaz de asumir la importancia del
cálculo de la probabilidad que tiene un electrón de encontrarse en un
determinado espacio y momento. y no tiene que recurrir a las
anfetaminas para recuperarse.
Cuando un muchacho de 20 años es capaz de entender la importancia de
la ecuación de Schrödinger con sus bonitas laplacianas al cuadrado. y
no termina integrado en una secta psicodélica para superarlo…
.es indudable que ese joven de 20 años está preparado para superar los
más ambiciosos retos laborales.
En suma, opino que cuando en plena juventud (casi en la adolescencia
vista desde hoy):
. Se es capaz de intuir la criticidad de la fuerza de Coriolis para
que el mundo siga dando vueltas.
. Se es capaz de apreciar la relevancia de los conceptos de entropía y
entalpía, o de la interacción de la luz y la materia.
. Se es capaz de comprender que sin el estudio de las aberraciones
cromáticas o sin el desarrollo de la física cuántica, la humanidad no
habría llegado hasta aquí.
Y además, se es capaz de todo eso sin claras manifestaciones de
enfermedad psicológica alguna («sin enfermar», que dicen en mi
pueblo).
Ese joven os garantizo que está excepcionalmente preparado para
desempeñar cualquier trabajo.
Todos nosotros, que durante aquellos años tuvimos la fortuna de
convivir, sin desmayar, sin abandonar (y sin enfermar), con Einstein,
Planck, Schrödinger o Pauli, estábamos preparados para el éxito
profesional tan bien como los mejores. pero ¡ojo! con una gran ventaja
sobre todos ellos: que nosotros además lo podíamos demostrar en
cualquier profesión.
A lo largo de estos 25 años he contratado a psicólogos, ingenieros o
biólogos, he trabajado con mba’s de Boston, químicos de Sarria,
ingenieros de Icai o economistas de Deusto, y lo que puedo confesaros
desde mi experiencia. es que cada día que pasa sigo confirmándome más
en la opinión de que ser físico es un verdadero lujazo, de que los
físicos somos gente muy preparada, gente capaz, y es por ello por lo
que cada día me siento más orgulloso de haber
compartido con vosotros estas aulas (aunque alguno ahora me recordará
en voz baja que yo de asistir a las aulas más bien poco).
Antes de concluir en exactamente 5 minutos, quiero aprovechar esta
excepcional ocasión para agradecer públicamente a mi madre la mucha
paciencia que tuvo entonces conmigo y con mi escaso ritmo de papeletas
anuales, lo que me permitió la gran suerte de ser hoy vuestro colega.
También quiero agradeceros a todos vosotros, después de 25 años,
vuestra ayuda de aquel entones, y vuestra compañía de hoy. Muchas
gracias y felicidades.
¡A qué coño viene esta parrafada que no dice nada de lo que se está tratando aquí! Si, ser físico debe ser la hostia, pero no tienes ni idea de informática. E informática no es saber manejar el ordenador.
Y encima nos quieres tomar el pelo con tu madre. ¡Manda cojones!
Tan solo quería decir que parte del problema viene de los mismos profesionales del sector, su falta de motivación y su falta de ¿»fe»?.
Lo primero que deberíamos pensar es que somos Ingenieros, y actuar como tales. Estoy harto de oir a compañeros de trabajo diciendo que de ingeniros nada, que venimos de picateclas y que cada una hace lo que puede y parchea como puede, y que el gestor de proyectos intenta cuadrar imposibles impuestos por los directivos.
Así que a la espera que los colegios oficiales consigan hacer más fuerza somos nosotros mismos los que deberíamos mejorar y reforzar la creencia de la gente hacia esta Ingenieria!
Estoy de acuerdo con el último comentario. Si los médicos no se dedican a diseñar planos de edificios, así como los arquitectos no traducen libros, que le hace pensar que cualquiera pueda hacer el trabajo de un ingeniero? A los que piensan que los que consiguen sacarse una ingeniería no hacen mas que jugar a cartas en el bar de la facultad, les insto a que se entretengan matriculándose en una. Y por cierto, aquellos que catalogan de intrusismo a aquel que llega con una ingeniería en informática a una empresa de ingeniería de software, podrían analizar este juego de palabras y darle un nuevo sentido al concepto de «intrusismo».
Al respecto del ciclo de desarrollo, la gente se resigna contratando a un “chapuzas” para que le haga un lavabo nuevo en su piso sin pedirle que le haga una reforma ejemplar, pues es consciente de que no lo será y se rinde a lo único que puede pagar. En la generación de software no pasa lo mismo, ya que aquí el cliente no sabe si quiera si el retrete debe ir colgado del techo o bien si lo quiere dentro de la ducha. Solo cuando lo ven saben lo que quieren (IKIWSI – I know it when I see it), y culpan al equipo desarrollador de no tener facetas de psicólogo – pitoniso. Así que espero que a base de fracasos y palos por parte de administraciones y empresas, algún día realmente exista una regulación sobre nuestra profesión, y si no llega que al menos me dejen trabajar de cirujano, que total no lo haré peor que muchos de nuestra rama y al menos ganaré una pasta. Saludos.
Pingback: Frases XIX: Probando, probando… - Un Blog Mas
Pingback: Prográmame: Un Menéame para programadores - Un Blog Mas
Soy quimico de profesión y trabajo actualmente en el diseño y desarrollo de un software para laboratorios de ensayos quimicos y micro biologicos y para mi que no soy ingeniero de software si me parece que es tiempo de considerar a ustedes como verdaderos ingenieros; por que se ve la creatividad y la innovacion inmediatamente y no con el el pasar del tiempo. Un puente o un edificio diseñado y desarrollado por un ingeniero civil o por un arquitecto no tiene en que demeritar el diseño y desarrollo en la construccion de un software por parte de un ingeniero de software. Estoy de acuerdo que un colegio no hace al ingeniero de software el se hace con su imaginacion, creatividad e innovacion. Por lo tanto le pido a ustedes que sigan adelante con la ingenieria de software porque personas de otra profesion como la mia siempre estaremos atentos a sus desarrollos de ingenieria de software.
Animo y no se dejen tocar por politicos y charlatanes y sabelotodo que son los que mas abundan en este mundo.
Saul Antonio Peñaranda Canosa
Pingback: Algo pasa con la ingeniería del software « Deambulando
Una pregunta, ¿por qué insistís tanto en comparar la ingeniería del software con la arquitectura, o con otras ingenierías?
¿Qué os hace pensar que hacer una casa es algo que sale maravillosamente bien gracias a los planos del arquitecto?
¿Acaso conocéis ese mundo? Porque de casas mal hechas está el mundo lleno (grietas, humedades, acabados pésimos, enchufes en lugares inverosímiles, ruidos del vecino…), y sólo tenéis que hablar con un jefe de obra para que os ponga al arquitecto a bajar de un burro (e igualmente con los curritos para que hagan lo mismo con el jefe de obra).
Y encima: hacer una casa es algo que se lleva haciendo desde la noche de los tiempos, y las similitudes entre ellas son evidentes. Y además, no es muy complejo: basta ver que un sólo arquitecto se hace los planos, ¿se haría un sólo informático el diseño de TODO un software?
No he conocido en la vida dos software ni remotamente parecidos. Cada uno es una historia nueva, y de ahí bienen todos los problemas.
Dios que falta, quise decir «vienen todos los problemas»…
Muy bien David asi se habla, dejenme agregar algo que seguramente lo habran dicho pero que importa no tengo ganas de leer todo. Hoy se quiera o no ser programador se trata de una ingenieria y el echo que alguien la realize como tal va por cuenta del profesional. Las herramientas existen y los contenidos tambien. Yo estoy estudiando la carrera en Argentina, si se, riansen todo lo que quieran pero puedo asegurarles que es muy buena y es acelerada (5 años) etc etc. Lo que encontre muy bueno es el comentario que hallan universidades que se dediquen exclusivamente a formar capacitados con algun conocimiento de otros campos pero siempre enfocados a la carrera. La mia es una universidad empresarial asique con respecto al tema de administracion tanto fisica como financiera es muy exigente. Otra cosa que veo muy interesante es la existencia de un campo dedicado al desarrollo emprendedor que realmente ayuda mucho. Vamos chicos no se depriman que en todos lados somos requeridos y plata por ahora no nos va a faltar. Aca ya siendo analista de sistemas (a los 3 años de Ing. Soft.) te consideran lo mismo por la falta de profesionales que hay. Y que importa si la carrera no se asemeja a ninguna del resto de las ingenierias, eso juega en contra nuestra. No sean boludos ni tampoco arrogantes..
Salu2 un ingeniero en proceso de impresión…
No estoy de acuerdo con tu opinión. No puedes comparar la construcción de un edificio de 15 plantas con una aplicación software desarrollada por una consultora para la gestión de historiales clínicos. Más bien, sería comparable con la construcción de una chabola («chabolismo informático»), donde si mañana llueve y hay goteras, se pone un parche y arreando!.
Compáralo mejor la construcción del edificio con el software que va embarcado en un avión: ese software sí tiene una metodología de desarrollo, sí tiene unas pruebas muy exigentes, sí tiene una documentación y unos gestores que, en caso de que falle, saben que se van directos a la calle.
Por eso, no todo el desarrollo de software cabe en la mismo saco. Hay software que se hace siguiendo prácticas de ingeniería y otro que no. En el caso del avión puede tardar más de un año en pasar a producción una línea de código escrita hoy. En el caso de la gestión de historiales una línea codificada por la mañana puede estar al día siguiente en producción, y si falla… se revisa y se actualiza el código al día siguiente. Eso es «chabolismo informático» o nivel 0 del CMMI.
Gente, tengo una pregunta para todos ustedes que saben mucho. Tengo una profesora que es ingeniera de software, la cual nos dijo que lo mas probable es que después de los 50 años los ingenieros de software no pueden trabajar mas ya que no pueden mantener el mismo ritmo que cuando eran jovenes, ni competir con el resto porque es una carrera que exige mucho de uno pero a esa edad es casi imposible soportarlo. Diganme que hay de cierto en eso, que voy a hacer despues de los 50 diganme voy a tener que hacerme hacker, profesor o trabajar en la administración de algún lugar. Es triste saber que sea asi.
Yo no tengo título alguno de ingeniería de software, mi formación es la de Químico Farmacéutico Biólogo y llevo desarrollando software desde los 15 años, primero por hobbie y después por necesidad. Mi campo ha sido principalmente el POS (Point of Sale), aunque he desarrollado software a nivel industrial. En todos estos años me he percatado exctamente de lo mismo que se comenta en este blog y mi particular forma de pensar es que lo que le hace falta a la ingeniería de software es precisamente una estandarización de la metodología de trabajo. ¿No es curioso que pretendemos programar y estandarizar un proceso de una empresa externa de cualquier giro: farmacéutico, automotriz, diseño, etc. pero somos incapaces de estandarizar un proceso de creción de software? Como dice un dicho popular en mi pueblo: en casa del herrero, azadón de palo. Las solución llegará cuando las empresas encargadas de desarrollar software formulen metodologías perfectamente definidas (estándares) sobre cómo se desarrolla un software para optimizar tiempos y minimizar costos. Esa es mi opinión. Gracias y saludos.