Dicho en EDGE, el foro de usuarios de Allfusion Plex.I'm a Plex true believer. I was on vacation last week and I ran into a guy that works for Red Hat as a kernel developer. We had a discussion about system vs. application programming. He was rather dismissive of code generators. This also seems to be true of most Java developers.
(the following applies to experienced Plex developers) If you can tolerate 10 times more time to develop your application, fewer features, less consistency, 10 times more bugs due to lazy coding and you just absolutely need the source code to do it your way, you can squeeze 5% to maybe 10% more efficiency out of your application. Big Fat Deal.
The learning curve is steep and long but the payoff is big.
You need fewer SMART developers. Most shops try to just have fewer CHEAP developers and never realize any benefits.
sábado, enero 08, 2005
En dos palabras, una declaración de principios
A propósito de una pregunta circunstancial, Christopher Smith define, en poco más de dos párrafos, la razón por la que los generadores de código devendrán la forma predominante de construír software. Frente a la nube de desarrolladores y dirigentes de IT que prefieren la construcción de código basados en su escritura directa ("handcoding"), la diferencia la hace la productividad:
Suscribirse a:
Comentarios de la entrada (Atom)
2 comentarios:
No Mariano, entendiste mal.
Las empresas (muchas veces, en promedio, y tanto más en promedio cuanto más bajás en su presupuesto) prefieren pagar programadores baratos que hagan diez veces más escritura de código, con menos riqueza arquitectónica, menos consistencia, diez veces más errores ocultos, que optar por soluciones que requieren menos programadores con más conocimiento y visión, para lograr la misma productividad. O mucha más productividad con la misma cantidad de personas. Es decir, las empresas hablan de economizar reduciendo la planta de programadores baratos, porque no cambian de paradigma: siguen trabajando mal, pero encima, con menos gente. Y lo que necesitan es usar inteligencia. Es decir, terminan gastando mal.
No creas que los "generadores de código" te dejarán sin trabajo. Tampoco creas que entraremos en la edad en que los robots gobernarán al mundo: tu idea acerca de "quién corregirá los errores de los generadores" puede ser atacada desde dos flancos:
1. Con ese criterio, deberías desconfiar de los compiladores, que generan el código ejecutable de tu programa todos los días (estos son los primeros generadores de código que conozco)
2. Tu idea supone que los programadores no cometen errores, y que por lo tanto son más confiables que los generadores de código; los compiladores entre ellos.
Corregir un error sigue las mismas reglas de aseguramiento de la calidad de cualquier programa, y de hecho, así se procesan las pruebas: armar un escenario de casos de uso, definir un conjunto de pruebas, y analizar el resultado. Un error produce resultados erróneos. Si no, no es error. Si el problema está en la función generada a través de "código automático" (quizá tengas una idea equivocada de qué es esto), se corrige por la vía usual en que se hace siempre: vuelves a tu función, y modificas el "código" (que es intervenible, aunque a un nivel abstracto). Si el error está en el generador de código, el error origina un PTF (un parche al código del generador). La pregunta es: ¿Cuántos errores de compilador (o ensamblador, en tu caso) encontrás en tu trabajo? y ¿Cuántos errores de programación?.
Es curioso, pero es común encontrar resistencia a los "generadores", sin entrar mucho en su estudio; y hacerlo oponiéndole el trabajo de desarrollo de código directo, que podríamos llamar artesanal. Muchas veces, acompañado por la idea de que el algoritmo es un arte. Cualquier estudio de calidad te llevaría a saber claramente que el porcentaje de error en el trabajo manual es alto, y que la sistematización y adopción de procedimientos regulares (y regulados), achica el margen de error. La idea de esforzarse por el algoritmo perfecto puede ser buena cuando estamos hablando de un trabajo de poca magnitud o riesgo. Pero cuando se trata de *sistemas* que pudieran involucrar varias decenas de miles de programas, y algunos cientos de tablas (o persistencia, para generalizar), elaborados por una o más decenas de programadores, la posibilidad de manejar el riesgo es remota sin procedimientos del tipo que quiza no todos, pero sí algunos generadores te permiten.
Y eso dicho en cuanto al código generado, porque luego queda mucho más: el manejo de versionamiento y release, por ejemplo, o el manejo de la documentación.
Publicar un comentario