Etiquetas
Entre 1992 y 2001 participé en unos proyectos europeos gordos de R&D relacionados con gráficos, realidad virtual, arquitectura y trabajo colaborativo (RACE Monalisa, CODI, Esprit M3D, eEurope MNM). En todos esos proyectos desarrollamos más de un par de millones de líneas de código (C++ fundamentalmente), y salvo excepciones todas están muertas de risa en algunos discos duros por «problemas de IPR» (Intellectual Property Rigths, creo que eso me influyó mucho para darme cuenta de los problemas de la «propiedad intelectual» en el software). Había socios de todos los tamaños, desde pequeñas empresas, universidades, BBC, Daimler Benz, Siemens, Thompson Multimedia –antes Thomson CSF–, etc. que hicieron más problemático lograr acuerdos, ni siquiera con la spinoff creada (aunque se sacaron productos como ELSET –Electronic Set, para estudios de televisión– que fue llevado a solas por una empresa de Hannover).
En casi todos esos proyectos colaboré estrechamente con Miguel Salles Dias, en su momento presidente de Adetti, hoy directivo de Microsoft (demás está decir que casi no lo ví desde que entró en Microsoft 😦 ).
Miguel era un fanático de lo que estaba «revolucionando» la ingeniería en aquellos años, el UML. Tanto que pasábamos horas –muy a mi pesar– estudiando los libros relacionados con UML que compraba para luego intentar aplicarlo en el desarrollo de nuestros proyecto –donde trabajaban más de 30 desarrolladores de 9 ó 10 países distintos–. Nunca nos ha ido demasiado bien, la verdad.
Suponíamos que se debía a que éramos unos inútiles, o lo que hacíamos era muy nuevo o bastante experimental, por lo que intentar convertir en predecible lo impredecible se hacía una tarea imposible. Al final imperaba el «diseño mínimo» –la arquitectura– y luego un proceso bastante evolutivo que se corregía cada mes o mes y medio en nuestras reuniones periódicas entre desarrolladores y «usuarios» que quedaban documentados de forma bastante caótica en los deliverables.
Esos fueron mis últimos años donde seguía más o menos el día a día de lo que se cocía de ingeniería del software de grandes proyectos. Luego seguí la pista al Extreme Programming (que decían que era «revolucionario», pero la verdad es que era bastante parecido y menos radical de lo que se hace en los proyectos gordos de software libre) y algo de patrones, pero poco más, me metí de lleno en temas de software libre, donde la impredecibilidad y el diseño estrictamente evolutivo suelen ser parte de la realidad imperante, quizás también la ventaja fundamental.
Después de varios años casi desconectado decidí intentar volver a ponerme al día. Hoy encontré un viejo artículo de Martin Fowler del 2000 pero actualizado en el 2005, New Methodology e Is Design Dead?
Son interesantes y algunas de las frases e ideas me parece geniales. Pero poco más. Seguí los enlaces –recomiendo el ejercicio pero de forma no guiada– y me encontré con mucha charlatenería, sin dar un ejemplo práctico, ni un sólo documento, ningún análisis comparativo de caso reales. Casi discusiones metafísicas sobre bondades y problemas de las diferentes metodologías (Yagni, XP, UML, patterns, planificado, evolutivo/incremental/interativo, etc.).
Ya, son sólo artículos y ensayos, pero me sorprende que haya tan poca «chicha». De todas maneras parecen referencias en sus campos, debe ser por algo. Pero me soprende que en uno de esos artículos –de hace pocos años– justifiquen a los «diseñadores» y el «diseño complejo» (como contrapuesto a los «ágiles») como la única forma de obtener frameworks y módulos reusables genéricos.
Me chirría, será por el momento obsesionado con Django y similares.
Si se analizan los frameworks de programación que más impacto están teniendo en el diseño web, estos son Rails y Django (o el propio Webapp de Google). Hasta donde llega mi conocimiento son el resultado del «diseño evolutivo» de unos hackers, a pesar que los hacks son uno de los pecados capitales de las metodologías complejas.
Debo reconocer mi gran desconocimiento de las profundidades del área, o de los múltiples frameworks para tipos de proyectos que desconozco, pero me resulta muy curioso. Aunque no sé todavía si los Rails o Django respaldan a metodologías ágiles, o a los hacks… o no dicen absolutamente nada. Si es lo último, ¿qué frameworks son los que significan algo?
Pero no debo ser especímen raro, hay otros que afirman –y parecen– saber muchísimo pero se atreven a hablar de pseudociencias para describir los «avances» de los últimos años.
Seguiré leyendo. ¿Alguna recomendación? ¿algunos buenos blogs que escriban sobre el tema que comento?
yo seguí la pista (en orden cronológico) a UML, eXtreme Programming y Patrones. Soy de la opinión de que hay muchos conferenciantes y profesores que dan muchas clases magistrales sobre como se debe programar sin haber tirado una línea en años. Algo así como el diseño vía comité, una engañifa. No hay un método fácil para manejar la complejidad, el que diga lo contrario miente.
No creo que los frameworks (otra de esas modas pasajeras que parece que van a convertirse en un silver bullet) impongan una metodología en concreto. Esto es si descartamos el código espagueti y el cruft a gran escala como metodología (que por desgracia es lo que más se ve por ahí, ni UML, ni XP ni gaitas)
Sobre los blogs de programación, bueno, yo leo Artima, Reddit, Joel y Raymond Chen (el maldito agregador cada vez hace procrastinar más fácil), pero si me pierdo algo interesante, comentalo.
Bueno este no es de metodologías: http://beautifulcode.oreillynet.com/
pero a cada rato se pone interesante 🙂
Yo impuse Ruby on Rails en mi empresa en un proyecto, y todos los programadores me odian. También los técnicos de sistemas, que se vuelven locos a base de máquinas virtuales y otras sofisticaciones para intentar que Mongrel escale. Y todos los dias rezamos para que no haya más de ocho accesos simultáneos al servicio (que por otro lado nos gustaría que fuese masivo) para que el sistema no se cuaje. La parte de firma electrónica la hemos tenido que hacer en java, porque no hay «gemas» para esos menesteres y el interfaz Ruby-Java es otra de esas cosas que nos hace sufrir.
Probablemente en un año, liberemos la aplicación en Ruby mientras la rehacemos en Java, para evitar que sus múltiples lineas de código se queden muertas de risa en un disco duro.
Todos reconocemos que programar es complejo y no hay via fácil analisi -> diseño -> implementación que funcione.
De todas formas, reconocer que es necesario algun tipo proceso iterativo, más limitado en cado paso y con el feedback de la iteración anterior, no significa caer en el caos o abandonar el aspecto de «ingenieria» del desarrollo.
Las metodologías ágiles hacen un buen trabajo al proporcinar consejos realistas para este estilo de desarrollo. Sistemas en código libre suelen de forma natural seguir un proceso similar, con sus frecuentes releases y mucho feedback por parte de los usuarios.
Dos recomentaciones bibliográficas para desarrollos iterativos serian el Test Driven: TDD and Acceptance TDD for Java Developers de Lasse Koskela y, sobre todo, Domain-Driven Design: Tackling Complexity in the Heart of Software de Eric Evans. Este último por que desmonta el mito de que los procesos ágiles no sirven para modelos complejos.
[i]por lo que intentar convertir en predecible lo impredecible se hacía una tarea imposible. Al final imperaba el “diseño mínimo” –la arquitectura– y luego un proceso bastante evolutivo que se corregía cada mes o mes y medio en nuestras reuniones periódicas[/i]
Ciertamente es muy difícil adelantarse a todos los problemas desde el diseño sin haber metido las manos en la masa pero eso no quita para que muchos de ellos sí que se puedan trabajar en esa primera fase de diseño y de hecho creo que debe ser así. Al igual que los patrones de diseño no son soluciones a intentar encajar en cualquier problema sino más bien una guía sobre algunas implementaciones típicas.
Lo que vengo a decir es que como en todo hay grises. El hecho de que no todos los problemas se puedan prever desde el diseño no justifica que se elimine completamente esa etapa. Creo que es bastante peor pasar completamente de UML, patrones de diseño, procesos etc.. que pasarse demasiado tiempo en la fase de diseño. Esto último, como el ejemplo que has dado creo que suele ocurrir por intentar encajar un ciclo de desarrollo lineal a un proyecto en lugar de una evolutivo o uno mediante prototipos. Ya que no todos los problemas se pueden prever en la primera fase de diseño lo suyo es ir refinándolo a medida que se van pudiendo prever otros problemas al estar más metidos en el proyecto.
Tienes razón en todo lo que dices. Desde luego existe muchísima charlatanería alrededor de buzzwords como «metodologías ágiles», «UML» o «patrones».
Aunque la discusión podría ser muy larga, me gustaría dejar mi opinión sobre varias cosas:
1-
Desde luego, si algo respalda Rails es los patrones. Rails está construido sobre MVC y ActiveRecord. Dos patrones que reducen y ordenan el código drásticamente.
2-
Respecto a «método de desarrollo de software libre versus métodos ágiles» si es verdad que siguen la misma filosofía de desarrollo evolutivo y feedback constante de los usuarios. Y si es verdad que casi todos los métodos ágiles se basan en las mismas premisas (iteraciones pequeñas, integración contínua, etc.) pero en el caso de Programación Extrema si que hay un principio «radical» que la diferencia del resto es «test-first: crea test unitarios para tus clases, antes de crear las clases.»
3-
Y, finalmente, respecto al UML, creo que es la mejor manera de DOCUMENTAR el diseño de una aplicación que use intensamente orientación a objetos y patrones. También es una buena manera de bocetear una idea cuando hablas con un compañero. Te dejo un artículo más de Martin Fowler sobre el tema: http://martinfowler.com/bliki/UmlAsSketch.html.
UML tiene además, ciertas implicaciones sicológicas. Y es que muchos Ingenieros en informática que salen de las facultades se agarran al UML para justificar que son Ingenieros de Software y no «simples programadores». Cuando el programador sale de la facultad, se encuentra con Ing.Industriales, Telecos o Diseñadores web que también saben programar. ¿Cómo justificar que uno es mejor que ellos? Porque uno sabe UML…
En fin, es un tema del que se puede hablar largo y tendido. Te recomiendo, como lectura en castellano, http://www.navegapolis.net/. Da una visión bastante práctica y desapasionada sobre las metodologías ágiles….
Un saludo!
Blogs no sé, pero te puedo comentar que en mi empresa (bueno, más bien en mi equipo de trabajo en el que somos unos bichos raros por usar y desarrollar software libre :-D) usamos como metodología de trabajo Scrum, y la verdad es que nos va bastante bien.
Puedes encontrar bastantes enlaces en el del.icio.us del jefe del equipo (scrum, xp). También somos bastante seguidores, sin talibanismos, de los patrones y la refactorización (bad smells) :-D.
Usamos Java y como framework Struts un poco por herencia (los proyectos son grandes y de larga duración), y últimamente andamos interesados en Grails.
En mi empresa se potencia el uso de frameworks para aplicaciones de cierto tamaño: AppFuse con Java y Symfony con PHP.
Con esto se consigue tener de forma natural un patrón MVC y tal.
Pero en realidad el proceso de desarrollo es algo mixto, no se sigue una metodología pura. Digamos que tenemos una especie de Scrum, pero con fases determinadas y algunos puntos tomados de autores algo más rígidos y menos ágiles.
Igual no hay bala de plata, y todo depende de la empresa, los grupos de trabajo y, muy frecuentemente, de los proyectos.
Hola otra vez,
he recordado un pdf bastante interesante de un tío que relata su uso REAL de los métodos ágiles. Nada de «teorías» 😀
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
redrac: En mi empresa desarrollamos al 85-58% en RoR y la gente está bastante contenta. Además, ahora estamos migrando los mongrels a mod_rails (http://www.modrails.com/) y la cosa marcha bien.
Ese sentimiento de «de verdad hay tan poca chicha?» es lo que sentimos casi todos al hacer un curso de Ingenieria del Software en la universidad …
#Inza
Supongo que ya lo teneis todo muy mirado… pero bueno, aqui tienes un enlace donde explican unos truquillos para hacer escalar rails
http://amaiac.net/conferenciarails2007/06_Rails_Hispana_2007_Sala1_Escalabilidad.wmv
Al final todas las metodologías de desarrollo terminan confluyendo en unico gran patrón para dominarlos a todos: el BBoM
http://www.laputan.org/mud/
(Si estoy de broma)
Yo no creo en las metodologías, yo creo en el cruft xD
Respecto al principio del artículo, por suerte hoy en día estos proyectos europeos van con software libre (estoy en uno de ellos). Las cosas cambian, aunque sea lentamente.
Me acabo de quedar sorprendido por tu nueva inquietud. Estoy desando leer tus conclusiones 🙂
Por mi parte, ya sabes que me muevo en el mundillo de Java y que todos mis proyectos (ya he perdido la cuenta) tienen su análisis y su diseño.
Con el tiempo el análisis se sintetiza, pero es mucho más preciso y el diseño se queda cada vez en menos.
UML sólo es la herramienta que usas cuando necesitas reflejar algo con una notación «estándar» (lo pongo entre comillas porque realmente no es estándar, lo que son estándares son los símbolos).
Principalmente Diagramas de casos de uso, de secuencia, de clases y de estado/transición.
Por otra parte, y esto es lo más interesante, está todo el tema de patrones de diseño (de ahí a que se reduzca tanto). Me parece francamente interesante y procuro leerme todo lo que me cae entre las manos al respecto.
Todo el mundo conoce Rails, Spring, Struts, Django, Symphony… pero pocos conocían MVC antes de ellos. Algunos piensan que todos los problemas pueden modelarse con patrones de software conocidos y si te los sabes (y te crees que son la mejor solución posible) los identificas fácilmente.
Una fuente interesante es TheServerSide. Cuando se publica algún artículo al respecto suele aparecer ahí. Libros, todos los relacionados con «design patterns». Los de Sun me gustan bastante. En cuanto a autores, algunos muy buenos como Debu Panda, pero demasiado contaminado de Oracle (una pena que este tío trabaje ahí). James Gosling tiene alguna perla, pero se dedica más a evangelizar y poco al trabajo más técnico.
Algunos de los antiguos de las listas de JBoss (de hace 5 años) que dejaron el proyecto antes de que lo comprar RedHat.
Por último ¿Cuál es el objetivo? Históricamente, el mercado del software (privativo, claro) propone el hito de la creación de un componente de software reutilizable y el «supermercado» del software. La idea es comprar 5 componentes y ensamblar una aplicación (digo… programa ;-)). Para mí es un hito inalcanzable y fuera de lugar después de lo aprendido gracias al software libre.
Por ese motivo, a falta de producto, mejoremos el proceso y creemos frameworks muy buenos que permitan efectuar desarrollos rápidos pero sin faltar a las reglas más elementales: buen diseño OO, buena encapsulación, uso correcto de patrones, BD normalizadas… etc.
Ah! Y si de verdad encuentras un autor que sea realmente bueno en este campo y con publicaciones modernas y con sustancia (casos reales tal vez) estaré encantado de sindicarlos. Mientras tanto, seguiré leyendo trespams.com, joelonsoftware.com y este blog 😉
Un sitio web sobre desarrollo, diseño, analisi, metodologias…
http://www.planetacodigo.com/
Es un recopilacion de varios blogs, paginas, etc.
Espero sirva!
Respecto al UML decir que lo utilizo como indica Paco. Es decir, lo utilizo en la fase de análisis inicial y me sirve para empezar a trabajar en el programa. Se trata de deseños muy básicos con las propiedades y métodos esenciales que ayuden a comprender lo que se quiere hacer. Esto nos permite identificar relaciones, ver posibles problemas, y sobre todo, explicar de qué va el programa. Es decir, se utiliza el UML como pizarra virtual y como lenguaje común. El UML una vez se ha cumplido su función NO se actualiza, lo que sí se hace es guardarlo en el svn del proyecto, ya que ayuda a entender cómo empezó todo y su estructura básica hace que nadie se atreva a considerar el diagrama como un algo acabado y mantenido. Sirve para lo que sirve, que es ayudar en el proceso de comunicación.
Respecto a la bibliografía:
* Extreme Programmin Explained de Kent Beck. Un clásico y como tal hay que leerlo. Prensenta muchas ideas que en estos momentos tenemos totalmente aceptadas pero que en su tiempo resultaron rompedoras consideradas en su conjunto: comunicación, refactorización, integración contínua, unit tests, etc. Podemos estar de acuerdo o no en poner en marcha todo lo que significa XP, pero lso concepto que presenta y sus prácticas seguro que están en el buen hacer de todo programador o jefe de proyecto que se precie de serlo.
* Agile & Iterative Development, de Craig Larman. Recoge las metodologías ágiles más importantes y presenta sus pros y sus contras. Tengo que decir que nunca he podido aplicar al 100% una de las metodologías (se supone que los máximos beneficios se recogen aplicándolo todo) pero con sólo aplicar los conceptos más importantes y menos «rompedores» de Scrum y XP ya tenemos un beneficio que es netamente superior a no tener ninguna metodología.
* Rapid development de Steve McConnel. Otro de los clásicos y posiblemente uno de los mejores libros de McConnell. Trata tanto metodología como gestión de proyectos y se concentra también en el factor humano. Si uno quiere complementarlo nada mejor que Peopleware de DeMarco y Lister.
* Uno de los pilares del desarrollo ágil es la refactorización. Por eso no puede faltar uno de los clásicos: Refactoring de Martin Fowler. Existe también un libro dedicado a las bases de datos, pero Refactoring es oro puro.
* AntiPatters de Brown y otros.. También sobre refactorización, sobre arquitecturas y proyectos en crisis.Es otra visión de los patrones de diseño y desarrollo en forma de cosas que no funcionan y defectos que debemos detectar. Ponerle nombre a las cosas ayuda y Anti-Patterns tiene nombres tan sugerentes como Poltergeist, Golden Hammer o Vendor Lock-In.
Creo que más que hablar de metodologías ágiles tendríamos que hablar de equipos de desarrollo ágiles. La metodología de desarrollo ayuda, pero si nuestro personal no está por la labor no hay nada que hacer. Hay guente que no ha nacido para esto, se trata de detectarla y mantenerla alejada de nuestro proyecto.
Respecto a los frameworks, decir que en estos momentos estoy utilizando Spring e Hibernate para la parte Java y Django en Python. Todos tienen un punto en común. Han nacido para resolver problemas concretos de programadores que estaban trabajando en un proyecto, no son tanto un producto comercial y de laboratorio como el haber sabido conectar con una necesidad de los programadores dando solución a problemas _reales_.
Cuando en Django te encuentras con una necesidad las posibilidades de que la gente de Django ya haya pensado en ello y tenga una solución son muy altas.
Los frameworks a mi me gustan que sean lo menos intrusivos posibles, orientados al trabajo a realizar y que ayuden al mantenimiento futuro de la aplicación, ayudando a establecer una serie de mejores prácticas. Estoy muy contento tanto con la elección de Java como con la de Django. En ambos casos nos ha permitido realizar y mantener proyectos de manera ágil y efectiva. Pero como ya he dicho antes, la metodología, los frameworks, los artículos, lo que sea, no son nada sin el equipo adecuado. Forma un buen equipo, súmale sentido común y ganas de aprender y el desarrollo rápido será algo natural.
No aporto ningún enlace pero si un poco de sabiduría popular:
«Hacer un proyecto según las especificaciones y caminar sobre el agua es sencillo, si ambos están congelados»
Pues tal i como decis. Sin ser un experto sino más bien un usuario con enfoque práctico, he experimentado las ventajas que aporta el uso de UML en el desarrollo de proyectos OO grandes o complejos, para mi ha sido enormemente práctico en:
1) Análisis de requerimientos y progresiva inmersión en la problemática de parte o todo el proyecto. A medida que avanzas dispones (a la fuerza), de un tiempo de «maduración de ideas».
2) Diseño top-down (de lo general al detalle)
3) Documentacion
4) Dividir el proyecto en subproyectos/Integrar Subproyectos
5) Explicar como funciona algo a nivel + o – detallado a alguien relacionado
con el proyecto. Comunicación.
6) Asignación de tareas/gestion del diseño Design version system (repositorio central)
4) Venta del proyecto en plan «pro».
5) Desarrollo/Mantenimiento (Iteraciones ->Ingenieria Inversa de classes)
6) Calidad y versatilidad del análisis. Medir la desviación en el análisis funcional.
7) Se combina bien con los patrones de diseño en los diagramas
8) Se autogenera parte del codigo..va…
9) otros…
Inconvenientes:
1) Lentitud y dificultad en su aplicación. Mucho trabajo desde el principio, demasiada información, la complejidad repartida o repetida puede producir «Parálisis por el análisis». Puede generar confusión.
2)Mucha gente huye despavorida cuando oyen hablar de UML (desconocimiento). Incomprensión, ignorancia u alergia.
3)A veces se genera demasiada paja pa lo que hay.
4)Baja reutilización del codigo fuera del proyecto (codigo demasiado especifico) no se si se mentiende.Se tiende a abusar de las ventajas aumentando la complejidad del diseño de forma enfermiza.
5)Se puede perder el control del proyecto a partir de un cierto tamaño y se vuelve en tu contra.
6)Malos rollos porque hay que documentar y codificar en exceso.
7) Uso conjunto con otros lenguages no OO
8) Bases de datos…pero eso ke é!
9) otros…
Bueno, no me crucifiqueis! Espero que se entienda que sustenta un buen desarrollo.
Bona nit!
Gracias a todos por las respuestas y enlaces, de un boboapunte salieron comentarios geniales 😉
Pero mi pregunta sin contestar es:
Según los especialistas, sólo con el diseño detallado y complejo pueden desarrollarse frameworks sofisticados… como Django o Rails.
Entonces, ¿cómo es que lo han hecho «hackers» y no los especialistas en diseño e ingeniería? Si el modelo MVC es conocido desde los tiempos del Smalltalk (hace casi 30 años), ¿cómo es que estos frameworks tan potentes y útiles no surgieron de esos especialistas? ¿dónde está la especificación UML? 😉
¿Qué creo? Que sí, que el diseño planificado/complejo funciona cuando el resultado y los componentes son ya perfectamente conocidos, pero no sirven cuando están en el «edge», cuando no hay antecedentes directos (el MVC es conocido, bien comprendido y relativamente sencillo, pero no en entornos de programación web y con lenguajes dinámicos).
#19 Es posible que se deba a que los proyectos de SL empiezan con una grupo reducido de gente que está muy en contacto y no tienen restricciones, sobre todo temporales, más que las que ellos mismo se marcan. Estos detalles hacen que tengan mucha más flexibilidad a la hora de corregir problemas por poca planificación, y no tienen que usar diagramas para comunicarse.
Sin embargo un proyecto empresarial puede tener varias decenas de personas en el, las cuales no tiene mucho contacto (sobre todo si son varias empresas implicadas) y además tienen restricciones temporales relativamente fuertes, por lo que tiene que centrarse más en seguir una metodología de desarrollo que los coordine.
«Según los especialistas, sólo con el diseño detallado y complejo pueden desarrollarse frameworks sofisticados… como Django o Rails.»
¿? Con un buen diseño se hacen mejor. Pero tú para hacer una carretera puedes hacerla con camiones y maquinaria o con un caldero, un pico y una pala, a base de dale que dale. Por poder puedes hacerlo y con tiempo y paciencia igual hasta te queda más chula.
«Entonces, ¿cómo es que lo han hecho “hackers” y no los especialistas en diseño e ingeniería? Si el modelo MVC es conocido desde los tiempos del Smalltalk (hace casi 30 años), ¿cómo es que estos frameworks tan potentes y útiles no surgieron de esos especialistas? ¿dónde está la especificación UML?»
No entiendo la aplicación del término «hackers» en este contexto, será más bien programadores aficionados. En informática todavía queda mucho por hacer, ¿por qué crees que un grupo de programadores aficionados no pueden hacer nada?. El problema vendrá con el mantenimiento y el soporte si no hay una buena documentación del desarrollo. ¿Nunca has oído lo del burro tocó la flauta?.
«¿Qué creo? Que sí, que el diseño planificado/complejo funciona cuando el resultado y los componentes son ya perfectamente conocidos, pero no sirven cuando están en el “edge”, cuando no hay antecedentes directos (el MVC es conocido, bien comprendido y relativamente sencillo, pero no en entornos de programación web y con lenguajes dinámicos).»
XDDDD Esto ya no te lo contesto, para contestar esta pregunta habría que pagar XDDDD No sabes ni lo que es la informática, ni como se aplica, ni lo que es el análisis y el diseño XDDDD menudo ingeniero estás hecho XDDDD, a leer libros y a ver si un día te acabas enterando y luego sueltas el rollo de la sabiduría que da la edad XDDDD. Estás tu hecho un buen «edge» o «border line», XDDDD. Esto que pones en público y en un blog, da mucho que pensar.
¿Crees que el producto tiene potencial por aplicar buenas técnicas de ingeniería o por ser una buena idea?. Para tener una buena idea no hace falta ser ingeniero XDDDD.
Vaya, veo que ahora resulta que a los programadores de software de licencia GPL los llaman, hackers XDDDD, al software lo llaman libre y a los desarrolladores hackers, joder, vaya perversión del lenguaje. A los equipos hay que llamarlos «bonitos». Hackers hacen software libre en equipos «bonitos». Y bueno para que la gente crea que hay negocio en el software de licencia GPL pues podemos hacer que las aplicaciones con licencia GPL se denominen con la palabra «rentables». Así nos quedaría, «hackers hacen software libre rentable en equipos bonitos». Bueno, lo mejor es denominar a los que no tengan título como «hackers» y a los ingenieros informáticos como «informáticos mega chuli piruli hackers».
XDDDD, joder con el software de licencia GPL, es lo que se denomina una perversión del lenguaje o una manipulación extrema, en lugar de programacion extrema, sería mejor software de manipulación extrema.
Sandman, si fueras menos ignorante, si leyeses bien inglés y los apuntes enlazados (de los «gurús» del diseño y la ingeniería) sabrías muy bien qué significa «hacker» y a qué se le llama «hack», también en los artículos sobre diseños. Por ejemplo:
«Extreme Programming (XP) challenges many of the common assumptions about software development. Of these one of the most controversial is its rejection of significant effort in up-front design, in favor of a more evolutionary approach. To its detractors this is a return to «code and fix» development – usually derided as hacking. To its fans it is often seen as a rejection of design techniques (such as the UML), principles and patterns. Don’t worry about design, if you listen to your code a good design will appear.»
Además de troll que no tiene idea de ingeniería, que se cree que sabe todo (a pesar que lloriqueas porque no consigues trabajo de acuerdo a «tu valía», no me extraña nada) no tienes idea de cultura informática, mucho menos de software libre o licencias de software.
Hombre siento tener que decirte que el término lo he mirado en un momento en la wikipedia y comenta que se denomina hackers a los desarrolladores de software libre y esa es la acepción respecto a la que he contestado.
Vamos eso es lo que de toda la vida se conoce como no tener ni idea de programar y hacer las cosas a lo burro y luego cobrar por el mantenimiento al cliente. Se gana dos veces, primero por el desarrollo y luego como no sirve para nada se cobra por el mantenimiento. Negocio redondo XDDDD.
Hay muchas cosas de las que no tengo idea. Pero me cuido en intentar saber lo que estoy haciendo en cada momento, el resto no son más que técnicas concretas. Los del software libre sois poco libres, ya que tenéis mucha costumbre de llamar troll a todo el que no piensa igual que vosotros y de llamar intolerantes, etc.
Por último te voy a explicar que no consigo trabajo ni de acuerdo a mi valía, ni de acuerdo a ninguna valía, no consigo trabajo de ningún tipo ni por 6000 euros, ni por 12000 euros, ni por 24000 euros. No es un tema de llorar, ni de lloriquear porque gracias a Dios tengo una solvencia económica que no me hace falta.
Pero lo que resulta ridículo es escuchar afirmaciones sobre grandes demandas de profesionales en el sector cuando yo puedo ver que eso no es real. Con el software mal llamado como libre me ocurre lo mismo me resulta ofensivo escuchar ciertas afirmaciones, el que defienda la licencia GPL debe defenderla por lo que es y no con historias raras, de libre, de hackers, etc.
De software libre y de licencias de software entiendo un poco XDDDD, eso sí, no lo defiendo porque no estoy de acuerdo, no debes confundir el no saber lo que es el software libre con no estar a favor. Yo no estoy a favor de la licencia GPL.
Debo decir que, este blog tiene sus pegas y es que no permite corregir los comentarios. Corrección, porque la gente se va a creer que soy un portentado, XDDDD, tengo una situación personal que me permite poder estar un tiempo sin trabajar, no es que tenga una situación económica XDDDD, que luego van a creer que… y es que el que poco tiene, poco necesita XDDDD.
Hola a todos, muy bueno este hilo.
Yo soy partidario del Model Driven Development, sobre todo cuando se aplica en determinado tipo de aplicaciones. Las aplicaciones de negocio todas tienen una arquitectura similar y utilizan unos patrones similares.
Yo tengo una opinión distinta a esta: «El UML una vez se ha cumplido su función NO se actualiza, lo que sí se hace es guardarlo en el svn del proyecto, ya que ayuda a entender cómo empezó todo y su estructura básica hace que nadie se atreva a considerar el diagrama como un algo acabado y mantenido.», que conste que antes haciamos lo mismo.
En nuestro caso el modelo UML(se podría utilizar otros lenguajes de modelado) es el que dirige el desarrollo. Seguro que durante el desarrollo cambian las relaciones entre clases, sus atributos o es necesario añadir nuevas clases, modificamos el modelo y generamos el código (no todo si no un código base), podemos generar este código para java con EJB3, para Spring + Hibernate, para C# con NHibernate o para cualquier otro framework que queramos (siempre que estén implementados los generadores).En los modelos no se modela la aplicación al detalle si no que se modela en un lenguaje mas próximo al negocio, tenemos Servicios, Entidades, Data Transfer Objects, se sigue algo parecido al Domain Driven Desing .Los patrones estan implementados en los generados y esto generadores se pueden intercambiar en función de nuestras necesidades tecnológicas. El mantenimiento es menos costoso, ya que modificando el modelo obtenemos el código.
Esta aproximación por el momento no es aplicable a cualquier tipo de aplicación, pero para aplicaciones empresariales es una solución muy potente.
Saludos.
Bufff… Veo una mezcla peligrosa entre lenguajes y frameworks (Ruby, Django), herramientas de diseño, patrones y arquitectura (UML, patterns) y metodologías de desarrollo (Agile, XP). Por cierto, me alucina que nadie haya mencionado aun Scrum (por cierto, el libro de Kniberg, que es BUENISIMO, lo teneis traducido al castellano en la web de Proyectalis, http://www.proyectalis.com/2008/02/26/scrum-y-xp-desde-las-trincheras/ ).
Por otra parte, me llama mucho la atención la equiparación que hace Gallir entre el seguimiento de los principios ágiles recogidos en el Agile Manifesto (www.agilemanifesto.org) y el «hacking institucionalizado». Ser Ágil no significa no tener un plan, no documentar, no tener un scope definido… Ahora bien, si para gallir el hacking sí incluye todo esto, entonces bien, estoy de acuerdo: el hacking es una estrategia mejor de desarrollo de software que el seguimiento de metodologías pesadas como Métrica et al. Pero las claves de una mejor metodología de desarrollo no están tanto en ensalzar el «hacking» como en un enfoque empírico de inspección y adaptación unido a una estrategia iterativa e incremental de desarrollo.
Por cierto, un libro imprescindible para el que quiera reflexionar sobre la mejor manera de hacer software es Lean Software Development, de Tom & Mary Poppendieck.
> Bufff… Veo una mezcla peligrosa entre lenguajes y frameworks (Ruby, Django), herramientas de diseño, patrones y arquitectura (UML, patterns) y metodologías de desarrollo (Agile, XP).
Lee de nuevo el apunte, no los estoy mezclando, sino que me hago preguntas por afirmaciones como la siguiente:
«The way YAGNI is usually described… The issue comes with such things as frameworks, reusable components, and flexible design. Such things are complicated to build. You pay an extra up-front cost to build them, in the expectation that you will gain back that cost later. This idea of building flexibility up-front is seen as a key part of effective software design.»
(El XP es contrario al YAGNI en ese sentido)
> Por cierto, me alucina que nadie haya mencionado aun Scrum
Están mencionados en #7, #8 y #16. Yo no lo hice, pero porque no se me ocurrió en ese momento (que por cierto, cuando estaba en la universidad estudiamos métodos holísticos sobre los que están basados el Scrum, no me sale el nombre de uno muy conocido y usado en IBM).
> Por otra parte, me llama mucho la atención la equiparación que hace Gallir entre el seguimiento de los principios ágiles recogidos en el Agile Manifesto (www.agilemanifesto.org) y el “hacking institucionalizado”
¿? No hice tal cosa, de hecho lo que comento no es del Agile Manifesto, sino de los dos artículos enlazados y algunas de las propuestas de XP. No entiendo cuál es la «equiparación», y si la hay quizás esté de acuerdo 🙂
Hola Angel,
Voy a comentar Scrum :-D. Nosotros estamos empezando a usar Scrum junto con el Model Driven Development(MDD), de echo el MDD por si solo no es una metodología de desarrollo.
Con mi anterior post quería separarme un poco de los lenguajes y los frameworks, hoy en día existen una autentica locura de lenguajes y frameworks, otro problema que veo con esto es que muchas veces se empieza diseñando la aplicación pensando en el lenguaje o framework sobre el que se va a implementar, lo cual es un error ya que las aplicaciones se realizan para resolver un problema del negocio, el lenguaje o el framework es un medio.
Tenia el libro en mi lista de TODO, en cuanto pueda le echo un vistazo.
Saludos.
En el libro Software Craftmanship The New Imperative, de Pete McBreen se realiza una tesis interesante sobre el origen de los modelos de desarrollo «clásicos».
Según el libro, la forma de organizar el desarrollo en un análisis detallado, con todo el tiempo que eso ocupa, seguido del tiempo de implementación tiene su origen en los primeros grandes sistemas de software creados. Para hacerse una idea, imaginaos cientos de ingenieros involucrados en la construcción de un sistema como el ibm 360 (si recuerdo bién el ejemplo). Este proyecto implicaba, como muchos otros de aquella época una primera fase de creación del hardware. Durante esta primera etapa, los ingenieros del software dedicaban mucho esfuerzo a especificar en detalle su trabajo, ya que no tenian otra opción.
Esta fase de «especificación», siguiendo con la hipótesis del libro, habría tenido continuidad en proyectos posteriores, aunque no hubiése motivo para tener «parado» el inicio de la implementación.
Otras motivos irracionales pueden ser la idea de mantener diferenciado el trabajo de expertos (analistas) y novatos, como en muchos otros otros trabajos, o la necesidad (ilusión) de tener una descripción exacta del trabajo ha realizar a efectos de planificación, presupuesto, etc.
En cualquier caso, com ya he dicho, siempre dentro de la linea argumental del libro de desechar la visión «tecnologica» ( en un sentido muy restringido) de la programación en favor de una visión «artística»
Ricardo, tal como aparece la frase no interpreto por ningun lado que XP sea contrario a YAGNI. De hecho, todo lo contrario: la priorización de una pila de producto, como en Scrum o en Lean, hacen que sólo se trabaje en un momento dado en aquellas cosas que el cliente valor. Mi interpretación del texto que citas es que el autor se pregunta si los enfoques basados en una flexibilidad de diseño desde el principio no requieren de un esfuerzo excesivo de modularización, reusabilidad, etc. que acabe siendo un lastre.
Mi experiencia desde luego, al igual que el esfuerzo dedicado a tests y QA, es que merece la pena al 110%, y que el retorno de inversión es mucho mayor que la cantidad de esfuerzo invertido en este enfoque. De hecho, el principio de la orientación a objeto (y que alguien me corrija si le parece que me equivoco) es precisamente obtener dicha modularidad a cambio de un mayor esfuerzo que en programación secuencial, y todos estaréis de acuerdo en que realmente suele merece la pena el enfoque orientado a objeto.
Respecto a la «equiparación» de la que te hablo, me refiero a la frase en la que comentas que cosas como Django son «el resultado del “diseño evolutivo” de unos hackers». No creo que porque un proyecto esté desarrollado por equipos distribuidos en el marco de Open Source ya tengamos que caracterizarlo de «hacking». Para mi el hacking es algo bastante más espontáneo y caótico (en un buen sentido, pero caótico) que un desarrollo ágil. En cualquier caso, probablemente se trate de un problema semántico entre tu percecpción de hacking y la mía 😉
#31 Angel, en primer lugar, ya me estoy leyendo el PDF que indica el enlace que has puesto (tuve que registrarme… y luego me dí cuenta que ya lo había bajado de otro enlace que me pusiero antes)
El tema de los framworks viene porque según lo que relata Martin Fowler los defensores de las metodologías pesadas afirmas que los frameworks sólo pueden surgir a partir de es «costosas fases de diseño». En ese contexto cuenta que los defensore sde Yagni critican a los métodos ágiles, como si estos fueran incapaces de generar frameworks sofisticados y generales (o es lo que interpreto).
> Mi experiencia desde luego, al igual que el esfuerzo dedicado a tests y QA, es que merece la pena al 110%
Esto es lo que afirma el XP, «primero las unidades de test, luego el código mínimo para superarlas, luego la refactorización para hacerlo más elegante y legible».
> y todos estaréis de acuerdo en que realmente suele merece la pena el enfoque orientado a objeto.
Depende fundamentalmente del tamaño, o de las herramientas y el framework que puedas usar.
> No creo que porque un proyecto esté desarrollado por equipos distribuidos en el marco de Open Source ya tengamos que caracterizarlo de “hacking”. Para mi el hacking es algo bastante más espontáneo y caótico (en un buen sentido, pero caótico) que un desarrollo ágil.
Como dice en la frase, los defensores de las «grandes metodologías» usan la palabra hacking como despectivo. No lo es tanto para mí, sobre todo porque un hacker no significa que haga chapuzas (todo lo contrario) y algunos «hacks» son brillantes. De hecho en el entorno de software libre un «hack» es una solución breve y brillante.
Lo que decía en mi apunte es que la XP no me sorprendió demasiado, porque mucho de lo que cuenta y exige es bastante habitual en el software libre.
Para sintetizar mi idea, algunos dices que los frameworks sólo pueden salir de costosas etapas de diseño, yo afirmo que el Django o Rail no surgieron así, sino de experiencias directas de programación en proyectos (mira la diferencia entre «diseñador» y «programador con experiencia»), y además son unos hackers del copón.
gallir en algunos de tus comentarios me da la impresión de que ves la llamada (o quizás mal llamada) «ingeniería del software» como algo completamente opuesto del desarrollo llevado a cabo por los hackers extendiéndolo así al software libre en general.
Es muy común encontrarse proyectos consistentes únicamente den tars o un repositorio público con el código y listas de distribución como medio de contacto/trabajo. Otros incluyen también un Wiki con FAQs para usuarios, notas de versión etc.
Lo que quiero decir es que en general suelen carecer de una documentación más o menos formal del proyecto. Documentación que debe de generarse a través de cada etapa de evolución del proyecto, análisis, diseño, codificación, mantenimiento.
Uno no debería necesitar mirar el código para entender cómo está diseñado el proyecto, de qué partes se compone, decisiones técnicas adoptadas, las dependencias funcionales etc de los diversos módulos.
Creo que hay un punto medio óptimo entre obsesionarse por el diseño, UML, patrones, procesos etc y empezar a desarrollar un proyecto programando directamente. Incluso poniéndonos ya pesados, dentro del código, los comentarios quizá deberían ser algo más formales de lo que se acostumbra, definiendo precond, post y aserciones importantes. De ese modo puedes hacer que se entienda lo que hace el código sin detenerse tanto en el código. Es una pena que esas prácticas metodológicas en concreto queden en el baúl de los recuerdos sin más tras terminar la carrera.
En serio, yo personalmente odio tener que bucear un .tar.gz por ejemplo y leerme gran parte del código o dar la chapa en listas de correo o IRC para entender dónde tengo que meter mano y porqué están hechas las cosas del modo en que están hechas. Eso no me parece hacking como a veces se llama sino simple ingeniería inversa, algo a evitar.
> gallir en algunos de tus comentarios me da la impresión de que ves la llamada (o quizás mal llamada) “ingeniería del software” como algo completamente opuesto del desarrollo llevado a cabo por los hackers extendiéndolo así al software libre en general.
Podría ser, pero de verdad, estoy haciendo un esfuerzo por «visualizar» tres cosas que no me acaban de cuadrar:
1. La insistencia del metodologías «pesadas» con su separación de «diseñadores» y «programadores».
2. El hype de los métodos ágiles (o ligeros) y el poco estudio formal que hay con el software libre (salvo la gente de la Univ. Juan Carlos que sí trabajan en este tema, http://libresoft.es/ ).
3. La divergencia entre la ing. del software «clásica» con los grandes proyectos de software libre. Si hiciésemos caso de todo lo que se dice (tanto en metodologías pesadas como ligeras) grandes proyectos como Linux, Gnome, KDE, Mono, etc. no podrían ni existir… violan casi todas las «reglas» (por ejemplo en la tan famosa Scrum la co-localización geográfica es un casi un requerimiento, ni hablar de las reuiniones y proceso burocráticos). A veces encuentro más sentido en cosas como «el Bazar y la Catedral» –que no es santo de mi devoción– que en los largos y sesudos artículos y libros «tradicionales».
Por eso, me hago preguntas e intento encontrar si de verdad hay ese gap tan grande o me estoy perdiendo algo que todo el mundo sabe pero no lo dice 😉
El software libre, per se, no es una forma de desarrollar software. Llámalo desarrollo colaborativo distribuido, pero no mezclemos la licencia con el método de desarrollo.
Insisto en que veo demasiada mezcla de conceptos. Aunque te reconozco que hay un hype con Agile.
Por cierto, Scrum efectivamente aboga por la co-alocación de equipos como forma de aumentar la productividad y la comunicación: cuanto más productivos no serían esos proyectos si contasen con equipos co-alocados. Pero existen muchas formas de implementar Scrum con equipos geográficamente distribuidos, y hay muchos casos de éxito al respecto. Te recomiendo el artículo de Sutherland sobre el tema. Y de nuevo, la catedral y el bazar se centra más en aspectos filosóficos y de negocio (la ventaja competitiva, la competencia de los pequeños con los grandes) que en la metodología de desarrollo.
> El software libre, per se, no es una forma de desarrollar software. Llámalo desarrollo colaborativo distribuido, pero no mezclemos la licencia con el método de desarrollo.
#35 Me parece que sigues sin querer entender. Lo que digo es que los grandes proyectos de software libre (como podrían llamar los grandes proyectos de marcinaitos verdes, pero esta vez son de software libre) no se ajustan a las metodologías tradicionales.
La gran mérito de CATB es haber puesto de manifiesto claramente (y en estilo fácil de leer) esas enormes diferencias.
> Y de nuevo, la catedral y el bazar se centra más en aspectos filosóficos y de negocio (la ventaja competitiva, la competencia de los pequeños con los grandes) que en la metodología de desarrollo.
Scrum es más gestión de proyectos (y su burocracia) y toma de decisiones que «metodología de diseño de software», no sé porqué tanto «hype», ¿será porque lo usa Google? http://video.google.com/videoplay?docid=8795214308797356840 (curiosamente, o no, lo aplican a una de las partes más «coñazo» para los desarrolladores de Google, la gestión de AdWords, que tampoco es software libre o comunitario-distribuido).
CATB da más detalles de desarrollo es sus puntos que todo el libro «Scrum and XP from the trenches», el que tú has recomendado. A mí no me gusta nada CATB, no es nada académico, pero está mejor escrito, tiene muchos puntos «revolucionarios» (que luego se apropió el XP) y más chicha que muchos otros.
No sé porqué esa obsesión de que si no se utiliza una metodología pesada no se puede hacer nada. Evidentemente se puede hacer. Ya he comentado el ejemplo del que va a hacer una carretera con camiones y maquinaria o el que la va a hacer con un caldero, un pico y una pala. El del caldero, el pico y la pala, la acabará haciendo y si no hay que hacer ningún puente pues mejor que mejor, pero no es un método eficaz, ni eficiente. Una vez hecha la carretera probablemente si no te fijas al detalle no se sabrá si ha sido hecha con un pico y una pala o con maquinaria más que por las soluciones que se hayan tomado para hacer el puente o para badear zonas, etc…
Con el software libre ocurre exactamente lo mismo. Se hacen infinidad de proyectos de software libre, la mayoría son una mierda y no llegan a ninguna parte. Oros proyectos a base de horas y horas y años pues se convierten en productos finalizados. Pero el problema es que puede faltar todo el análisis y todo el diseño y toda la documentación y cuando llegue a un punto será algo infumable. La forma de trabajar en software libre al ser desarrollos mayoritariamente realizados por aficionados se ajusta a la técnica del pico y de la pala y como es gratis y hay todo el tiempo del mundo pues si el proyecto acaba siendo una mierda no pasa nada y si es bueno, pues eso, como ese proyecto no hay nada y los forofos a adular un proyecto entre cien que son una mierda.
He sido bastante directo, así es más sencillo de comprender.
Luego se podría hablar de lo que son las metodologías, como se aplican, su utilidad, etc, etc, pero ya sería mucho…
> Si se analizan los frameworks de programación que más impacto están teniendo en el diseño web, estos son Rails y Django (o el propio Webapp de Google)
No sé por qué nos olvidamos de PHP(5) + Zend Framework, donde el diseño del framework es extenso pero no complejo (una virtud por sobre otros frameworks).
Nota aparte: jaiku no sufre los problemas de escalabilidad que tiene twitter. La tecnología cuenta: RoR vs PHP + Framework (no sé cual es), aunque según comentan están pasando a Django 😉
Pingback: Múltiples accesos simultáneos con Mongrel y Ruby on Rails « Todo es electrónico
Pingback: Redescubriendo a Dijkstra 18 años después « Ricardo Galli, de software libre