Hace 14 años | Por toptnc a gallir.wordpress.com
Publicado hace 14 años por toptnc a gallir.wordpress.com

Los que leen habitualmente mi blog conocen mi opinión sobre la “ingeniería del software tradicional”, muchas veces hablé de ello y del “mal” que hacen en general a la profesión, hasta como limitan la innovación. Nunca me gusta que se llame “ingeniería” a un proceso que no tiene nada que ver con las ingenierías tradicionales. Pero ahora está surgiendo el mea culpa de los gurús incondicionales de la “ingeniería del software”, el reconocido gurú Tom DeMarco que escribió el artículo de opinión Ingeniería del software: ¿una idea de tiempos pasados?

Comentarios

angelitoMagno

¿Se puede saber que saber algún proyecto importante y complejo que haya dirigido este tal Gallir? Porque parece que habla sin saber

D

Para hacer buen software hace falta talento. A veces puede ser preferible estandarizar la mediocridad. Creo que ha faltado esta perspectiva, el mundo del soft libre y el de la selva son muy distintos

Nitros

#29 #30 En el apunte, pone un link al twit de donde ha sacado el enlace que pones en 29 (

.

Así que de plagio nada.

Por otra parte, fantástico apunte, lastima que la frecuencia de actualización del blog haya bajado.

trollinator

Por favor, una cosa me gustaría comentar:

Todos tenemos "historias de horror", tanto de ingenieros como de no ingenieros. No demuestran nada, son casos particulares. Si queremos ser rigurosos con la ciencia, ya que precisamente hablamos de ello, deberíamos dejar de lado esas chiquilladas, un ejemplo concreto nunca ha servido para generalizar.

D

#18, no sé, ¿a Zapatero?

sorrillo

#6 El problema es que olvides que el cliente siempre manda, porqué es el que paga. El trabajo del comercial es conseguir un rendimiento económico del proyecto, negociando el precio y funcionalidades con el cliente.

Si lo que pide el cliente es técnicamente viable y económicamente rentable debe hacerse. No solo sin rechistar sino con una sonrisa de oreja a oreja.

El problema viene de creer que desarrollar es un arte. Los artistas son esos que se mueren de hambre en la calle y se les reconoce el talento cuando llevan 200 años muertos, los artistas hacen genialidades y después se pasan años sin producir nada de nada. Como comprenderás esto para una empresa no es rentable y el riesgo es demasiado alto.

El hecho que si tu te vas seas irreemplazable demuestra una muy mala gestión y poca profesionalidad. Tu desarrollo debería esta suficientemente organizado y documentado para que otro desarrollador pueda ponerse al día en un tiempo razonable. Y el jefe del proyecto debería controlar que eso sea así, si no hace ese control es tan culpable como el desarrollador.

L

#29 Ambos artículos comentan el mismo tercer articulo, vamos que me parece normal que se parezcan.

i

Esta es la antiquísima discusión. Yo creo que es como el dicho de "si un árbol cae en el bosque, qué ruido hará?". Más o menos lo mismo.

Sobre #42 y estándares en el desarrollo de software. Haberlos, los hay, pero no son requeridos por ningún organismo. Como mucho, estar sujetos a la LOPD o a NDA de algún tipo, lo cual, al no requerir de una titulación especial dicha certificación, no sé hasta que punto puede considerarse como tal.

Como bien dice el artículo original, ciertos procesos pueden "ingenierizarse", pero en cualquier campo, en las partes de investigación, la parte de ingeniería es la menor de las partes. Sobre todo en informática. En ingeniería de estructuras, antes de ponerte a intentar fabricar a escala real un edificio horizontal, intentarás demostrar dicha posibilidad a través de un sistema de razonamiento (en ese caso física y matemáticas). Sin embargo en informática lo más parecido a un sistema de demostración razonable que tenemos es el diseño (UMLv2 habitualmente) o la simple demostración real (pruebas de código), siendo la más habitual, la última.

Yo no soy ingeniero titulado, todavía (el Grado EEES algún año caerá), trabajo en una empresa en el departamento de "ingeniería tecnológica", en proyectos de I+D. Los procesos están, más o menos, definidos. Se realizan análisis documental cuando se puede (aunque más tarde o más temprano siempre se asocian "notas" a la documentación), un diseño más grande o más pequeño y luego el desarrollo con su consiguiente memoria.

Cuando trabajas en una consultora no puedes esperar más que un trabajo en el que se usarán siempre un churro de tecnologías que vienen dadas por el comercial, porque venden y quedan bien en la oferta. Harás muchas más horas de las debidas, te pagarán poco y habrá que joderse. La solución la tenéis en la mano, dejad de trabajar para ellos, haced como hicieron otros. Buscad otro tipo de empresas de ing. de software, salid del país. Es fácil venir a meneame pidiendo la buaaambulancia, pero tenéis la solución en la palma de la mano.

i

#49 estándares sobre la propia creación de software? Es decir, a parte de los estándares en diseño, como es el uml, y los estándares RFC o especificaciones de protocolo, yo no conozco muchos más. Luego, están los JSR, propios de Java y establecidos por el JCP (wikipedia para el que no sepa que es).

A lo que me refería con mi afirmación, es que no tienen validez legal. Sin embargo, si tú construyes un puente de estructura metálica, usarás unos pernos concretos, que puedan soportar el peso de dicha estructura, y esos pernos, legalmente, tienen unos requisitos que cumplir, lo que comunmente los mortales denominamos estándares. Desgraciadamente (o no tanto...) en informática no tenemos esos requisitos legales. El día que los haya, y con el consecuente esfuerzo que conllevan dichas certificaciones (tanto personal, temporal y económico) diremos adiós a muchos proyectos opensource.

Lo que empieza un poco a cansar es tanto los FPs con el tema de "he visto ingenieros que no sabían nah!!", como los ings de "los FPs sois unos picateclas" y luego todos a coro "mi jefe es un matemático!!!". De verdad, generalizar huele. He currado con un ingeniero superior con un año y poco de exp que era, como poco, retrasado. Curro con un ingeniero, actualmente, que es un jodido crack. Con FPs más o menos lo mismo. Y gente de fuera, pues no tengo el placer o la desgracia de conocer a ninguno.

albertbp

El tema del "cliente" en la mayoria de las ocasiones puede resumirse en un "no sabe lo que quiere", "no quiere pagar lo que vale", "no entiendo lo que se va a tardar y lo quiere para ayer", pero es el que paga

D

#11 Creo que hizo una pagina web en php y ya esta todo flipao.

D

Veo que DeMarco, además, confunde lo que algunos llaman "radical design" con "normal design". DeMarco dice que se han dado saltos gigantescos sin necesidad de tanto control, pero claro, esos saltos eran "radical design", no un software de nóminas. El "radical design" es lo que hicieron los hermanos Wright, y la gente de google. Pero eso no es el pan nuestro de cada día. Ahí domina el "normal design" y las consideraciones de DeMarco pierden fuerza.

D

#11, pues el que tú estás usando ahora mismo, el Menéame. Qué manera más escandalosa de meter la pata, tío.

¡Toma, toma negativo, tomaaaaa!

g

#19 ¿existe alguna normativa internacional que indique que medidas de seguridad debe tener un software?. Pues para los aviones si, esa es la diferencia.

Si a la creación de software no se le puede llamar ingeniería ¿como lo llamamos?. ¿Arte? Según el artículo debería ser así ya que no tenemos ninguna herramienta para crear el software, solo nuestra intuición y experiencia.

D

#10 Vale, la próxima vez que una aerolínea llegue por la puerta pidiendo un avión que se salte toda la normativa de seguridad habrá que hacérselo sin rechistar.... total... eso de la deontológica profesional es sólo para médicos.....

sorrillo

#9 El cliente, incluso en ese caso que comentas, sigue teniendo razón. Es su producto, es su dinero, es su negocio.

Él asume los riesgos, ya sea conscientemente o por incompetencia, y él deberá asumir las consecuencias.

atzu

#1 Quieres que llore también en tu nombre?
Estoy de acuerdo sobre todo en el tema del control de las aplicaciones y del valor real que tienen.

D

Mierda... tras 5 años de ingeniería informática... creí que una de las pocas cosas que nos diferenciaba de los no titulados era precisamente que nosotros sabíamos hacer ingeniería del software...
Ahora solo nos queda la excusa de que hemos aprendido a pensar gracias a las asignaturas de física que tanto nos servirán en el futuro

KimDeal

El artículo tiene razón en parte.

Un diseño muy rígido y muy planificado limita muchísimo la creatividad y la innovación. Pero por otra parte, los usuarios quieren las aplicaciones para una fecha y sus recursos no son ilimitados. Así que un mínimo de planificación hay que hacer.

La cuestión es que muchos tipos de proyectos informáticos, y el que trabaja dia a día con clientes que se juegan el dinero y tiene fechas límite no tiene nada que ver con el que trabaja en una universidad o con el afortunado que está en el departamento de I+D de una empresa y tiene barra libre para probar ideas nuevas.

Aun así, lo cierto es que ultimamente noto que las nuevas hornadas de programadores apenas han oido hablar del concepto "diseño y programación estructurados".

H

#54 CMMI ayuda a que los proyectos no se vayan de madre, a tener los posibles riesgos identificados y a que los errores sean detectados y corregidos. Pero no ayuda a la hora de diseñar y picar.

CMMI te puede decir como va la construcción de tu edificio. Que las cañerías a partir del 5º piso pueden quedarse sin presión. Y que las paredes del piso 2º están mal levantadas. Pero no te va a ayudar en nada a proyectar el edificio; ni en como calcular pesos y poner las vigas maestras.

Sirve para que los jefes de proyecto tengan el ciclo de vida y la calidad bajo control. Pero no en el desarrollo propiamente dicho.

g

Estoy en total desacuerdo con el autor del artículo

Desarrollar un software complejo es difícil, pero aún lo es más estimar el esfuerzo que requiere ese desarrollo, y hacer que ese esfuerzo sea rentable; y ahí es donde entra la ingeniería del software.

De nada me sirve hablar de proyectos de software libre donde los recursos son ilimitados, donde no tienes un presupuesto limitado, ni unos plazos fijados por el cliente, ni una rentabilidad mínima esperada

¿Cuál hubiera sido el coste de GNU/Linux si hubiera que pagar las horas de trabajo de las miles de personas involucradas en el proyecto? ¿Hubiera sido menor ese coste si se hubieran utilizado metodologías de desarrollo más formales?

d

Estoy totalmente en desacuerdo con el artículo.

Estoy tan cansado entre los que dicen que con Ingeniería del Software (I.S.) se resuelven todos los problemas, haciendo documento tras documento (tanto que ningún desarrollador tiene tiempo de leer) como con los que dicen que la I.S. no vale para nada, como parece que dice el artículo.

¿Que hay gente que no le gusta que se llame ingeniería? Estupendo, que lo llamen de otra forma, yo paso de tirarme discutiendo sobre las palabras más que sobre el significado, si todo el mundo entiende de lo que hablamos (no soy Stallman ).

La I.S. estudia y propone (propone) técnicas y herramientas para desarrollar un software más fiable. No busca la innovación, pero porque no es su cometido.
Si hacemos un software pequeño o entre una persona gran parte de lo que propone no son necesarios, no creo que nadie diga lo contrario (excepto los muy fanáticos que tiran por el MDA, Modern Driven Architecture, no me refiero a la droga ). Que a menudo se proponen cosas excesivamente complejas? Cierto, pero el tiempo suele ir dando la razón a lo adecuado.

Lo que no se sostiene por ningún lado es el usar el Software Libre para comparar.

¿Qué en el software libre no hay documentación?
Es un problema en muchos casos, porque al final para entender algún software para poder entenderlo tienes que tirarte semanas (y meses) leyendo el código, interpretándolo y dando el 'coñazo' en las listas. Un poco más de documentación en muchos casos se echa en falta.
¿Y la comunicación? Las listas de correo, en casi cualquier proyecto hay mensajes y mensajes, que si dejas de participar debes de quitarte de la lista antes de ser saturado.
¿Y la coordinación? Debido a las restricciones (espaciales y temporales) se decibe en responsabilidades separadas, y la decisiones en la 'meritocracia'.

Y usar el software de Google como ejemplo de software sin I.S., puff, sin palabras.

(A no ser claro, que creamos que I.S. es lo que dice el 'gurú' de turno).

Sin acritud.

g

no estoy de acuerdo

D

¿Alguien ha leído el artículo de DeMarco? Es una crítica a las métricas y medidas del software, y no va mucho más allá. En ningún momento dice que haya que abandonar el análisis de requisitos, el diseño, los planes de pruebas, la gestión de configuración y otras "pequeñas cosillas" que constituyen la ingeniería del software.

m

#10 Para fraseando a Muchachada Nui (y no te lo tomes a mal):

"Que quieres analogico? ruido, imagen doble y nieve? pues muy bien!"

Airangel

#41 Claro que hay normas internacionales. Por cierto, unos de mi universidad están desarrollando software para una importantísima empresa aeronáutica (para simuladores de vuelo), y el Ingeniero Aeronáutico que les han asignado en esa compañía no tiene ni puta idea de nada, así que tienes a tres Ingenieros Informáticos desarrollando un simulador de vuelo gracias a la Wikipedia. Eso sí, seguro que nadie se va a quejar de que llamen a ese tipo "Ingeniero" Aeronáutico...

B

#48 Hay estándares y su uso aún no está extendido, porque es la Ingeniería informática y todo lo de alrededor en general es algo muy reciente y esta en bragas.

Muy de acuerdo con la 2º parte, no tienes porque acabar en una cárnica haciendo paginas web's en php.

D

Gilipolleces. La ingeniería del software busca más el desarrollo de una disciplina personal y buenas prácticas en el trabajo que la innovación. Eso todo el mundo lo sabe desde la primera clase de cualquier asignatura relacionada con la ingeniería del software.

A partir de ahí ya interviene la capacidad personal del programador para aportar una solución más o menos creativa. Lo que se busca es que un programador, basándose en toda su experiencia anterior, sepa cuánta cantidad de trabajo puede realizar, y sepa realizar estimaciones ajustadas a la realidad. Si el programador es muy disciplinado, puede llegar al mismo nivel que un programador muy creativo (un genio, vamos).

En cuanto al resto de ingenierías: ¿las métricas usadas en la construcción de edificios aseguran al 100% que este no se caiga? Vaaaaaya, parece que no. Pues con el software igual, aunque mayores, desde hace algunos años se está reduciendo drásticamente el porcentaje de proyectos que terminan en fracaso o fuera de plazo con sobrecostes, y cada vez más se ajustan con éxito a las necesidades iniciales del cliente. No me cabe duda de que dentro de poco este porcentaje crecerá.

Ya se sabe de dónde vienen todas las críticas a la informática como ciencia exacta, así que no me extraño de nada...

o

La universidad es solo una forma de obtener el conocimiento, y tal y como esta la educacion en Ejpaña, no estoy muy seguro de ello.

Como puntualizacion, los mejores profesionales con los que he trabajado y de los que mas he aprendido no estaban titulados.

D

#11 ¿Estas hablando en serio despues de los años que llevas escribiendo aqui todos los dias? No me lo puedo creer.

D

#10 Pero tú tienes la obligación de explicar y documentar los riesgos. Luego, lo que ocurra ya no será culpa tuya.

#15 Qué trenes dices que se chocan por un error informático cuando falla un server de meneame? Para meneame no hace falta ingeniería de software, esto creo que es de cajón.

B

#52 No tiene validez legal porque la profesión no esta regulada. Qué es algo irrelevante para hacer una web pero muy importante para hacer el software que contola el piloto automático.

El marco actual es un sinsentido y un vivalavirgen que no preocupa hasta que algún día pase algo. Porque aquí siempre se legisla posteriori y nunca de forma preventiva.

D

En parte tiene razón. Sin embargo, por otro lado, la informática es algo

Airangel

Por cierto, lo que dice la drae a cerca de un ingeniero: "Persona que discurre con ingenio las trazas y modos de conseguir o ejecutar algo." Y sobre ingeniería: "Estudio y aplicación, por especialistas, de las diversas ramas de la tecnología."...

Así que no entiendo la manía esa de decir que la Ingeniería Informática no es lo que se conoce como una ingeniería clásica...

enderwiggins

Primero; si la ingeniería del software es una pseudociencia, la metereología también
Segundo; la ingeniería del software habla de procesos y de patrones conocidos; reinventar la rueda está muy bien si quieres aprender, pero no es ni útil, ni eficiente y precisamente ahonda en ese problema; no poder predecir los proyectos. Decir que la ingeniería del software no es útil porque "organiza" las cosas es ahondar en esa visión romántica de que el desarrollo de aplicaicones es un arte; y eso es un error; hay partes del desarrollo de un proyecto que dependen del ingenio; soluciones elegantes, algoritmos ingeniosos,... esas partes, son arte. Definir una arquitectura, organizar módulos, tener la especificación de requisitos, pensar en lo que vas a hacer antes de hacerlo... eso no se puede hacer así, a pinceladas. "Soy el vangogh de la programación".Por el santísimo MEV, vaya chorrada.

¿Las métricas? son útiles si previamente tienes todo montado; si no sabes qué quieres medir y para qué, de poco sirven.

¿Estimaciones? hacerlas de la nada no es factible. Antes ha de haber un proceso de recogida de requisitos, evaluación de viabilidad, decisión de tecnología y qué componentes se van a implementar y cuales se vana reutilizar...

Intentar que la ingeniería del software funcione cuando se tiene el concepto de que TODA la creación de software es creatividad e ingenio no es viable. Estoy de acuerdo en que sistemas como RUP son arcaicos, se crea demasiada documentaicón de escasa utilidad y en general, son ineficientes. Pero hay evoluciones y nuevas metodologías (las metodologías ágiles, por ejemplo) que son bastante útiles.

s

Desde mi punto de vista el problema esta en las grandes empresas dirigidas por ejecutivos que nada saben de informática, estos solo saben de presupuestos, de plazos, de documentación tangible y pensable en kilos y de jefecillos que piensan que para dirigir un proyecto software solo se necesitan de algún enchufado que sepa un mínimo de informática(dicese cualquier curso de 10 o más horas realizado sobre ordenador).

R

El comentario que dejé ayer en su blog, y que por alguna razón no ha querido publicar o no he encontrado publicado:

"Aunque estoy de acuerdo, no es lo mismo hacer un meneame, que un programa para el programa espacial de la NASA".

No es que meneame no tenga trabajo y sea una buena aplicación pero no deja de ser una web con AJAX+PHP?, o sea, nada especialmente sofisticado. Luego el tema de la escalabilidad a nivel de red es otro tema pero depende del hosting y demás. Tal vez no lo haya publicado por eso.

El éxito de meneame no es el software (que no se puede comparar al Kernel de Linux ni similares, ni a otros sistemas web parecidos. Y con una innovación existente, pero no exagerada) como para si no los usuarios que estan registrados en meneame.

(Más o menos)

sorrillo

#42 y #19 Si uno de los requerimientos que te pone el cliente para programar ese software es que cumpla una normativa de seguridad entonces el software tiene que cumplirlo. Si el cliente, aunque sea el propietario de una aerolínea, te dice que no debe cumplirlo pues tu software no debe cumplirlo. Es igual que después se use para dirigir aviones, no es tu producto y por lo tanto no es tu responsabilidad.

Ese producto simplemente está hecho a medida de tu cliente que lo usará para lo que le dé la gana. Eso si, no puede nunca obligarte a indicar que cumple tal o cual si no lo cumple. En ese caso estarías incurriendo en un posible delito.

Otra historia muy distinta es como presentas ese producto que has fabricado para ese cliente a tus otros clientes, evidentemente no puedes venderlo como que cumple tal normativa porque no la cumple.

Pero lo que hay que tener claro es que cuando fabricas un producto a medida ese producto no es tuyo, es del cliente.

Si eres una empresa de productos estándar que los vendes a distintos clientes entonces el cliente no tiene derecho a decirte como debe ser tu producto, solo puede sugerirlo y es la dirección de tu empresa quien decide si se hace de esa forma o no. Pero las capas bajas (de director para abajo) deben seguir las instrucciones de sus superiores (excepto si haciéndolo incurres en un delito, evidentemente).

Eso es a lo que comúnmente se le llama ser un trabajador asalariado.

Los que queráis ser artistas adelante, pero asumid las consecuencias de vuestra decisión.

RaiderDK

Estoy de acuerdo en que la IS no es la panacéa, y me ha costado suspender alguna que otra asignatura por ocmentarlo delante de profesores de universidad cuadriculados. Para proyectos pequeños tengo clarísimo que no funciona, para otros más grandes aun tengo mis dudas.

El problema de elevar a arte el desarrollo de software como dice el Sr. Galli, es que aparecen pseudo-gurús-artistas diciendo que su arte es el mejor, y si no lo entiendes eres una analfabeto digital. Y no hay que irse demasiado lejos del citado autor para darse cuenta.

B

Para empezar de junior y con proyectos "normales" como webs muy tipicas o programas tradicionales la Ingeniería del Software es totalmente necesaria para que eso no se convierta en un disparate y un caos total.

Luego, despues de muchos años, si juntas a unos cuantos con mucha experiencia la ingeniería como muchos formalismos en otras áreas lo único que hacen es ralentizar el desarrollo.

Para programas de I+D+d o programas no típicos puede que sea mejor ir a tu bola, es indudable, pero si ya tienes uan experiencia.

Teniendo unos pasos concretos que seguir se aprende mucho más rapido, luego siempre hay tiempo de saltarse pasos.

Pero es que vamos, insinuar que sobra me parece ridículo.

z

#17 a que tipo de ingenieros te refieres? Porque todos sabemos que Ingenieros en Telecomunicaciones en empresas hay a patadas desempeñando el mismo papel que Ingenierios en Informática.

D

#1 !Toma negativo, toma! ¡Que nos los desanimas!

D

#59 añado diferencias... envié el comentario demasiado rápido

1/que en el caso de la informática los planos y el edificio son la misma cosa.
2/que el cemento se agrieta, las piezas hay que llegar a ellas para cambiarlas... pero los while no se agrietan ni hay que cambiarlos. La informática está liberada de muchas restricciones del mundo real.
3/como la inteligencia es la misma y el camino es más llano, podemos liarnos a hacer cosas más complicadas.

D

¿En el desarrollo de software también hay jubiletas criticando la obra? Por curiosidad.

D

ingeniero: "Hombre que discurre con ingenio las trazas y modos de conseguir o ejecutar algo." (DRAE)
ingeniero: "Aquel que tiene por profesión trazar y ejecutar obras de construcción según principios científicos" ("El qui té per professió traçar i executar obres de construcció segons principis científics.", Diccionari Català-Valencià-Balear)
ingeniería: "Estudio y aplicación, por especialistas, de las diversas ramas de la tecnología." (DRAE)

Creo que mi trabajo cumple con estas definiciones. No veo diferencia entre el código de un programa y los planos de un edificio, excepto que en el caso de la informática los planos y el edificio son la misma cosa. Ahora bien, yo soy ingeniero informático, y nunca he sido ingeniero de ninguna otra clase, así que no sé nada de las otras ingenierías. Quizá me equivoco

d

Como he comentado en el propio blog de Galli, tiene parte de razón la idea de que la ingeniería informática es algo diferente a las demás (aunque yo sigo pensando que sí es una ingeniería). Ahora bien, en el resto, creo que está equivocado. Una cosa es el software libre, pero según qué proyectos para empresas no puedes pretender que el programa evolucione sin plazos y especificaciones.

#59, #60: Efectivamente, esa es la diferencia principal: en informática, los planos y lo que hay que hacer son básicamente lo mismo. Precisamente por eso cuesta tanto especificar los programas, porque es tan costoso (o más) que picar el código, y a menudo se prefiere picar directamente para ahorrar ese enorme coste.

Básicamente depende del proyecto. A los jefes de la NASA, por ejemplo, no les vas a venir diciendo que el sofware de control del transbordador va a ser un programa "con vida propia", sin especificar.

D

No estoy nada de acuerdo. La potencia sin control no sirve de nada, y el software esta fatal y los usuarios mosqueados, y de esto deriva la mala fama que tenemos los informáticos. Los proyectos deberían ser mas estructurados y definidos, y eso es la ingeniería del software, y claro que hay técnicas malas, como también las hay buenas, y por supuesto también hay desfasadas y también innovadoras.

a

joe hablais en unos terminos que no os entiende nadie! jejeje

i

#49 Acabo de encontrar, Googleando, que el CMMI es un estándar, cuando realmente tenía entendido que es una certificación de una empresa (véase ISO9001, ISO12001, etc). Aunque la fuente es la dichosa Wikipedia.

Alguien un poco puesto en calidad de software puede aclarar eso?

a

Por dios nada mas leerlo me he dicho, esto me suena, donde he leído esto yo antes...

http://www.codinghorror.com/blog/archives/001288.html

a ver si somos mas originales

D

#21 A Zapatero le he visto hacer tantas cosas... Pero vamos, que al anterior encargado de mantenimiento le ví hacer cosas peores, entre ellas intentar infectar sistemas ajenos.

sorrillo

Hay una parte importante de "ingenieros de software" (también conocidos como programadores o analistas) que son gente que no saben estarse quietos. Se aburren cuando ya empiezan a ser productivos y deciden reenfocar su carrera hacia otras tecnologías para enriquecerse personalmente (que no económicamente).

Esto es lo que les crea la fama de que "lo hacen porqué les gusta" y es que cuando deja de gustarles se van a otro sitio.

Una empresa no puede aprovechar un talento si poco después de formarlo se va de la empresa. No puede sacar un buen rendimiento económico si no puede contar con constancia y perseverancia a su vez que experiencia no solo en la tecnología sino en el entorno empresarial concreto.

Evidentemente que hay muchos ingenieros que no son así, a los que no solo les gusta su trabajo sino que además saben qué es un trabajo. Pero estos son los que no se quejan, los que ascienden, los que progresan. Los útiles.

D

Vaya... ya tardaba en abrir la boca el Cantamañanas profesional. ¡Qué facil es escribir un blog!

D

#24 Los mejores profesionales con los que he trabajado están titulados, pero uno es físico y otro es filólogo. Ambos tienen publicaciones y ambos tienen más inquietudes que cualquier informático.

Desde luego, hay mejores formas de obtener el conocimiento que la universidad, pero eso requiere tener muchas inquietudes y mucha fuerza de voluntad. El que hayan pasado por la universidad al menos te garantiza un mínimo, que no es mucho pero es algo.

D

yo tras conocer por mi trabajo a muchísimos ingenieros entiendo cada vez mejor porque de 7 días de la semana 6 falla algún sistema de renfe.
Hace un tiempo, no mucho, trabaje para informática del departamento de justicia de cataluña cuyos sistemas,como no, están diseñados por un equipo de ingenieros. Pues bien raro era el día en que no se cayeran 2 o 3 servidores(mantenidos casualmente por ingenieros) y rara era el mes en que no muriera la BBDD(diseñada también por un ingeniero) asi que con todo esto me da a mi que mientras nuestros ingenieros sean así miedo me da que desarrollen según el que.

eldelshell

Joder, como se ve que la gente no lee los comentarios, ya han votado este plagio 10 personas desde que puse mi comentario.

m

Ricardo Galli opina sobre algo que no sabe nada y ahora es portada de menéame...

n

Yo propongo que deje de aplicarse la ingeniería en la construcción de aviones. Juntemos a un montón de aficionados y que vayan aportando sus granitos de arena: alas, motores,... Amos, no me jodas. Las barbaridades que hay que escuchar.

eldelshell

#28 Lo Peor es que es un plagio puro y duro de un articulo muy parecido de codinghorror.com

http://www.codinghorror.com/blog/archives/001288.html
Software Engineering: Dead?

"Tom DeMarco is one of the most deeply respected authority figures in the software industry, having coauthored the brilliant and seminal Peopleware as well as many other near-classic software project management books like Waltzing With Bears. For a guy of Tom's caliber, experience, and influence to come out and just flat out say that Software Engineering is Dead"

Aunque no es una traducción directa, la idea es la misma, al pobre Ricardo se le ve el plumero.

D

Yo a quien he visto iterar una lista borrando el primer elemento no era ingeniero, al que ví dejándose un tunel SSH en un servidor productivo para disfrute propio tampoco era ingeniero. Al que ví creando procesos simultaneos que usaban variables compartidas tampoco era ingeniero. El que dio orden a un grupo de ingenieros de acabar en dos semanas "aunque saliera una chapuza" (literal) tampoco era ingeniero. En este último caso salió lo que salió, y a que no sabes a quien pretendían echar la culpa?

DZPM

Hingeñeros de primero a llorar debajo de la línea:
-------------------------------------------------------------------------------------------------------