John y Jim son desarrolladores de software que pasaron del proyecto X dejando un gran código heredado a Bob y Bill. Bob se pone al día con el código de John con bastante rapidez. En una semana o dos, ya está implementando nuevas funciones además del código de John. Bill, sin embargo, lucha por hacerse cargo del código de Jim. Después de un mes, todavía no se siente cómodo al tocarlo y cuando lo hace, sus actualizaciones están llenas de regresiones.
Entonces, ¿quién fue el mejor desarrollador? John o Jim?
La falacia común de la administración es pensar que Jim era el prodigio de la programación, ya que es muy difícil de reemplazar. Ningún desarrollador que haya pisado la tierra puede continuar donde Jim lo dejó. Es lógico concluir que, dado que Jim es difícil de reemplazar, simplemente no hay nadie que coincida con sus habilidades. Nadie hasta el nivel donde estaba Jim.
- ¿Cuál es la diferencia entre ingeniería mecánica y física de ingeniería?
- ¿Son los procesos de soldadura de soldadura por puntos y soldadura de estado sólido?
- A diferencia de la transmisión por computadora, ¿por qué la ingeniería civil no aumenta a esa velocidad?
- ¿Qué es lo que los profesores de matemáticas no te dicen y que sería útil mientras estudias ingeniería civil?
- ¿Cómo pueden los niños aprender sobre ingeniería de hardware que puede ser práctica en el mundo real?
En cuanto a John. Venga. Tengo un interno que retomó donde lo dejó. ¿Por qué le pagamos esa fortuna cada mes nuevamente si un interno puede reemplazarlo?
La verdad es que los buenos programadores tienen una claridad de pensamiento y producen un código que es limpio, fácil de entender y predecible para construir. Mientras tanto, los programadores mediocres piensan espaguetis, producen espaguetis. Asumir el código de un programador extremadamente bueno es, en un orden de magnitud, más fácil que asumir las lamentables sobras de un desarrollador pobre.
Como regla general, la estimación del peor de los casos para hacerse cargo del código es casi al mismo tiempo que le llevaría al nuevo desarrollador producir la misma funcionalidad desde cero . Esto también es bastante frecuente: el nuevo desarrollador comienza a reescribir y refactorizar el código hasta que sea suyo. La mejor estimación del caso es de aproximadamente una semana . Para que un buen desarrollador comience a producir sobre el legado de otro buen desarrollador, aproximadamente una semana de presentación será suficiente. Él sabrá en qué nuevas características o correcciones son de bajo riesgo para comenzar a trabajar mientras aún aprende la profundidad del código. Aprenderá por mucho tiempo. Pero mientras tanto ya estará produciendo código útil.
La realidad estará en algún punto intermedio.