-
Ponga a los mejores en los proyectos pequeños E-mail
04.09.2007

equipoAl aumentar el tamaño del equipo del proyecto, disminuye la productividad personal. ¿Es porque en los equipos grandes los programadores son peores? ¿Porque la gestión los entorpece?.

Por supuesto que se trata de una generalización, pero es una percepción recurrente, o al menos a mi me da esa impresión, y por eso me ha llamado la atención este consejo del consultor de EE Times, Jack Ganssle:

Ponga a los mejores en los proyectos pequeños.
Los mejores desarrolladores son seis veces más productivos que el más flojo del equipo, pero sólo cuando se mide a ambos en proyectos pequeños.
A medida que el proyecto crece el mejor y el peor son igual de improductivos. Los grandes proyectos tienen grandes cantidades de ruido, reuniones, informes, e-mail...
Un espabilado atiende en las reuniones a la misma velocidad que un torpe.

Comentarios

Publicar un comentario

Entradas más populares de este blog

Stop Naming Your Variables "Flag": The Art of Boolean Prefixes

-
Shallow Focus Flags — Stop Naming Your Variables "Flag" Shallow Focus Flags thatamazingprogrammer.com — Stop Naming Your Variables "Flag": The Art of Boolean Prefixes The Problem You inherit a codebase and find this: public class OrderProcessor { private bool open; private bool flag; private bool done; private bool status; public void Process(bool check) { if (open && flag) { flag = false; status = true; } if (done) { // what happens here? } } } Readable? No. What is open ? Is the store open? Should the file open? What is flag ? That's a variable screaming "I'll fix this later." And is done a question ("is it done?") or a command ("mark it done")? Boolean names are ambiguous land mines. They look innocent until you have to figure out what they mean during a 3 AM outage. ...
Leer más

Programadores con producción neta negativa (NNPP)

-
Imagen
Cuando me topé por primera vez con el término NNPP (siglas de "Net Negative Producing Programmer") no puedo negar que me hizo cierta gracia. Cuanto menos, resultaba curioso pensar que podían existir desarrolladores cuyo saldo en las aportaciones a un proyecto resultara negativo, o lo que es lo mismo, que el valor de su producción fuera superado por el coste de los errores y defectos que introducían en las aplicaciones. Y con el término "desarrolladores" no me refiero exclusivamente a programadores; el concepto es válido para analistas, arquitectos, testers, o cualquier otro rol relacionado con la construcción de software. Aunque seguro que todos hemos trabajado con profesionales que consideramos desastrosos poco habilidosos en la ejecución de sus tareas, probablemente no hayamos reflexionado lo suficiente sobre el impacto que tiene esto en un proyecto, y el coste final que clientes, nuestra empresa, o nosotros mismos ...
Leer más

Koalite: Sobre velocidad y coste de desarrollo

-
Koalite: Sobre velocidad y coste de desarrollo Koalite: Sobre velocidad y coste de desarrollo blog.koalite.com/2025/12/sobre-velocidad-y-coste-de-desarrollo Al desarrollar software, y más cuando se trata de un producto maduro, es habitual que surja la sensación de que «antes sacábamos cambios rápido y ahora todo va más lento» y, por tanto, se proponga «contratar más gente para volver a ir rápido». Desde fuera puede parecer que el equipo simplemente se ha vuelto menos eficiente. Desde dentro, normalmente lo que está pasando es bastante más mecánico y predecible: A medida que el software crece, su coste mínimo de mantenimiento y evolución sube. A medida que crece el equipo, la capacidad productiva media por persona decrece. Esto, que puede parecer algo exclusivo del mundo del desarrollo, se hace patente en muchas otras áreas. Por ejemplo, en el nivel de vida de una persona. La complejidad tiene un coste Cuando un software es pequeño, t...
Leer más