por
pobrecito hablador
el Viernes, 13 Enero de 2012, 11:55h
(#1297932)
Refiriéndonos al software a medida:
Realmente me parece una jugarreta muy sucia y algo a advertir a los clientes: he reducido el coste de este software a base de cargar los requerimientos.
Normalmente es requerimiento del cliente y es muy consciente de lo que pide.
El hardware es estándar, llamas a la empresa y te pone la cantidad que quieres a un precio alto pero conocido de antemano con la garantía de que todo va a funcionar.
El software es a medida por lo que se debe modificar constantemente según las necesidades o caprichos del cliente y eso es un trabajo de muchas horas, difícil de valorar a priori y sin garantía de éxito. Mejor programadores baratos y software cutre pero fácil de entender por cualquiera, que software de calidad pero fácil de entender solo para expertos que cobran un pastón (de los que vas a depender para toda la vida).
Es triste pero más importante que la calidad es no complicarse la vida.
El hecho de focalizar en trabajo por trabajo es migajas para hoy, hambre para todos mañana.
Más bien pasado mañana o al otro. Para hoy y mañana a las consultoras les sale más rentable el trabajo chapucero y, en la mayoría de los casos, al cliente también. Desde luego a la larga el mal trabajo sale más caro, pero normalmente paga el cliente, así que para que preocuparse.
Y esto es así en España, Alemania, EEUU, China, etc. etc. en todo el mundo mundial, aunque es cierto que en chapucería España es champions league.
por
pobrecito hablador
el Viernes, 13 Enero de 2012, 13:23h
(#1297946)
Mejor programadores baratos y software cutre pero fácil de entender por cualquiera
¡Coño! ¡Un oxímoron de esos!
Como ya han dicho por ahí, la diferencia va a estar entre hacer un buen trabajo y hacer un mal trabajo. Un mal programador puede hacerte una chapuza en Java, pero no te va a hacer nada funcional en C. Cuando alguien me dice que en Java se tarda mucho menos ya sé que en realidad me está diciendo que en C no es capaz de hacerlo.
Java tiene muchas facilidades que hacen tareas típicas mucho más rápidas, en C tienes que buscarte una biblioteca que te lo haga (si no quieres implementarlo tú). A la larga, en un proyecto largo, esos detalles no se notan en el tiempo de desarrollo. Lo que sí se nota es si tus programadores eran unos chapuceros. Harto estoy de ver programas en Java con fugas de memoria, problemas de interbloqueo, deadlocks, mala gestión de red que hace que la aplicación caiga en cuanto pasa algo inusual o tan mala gestión de hilos que se satura en cuanto recibe un mínimo de carga.
Esos problemas son los que se van a comer el tiempo de desarrollo, y el 90% de los "programadores" de Java a los que se les llena la boca con lo rápido que se hacen las cosas en Java, son incapaces totalmente de abordarlos.
Y eso de que con más hardware se soluciona es una chorrada como un templo, por mil motivos. Ya te han contado unos cuantos...
Hola,
Sobre esto tengo algo que decir.
He trabajado en esto durante 12 años. En clientes/proyectos grandes. Hay que tener en cuenta todos los costes totales de un sistema informático. Es decir: infraestructura(Hardware&Comunicaciones) mantenimiento de los entornos (desarrollo, pruebas, certificación y producción) personal de operaciones, monitorización y soporte desarrollo, pruebas, certificación gestión del proyecto, de la configuración, despliegues etc. De todo esos costes, el coste de hardware es el más controlado, el que da más resultado visible y en comparación menos costoso. Si requieres de técnicos de sistemas, gente de almacenamiento/backup, soporte/guardias 7x24, analistas, diseñadores, programadores, gente de pruebas, certificación y calidad, y claro está, sus respectivos responsables, pongamos que el coste medio por jornada es de 250(y tiro bajo), echad las cuentas en un año. Estamos hablando de plantillas internas y externas de miles de personas. Pongamos un ejemplo de una empresa que tenga unas 1.000 personas estables al año dedicadas a proyectos(entre internos y externos), unos 200 días de trabajo al año y pongamos una media de unos 250/día. Sale unos 50 millones/año. Comprenderéis que el coste en hardware (Pongamos unos 10 millones) en renovar los servidores/cabinas cada 5 años es asumible (eso si no es de renting que te los renuevan cada cuierto tiempo), y eso que cada vez el consumo del nuevo hardware disminuye y las prestaciones aumentan. el hardware mejora horrores!!!!
Entiendo la postura de mejorar en el desarrollo, pero la realidad dice que invertir en hardware más potente da más resultado visibles que en formar y contratar a mejores programadores, por no decir que cada día sale un lenguaje o un nuevo framework o algo que hace que la gente que a día de hoy esta preparada, y con experiencia, pase a estar desfasada de un día para otro.
Sobre la ingeniería en la informática. Un proyecto de ingeniería, todos los recursos de un mismo perfil deben estar normalizados, no debería haber ni mejores ni peores, todos deberían ser reemplazables de forma transparente y todo el conocimiento total o parcial no debería residir en nadie en concreto, es decir que hoy podría empezar una fase una empresa y seguir otra fase otra empresa sin afectación. eso es el ideal de la ingeniería. La automatización, reutilización, cumplimiento de calidad y plazos establecidos, control de riegos, costes,tiempo, etc...
El programador genial que hace cosas increíbles y revolucionarias, no encajaría en proyecto de ingeniería normales(Quizás como consultor sí o en proyectos de I+D). Es como decir que un proyecto de un edificio de pisos normalito depende en gran medida de un arquitecto/albañil genial. Es verdad que, sin embargo algunos de los proyectos más exitosos los lidera "Programadores geniales", pero realmente son falsos programadores a secas y nos son 4, son más que programadores y son mucha gente detrás
La ingeniería lo que provee es una manera de hacer procimentalizada que asegura en mayor medida el éxito del proyecto en base a una experiencia previa y contrastada. Ejemplo: ¿Os suena los patrones? Pues utilizar patrones, al menos para mi, supone renunciar a pensar una solución mejor que la propuesta por la experiencia de otra gente que se ha enfrentado al mismo problema y a las herramientas o desarrollos realizados en base a ellos (Como por ejemplo los framework). Quizás el uso correcto de patrones a los "programadores artistas" eso no les parezca creativo ni motivador, pero para un ingeniero en informática ese es el camino correcto.
Re:Captain obvious strikes back
(Puntos:0)El hardware es estándar, llamas a la empresa y te pone la cantidad que quieres a un precio alto pero conocido de antemano con la garantía de que todo va a funcionar.
El software es a medida por lo que se debe modificar constantemente según las necesidades o caprichos del cliente y eso es un trabajo de muchas horas, difícil de valorar a priori y sin garantía de éxito. Mejor programadores baratos y software cutre pero fácil de entender por cualquiera, que software de calidad pero fácil de entender solo para expertos que cobran un pastón (de los que vas a depender para toda la vida).
Es triste pero más importante que la calidad es no complicarse la vida.
Y esto es así en España, Alemania, EEUU, China, etc. etc. en todo el mundo mundial, aunque es cierto que en chapucería España es champions league.
Re:Captain obvious strikes back
(Puntos:1, Inspirado)¡Coño! ¡Un oxímoron de esos!
Como ya han dicho por ahí, la diferencia va a estar entre hacer un buen trabajo y hacer un mal trabajo. Un mal programador puede hacerte una chapuza en Java, pero no te va a hacer nada funcional en C. Cuando alguien me dice que en Java se tarda mucho menos ya sé que en realidad me está diciendo que en C no es capaz de hacerlo.
Java tiene muchas facilidades que hacen tareas típicas mucho más rápidas, en C tienes que buscarte una biblioteca que te lo haga (si no quieres implementarlo tú). A la larga, en un proyecto largo, esos detalles no se notan en el tiempo de desarrollo. Lo que sí se nota es si tus programadores eran unos chapuceros. Harto estoy de ver programas en Java con fugas de memoria, problemas de interbloqueo, deadlocks, mala gestión de red que hace que la aplicación caiga en cuanto pasa algo inusual o tan mala gestión de hilos que se satura en cuanto recibe un mínimo de carga.
Esos problemas son los que se van a comer el tiempo de desarrollo, y el 90% de los "programadores" de Java a los que se les llena la boca con lo rápido que se hacen las cosas en Java, son incapaces totalmente de abordarlos.
Y eso de que con más hardware se soluciona es una chorrada como un templo, por mil motivos. Ya te han contado unos cuantos...
Re:Captain obvious strikes back
(Puntos:1)Sobre esto tengo algo que decir. He trabajado en esto durante 12 años. En clientes/proyectos grandes.
Hay que tener en cuenta todos los costes totales de un sistema informático. Es decir:
infraestructura(Hardware&Comunicaciones)
mantenimiento de los entornos (desarrollo, pruebas, certificación y producción)
personal de operaciones, monitorización y soporte
desarrollo, pruebas, certificación
gestión del proyecto, de la configuración, despliegues
etc.
De todo esos costes, el coste de hardware es el más controlado, el que da más resultado visible y en comparación menos costoso.
Si requieres de técnicos de sistemas, gente de almacenamiento/backup, soporte/guardias 7x24, analistas, diseñadores, programadores, gente de pruebas, certificación y calidad, y claro está, sus respectivos responsables, pongamos que el coste medio por jornada es de 250(y tiro bajo), echad las cuentas en un año. Estamos hablando de plantillas internas y externas de miles de personas.
Pongamos un ejemplo de una empresa que tenga unas 1.000 personas estables al año dedicadas a proyectos(entre internos y externos), unos 200 días de trabajo al año y pongamos una media de unos 250/día. Sale unos 50 millones/año.
Comprenderéis que el coste en hardware (Pongamos unos 10 millones) en renovar los servidores/cabinas cada 5 años es asumible (eso si no es de renting que te los renuevan cada cuierto tiempo), y eso que cada vez el consumo del nuevo hardware disminuye y las prestaciones aumentan. el hardware mejora horrores!!!!
Entiendo la postura de mejorar en el desarrollo, pero la realidad dice que invertir en hardware más potente da más resultado visibles que en formar y contratar a mejores programadores, por no decir que cada día sale un lenguaje o un nuevo framework o algo que hace que la gente que a día de hoy esta preparada, y con experiencia, pase a estar desfasada de un día para otro.
Sobre la ingeniería en la informática.
Un proyecto de ingeniería, todos los recursos de un mismo perfil deben estar normalizados, no debería haber ni mejores ni peores, todos deberían ser reemplazables de forma transparente y todo el conocimiento total o parcial no debería residir en nadie en concreto, es decir que hoy podría empezar una fase una empresa y seguir otra fase otra empresa sin afectación. eso es el ideal de la ingeniería.
La automatización, reutilización, cumplimiento de calidad y plazos establecidos, control de riegos, costes,tiempo, etc...
El programador genial que hace cosas increíbles y revolucionarias, no encajaría en proyecto de ingeniería normales(Quizás como consultor sí o en proyectos de I+D). Es como decir que un proyecto de un edificio de pisos normalito depende en gran medida de un arquitecto/albañil genial. Es verdad que, sin embargo algunos de los proyectos más exitosos los lidera "Programadores geniales", pero realmente son falsos programadores a secas y nos son 4, son más que programadores y son mucha gente detrás
La ingeniería lo que provee es una manera de hacer procimentalizada que asegura en mayor medida el éxito del proyecto en base a una experiencia previa y contrastada.
Ejemplo: ¿Os suena los patrones? Pues utilizar patrones, al menos para mi, supone renunciar a pensar una solución mejor que la propuesta por la experiencia de otra gente que se ha enfrentado al mismo problema y a las herramientas o desarrollos realizados en base a ellos (Como por ejemplo los framework). Quizás el uso correcto de patrones a los "programadores artistas" eso no les parezca creativo ni motivador, pero para un ingeniero en informática ese es el camino correcto.