El hardware no es la panacea, estoy de acuerdo contigo, pero el resultado del cambio de hardware o su duplicación suele ser visible de inmediato, y la inmediatez hoy en día es un valor en alza. Si un programa esta medianamente bien hecho las mejoras no suelen ser tan drásticas, otra cosa es que sea un auténtico desastre o que no se pensaró en sus inicios para los requerimientos actuales, en ese caso tienes toda la razón.
"Un buen programado es un buen programador", eso no te lo crees tú, ni nadie. Un buen programador en C con 15 años de experiencia que se pase a Java no es igual de productivo que un programador medio que se haya criado con la POO y que haya programado durante 3 años en Java, pese a quien le pese. Después de cierto tiempo, no digo yo que se igualen o que incluso le supere. bueno eso depende del tiempo libre, la familia y las ganas que tengas. no es lo mismo tener 25 años que 35 años, todo se oxida. Pues ese párrafo se basa en mi experiencia en el mundo del desarrollo del programador español. Lo que quiero decir que a la informática le faltan muchas cosas para llegar a ser una ingeniería. Todavía existen muchas malas prácticas, dando valor solo a tirar lineas de código y realizar las entregas en fechas sea como sea. He visto muchos desarrollos que no son ingeniería, ¿Por que se sabe que no son ingeniería?
No existe documentación de requisitos, ni análisis o diseño o la que hay está desactualizada, no hay histórico de cambios ni hay versionado. Si se creando una aplicación no hay planificación o la que hay es imposible y no se la cree nadie. El código no está normalizado, nomenclatura kafquiana, sin cabeceras, ni comentado, ni con posibilidad de generar documentación automatizada, o en el peor de los casos con código deliberamadente ofuscado. El conocimiento reside en un tío "imprescindible" que no puede ni irse de vacaciones, sea un crack o un mamón, etc. Y alguna o varias de estas cosas puede ocurrir y que el código sea digno de enmarcar si ese tío es un artista de la variable!!!! No confundir programar de lujo con hacer ingeniería. Un ingeniero prefiere tener a 4 tíos normales y no a un 1 crack más un inútil.
Yo recuerdo que hubo una época que los patrones y los framework no existían y los proyectos salían adelante. Cuando había que hacer un programa para algo se hacia un análisis y un diseño propio para cada proyecto, luego era correcto o incorrecto, pero para cada proyecto se hacia un estudio personalizado total. Hoy en día, lo que se hace es un estudio para ver analizar el problema e intentar ajustarlo a un solución de patrón de diseño, no digo que siempre, pero si que lo hace la mayoría. Y si no lo hacen, es que una de dos, o son unos gañanes y no tiene ni puta idea de los patrones o al revés, es suficientemente bueno para plantearse crear su diseño totalmente personalizado para esa aplicación. Te voy a decir un secreto, los patrones/framework son soluciones genéricas a problemas genéricos y suelen funcionar generalmente en la mayoría de los casos. Pero una buena solución personalizada, aunque requiere más análisis y más trabajo (Aunque sea modificando ligeramente un patrón concreto), da mejor rendimiento. Yo no he dicho que si no eres un artista eres un chapuza, es más eso creo que son los casos mínimos, el 90% de la gente es normalita o mejor dicho, el tipo de trabajo, la falta de motivación o los plazos de entrega hacen que el resultado sea normalito. Sinceramente yo conozco a poca gente que haya definido un nuevo patrón de diseño, un nuevo paradigma o lenguaje de programación o un framework de relevancia. La mayoría de gente que yo conozco se dedica a las personalizaciones de paquetes de software de gestión (ERP, CRM, SCM, BI, DWH, DM, ETL) o en el peor de los casos, al mantenimiento de aplicaciones legacy y alguna cosilla más o menos aburrida. Bueno, conozco algún caso de gente realmente buena que se dedica a cosas realmente interesantes pero son residuales. También conozco poca gente desastrosa que siga trabajando durante mucho tiempo.
Re:Captain obvious strikes back
(Puntos:1)Si un programa esta medianamente bien hecho las mejoras no suelen ser tan drásticas, otra cosa es que sea un auténtico desastre o que no se pensaró en sus inicios para los requerimientos actuales, en ese caso tienes toda la razón.
"Un buen programado es un buen programador", eso no te lo crees tú, ni nadie. Un buen programador en C con 15 años de experiencia que se pase a Java no es igual de productivo que un programador medio que se haya criado con la POO y que haya programado durante 3 años en Java, pese a quien le pese. Después de cierto tiempo, no digo yo que se igualen o que incluso le supere. bueno eso depende del tiempo libre, la familia y las ganas que tengas. no es lo mismo tener 25 años que 35 años, todo se oxida.
Pues ese párrafo se basa en mi experiencia en el mundo del desarrollo del programador español. Lo que quiero decir que a la informática le faltan muchas cosas para llegar a ser una ingeniería. Todavía existen muchas malas prácticas, dando valor solo a tirar lineas de código y realizar las entregas en fechas sea como sea. He visto muchos desarrollos que no son ingeniería, ¿Por que se sabe que no son ingeniería?
No existe documentación de requisitos, ni análisis o diseño o la que hay está desactualizada, no hay histórico de cambios ni hay versionado. Si se creando una aplicación no hay planificación o la que hay es imposible y no se la cree nadie. El código no está normalizado, nomenclatura kafquiana, sin cabeceras, ni comentado, ni con posibilidad de generar documentación automatizada, o en el peor de los casos con código deliberamadente ofuscado. El conocimiento reside en un tío "imprescindible" que no puede ni irse de vacaciones, sea un crack o un mamón, etc. Y alguna o varias de estas cosas puede ocurrir y que el código sea digno de enmarcar si ese tío es un artista de la variable!!!!
No confundir programar de lujo con hacer ingeniería.
Un ingeniero prefiere tener a 4 tíos normales y no a un 1 crack más un inútil.
Yo recuerdo que hubo una época que los patrones y los framework no existían y los proyectos salían adelante.
Cuando había que hacer un programa para algo se hacia un análisis y un diseño propio para cada proyecto, luego era correcto o incorrecto, pero para cada proyecto se hacia un estudio personalizado total. Hoy en día, lo que se hace es un estudio para ver analizar el problema e intentar ajustarlo a un solución de patrón de diseño, no digo que siempre, pero si que lo hace la mayoría. Y si no lo hacen, es que una de dos, o son unos gañanes y no tiene ni puta idea de los patrones o al revés, es suficientemente bueno para plantearse crear su diseño totalmente personalizado para esa aplicación.
Te voy a decir un secreto, los patrones/framework son soluciones genéricas a problemas genéricos y suelen funcionar generalmente en la mayoría de los casos. Pero una buena solución personalizada, aunque requiere más análisis y más trabajo (Aunque sea modificando ligeramente un patrón concreto), da mejor rendimiento.
Yo no he dicho que si no eres un artista eres un chapuza, es más eso creo que son los casos mínimos, el 90% de la gente es normalita o mejor dicho, el tipo de trabajo, la falta de motivación o los plazos de entrega hacen que el resultado sea normalito. Sinceramente yo conozco a poca gente que haya definido un nuevo patrón de diseño, un nuevo paradigma o lenguaje de programación o un framework de relevancia. La mayoría de gente que yo conozco se dedica a las personalizaciones de paquetes de software de gestión (ERP, CRM, SCM, BI, DWH, DM, ETL) o en el peor de los casos, al mantenimiento de aplicaciones legacy y alguna cosilla más o menos aburrida. Bueno, conozco algún caso de gente realmente buena que se dedica a cosas realmente interesantes pero son residuales. También conozco poca gente desastrosa que siga trabajando durante mucho tiempo.