Si sirve como ejemplo, acabo de terminar una evaluación de arquitectura para una empresa que tiene un sistema que integra todos sus procesos. El sistema esta hecho en C#, y lo están haciendo, un equipo de 10 programadores, desde hace 1 año y 8 meses (si, parte de las cosas aburridas que hacemos para poder hacer cosas divertidas es "consultoría de arquitectura"). Bueno, justo da la casualidad de que el año pasado nosotros hicimos un sistema para una empresa del mismo tipo que esta... más chica en volumen pero exactamente igual en el modelo de negocio. Nosotros el sistema lo hicimos en 8 meses hombre. Ponele que dado el tamaño y ciertas particularidades, hubieramos tardado 1 año... sigue siendo menos del 7% del esfuerzo, para hacer lo mismo. Ni hablar de la plata que se gastaron. entonces... yo digo que no importa que todo se pueda hacer con todo... por algo no programamos en assembler. Y tampoco deberíamos programar en Java o C#, con esos niveles de rendimiento. Y por cierto, eso me hace dudar mucho del criterio "eficientista" de los que usan Java o .Net, lo que me lleva a pensar que hay otro motivo. Y el motivo que yo creo es este: durante años han tratado de llevar la producción de sistemas a un modelo fordista, donde hay un par de gente que conoce todo el proceso, contra un montón de gente que solo sabe operar su máquina, y nada más... eso es más fácil de implementar con Java o .Net que con Smalltalk. Pero como no funciona en realidad para la producción de sistemas, los resultados son toda esa porquería que anda dando vueltas. Y después se extrañan que, en esas tecnologías, solo el 65% de los proyectos iniciados se implementen, y solo el 30% se hagan con el presupuesto inicialmente estimado.
Saludos, Esteban El 08/05/2010, a las 2:37p.m., Hernán Galante escribió: > Personalmente no dejo de sorprenderme cuando veo algunos resultados de cosas > hechas con Smalltalk. Hay que admitir que probablemente el 99.9% de las > problematicas a resolver computacionalmente, se pueden hacer en cualquier > herramienta. Lo que no se habla, es de los costos y tiempos de hacer ello. > Creo que Smalltalk tiene una gran ventaja allí en ahorros de tiempos para la > prototipación rápida, y para algo más importante aún, el entendimiento de la > problematica. > En la última edición de Smalltalks, estaba junto a Andrés Valloud y recuerdo > haberme literalmente quedado con "la boca abierta" al ver el software que > hicieron dos personas para el negocio de casinos. Un soft de muchisima > calidad, dado que el producto final se veía muy bueno. Pero quizás nada fuera > de lo normal que puedas ver en el mercado. > Lo interesante, no fue el producto, fueron los tiempos. Se desarrolló y > aprendió la problematica de negocio y la problemática técnica en 6 meses, > sólo 2 personas. > Y yo me acuerdo que le dije a Andrés, yo con 3 veces la cantidad de recursos > en 6 meses desarrollamos un aplicativo de ticketing en C# y era inusable para > el usuario. Recién al cabo de casi 2 años de desarrollo y más de 100K USD x > año invertidos por la empresa, entró en la etapa de madurez y ya me estoy > retirando de ese equipo de trabajo. Economicamente, un desastre. Recuerdo que > Andrés me decía, "decilo, decilo", y yo pensaba, "estas loco, me muero de la > verguenza!!!". > Deberíamos empezar a mostrar al resto del mundo estos resultados. Los > análisis post-morten de cada desarrollo. Son realmente fascinantes. > -- > Saludos, > Hernán.- > > 2010/5/8 Norberto Manzanos <[email protected]> > Muy buenos datos, Guillermo. Hay muchos temas interesantes. > Me quedo con una cuestión. > "todo lo que se puede hacer con Smalltalk también se puede hacer con Java" > > Yo no se si esto es así. Muchas veces he pensado que con un criterio > eficientista, conviene desarrollar con Java. > La cuestión es si el eficientismo, el "se puede hacer igual", el sólo medir > los resultados obtenidos y el costo que implicaron es lo único que importa. > Indudablemente, no se puede esperar otra cosa de una empresa privada. Al > menos, si la ley fundamental es el aumento de la ganancia y su consecuente > reducción de costos. También hay que considerar que el aumento de la ganancia > no tiene un único camino posible, no siempre es tan mecánico. Ahí está Google > con su modelo de negocios bastante más complejo, posicionandose entre las > primeras empresas del mundo. > Pero más allá de que Smalltalk sea una tecnología mejor, y que es una > cuestión muy difícil de explicar cómo puede ser que una tecnología mejor no > se imponga (creo que el gran culpable es la economía de mercado, pero admito > que no es sencillo), me parece que lo que no tenemos que olvidar es nuestra > situación en tanto programadores. Porque no se trata sólo de dos actores: > empresas y consumidores. Se trata también de trabajadores que están en el > medio del proceso. Smalltalk no es una tecnología mejor (o lo sería) porque > produzca código más eficiente, más sustentable, más escalable. Es mejor > porque el trabajo con esa tecnología es más humano, es más placentero, > requiere otras habilidades, además de las que se requieren en otros > lenguajes, se puede explicar mejor a los usuarios, se asemeja más a los modos > de pensamiento generales, etc, etc. > Se que son argumentos que parecen no poder salir del círculo de fans de > Smalltalk, que no se pueden esgrimir en una situación de negocios o de > contratación, etc. > Acaso una de las explicaciones de la "derrota" de Smalltalk frente a Java es > que lo que piensan y sienten los programadores no es tenido en cuenta, si no > sólo la eficiencia y la optimización de la ganancia. > > Saludos > Norberto > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org > > > > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
