Portada
mis comunidades
otras secciones
#1:
“Lo que un programador puede hacer en un mes, dos programadores pueden hacerlo en dos meses.”
#5:
Si ponemos a una programadora a parir un hijo, podemos tener el resultado en 9 meses.
Pero si ponemos a un equipo de dos programadoras, podemos tenerlo en 4.5 meses.
Si una de las programadoras es una programadora senior, podemos dejar el tiempo en 3.5 meses.
Si añadimos a dos becarias, que aunque no tienen tanto expertise sí tienen ganas y juventud, podemos reducir el tiempo a 2 meses. Y además, formamos a las becarias por inmersión.
Y si les pedimos un esfuerzo y se quedan por las tardes y los fines de semana, podemos conseguir que el niño esté listo en 1 mes.
Y los posibles defectos, al mantenimiento.
Pero si ponemos a un equipo de dos programadoras, podemos tenerlo en 4.5 meses.
Si una de las programadoras es una programadora senior, podemos dejar el tiempo en 3.5 meses.
Si añadimos a dos becarias, que aunque no tienen tanto expertise sí tienen ganas y juventud, podemos reducir el tiempo a 2 meses. Y además, formamos a las becarias por inmersión.
Y si les pedimos un esfuerzo y se quedan por las tardes y los fines de semana, podemos conseguir que el niño esté listo en 1 mes.
Y los posibles defectos, al mantenimiento.
Comentarios
“Lo que un programador puede hacer en un mes, dos programadores pueden hacerlo en dos meses.”
#1 Muy buena. Me la apunto.
#1 Estas hablando de buenos programadores. Si no son "tan buenos", dobla el tiempo (otra vez) por cada programador que añadas, o reduce la calidad en la misma medida.
#1 a mi me enseñaron: "lo que una mujer hace en 9 meses, no lo pueden hacer 9 mujeres en un mes"
#4 Esa cita me encanta pero no está muy bien traducida.
La gestación de un niño tarda nueve meses no importa a cuántas mujeres pongas en ello.
Así quedaría mejor
#1 #4 #8 La versión que yo conozco dice: «Un Project Manager es alguien que cree que nueve mujeres pueden alumbrar un niño en un mes.»
CC #5 #7
#10 Buena también!
#8 #4 Pero 9 mujeres te dan 9 hijos en 9 meses... Si se sabe dividir el trabajo se coge buena eficiencia.
#13 Ahí está la cosa. El software no es algodón o patatas. Si necesitas un proyecto determinado, el conseguir nueve no te va a aportar nada, tendrás que tirar ocho a la basura.
#13 La cosa es que el proyecto se llama niño, no cole.
#4 Yo la conozco simplemente como "una mujer tiene un niño en 9 meses, pero 9 mujeres no tienen un niño en un mes". Y a algún gerente se la he soltado.
#1 Tranquilo siempre vendrá el comercial de turno: mete a 5 tios y lo quiero en una semana
luego fui a un lugar mejor pagado.
pd: a mi me ha pasado. Hasta que le he dicho que solo uno puede tocar lo que había que hacer y era secuencial: Primero A, luego B... hasta el final. Es decir el B no s puede acometer sin el A.
ppd: me cambiaron de cliente en cuanto dije eso
Si ponemos a una programadora a parir un hijo, podemos tener el resultado en 9 meses.
Pero si ponemos a un equipo de dos programadoras, podemos tenerlo en 4.5 meses.
Si una de las programadoras es una programadora senior, podemos dejar el tiempo en 3.5 meses.
Si añadimos a dos becarias, que aunque no tienen tanto expertise sí tienen ganas y juventud, podemos reducir el tiempo a 2 meses. Y además, formamos a las becarias por inmersión.
Y si les pedimos un esfuerzo y se quedan por las tardes y los fines de semana, podemos conseguir que el niño esté listo en 1 mes.
Y los posibles defectos, al mantenimiento.
Un monstruo ese Brooks, además teniendo en cuenta la época.
Cuando leí el libro me encantó esta cita:
The bearing of a child takes nine months, no matter how many women are assigned.
Creo que en todos estos comentarios se refleja muy bien el punto de vista de los desarrolladores pero falta el punto de vista del gestor, comercial, jefe de proyecto o lo que sea. En un ejercicio de empatía voy a ponerme un momento de su parte.
Primero tengo que dar toda la razón al artículo y a la mayoría de los comentarios que acertadamente defienden ese puto de vista. Dicho esto, tengo que añadir que los proyectos software sólo existen si hay alguien que decide poner dinero para ponerlos en marcha. No nacen como entes perfectos con financiación ilimitada. Los proyectos suelen partir de definiciones pobres e incompletas y el cliente no tiene una idea realista de cuanto esfuerzo puede llevar ejecutarlo.
En esta situación, es poco probable que el cliente asuma el coste real del proyecto. Si no lo asume, contratará una ejecución que ha rebajado precios para captar al cliente y que no puede permitirse emplear a los recursos necesarios por lo que obtendrá un resultado insatisfactorio. Si lo asume, y esto es muy difícil porque recordemos que no tiene una estimación realista, depende de la empresa desarrolladora. Esta puede decidir maximizar beneficio haciendo mierda a precio de oro (y así de paso compensar todos los proyectos del primer tipo que ha ejecutado) o puede decidir hacer las cosas bien aún a costa de estrechar peligrosamente los márgenes o incluso convertir en pérdidas lo que a priori podía ser un goloso beneficio. ¿Como proveedores qué haríais?
El problema bajo mi punto de vista viene del punto inicial: la mala definición del problema y, derivado de esto, la dificultad que tienen los contratantes en exigir responsabilidades en base a la definición inicial. Como es difícil exigir responsabilidades, las empresas desarrolladoras se suelen ir de rositas haciendo mierda y, como el método funciona, van a seguir haciéndola sine die.
En resumen: El problema bajo mi punto de vista viene de la poca experiencia que tienen los clientes planteando sus propios proyectos y haciendo el seguimiento adecuado. Aquí aportan mucho las metodologías ágiles que permiten rectificar a tiempo antes de pegarse la gran hostia, pero estas o no se aplican o se hace de manera catastrófica.
Los gestores, comerciales, etc sólo hacen su trabajo: captar cuantos más clientes mejor e intentar ganar lo más posible aunque esto genere malestar en los desarrolladores que son conscientes de que están haciendo mierda pero no lo son tanto de lo que cuesta pagar las nóminas.
PD1: Sé que el artículo habla de hacer las cosas bien desde el principio para abaratar costes, pero pensad que los que toman las decisiones intentan abaratarlos desde el principio para hacer lo mínimo para cobrar. Calcular ese mínimo sobre la marcha es un proceso de negociación donde los equilibrios son muy complicados. Muchas veces entregas una mierda inicial, la cobras y luego la rentabilizas con mantenimiento por muchos años. Si lo haces muy bien de primeras te has gastado todo el dinero y encima te quedas sin mantenimiento. Al cliente le habrá salido muy bien, pero al desarrollador no.
PD2: ¿Si hacer las cosas bien fuera más rentable, por qué no sobreviven o crecen más las empresas que lo hacen bien? Alguna habrá habido que lo hiciera bien aunque fuera de forma experimental
Lo que me cuesta en mi empresa que entiendan eso...
#9 en la tuya y en muchas. Gestores y jefes de proyecto mediocres con desarrolladores muy buenos, llevando proyectos la mar de mal quemando desarrolladores y cuando sus gestiones y planificaciones han sido pésimas, su solución es "meter más gente". Claro como todos "los de arriba" son mediocres y tienen, eso si, un master en escurrir el bulto, es lo que se lleva utilizando desde hace décadas.
#11 Meter mas gente y, sobre todo, hacer mas horas extras (gratis, por supuesto). De un curro me pire precisamente porque esta era la única solución que tenían para cualquier problema, por mucho que le explicases de donde venían los retrasos (requisitos escritos en una servilleta de bar y sobraba espacio).
#9 Ah. Pero lo entienden? Joder, enhorabuena.
Aunque ya conocido, meneo, a ver si se lo lee más de uno que yo me sé...
Un equipo muy pequeño, inclusive un solo buen programador podría crear el mejor sistema operativo de la historia, pero NO triunfará porque al común de los mortales les importa un pimiento eso, lo que interesa es que se pueda ejecutar algún viejo software aplicativo de 30 años que no quieren actualizar o nadie quiere portar. Seamos claros, tanto Windows como Linux arrastran una muy pesada carga de "software legacy" y prácticas que en el pasado eran muy necesarias por lo limitado del hardware (por ejemplo librerías compartidas para que las use N programas) y todo para dar soporte a software dinosaurio del pasado.
Hoy un software podría tener TODAS las dependencias en su propio directorio, así se repita la misma librería 1000 veces en todo el disco duro. ¡Que tenemos discos de terabytes!, o esa grosería llamada el registro de Windows o más grosero aún las llamadas variables de entorno.. puaj.
#18 Se te ha olvidado añadir "parodia" que la gente se lo va tomar en serio.
#26 ¿dices que vas a estudiar tanto que vas a perder horas de sueño?
#27
Ya te vale. Que no es desprecio a ninguna profesión, que conste. Y si se ha entendido así, mis disculpas.
#28 No entiendo que quieres decir. ¿Porque te voy a quitar tu sueño si lo que te he dado es la posibilidad de conseguirlo?
De ahí la importancia de conservar a los buenos trabajadores. Si les tratan a palos y con desprecio, tarde o temprano se acabarán yendo, y para sustituirlos se pueden encontrar con un buen problema. Por ahorrarse 2000 € al año al final tienen que pagar dos veces su sueldo y ni aún así pueden sacar el trabajo igual.
Ya, pero los problemas desde el punto de vista de alguien de sistemas, con perdón son:
1. Cárnicas incompetetes que solo saben vender humo y carne. Para ellas todo es posible, solo hay que presionar.
2. Clientes psicópatas que solo buscan máximo rendimiento, pidiendo el cielo a precio de coste.
3. Programadores inútiles y/o quemados. Solo saben de lo suyo p.e. Php y cuando tienen problemas balones fuera, siempre al campo de sistemas para que les den la solución.
Amenazas, insultos, coacciones, jornadas eternas ... en fin, prefiero trabajar de barrendero.
#21 https://cursosmasters.com/oposiciones-barrendero/
#23 Me has quitado mi sueño,