Etiquetas
Hay profesores, lecturas y autores que te influyen desde joven y forjan las ideas y posturas que te perfilan como profesional. Los que me siguen en este blog, o los que han leído mis argumentos –o los de la ACM– respecto a regulaciones (sobre el que no pretendo volver en este apunto, es sólo una autoreferencia) conocen mi postura bastante escéptica sobre el «estado de la ingeniería del software» y el rechazo fanático a las buzzwords y promesas de panaceas.
Varias veces he comentado y citado que casi toda la bibliografía de ingeniería de software de las últimas décadas es sólo una recopilación de anécdotas y estadísticas, casi una pseudociencia, a la que solemos adorar como si la última metodología fuese la bala de plata, la que dará el fundamento a la ingeniería. Pero hace mucho que ya no creo en esto, sobre todo cuando observas que cada cinco años aparece una nueva mutación de metodología que promete ser La Herramienta de la ingeniería del software.
No recordaba cuál bien el camino recorrido, o cuál fue el punto de partida o desvío tomado, para que haya asumido esta postura muy escéptica y bastante minoritaria entre mis colegas y compañeros. Recuerdo que cuando acabé mi último examen y fui con una beca a hacer mi PFC –enero de 1990– me creía el rey del mambo. Estaba seguro que mi formación y presunto dominio del diseño funcional, la visión «sistémica-holística» (sí, vaya, pero eso fueron también los inicios de Scrum basado en trabajos de Hirotaka Takeuchi en 1986) y el dominio de la metodología de moda en aquél momento –Gane-Sarson, luego «mutó» en la de Yourdon– me convertiría en un sólido profesional informático resolvedor de problemas complejos y que encontraría soluciones espectaculares a los grandes problemas de la informática.
Pero cuando quince meses después acabé mi PFC tenía una visión completamente diferente. Cada vez que alguien me explicaba las fantásticas bondades de una metodología nueva, o que casi al principio de una conversación soltaba la frase «un ingeniero no tiene por qué ser un programador» se me ponían los pelos de punta y sólo atinaba a pensar que ojalá no me tocase trabajar con esa persona.
Con el tiempo me convertí en un escéptico casi radical sobre el «[no] cientificismo» y la falta de rigurosidad de metodologías. En el mejor y la mayoría de los casos sólo lo veía como intentos de estandarizar una guía de buenas prácticas y estándares de documentación. Y por otro lado cogí el gusto por aprender a programar y admirar y disfrutar con el trabajo de los que se definían como «programadores» antes que «ingenieros» (o «doctores» o «científicos»)-
Hoy rvr en Barrapunto me hizo un bonito y entrañable regalo, me hizo redescubrir cuál fue una de las lecturas de aquellos años que tanto me influyó. Creo que fue el punto crítico. Se trata de unos de los ensayos más provocadores de Dijkstra –escrito en 1988, que blogger espectacular hubiese sido–: On the Cruelty of Really Teaching Computer Science (en castellano).
Aunque en aquellos años casi no conocía a Dijkstra, creo que fue el director de mi proyecto o alguno de los que trabajaban en el laboratorio el que me lo pasó (teníamos Internet y estábamos todo el día enganchados bajando ficheros por FTP anónimo y leyendo listas de correos y las news).
Rescato una de las frases que más me impactaron como «ingeniero», por aquellas épocas yo tenía una perspectiva radicalmente opuesta:
[…] Lo haré explicando una serie de fenómenos que de otra manera serían extraños por la frustrante –pero, como ahora sabemos, condenada– ocultación o negación de su aterradora extrañeza.
Cierta cantidad de estos fenómenos han sido agrupados bajo el nombre de «Ingeniería de Software». Así como la economía es conocida como «La Ciencia Miserable», la ingeniería de software debería ser conocida como «La Disciplina Condenada», condenada porque ni siquiera puede acercarse a su meta, dado que la misma es en sí misma contradictoria. La ingeniería de software, por supuesto, se presenta a sí misma como otra causa valiosa, pero es un colirio: si lee cuidadosamente su literatura y analiza lo que realmente hacen quienes se avocan a ella, descubrirá que la ingeniería de software ha adoptado como su estatuto «Cómo programar si usted no puede».
[…] La práctica está impregnada de la confortable ilusión de que los programas son simplemente dispositivos como cualquier otro, la única diferencia que se admite es que su fabricación pueden requerir un nuevo tipo de expertos, a saber: programadores.
[…] Han pasado ya dos décadas desde que se señaló que el testing de programas puede convincentemente demostrar la presencia de errores, pero nunca puede demostrar su ausencia. Después de citar devotamente este comentario bien publicitado, el ingeniero de software vuelve al orden del día y continúa refinando sus estrategias de testing, tal como el alquimista de antaño, quien continuaba refinando sus purificaciones crisocósmicas.
[…] En el mismo sentido debo llamar la atención sobre la sorprendente facilidad con que se ha aceptado la sugerencia de que los males de la producción de software de deben, en gran medida, a la falta de «herramientas de programación» apropiadas.
Hay que leer todo el ensayo para entenderlo mejor y entender la justificación. No es tan difícil, tampoco fácil. Es un ensayo de esos de gran calado (y por los pocos comentarios que leí en Barrapunto, la mayoría no lo debe haber leído, o no lo entendió).
Ojalá lo disfrutéis tanto como yo la primera vez que lo leí y nuevamente ahora, casi dieciocho años después 🙂
PS: Creo que ahora comprendí a Dijkstra mucho mejor que la primera vez.
Ricardo Galli, de software 
Pues ya me había apuntado el documento a favoritos para leérlo este fin de semana, pero si encima hay recomendaciones como la tuya creo que lo leeré mañana mismo (¿esto se llama ser «palmero»?)
Pero me ha sorprendido una cosa de las que has dicho…
¿No conocías a Dijkstra al terminar tus estudios? ¿Y su famoso algoritmo para la búsqueda de caminos mínimos en un grafo?
Bueno, no te culpo. No aprendemos todo lo que nos cuentan en la facultad (una lástima, pero es así).
Del fragmento que has publicado yo me quedo con este:
¡Eso no se lo digas a uno de sus defensores o te sacará los ojos!
Copio y pego:
«Segundo, explica por qué el mundo de las matemáticas ha ignorado el desafío de la programación: los programas eran fórmulas mucho más largas que las usuales, al punto que ni siquiera las reconocieron como tales.»
Siento decir que esto es cierto y falso a la vez. Las matemáticas estudian algoritmos. Los algoritmos han estado en las matemáticas prácticamente desde el principio de las mismas. Lo que no estudia, y en mi más humilde opinión de alumno de ciencias matemáticas (rama computacional) nunca hará, es programas en el sentido de implementación. Sinceramente, creo que está fuera del ambiente de estudio de las matemáticas (este punto es difícil de explicar puesto que me refiero a la implementación de un algoritmo en concreto, por ejemplo, en métodos numéricos se nos enseñan diversos errores y problemas de la representación binaria de un número). A pesar de eso, si se quiere usar un ordenador (teorema de los cuatro colores), sí que habría que probar la validez formal de la implementación.
En otro párrafo:
«En el largo plazo espero que la ciencia de la computación trascienda a sus disciplinas padres, matemática y lógica, efectivamente realizando una parte significativa del Sueño de Leibniz de proveer un cálculo simbólico como una alternativa al razonamiento humano. (Por favor, note la diferencia entre «imitar» y «proveer una alternativa a»: a las alternativas se les permite ser mejores.)»
Sinceramente, como estudiante de Matemáticas creo que tengo un contacto bastante más directo con matemáticas que la media (he dicho contacto, no conocimiento) y, por FSM, si esto se consigue, daré palmas con las orejas. Sin embargo, pienso que el descubrimiento, de realizarse, se realizará en las matemáticas, dejando la implementación para la ciencia de la computación. Siguiendo con el tema:
«(0) la comunidad matemática, que quisiera continuar creyendo que el Sueño de Leibniz es una ilusión irreal»
De momento, que yo sepa, no está probado, ni no probada su existencia. De todas formas, si he sido expuesto a la suficiente cantidad de demostraciones como para saber que de existir va a ser bastante complicada (aunque, a su vez, seguramente de una bella simpleza). De todas formas, vendría muy bien que algo así existiera, pues los teoremas más «gordos» tardan años en ser demostrados. Después de eso, pasan años hasta ser aceptados (hay muchas sutilezas que fuera de la carrera es extraño ver).
Finalmente (no copio el texto porque son varios de los párrafos finales) estoy de acuerdo con lo de que se debería enseñar métodos formales el primer año. Es la razón por la que estudio matemáticas y no ingeniería informática. Ahora mismo estoy de Erasmus, y tengo cursos en la facultad de Computer Science. Demostraron que el flujo de un grafo es menor o igual que cualquier corte (perdón si la nomenclatura está mal, estoy traduciendo directamente del inglés). De lo que dedujeron que el flujo máximo es igual al corte mínimo. Eso, un matemático, no lo hubiese aceptado (un amigo y yo nos descojonamos en el descanso).
Perdón por el ladrillo.
@joan
> ¿No conocías a Dijkstra al terminar tus estudios? ¿Y su famoso algoritmo para la búsqueda de caminos mínimos en un grafo?
Primero que dije «casi» 🙂
Segundo que saber el nombre del autor de unos algoritmos (o los semáforos, que vaya si tiene impacto en el software moderno) no es lo que yo acepto como «conocer». Con el tiempo supe mucho más.
Por ejemplo sé algunas de las cosas que hizo Gauss, pero casi no conozco a Gauss (o al menos lo «conozco» mucho menos que a Dijkstra).
> No conocías a Dijkstra al terminar tus estudios? ¿Y su famoso algoritmo para la búsqueda de caminos mínimos en un grafo?
En realidad muy pocos profesores «cuentan» de la historia y sus personajes, se limitan a citar el nombre. Craso error, siempre intento contar el «inventor», su contexto y motivación para resolver el problema.
> No conocías a Dijkstra al terminar tus estudios? ¿Y su famoso algoritmo para la búsqueda de caminos mínimos en un grafo?
Ya, aunque opino lo mismo si lo digo con otras palabras más suaves («todo ingeniero debería ser buen programador») ya me machacan 🙂
> En realidad muy pocos profesores “cuentan” de la historia y sus personajes, se limitan a citar el nombre. Craso error, siempre intento contar el “inventor”, su contexto y motivación para resolver el problema.
Cierto, y si algo puedo reconocer es que esas historias que explicas en clase, le quedan grabadas a uno, incluso ayudan a recordar hasta los mínimos detalles de las soluciones.
PS: Aprovecho para saludarte, que casi nunca te comento los artículos 😉 A ver si nos vemos en un futuro no muy lejano.
Yo con los años he llegado también a la conclusion de que un ingeniero en informática que no sabe programar no es ingeniero, independientemente tenga papel o no.
A mi la idea de comparar al ingeniero con el arquitecto y al programador con el albañil me parece simplemente estúpido, aunque sea cierto que los arquitectos por norma no suelen hacer pasta de cemento.
Tampoco entiendo porque la mayoría de los que terminan informática se creen que su misión en la vida es dirigir, un equipo, un departamento, …
Y por mi parte, mi mayor problema es saber presupestar los trabajos de antemano, es decir estimar el coste de producir y crear un software que no existe. Y tengo claro que utilizando técnicas propias de ingeniería de software no difieren en sus estimaciones a la utilización de un cubilete y unos dados, aunque este último métido es mucho más económico (especialmente en presupuestos rechazados).
Y añado que ojala pudiese dedicarme unicamente a programar en lugar de organizar y dirigir.
Totalmente de acuerdo. Y lo enlazo con lo segundo.
Imagino, que los profesores a veces no tienen tiempo para más si quieren dar todo el temario (y tu me lo podrás confirmar o desmentir). Pero ahí es donde juega el papel el alumno, no basta con quedarse lo que te cuentan en clase. Por ejemplo, la primera vez que yo oí hablar del algoritmo de Dijkstra fue en una asignatura de álgebra y matemática discreta y simplemente nos dijeron: «El algoritmo de Dijkstra sirve para calcular el camino mínimo entre dos vértices de un grafo. Para usarlo en el Mathematica debéis importar el fichero X y hacer Dijkstra[Grafo, (V1,V2)]». Lamentable. Pero bueno, la Wikipedia y Google está para algo. Quien no está informado es porqué no quiere…
PS: Ahora que termino de escribir el comentario me doy cuenta de que quizás sea un poco optimista respecto al papel del alumno y bastante friki al buscar la biografía de Edsger en mi tiempo libre y interesarme un poco por su algoritmo (el tema de los semáforos, se lo que son, pero todavía no los he estudiado como para ser consciente de su importancia)…
@miguel
> A mi la idea de comparar al ingeniero con el arquitecto y al programador con el albañil me parece simplemente estúpido
Esto es uno de los temas centrales del ensayo, los excesos del razonamiento por analogía. De hecho dice que fue un exceso típico del medioevo y unas de las razones del declive de España.
> aunque sea cierto que los arquitectos por norma no suelen hacer pasta de cemento.
Pero seguro que sabría hacela, y las combinaciones posibles con los tipos diferentes de cemento. Si no lo sabe podría aprenderlo en muy pocas horas, incluso a ser buen albañil. Por eso también me parece ridícula la analogía (incluso la analogía de construir software con edificios es ridícula).
«De más está decirlo, esta visión acerca de qué trata la ciencia de la computación no es universalmente aplaudida. Por el contrario, ha encontrado oposición –y a veces hasta violenta– desde todo tipo de direcciones. Menciono como ejemplos:
(0) la comunidad matemática, que quisiera continuar creyendo que el Sueño de Leibniz es una ilusión irreal
(1) la comunidad empresarial, quienes, habiéndoseles vendido la idea de que las computadoras harían la vida más simple, no están mentalmente preparados para aceptar que sólo resolvieron los problemas más simples al precio de crear uno mucho más difícil
(2) la subcultura del programador compulsivo, cuya ética prescribe que una idea tonta y un mes de codificación frenética deberían bastar para hacerlo millonario de por vida
(3) los ingenieros en computación, quienes quisieran continuar actuando como si fuera solamente cuestión de mayor flujo de bits o más flops por segundo
(4) la milicia, quienes están hoy totalmente absorbidos por el negocio de usar computadoras para transformar partidas de miles de millones de dólares en la ilusión de seguridad automática
(5) todo tipo de ciencias para las cuales la computación ahora actúa de alguna especie de refugio interdisciplinario
(6) el negocio educativo que siente que, si tiene que enseñar matemática formal a los estudiantes de Ciencias de la Computación, también debería cerrar sus escuelas.»
Y tan provocador xD, es que da para todos lados xD
Y 18 años después ya hablaba de Bolonia xD:
«Así, si miro en mi borrosa bola de cristal hacia el futuro de la educación en ciencias de la computación, veo sobrecogedoramente la deprimente imagen del «Negocio acostumbrado». A las universidades les seguirá faltando el coraje de enseñar ciencia dura, continuará orientando mal a los estudiantes, y cada nuevo escalón de infantilización del currículum será exaltado como progreso educativo. «
Quería decir 18 años antes. Perdón por la errata (y por tanto comentario).
@pepe
> Y 18 años después ya hablaba de Bolonia xD:
Aquí hay que aplicar lo de «al César lo que es del César». El proceso de Bolonia no apunta a la infantilización de curriculums, de hecho casi va en el sentido contrario al obligar a meter más «ciencia» en las asignaturas de formación básica. Así que no es achacable al proceso en sí.
Es verdad –lo he visto– que algunos planes de estudio en su afán de parecer modernos y actualizados son infantiles a más no poder. Pero eso es culpa nuestra, de los profesores que hacemos los planes por ser tan capullamente infantiles de caer en modas y buzzwords, y también en parte a esa especie de doctrina que el «hay que acercar más las universidades a las empresas» significa reducir los planes a las tonterías que demandan las empresas locales.
Pero no todos estamos por la labor, al menos no yo, pro ejemplo:
https://gallir.wordpress.com/2008/04/28/sintonizar-universidades-y-empresas-pero-%C2%BFque-debe-saber-un-ingeniero/
https://gallir.wordpress.com/2008/05/19/tras-anos-de-desacreditar-las-ciencias-y-las-ingenierias/
https://gallir.wordpress.com/2008/05/20/esas-asignaturas-que-no-sirven-para-nada/
Desde luego el estado del arte en ingeniería de proyectos software (por diferenciarlo de «Ingeniería del software», que trata sobre ciclo de vida y metodologías de desarrollo de software) no se parece nada al del momento en que Dijkstra escribió en ese artículo. Ahora podemos atacar proyectos enormes con costes mucho más reducidos manteniendo un nivel de calidad aceptable
En cuanto a lo de pseudo-ciencia, entiendo lo que dices pero no lo comparto:
1, Durante mucho tiempo ha sido así. En pequeños proyectos sigue existiendo, pero ha llovido mucho y los grandes proyectos de éxito (en términos de alcance,coste,calidad) son ejemplos de rigurosidad.
2, Los ingenieros informáticos tendemos a pensar que la propia naturaleza de nuestra rama la hace inabarcable y que cada nuevo día de trabajo nos traerá sorpresas. Eso es cierto, pero también le pasa en buena medida a cualquier ingeniero (y algo menos al arquitecto). Eso sólo significa que nuestra estimación de costes tendrá mayor error, no que estemos gestionando algo completamente alejado de cualquier proyecto de ingeniería.
La «Ingeniería del Software» es una parte de la formación que un ingeniero de proyectos software debe recibir. Es la carrera y no sólo las asignaturas informáticas (matemáticas, programación, algoritmia, TADs, SSOO, BBDD, compiladores) la que crean un ingeniero:
-Recursos humanos
-Organización de empresas
-Gestión de proyectos
-Estadística aplicada
-Gestión financiera
-Optimización (investigación de operaciones, microeconomía)
-Explotación de sistemas informáticos
-Calidad
-Gestión de sistemas productivos
En mayor o menor medida todas estas materias están contenidas en la titulación, y son las que convierten un informático en ingeniero.
@leo
Obviamente no estoy de acuerdo, pero no voy a discutir salvo un par de frases:
> no se parece nada al del momento en que Dijkstra escribió en ese artículo.
¿Qué es lo que ha cambiado tanto en el fondo? ¿Qué es lo que Dijkstra no sabía? (además puse otro enlace de una opinión similar de otro reconocido «ingeniero» hace muy pocos meses).
Para hacer semejantes afirmaciones de calado hay que justificarlas muy bien. Todos esos temas que mencionas luego ya se conocían en 1988.
> Ahora podemos atacar proyectos enormes con costes mucho más reducidos manteniendo un nivel de calidad aceptable
El coste no tiene nada que ver, hay muchos factores que fueron los que han hecho que bajen los costes: los PCs y su potencia, impresionante bajada del precio del hardware y comunicaciones (que es casi cero con internet), disponibilidad enorme de sistemas de software libre (y privativos de bajo precio o gratuitos), la estandarización (TCP/IP, HTTP, SQL, XML, etc.), herramientas de desarrollo más sofisticadas (pero esto no tiene nada que ver con el fondo de la cuestión, ya lo dice en «los males de la producción de software de deben, en gran medida, a la falta de “herramientas de programación” apropiadas»).
@gallir
En efecto. Quizá lo que debía haber dicho es que 18 años antes ya veía como iban a plantear algunos Bolonia (en teoría el proceso en sí no debería suponer problemas, sino incluso todo lo contrario, si se hiciera bien).
Pero por ejemplo, en la universidad de Murcia, donde las cosas creo que no se están haciendo especialmente mal (sino al contrario), se pasa de una asignatura de 9 créditos de autómatas y lenguajes formales y otra de 4,5 de computabilidad (donde por cierto se daba la materia que Dijkstra comenta al final del ensayo), a una única asignatura de autómatas y computabilidad de 6 créditos ECTS.
Y digo que en Murcia no se hacen las cosas mal porque no se plantean (de momento) cosas como esta (Grado en Ingeniería Multimedia):
http://www.salle.url.edu/portal/lasalle/Controller?mvchandler=portals&action=start&showingIndex=true&use-lang=es&screen=workspace&idSection=6009&id_especialidad_plan_estudios=GM&onSom4=multimedia&onSomUrl4=1096&tipus_titulacio=6
Y es cierto que la infantilización no es culpa de Bolonia. Por ejemplo la reducción de temario no es algo nuevo que se invente ahora. El problema es que ante una reforma así es cuando se puede aprovechar para que esa infantilización llegue de golpe (aunque muchos nos opongamos, como tú o yo).
Siento darte un argumento infantil y pueril, pero la ingeniería, por definición, no es una ciencia (y menos aún una pseudociencia). Busca definiciones por ahí. Wilipedia, por ejemplo:
«La ingeniería es la profesión que aplica conocimientos y experiencias para que mediante diseños, modelos y técnicas se resuelvan problemas que afectan a la humanidad.»
Tampoco se puede identificar una ingeniería con una herramienta o metodología en particular.
Aquí acabo.
Admitiendo que la IS es pseudo-ciencia. ¿Esa es razón suficiente para ignorar todas las metodologías y estándares de la misma hasta el punto de que muchos proyectos carecen de documentación alguna?
Esta misma pregunta ya te la hice en su día respecto a Meneame, y ya hablamos del tema, lo que no recuerdo es el post en cuestión.
Me alegro de volver a leer este tipo de posts. Tanta blogosfera, regulación etc ya cansa.
Creo que tu visión de ingeniería del software encaja perfectamente con la visión de Jacks W. Reeves [1] en la que el código es el documento de diseño definitivo.
Este enfoque explica que la complejidad del software es muy alta porque hay que llegar hasta el código para poder definirlo con precisión.
El código fuente es el elemento central de la ingeniera del software y algunos ingenieros de software parecen olvidar esto y se quedan en sus diagramas UML, etc. No digo que haya que eliminarlos, simplemente que no hay que quedarse ahí, y que lo importante es el código, no los diagramas.
[1] http://www.developerdotstar.com/mag/articles/reeves_design_main.html
@quicksort
Ains, esa manía tan tradicional de ver todo como si fuesen catedrales 🙂
Estás confundiendo «no tener documentación en un formato X al nivel semántico Y» con «no tener documentación» y/o «no seguir metodologías o patrones».
No es lo mismo. Ya lo comenté antes, en el caso del Menéame no hay documentación en «formato X» al nivel semántico que pretendes (no sé cuál), porque tienes a mano la mejor documentación que a mí (diseñador y desarrollador principal) me interesa: el código fuente (el nivel semánticos de mayor precisión) y el historial de su evolución: http://svn.meneame.net/index.cgi/branches/ (con comentarios de «intenciones»).
Además es relativamente sencillo por lo que no lo necesito documentar a un nivel semántico superior, se usan patrones básicos conocidos como el ActiveRecord para las clases principales (links, comments, posts, votes), base de datos relacional con SQL bastantes simples, modularización bastante clara de ficheros y directorios, etc. Cualquiera que sepa más o menos de programación web y PHP lo puede entender rápidamente. A eso súmale el wiki o las explicaciones técnicas y de los «APIs» en http://blog.meneame.net
Aún así, el software es libre, eres también libre de escribir una documentación en nivel semántico y formato que desees, si está bien y tiene licencia libre la agregaré al SVN y al wiki.
Si tienes problemas para entender determinadas cuestiones, pregúntame, la responderé sin problemas. Si sabes y quieres mejorarlo (claro que es mejorable), envíame los parches que los miro, discutimos e integramos si estamos de acuerdo.
Si no te interesa nada de eso, ¿por qué debería haberme tomado el trabajo de preparar documentación adicional que no necesito? (tengo notas y diagramas inciiales en un cuaderno, en realidad ya ni falta me hacen, es más fácil recurrir directamente al código/esquema en cuestión)
Es algo que siempre discuto y cansa de explicar. El núcelo Linux (con más de 6 millones de línea de código y más de 1000 programadores activos «concurrentes») no tiene «documentación oficial» [a niveles semánticos altos, el código sí que está, la listas de correos, el historial], y no tuvo ningún tipo de documentación por varios años hasta que empezaron a salir tutoriales, referencias, libros y hasta el web kernelnewbies para los que no entendían. Pero eso no significa que no se sigan metodologías o «que no haya ningún tipo de documentación», o que era responsabilidad/obligación de Linus Torvalds hacerlas, sólo faltaría. Simplemente que la forma de desarrollo es otra distinta, un paradigma diferente que no es comparable.
Lo mismo que acabo de contar vale paa cualquier proyecto de este tipo, sobre todo los de web. ¿Dónde tienes la documentación de diseño del WordPress, Drupal, KDE, etc. etc.? ¿quién hizo las que existen? ¿las hicieron los diseñadores/programadores originales o si las hay es colaboración de la comunidad?
Lo que vale al final es el código, si fuese privativo o no tuvieses acceso a determinados módulos, vale, es un requerimiento para desarrollar otros módulos. Pero si es libre no hay excusa posible ni razonable para exigir que el que lo programó también te entrege un UML con el esquema de la base de datos (cuando es tan fácil como mirar el http://svn.meneame.net/index.cgi/branches/version3/sql/meneame.sql) o que te haga el dibujo de las clases y «activerecord» cuando son fáciles de ver en el código.
Como respuesta general a este tipo de cuestiones en software libre: show me the code, o show me your docs. Como dice Dijkstra, eso que pides es sólo colirio. Pero además no pretendas exigirme que lo prepare yo 😉
> Aún así, el software es libre, eres también libre de > escribir una documentación en nivel semántico y
> formato que desees, si está bien y tiene licencia
> libre la agregaré al SVN y al wiki.
Como sabrás, la calidad de la documentación creada a partir de «ingeniería inversa» de código ajeno no puede llegar ni por asomo a la calidad y valor de la documentación escrita por los participantes del proyecto en sí. No digo que sea inútil ni mucho menos, simplemente que no es lo mismo.
La documentación a posteriori como mucho puede reflejar qué es lo que hay y un enfoque difícilmente correcto de la evolución cuando la información de primera mano son los comentarios de los commits al svn.
> ¿por qué debería haberme tomado el trabajo de preparar documentación adicional que no necesito?
Precisamente la documentación que realmente tiene sentido es la que sirve o sirvió para desarrollar el proyecto. Ciertamente un error común es hacer documentación, decenas de diagramas por ejemplo o casos de uso ultradetallados con el único fín de documentar. No debe ser así, debe documentarse lo que realmente puede resultar útil.
> (tengo notas y diagramas inciiales en un cuaderno, en realidad ya ni falta me hacen, es más fácil recurrir directamente al código/esquema en cuestión)
Seguramente porque lo conoces al dedillo. Sin embargo, ese tipo de información puede ser útil para otras personas. Ahí está la otra finalidad de la documentación que no es otra que la comunicación.
> El núcelo Linux (con más de 6 millones de línea de código y más de 1000 programadores activos “concurrentes”) no tiene “documentación oficial”
En el mundillo hacker, por llamarlo de alguna manera (sin sentido peyorativo) parece como si estuviera mal visto documentar o seguir cualquier metodología, incluso molestarse en conocerlas. Está claro que así se evita caer en el error de los abusos de las metodologías pero el caso extremo para muchos proyectos también puede ser igual de contraproducente.
> Lo que vale al final es el código, si fuese privativo o no tuvieses acceso a determinados módulos, vale, es un requerimiento para desarrollar otros módulos
Efectivamente, no hay que perder de vista que mal que nos pese la mayoría (número) de los proyectos del día a día son software privativo, y sin acceso al código fuente la documentación de calidad deja de ser opción recomendable para pasar a ser crítica.
> Pero además no pretendas exigirme que lo prepare yo
Ni mucho menos.
Sin embargo, ya me ha tocado tener que continuar proyectos de otros sin documentación alguna, simplemente código, y por mucho que el código fuente esté disponible hay muchos detalles del proyecto que se pierden o se pierde muchísimo tiempo en entenderlos. Yo sin embargo sí que procuro aplicar algunas cosas de las pocas que conozco de IS, precisamente aquellas que yo agradecería que otros realizaran, empezando por documentar los requisitos funcionales.
@quicksort
> En el mundillo hacker, por llamarlo de alguna manera (sin sentido peyorativo) parece como si estuviera mal visto documentar o seguir cualquier metodología, incluso molestarse en conocerlas.
Creo que de estos prejuicios derivan muchos otros. Más vale aclararlos de entrada.
¿Tú crees de verdad que Linus Torvalds no hizo documentación inicial porque no conocía ninguna metodología? ¿de verdad piensas eso? (es ingeniero informático) ¿crees que es tan difícil aprender una metodología? ¿crees que es más fácil programar un git que escribir documentos? ¿crees que las metodologías son un secreto guardado por las facultades informáticas?
Seguramente me dirás que no a todas, por lo que queda en gran parte desmentido el mito. Pero hay más.
Hacer documentación cuesta mucho trabajo, pero cuesta aún más trabajo mantener esa documentación para que refleje las «ideas iniciales» y luego el código de verdad. Eso son horas hombre «robadas» al desarrollo. Por eso es un balance que hay que hacer, no tiene sentido que Torvalds o Alan Cox se encarguen de eso.
Una persona con mucha experiencia o que conozca bien un proyecto preferirá discutir idea fundamentales y luego implementarlas para el «peer review» que estar haciendo UMLs que en realidad dicen poco cuando se trata de ideas concretas.
Y por último pero no menos importante: puede haber casos donde ninguna metodología te de los beneficios que compensen el overhead que genera. Pasa típicamente con los proyectos de software libre que han violado todas las normas de la «ingeniería tradicional»: cientos o miles de personas que no se han vista ninguna vez en su vida trabajando en un proyecto complejo sólo comunicándose por email o listas de correo.
Según esa «ingeniería tradicional» (que todavía da el coñazo, y mucho) no podría existir ni Linux ni GNU/Linux.
Esta ingeniería tradicional sólo pensaba en proyectos tipo «catedral» (por eso lo mencioné al principio): todos los requisitos son conocidos, se conocen los resultados esperados desde el principio, se conoce perfectamete toda la tecnología y sus capacidades de antemano, no habrá cambios importantes hasta que todo esté acabado, etc. etc. Por eso afirman que es posible definir el sistema hasta niveles de detalle bastantes profundos sin haber escrito una línea de código.
Esa forma de desarrollo no es compatible con la inmensa mayoría de proyectos, mucho menos con los novedosos o innovadores, donde justamente se trata de llevar la tecnología al límite, donde no estás seguro cuál será el resultado final ni sus patrones de uso, sabes que le tecnología en dos años habrá cambiado –por ejemplo navegadores y estándares, o hardware para un SO–, no sabes los requerimientos de tus usuarios porque están repartidos por todo el mundo y no estań dispuestos ni puedes tener sesiones para extraer requerimientos (que tampoco lo saben).
El otro problema es que la cantidad de niveles semánticos y de subdivisión que hay en software (Dikstra habla de 10^9) que sobrepasa en muchos ordenes de magnitud a otras ingenierías (da el ejemplo de «medio de transporte», comparar un bebé con un avión, la diferencia es de sólo 10^3…).
Por eso la «ingeniería tradicional» ha petado seriamente, por eso es que hasta hace dudar que sea ingeniería. El sólo hecho que no haya un conjunto mínimo de herramientas genéricas –como en otras ingenierías– ya pone en duda todo.
Recién hace unos años, con la aparición de las ágiles, el «source code peer review» (que se hace en casi todos los proyectos de SL y Google lo usa ahora en todos sus proyectos) e incluso con algo de la Scrum se están tomando en cuenta estos escenarios.
Pero además hay otra cosa. Recién con el software libre se pueden hacer estudios, porque los datos están allí afuera. Pero al «ingeniería tradicional» todavía se resiste a usar las herramientas matemáticas-formales para analizar esos datos y se empecina en juntar anécdotas y acompañarlas de estadísticas que nunca podrás validar y que sólo logran que te fíes que funcionan… hasta que tu proyecto peta teriblemente porque no han servido para nada y has hecho gastar dinero y tiempo forzando unas prácticas antinaturales.
Y aquí, en vez de hacer la autocrítica por la mala elección o por el «estado de la ingeniería», el ingeniero tradicional se justificará echando la culpa a sus programadores porque «no saben aplicar metodologías».
«Too much» para la ingeniería 🙂
@gallir
Dos cosas antes de decir nada, y sin ánimo de montar polémica: Voy sólo a poner una parte de tu texto, aunque me lo he leido todo, y me gustaría que lo entendieras como una réplica a todo su conjunto, no sólo al extracto:
> Lo que vale al final es el código, si fuese
> privativo o no tuvieses acceso a determinados
> módulos, vale, es un requerimiento para
> desarrollar otros módulos.
Cierto. El código es lo que al final la máquina transformará en proceso, pero existe un problema fundamental en el desarrollo, y que es previo a su implementación: Las necesidades.
La ingeniería del software busca ser el nexo de unión entre lo que el sistema hace (el código, al fin y al cabo) y lo que el sistema tiene que hacer (lo que el cliente necesita), de tal forma que las metodologías, y sus diagramas o documentación, buscan no sólo informar al equipo de desarrolladores, sino también establecer los términos de un acuerdo de desarrollo entre un proveedor y un cliente.
Reducirlo todo al código podría ser una opción válida si:
1) El cliente supiera programar, y por lo tanto tuviera la capacidad para entender qué se ha hecho. Además, si así fuera, ¿para qué necesita un desarrollador?
2) La misma persona que desarrolla es la misma persona que diseña, y la misma que prueba, y la misma que lo mantiene, y la misma que lo modifica o reimplementa, o al menos tienen una relación tan estrecha con el proyecto que son capaces de realizar un seguimiento completo de su evolución
3) El código hace exactamente lo que el cliente deseaba que hiciera, y cuenta con mecanismos para corroborarlo
De hecho, una de las áreas de la ingeniería del software que más literatura ha generado, y que está incorporada como estándar tanto por ISO como por IEEE es la captura de requisitos, y lo curioso del tema es que no busca tanto facilitar al desarrollador los medios para hacer las cosas, sino facilitar al cliente la interpretación de lo que está pidiendo (incluyendo incluso apartados específicos para definiciones y glosarios) o la interpretación por parte de un tercero en caso de controversia.
Porque, además, el código no es algo que se pueda firmar antes de contratar un servicio como es el desarrollo de software.
@gallir
Y respecto a lo que dices del software libre vs. ingeniería tradicional, coincido contigo.
Pero es que el perfil de producto de software libre y su modelo de desarrollo buscan la eficacia frente a la garantía.
Ninguno es mejor que otro, son sencillamente diferentes. Ambos pueden dar lugar a críticas, porque ninguno de ellos es la piedra filosofal aplicable a todos los paradigmas.
Por hacer una analogía, es como si tuviera que hacer un esquema eléctrico para cambiar los enchufes de mi casa.
Y para cambiar los enchufes de mi casa, no hace falta ni regulación, ni colegio (ya está, ya lo he dicho :P).
Idem para el software libre.
@pablo perez
Creo que está contestado en mi comentario anterior, especialmente el tema de requisitos y lo que «el cliente quiere».
Lo que me dices de ISO supongo que se refiere al ISO 12207. Pero eso es sólo unas metarecomendaciones de buenas prácticas. No sé, es como decir que el ISO 900x es fundamento de la ingeniería X.
Pero insisto, hay muchos proyectos que no sabes lo que el cliente quiere, porque tú estás inventando una nueva solución nueva (o llámale «necesidad» nueva). Si siempre supiésemos lo que el cliente quiere, el software nunca innovaría en los negocios, empresas o sociedad. Simplemente emularía más rápido lo que ya se hace ahora. Mejor que «emular» es hacer algo distinto.
> Lo que me dices de ISO supongo que se refiere al
> ISO 12207. Pero eso es sólo unas
> metarecomendaciones de buenas prácticas.
> No sé, es como decir que el ISO 900x es
> fundamento de la ingeniería X.
Si. Y me hace gracia que hagas esa comparación, porque siempre utilizo el mismo ejemplo para hablar de las ISO 900x o de ‘cosas’ como CMMi (tan de moda ahora): Que un fabricante de coches tenga la ISO 900x no significa que haga coches de cuatro ruedas, significa que si hace coches de tres ruedas, los hace todos igual.
> Pero insisto, hay muchos proyectos que no sabes lo
> que el cliente quiere,
Hay muchas veces que ni siquiera el cliente lo sabe. 😉
> porque tú estás inventando una nueva solución nueva
> (o llámale “necesidad” nueva). Si siempre
> supiésemos lo que el cliente quiere, el software
> nunca innovaría en los negocios, empresas o
> sociedad.
Creo que estás mezclando dos conceptos: Innovación e Ingeniería.
Que desarrolles una solución para una necesidad que ni siquiera el cliente tenía, o que ‘abordes’ sus necesidades con soluciones totalmente rompedoras es innovación, y tiene más que ver con tu capacidad que con las técnicas (aunque conocerlas es un paso). El otro día leía una cita que me viene al pelo para explicarme: «inteligencia es lo que uno hace cuando uno no sabe que hacer»
Pero no creo que eso esté reñido con el uso de técnicas más o menos formales y comunmente aceptadas, que es lo que vendría a ser la ingeniería. Por poner un ejemplo, hay miles de máquinas industriales que hacen cosas portentosas y que mejoran los sistemas productivos enormemente, pero no por ello dejan de ser diseñadas con un CAD y entregados sus esquemas eléctricos, mecánicos e hidráulicos para su fabricación y mantenimiento.
> Simplemente emularía más rápido lo que
> ya se hace ahora. Mejor que “emular” es hacer
> algo distinto.
«Don’t imitate. Innovate». 😉
No todos innovan, y no siempre los escenarios son propicios para ello.
Además, eso es lo que diferencia a los profesionales de los buenos profesionales.
Pingback: La ingenieria informática « Towards 2.0 Emprendiendo en época de cambios
> Creo que de estos prejuicios derivan muchos otros. > Más vale aclararlos de entrada.
Obviamente no comparto esos prejuicios.
> Por eso es un balance que hay que hacer, no tiene
> sentido que Torvalds o Alan Cox se encarguen de eso.
Ya te digo que no es lo mismo la documentación a posteriori que la documentación de la que se habla en IS. Si en Linux u otros proyectos necesitan poca o nula documentación en el desarrollo me parece perfecto, pero ya digo que el esfuerzo de otros voluntarios en tratar de documentar el proyecto puede ser valioso pero para nada lo mismo.
> Esta ingeniería tradicional sólo pensaba en
> proyectos tipo “catedral” (por eso lo mencioné al
> principio): todos los requisitos son conocidos, se > conocen los resultados esperados desde el
> principio, se conoce perfectamete toda la
> tecnología y sus capacidades de antemano, no habrá > cambios importantes hasta que todo esté acabado,
> etc. etc. Por eso afirman que es posible definir el > sistema hasta niveles de detalle bastantes rofundos
> sin haber escrito una línea de código.
Yo creo que eso está bastante superado. Supongo que sabrás que hay metodologías de desarrollo iterativas como UP por poner un ejemplo, que para nada consideran que haya que entrar al detalle hasta el punto de que implementar sea traducir pseudocódigo como se decía antigüamente. No se habrá avanzado mucho en IS pero eso está ya bastante superado y ya te digo que yo no soy ningún experto en IS.
No sé, habrás leído a Craig Larman por ejemplo.
Esto es como quien critica UML porque dice que muchas cosas no son útiles, perfecto, ¿Cual es el problema?, nadie obliga a usar todo lo que hay de UML, utiliza lo que creas que te sirve en tu proyecto, el resto obviamente es perder el tiempo.
¡Me ha llegado un mensaje de Dijkstra desde el más allá! 🙂
Dice así:
»
Me congratulo al comprobar que la juventud en ese país aboga por la programación desde una óptica rigurosa y científica y, por tanto, fundamentada en una formación estrictamente universitaria en la rama de la computación. Que creen sus artificios usando técnicas de razonamiento efectivo y métodos formales de especificación, desarrollo y verificación formal asegurándose de que sus programas hacen lo que dicen hacer y libres por completo de fallos. Y que no lo hacen mediante el esquema de prueba y verificación, que como digo yo, es como poner el carro delante del caballo. Cerramos así las puertas a curanderos y charlatanes, quienes en este caso toman la forma de gurús de la Ingeniería de Software.
Me congratulo además, de que no os acogisteis a la subcultura del programador compulsivo, cuya ética prescribe que una idea tonta y un mes de codificación frenética deberían bastar para hacerlo millonario de por vida
»
😉
Es sólo una broma infantil. Espero que no moleste a nadie.
@pablo perez
Te aclaro que tener una ISO900x lamentablemente no implica que todos los vehículos sean idénticos, es más en la mayoría de las ocasiones no implica absolutamente nada.
Una certificación ISO900x se puede comprar, es decir contratar a un auditor que no haga preguntas, y para una empresa pequeña no es excesivamente caro.
Ese es el resultado que tiene excederse con las metodologías, que acaban considerándose en un gasto y no en un valor añadido.
En este sentido recuerdo hace mucho tiempo hicimos una aplicación para una institución publica. Cuando terminamos la aplicación que funcionaba correctamente nos pusieron como requisito para cobrar entregar la documentación de la aplicación, para que otros pudiesen realizar modificaciones de mantenimiento (no les bastaba con los fuentes).
Obviamente no habíamos hecho ninguna, por lo que hacerla era un gasto extra. Nos propusimos como único objetivo rellenar 150 folios como sea. El resultado fué una colección de hojas, infumable, tan costosa como inutil, pero que el cliente aceptó (estoy convencido que nunca miró porque era horrible, a pesar de estar todo lleno de gráficos y erratas).
Aquí el problema es que hay demasiados titulados en ingeniería que no son ingenieros y eso hay que taparlo de alguna manera, ya sea mediante regulaciones, colegios fuertes o simplemente intentandonos convencer que los ingenieros no deben hacer trabajos de ingeniería, como programar. (ahora el rollo que programar es para los FP que deben seguir directrices de seres superiores).
No se puede negar que un ingeniero en informática, dirigiendo, por ejemplo un departamento de recursos humanos, como se apunta más arriba, puede disimular bastante sus carencias.
Un caso es el de los enchufes, es cierto que uno puede ilegalmente poner enchufes en su casa, pero lo correcto es que luego llame a un ingeniero industrial, aunque sea de la rama mecánica, para que le certifique que la instalación que ha realizado es correcta. Probablemente el ingeniero industrial pase una factura y no mire absolutamente nada, eso si redactará un bonito documento debidamente encuadernado.
Y por poner similes, lo bonito sería que cualquiera que crease algo de software, tuviese que ir detrás un ingeniero informático certificando (cobrando).
Y el fondo de ello está en la enseñanza, a alumnos cada vez más desmotivados debe ponerseles un nivel cada vez más bajo. El problema es a todos los niveles, comenzando desde la Eso. Los planes de Bolonia es lo que demandan los actuales bachilleres, menos matemáticas y formalidades que requieren «pensar» y más licenciados light en chorradas.
Personalmente no entiendo como pueden salir titulados que no solo no saben absolutamente nada sino que además no tienen ningún interés (por suerte no son todos). Imagino que profesores y catedráticos no serán conscientes del daño que están haciendo a la sociedad.
Pingback: Los problemas derivados del abuso de las analogías « Ricardo Galli, de software libre
Probablemente si tuviese que enseñarle matemáticas o los algoritmos de la ciencia de la computación a una persona muy brillante lo haría como dice Dijkstra, pero nunca al resto de los mortales.
Lo malo es que las ideas de Dijkstra calaron en pegagogos de la matemática moderna de gran influencia en nuestros planes de estudios como Bourbaki. Así muchos sufrimos la enseñanza desde muy pequeños de eso que llamaban matemática moderna (con los puñeteros diagaramas de Venn, conjuntos y aplicaciones inyectivas y biyectivas, la base 2 y la base 10, etc… desde de la EGB) en lugar de enseñarnos la matemática concreta (geometría, trigonometría y resolución de problemas concretos) . Toda una generación quedó capada de cara al aprendizage de la geometría pues no pocos pedagogos han demostrado después que caundo uno es pequeño se aprende más por inducción de lo concreto a lo abstractro que por deducción de lo abstracto a lo concreto, de la misma manera que Newton desarrolla el concepto de derivada a partir de la tangente y el de integral a partir del área. Una pena.
Corrijo mi anterior comentario: la influencia de este estilo de enseñar matemáticas fue Bourbaki -> Dijkstra -> seguidores de Bourbaki. No obstante, he podido verficar que Dijkstra acabó renegando de algunas de las ideas de Bourbaki.
@miguel
> Te aclaro que tener una ISO900x lamentablemente
> no implica que todos los vehículos sean idénticos, > …
>
> Una certificación ISO900x se puede comprar.
Llámame idealista, pero me gusta pensar que ‘cosas’ como la ISO 900x, aunque poco, significan algo.
Creo, y es una opinión personal, que es un error de base calificar la bondad o maldad de un determinado modelo por experiencias personales negativas. Eso invalida la aplicación práctica, no el modelo en si mismo.
La ISO 900x (o cualquiera) tiene una utilidad, la que sea, y certifica algo. Si la gente no sabe evaluar su significado no es problema de la ISO, sino de quien evalúa su utilidad.
> Ese es el resultado que tiene excederse con
> las metodologías, que acaban considerándose
> en un gasto y no en un valor añadido.
Incido en lo mismo. La utilidad de la ISO 900x y de cualquier otra metodología/estándar es la que es. Quien quiera sacarle más partido o bien está engañando a la gente, o tiene enfrente a alguien que no sabe lo que está pidiendo, o lo que es peor, por qué lo está pidiendo.
> En este sentido recuerdo hace mucho
> tiempo hicimos una aplicación para
> una institución publica. Cuando terminamos
> la aplicación que funcionaba correctamente
> nos pusieron como requisito para cobrar
> entregar la documentación de la aplicación,
> …
> Obviamente no habíamos hecho ninguna,
> por lo que hacerla era un gasto extra.
> Nos propusimos como único objetivo rellenar 150
> folios como sea.
> …
> El resultado fué una colección de hojas,
> infumable, tan costosa como inutil,
> pero que el cliente aceptó
> (estoy convencido que nunca miró
> porque era horrible, a pesar de estar
> todo lleno de gráficos y erratas).
Supongo que será para estar orgullosos.
Ahora pregúntate una cosa: ¿En qué situación queda el cliente? ¿Está protegido?
Yo a eso lo llamo de una manera: fraude.
> Aquí el problema es que hay demasiados
> titulados en ingeniería que no son ingenieros
> y eso hay que taparlo de alguna manera, ya sea
> mediante regulaciones, colegios fuertes o
> simplemente intentandonos convencer que los
> ingenieros no deben hacer trabajos de ingeniería,
> como programar. (ahora el rollo que programar es
> para los FP que deben seguir directrices de seres
> superiores).
No se de donde has sacado esa gilipollez de que los ingenieros no programan. Lo preocupante es que es una gilipollez bastante extendida.
Hasta donde yo se, cualquier titulado en ingeniería es ingeniero, porque así lo dice su título.
Y, sinceramente, ya dije desde un principio que no iba a entrar en polémicas sobre la regulación en este apunte.
> Un caso es el de los enchufes, es cierto que
> uno puede ilegalmente poner enchufes en su casa,
> pero lo correcto es que luego llame a un ingeniero > industrial, aunque sea de la rama mecánica,
> para que le certifique que la instalación que
> ha realizado es correcta. Probablemente el
> ingeniero industrial pase una factura y no
> mire absolutamente nada, eso si redactará un
> bonito documento debidamente encuadernado.
Vuelvo a incidir en lo mismo: tus experiencias personales no invalidan los modelos.
Ese documento debidamente firmado por un técnico en instalaciones eléctricas (que no es necesariamente ingeniero, y puede ser cualquier persona que supere el examen para obtener el carnet), y por el que cobra, lo responsabiliza de cualquier fallo de diseño en la instalación, así que dime tú donde está el problema.
> Y por poner similes, lo bonito sería que
> cualquiera que crease algo de software,
> tuviese que ir detrás un ingeniero
> informático certificando (cobrando).
En ningún momento he dicho eso, no lo suscribo y, es más, lo condeno. Te ruego que vuelvas a revisar todo lo que he escrito, y lo compruebes por tí mismo.
El software está presente en muchos ámbitos, y no todos tienen la misma incidencia.
> Y el fondo de ello está en la enseñanza,
> a alumnos cada vez más desmotivados debe
> ponerseles un nivel cada vez más bajo.
> El problema es a todos los niveles, comenzando
> desde la Eso. Los planes de Bolonia es lo
> que demandan los actuales bachilleres,
> menos matemáticas y formalidades que
> requieren “pensar” y más licenciados light
> en chorradas.
Totalmente de acuerdo, en lugar de dedicar esfuerzos a subir el nivel ‘por abajo’, a que esas personas que tienen la capacidad pero no los recursos o el entorno se vean protegidos por un sistema educativo que les sacará el mayor partido para que sean personas de utilidad, se baja el listón para que los mediocres no lo sean tanto.
Es un mal endémico de esta sociedad.
> Personalmente no entiendo como pueden salir
> titulados que no solo no saben absolutamente
> nada
Esa es una afirmación demasiado arriesgada. No me creo, sinceramente, que un titulado de cualquier rama o carrera salga sin saber absolutamente nada.
> sino que además no tienen ningún interés
> (por suerte no son todos).
> Imagino que profesores y catedráticos no
> serán conscientes del daño que están haciendo
> a la sociedad.
A lo mejor lo que falla es el sistema universitario, y no los catedráticos (que también harán lo suyo).
@xm carreira
> Lo malo es que las ideas de Dijkstra calaron en pegagogos de la matemática moderna de gran influencia en nuestros planes de estudios como Bourbaki. Así muchos sufrimos la enseñanza desde muy pequeños […]
> Corrijo mi anterior comentario: la influencia de este estilo de enseñar matemáticas fue Bourbaki -> Dijkstra -> seguidores de Bourbaki.
¿Semejantes afirmaciones sin ninguna evidencia? ¿que al principio sí y al final no?
En 1973:
1981:
Si yo hiciese afirmaciones de ese estilo en un apunte me lloverían piedras enormes de los mismos comentaristas que hacen este tipo de comentarios simplistas, generalistas y sin ninguna prueba o enlace para contrastar.
@galli
Hombre, no puedo usar citas en todos mis comentarios como si fuesen una tesis doctoral y menos en horario laboral :-). Después de mi primer apunte rápido estuve tratando de buscar esta información en Google pero reconozco que no encontré un documento que ligue directamente a Dijkstra con los bourbakianos. En cambio encontré el texto que pones arriba y por eso maticé el comentario.
Ahora mismo no recuerdo donde lei la influencia mútua de la obra del grupo Bourbaki en Dijkstra. A falta de citas o documentos contundentes de apoyo puedes tomarlo como una opinión personal mía.
Pienso que las ideas pedagógicas de mayor formalismo y notación más seria en las matemáticas de Bourbaki causaron una profunda impresión en Dijkstra. «Los grafos no se dibujan» lo pudo haber dicho Dijkstra o Bourbaki. Supongo que a Dijkstra le gustaba esta idea de formalismo y no hacer abusos en la notación pero seguramente se cansó del dogmatismo de los bourbakianos. Un saludo.
> Cada vez que alguien me explicaba las fantásticas
> bondades de una metodología nueva, o que casi al >principio de una conversación soltaba la frase “un >ingeniero no tiene por qué ser un programador” se me >ponían los pelos de punta y sólo atinaba a pensar >que ojalá no me tocase trabajar con esa persona.
>Con el tiempo me convertí en un escéptico casi >radical sobre el “[no] cientificismo” y la falta de >rigurosidad de metodologías.
Si vamos a aceptar como argumento de autoridad acerca de Ingeniería del Software lo que Dijkstra decía hace 20 años creo que lo justo debería ser hacerle caso también en todo lo demás. Sirva esto como mensaje a quien crea que Dijkstra era un abanderado de el «ARTE de la programación» o un absoluto crítico de los formalismos.
Lo mismo hay que re-redescubrir a Dijkstra y ver la importancia que daba a cosas como la «derivación de programas». Para quien no sepa qué es, se trata de un método de programación en el que se parte de la especificación, precondición y postcondición, y mediante transformaciones formalmente válidas, se va convirtiendo esa precondición hasta lograr la postcondición. Yo personalmente tuve que pelearme con eso en la universidad y no tardé en ver que es un método inviable por la complejidad que aporta.
Si muchos desarrolladores critican todo lo que suene a IS, argumentando falta de formalismo, me gustaría verles programando al estilo que Dijkstra sugería. Para Dijkstra programar no era sentarse en una computadora y empezar a programar en ella desde 0, en plan hacker, todo lo contrario, y justamente en ese punto coincide con quienes defienden la ingeniería del software.
Es necesaria una o varias fases previas y posteriores a la programación. Estando de acuerdo en eso, en las últimas décadas vemos como ha habido diferentes enfoques y obviamente muchos errores. Parece que debido a esos errores, como por ejemplo el hecho de que en un comienzo el desarrollo se suponía lineal y la programación se decía que es simplemente traducción/codificación, se tendiende a menospreciar cualquier avance que se haga en estos aspectos.
A ver si algunos se van enterando por ejemplo que hace mucho que en IS se superó lo de que programar no tiene importancia o que la documentación debe ser exhaustiva o más importante que la programación en sí.
Suponer que IS significa considerar que “un ingeniero no tiene por qué ser un programador” es un absurdo hoy en día, basta ver que el UP o las metodologías ágiles tan de moda no dicen nada de eso.
@Pablo Perez
No puedo otra cosa que formar mis ideas a partir de lo que percibo con mis sentidos.
Las regulaciones y normalizaciones pierden totalmente su utilidad en el momento que el fraude es un hecho habitual.
Y en el caso concreto de la normatica ISO900x se puede comprar (llamalo corrupción). La intención de cumplirla, a pesar de que burocratiza el trabajo y lo hace más lento, no es malam, pues da una metodología de trabajo. También hay que admitir que no sujetarse a normativas no quiere decir que una empresa carezca de metodología.
Evidentemente rellenar hojas que no sirven para nada es un fraude. Pero yendo a la cuestión yo he realizado esfuerzos es dar una visión de ingeniería de software al desarrollo de los proyectos, pero la hora de la verdad, en mi experiencia, es inutil.
La documentación inicial a medida que avanza el proyecto va distanciandose del producto creado. Actualizar la documentación es tan costoso que al final puede paralizar el proyecto más sencillo. Hubo un tiempo que fuí entusiasta de esas ideas, pero ya las he desechado.
También discrepo con el triste hecho que hay personas que salen de la universidad con su título y no saben NADA. Lamentablemente es posible aprobar con conocimientos volátiles. Imagino que el punto de vista del empleador y empleado son distintos.
No digo que particularmente tu suscribas la frase del ingeniero es para dirigir y el FP para programar o más despectivamente picar código. Pero si está en la mente de muchos, especialmente los ingenieros en informática que se les da mal programar.
Desconozco la responsabilidad que tienen los catedráticos en la calidad de los alumnos, desconozco el tipo de contrato que tienen y su autonomía dentro de las aulas. Eso lo tendrá que explicar algún catedrático.
Lo que si discrepo es que por ley se puedan dar definiciones de una palabra. Un señor puede estar en posesión de un título de ingeniero y no por ello será un ingeniero, aunque legalmente si. Ingeniero implica algo más que haber superado 4 docenas de exámenes.
Yo puedo estudiar medicina, tener un título de medicina, dedicarme a cantar durante 30 años y a pesar de mi título ya no seré médico. Y por supuesto no son necesarios 30 años para olvidar los conocimientos adquiridos en la universidad, algunos lo logran milagrosamente en su primer día de trabajo.
Hombre miguel eso que dices lo sabemos todos.
El problema se da cuando se convierte en una injusticia pública y clamorosa. Es decir, los ingenieros informáticos tienen vetado el acceso a otras profesiones pero su campo está abierto a todo el mundo.
No se sostiene. Es un modelo que se ha roto.
¿pondrá este gobierno el cascabel al gato de la libre competencia¿¿desregulación total para todos y ultraliberalismo? Veremos
@Ramiro
¿Y a que profesiones te refieres? O dicho de otro modo ¿que es lo que no podemos hacer los ingenieros en informática?
¿¿¿???
¿Lo preguntas en serio?
Pingback: Necios en huelga « Ricardo Galli, de software libre