Cuando se habla de software exitoso, ¿compensa contratar a programadores rápidos? ¿O ganan siempre la carrera los programadores lentos y constantes? Según el autor de "The Case For Slow Programming", los programadores tienen que desacelerar para obtener resultados más rápido.
A veces genera más dinero hacerlo rapido y mal. Permite conseguir el contrato al ofertar mejores plazos y precio, y luego genera ingresos por mantenimientos.
#1 yo entiendo que el texto se refiere a obtener un producto de calidad, en otro caso no tendría sentido, cualquier puede entregar una ñapa en 4 días que no se aguante, pero a eso no se le suele llamar "cumplir un objetivo", ¿no?
#4 no se porque con tus palabras estaba pensando en la web del AEAT, en la nueva de transparencia, en la de RENFE...
#4 En los 90 el eslogan de la Generalitat de Catalunya era:
"La feina mal feta no te futur" (el trabajo mal hecho no tiene futuro)
y nosotros (en esa época eramos desarrolladores COBOL) deciamos: "el trabajo mal hecho... tiene garantizado un contrato de mantenimiento de varios años".
Depende de si el proyecto es trivial o no. La repercusión de cualquier error de diseño por pequeño que sea termina convirtiéndose en una piedra atada a tu cuello con la que tendrás que nadar hasta el final. En ocasiones, cuando los errores han sido importantes merece la pena volver al principio, soltar la pesada piedra y volver a partir de cero o casi de cero.
Es algo que me ronda la cabeza últimamente. Yo al menos necesito tiempo para asimilar el problema y el modelo del mismo que yo he creado (el software). Estoy seguro que cuanto más rápido programo más errores de diseño y análisis cometo.
Sí. Es como leer, puedes leer muy rápido y no enterarte de nada. Pero si lees más pausado, te enterarás mucho mejor.
Si escribes código muy rápido hay mayores probabilidades de que falles o pongas una orden, línea,... errónea. Si lo haces más lento te fijarás más. Claro, alguno pensará ¿Pero si alguien programa 2.000 líneas de código, en una hora (por poner un ejemplo) y otro programa 1.200 líneas. El programa no se acaba antes en el primer caso?, sí. Pero precisamente ese es un problema muy actual. Que aplicaciones salgan con una enorme cantidad de errores, algunos infantiles, por meter esa prisa.
Por lo tanto, los que se fijan más no tienen luego que andar reparando errores. Irán más lentos, pero sacarán un producto de calidad, y encima a medio-plazo perderán menos dinero que si se tienen que dedicar a reescribir parte del código y solucionar errores, por esa prisa anteriormente mencionada.
Comentarios
A veces genera más dinero hacerlo rapido y mal. Permite conseguir el contrato al ofertar mejores plazos y precio, y luego genera ingresos por mantenimientos.
El modelo de las cárnicas.
#1 yo entiendo que el texto se refiere a obtener un producto de calidad, en otro caso no tendría sentido, cualquier puede entregar una ñapa en 4 días que no se aguante, pero a eso no se le suele llamar "cumplir un objetivo", ¿no?
#4 no se porque con tus palabras estaba pensando en la web del AEAT, en la nueva de transparencia, en la de RENFE...
#4 En los 90 el eslogan de la Generalitat de Catalunya era:
"La feina mal feta no te futur" (el trabajo mal hecho no tiene futuro)
y nosotros (en esa época eramos desarrolladores COBOL) deciamos: "el trabajo mal hecho... tiene garantizado un contrato de mantenimiento de varios años".
Depende de si el proyecto es trivial o no. La repercusión de cualquier error de diseño por pequeño que sea termina convirtiéndose en una piedra atada a tu cuello con la que tendrás que nadar hasta el final. En ocasiones, cuando los errores han sido importantes merece la pena volver al principio, soltar la pesada piedra y volver a partir de cero o casi de cero.
Es algo que me ronda la cabeza últimamente. Yo al menos necesito tiempo para asimilar el problema y el modelo del mismo que yo he creado (el software). Estoy seguro que cuanto más rápido programo más errores de diseño y análisis cometo.
Depende de si el objetivo es entregar "algo" pronto o el objetivo es entregarlo bien.
Sí. Es como leer, puedes leer muy rápido y no enterarte de nada. Pero si lees más pausado, te enterarás mucho mejor.
Si escribes código muy rápido hay mayores probabilidades de que falles o pongas una orden, línea,... errónea. Si lo haces más lento te fijarás más. Claro, alguno pensará ¿Pero si alguien programa 2.000 líneas de código, en una hora (por poner un ejemplo) y otro programa 1.200 líneas. El programa no se acaba antes en el primer caso?, sí. Pero precisamente ese es un problema muy actual. Que aplicaciones salgan con una enorme cantidad de errores, algunos infantiles, por meter esa prisa.
Por lo tanto, los que se fijan más no tienen luego que andar reparando errores. Irán más lentos, pero sacarán un producto de calidad, y encima a medio-plazo perderán menos dinero que si se tienen que dedicar a reescribir parte del código y solucionar errores, por esa prisa anteriormente mencionada.
Y obviamente, esto es mucho peor con el hardware.
Salu2