Mr. Hejlsberg
"When you don't code, you tend to become one of those architects who thinks everything is possible"
Anders Hejlsberg
Anders Hejlsberg
Ian Marteens, 1:27 p. m.
La Cara Burlona del Dr. Marteens
(blog no apto para almitas sensibles)
Ian Marteens, 1:27 p. m.
6 Comments:
Sí Ian, sí.
La entrevista ya la había seguido hace un tiempo y es sencillamente genial. También vale la pena la que le hacen a Jim Gray, el padre de las propiedades ACID de las transacciones en BD.
Completamente de acuerdo con Anders. Si no te "ensucias las manos" con el código, se pierde la perspectiva de la complejidad de las cosas.
Es lo que sucede con los directivos, políticos,... Tanto hablar a alto nivel de abstracción y no querer entrar en los detalles, les provoca ver todos los problemas del mundo como una caja negra con una única entrada i una única salida.
El tema no es nuevo : seguro que algún filósofo griego ya hablo de ello.
Saludos.
¿Qué opinas sobre eXtreme Programming, Agile y todo eso? ... vale: es una pregunta con trampa. Es que creo que las pocas cosas que tienen sentido en estas "metodologías" o como las llamen, son trivialidades. Y el resto, un puñado de tonterías. Quitando los diagramas de clases, ¿te ha servido para algo otro tipo de diagrama en UML? Es que es más fácil leer código fuente que entender un diagrama de actividad de UML.
¿Y toda esa historia sobre "test-driven development"? Creo que existen tipos de aplicaciones para las que puede valer... aunque no es necesario inflar tanto la idea, pues nuevamente la parte que funciona es la que utiliza el sentido común. Por el contrario, hay aplicaciones en los que el enfoque "test-driven" hace mucho daño. Un compilador, por ejemplo. Si no te montas una "teoría" de la compilación, y procedes mediante pequeños pasos incrementales... terminas probablemente con el compilador de Delphi 2006 entre las manos (además, probablemente sólo puede hacerse cuando se parte de un proyecto que ya funciona).
"Ed Yourdon ha cambiado de paradigma con más frecuencia que Elizabeth Taylor de marido". No recuerdo quien lo dijo, pero es cierto.
Amén a todo ello.
Ya sabía de la existencia de esa entrevista hace unas semanas por los blogs de Borland, pero aún no he encontrado tiempo (ni excusa, jeje) para verla.
Por cierto hablando de los blogs de Borland, mirar en qué se entretienen los señores ingenieros en sus horas libres.
Yo de mayor quiero ser como ellos xD
Ian,
Yo opino que las metodologías són necesarias y útiles cuando se abarcan determinados proyectos de envergadura.
Hay que tomárselos como mecanismos de reducción de la complejidad de los proyectos y como herramientas para hacer comprender a todos los participantes en el proyecto el signifcado de los procesos y marcar el camino a seguir en un lenguaje (que se supone) gráfico y sencillo de entender para el mayor número de participantes.
Estoy contigo en que ni todas las metodologías valen, ni valen para todo tipo de proyectos, ni para todo tipo de equipos de desarrollo y que algunas "envilecen" más que "ennoblecen".
Igual que hay que elegir la plataforma, la herramienta de desarrollo, el sistema de almacenamiento,... también hay que decidir la metodología a utilizar.
Las metodologías que comentas las considero metodologías muy específicas, para problemas muy concretos.
Saludos.
Este comentario ha sido eliminado por un administrador del blog.
Hola Ian:
Se te extraña el que ya no saques nada sobre Delphi..espero reconsideres tu postura ademas segun lei Borland separara en una nueva empresa sus entornos de programacion y lo situara en Europa
Un Abrazo
Martincv
Publicar un comentario
<< Home