El sáb, 29-11-2008 a las 23:25 -0300, Horst H. von Brand escribió: > Hay quienes difieren. Si se requiere documentacion del codigo, el codigo no > se entiende y es malo. Si el programa requiere extensa documentacion extra, > es demasiado complejo de usar y no sirve.
Hay varios niveles de documentación, no solo el código. Por ejemplo diseños de alto nivel o API's. En general, cosas que no se pueden desprender del código fácilmente. No estoy hablando de toneladas de manuales inservibles, sino de lo mínimo necesario para que entender de qué se trata el asunto, para que ese análisis no me quite un par de días de trabajo. También está la documentación de los procesos, algo que gracias a las herramientas actuales se puede hacer de forma bastante simple, indolora y principalmente UTIL. Por ejemplo registros de cambios o seguimientos de bugs. Estas cosas que son obvias en el mundo del desarrollo de código abierto no lo son a nivel de desarrollo cerrado. Obviamente no estoy hablando de mi caso en particular, estoy hablando del resto de las empresas incluyendo las grandes. > > > - que use tecnologia (lenguaje, etc.) que provee una empresa > > > "importante" del rubro como IBM, Oracle, Sun o Microsoft? > > > Que use la mejor opción para resolver los requirimientos. > > Como determinas cual es esa? Desde el punto de vista de la comodidad del > desarrollador? Del usuario? De quien lo mantendra luego? Del que provee las > herramientas (al que le conviene cobrar lo mas caro posible, claro)? En general, en mi experiencia, no hay muchas opciones al respecto, casi siempre el entorno te encamina hacia una tecnología. Además que para este tipo de cosas no conviene ponerse inventivo, a la larga provoca mas dolores de cabeza para todos. Es muy tentador poner en practica "la ultima tecnología aprendida" pero con la experiencia se ve que hay que mezclar el ser conservador y al mismo tiempo explorador de nuevas tecnologías. > Hay que considerar la ultima hornada de TLA y buzzwords? Realmente la > ultima pomada de "desarrollo por telepatia con los alienigenas de los > planetas recien descubiertos" es mejor que las tradicionales o no? Como se > determina eso (particularmente antes que la moda haya sido reemplazada por > la de la siguiente temporada)? No necesariamente son modas. En vez de descartar una cosa por otra, se van encontrando mejoras, yo lo llamaría evolución. Por ejemplo hasta hace poco era natural pensar en aplicaciones con el contenido+presentación generado en el servidor (php/asp/jsp, etc), eso tenía ventajas y desventajas. Hoy en día es posible hacer aplicaciones que corren en el lado del cliente, eliminando las desventajas del modelo previo, pero manteniendo y ampliando sus ventajas. > > >> Nosotros conocemos el caso de Tuxpan ya que somos estudiantes de la > > >> UTFSM Sede Viña y en alguna oportunidad ellos hicieron presentaciones, > > >> donde por lo menos a mi me quedo claro > > >> que si se puede desarrollar sw de calidad. > > > > como estudiante uno no tiene mayor nocion de la "realidad"... si le > > > Cual es esa realidad ? > > Si tienes que preguntar, es que ni la sospechas... > > > > creiste a unas simples presentaciones creo vas por mal camino como > > > futuro empresario, a menos que hayas aprendido algunos tips de como > > > hacer buenas presentaciones... ;) > > > ¿¿¿ Cual seria un buen punto de partida para tener un empresa que cree > > sw de calidad ??? > > Leer a conciencia la literatura /seria/ al respecto (no, no son las cosas > que se publican bajo "Ingenieria de Software" precisamente; son clasicos > como el libro de Brooks y lo que han publicado Kernighan, Ritchie, Aho, > Plaugher, Bentley (la tropa de AT&T tras Unix) y los BSDistas originales; > ver los comentarios sobre "buen gusto" de Linus Torvalds, Alan Cox, Al Viro > y algunas otras luminarias similares). Conocer los famosos modelos de > madurez de desarrollo. Estos ultimos entenderlos lo suficiente para saber > que debieran ser quemados ritualmente en una pira [Aportan mucho mas a > generar frondosa documentacion y burocracia que buenos resultados]. Depende. El modelo CMMI por ejemplo habla de cosas que deberias tener como parte de tus practicas, pero queda de tu parte la forma en que las implementas. En general las prácticas son cosas que te ayudan y no se trata de simple burocracia, no creo por ejemplo que alguien en su sano juicio encuentre que hacer seguimiento de bugs formal es una burocracia, y cuando me refiero a formal no estoy hablando de llenar un monton de formularios inútiles, estoy hablando de las mismas prácticas que se llevan en el desarollo de código abierto. Se que la recomendación viene de cerca, pero me gustó mucho como quedó esta artículo sobre el tema: Madurez Organizacional: No es fanatismo Nerd http://tinyurl.com/6pjey6 [...] > Tener presente que la diferencia de productividad entre un desarrollador > malo y uno excelente puede facilmente superar las 100 veces. También hay que considerar que un desarrollador excelente no le va a ser atractivo trabajar en tareas triviales, tener sólo desarrolladores excelentes hace que nadie sea capaz de llevar a cabo ese tipo de tareas. Personalmente creo en un mezcla de ambos, en donde un conjunto de excelencia se encarga de la infraestructura, y otro grupo se encarga de "las terminaciones". -- Franco