Saltar al contenido

Las líneas de código es una métrica sin valor. Excepto cuando no lo es.

Probablemente no quieras que tu equipo sea pagado en base a líneas de código. Pero escribir mucho código también es una buena idea.

Por qué odiamos medir las líneas de código

Le preguntamos a un montón de gente por qué odian tanto la idea de medir líneas de código. Dado que estamos algo obsesionados con la cuantificación del trabajo de ingeniería, esto parecía una pregunta importante a responder.

Las líneas de código es una métrica sin valor. Excepto cuando no lo es.
Las líneas de código es una métrica sin valor. Excepto cuando no lo es.

Los resultados aquí variaron bastante, con la gente diciendo “porque la gente simplemente escribirá mucho código terrible” o “es una métrica muy fácil de jugar”.

Todo esto es cierto, por supuesto. Pero acechando bajo la superficie entre todos los sentimientos había un hilo conductor: No nos gusta medir las líneas de código porque es ofensivo.

Los ingenieros en computación son personas salvajemente brillantes, y sin embargo esta brillantez es constantemente mal entendida y la naturaleza específica de esa brillantez no es comúnmente reconocida por el “mundo civil” (no desarrolladores). Los ingenieros son raros. Esto es quizás lo más hilarantemente ilustrado por los propios ingenieros, que hemos oído describir interacciones como esta mientras heroicamente arreglan bichos los fines de semana:

“Querida, deja de jugar con tu ordenador.”

“MOM I$0027M A PROFESSIONAL ENGINEER FOR GOD$0027S SAKE”

Estas son grandes anécdotas, y muestran lo generalmente reduccionistas que son los no desarrolladores sobre el trabajo de ingeniería de software. Hay mucha sutileza en ser un gran ingeniero, y esto no puede reducirse a una sola métrica sin contexto. Hacerlo despoja de todo el arte y es… bueno, es una falta de respeto.

No se paga a un Miguel Ángel para que haga pinceladas, se le paga para que sea un genio.

Una de las mejores metáforas para describir esto es comparándolo con otras artes sutiles. Miguel Ángel, siendo el artista fantástico que era, fue pagado generosamente por su trabajo, pero nunca se le pagó por la pincelada. Eso es porque no se le paga a un Miguel Ángel para que haga pinceladas – se le paga para que sea un genio.

La ingeniería de software es esencialmente el mismo arreglo.

Cuando los golpes de pincel importan

Esto no quiere decir que las pinceladas no le importen a un pintor – todos los grandes artistas son por naturaleza prolíficos. Cada uno tiene miles de bocetos, borradores, versiones y cuadernos. Pintan, dibujan y hacen bocetos porque por encima de todo les gusta crear y una gran cantidad de trabajo es el resultado natural de toda una vida de creatividad.

Lo mismo ocurre con los programadores: a todos los grandes codificadores les encanta crear, y mucho código es un resultado natural de ese amor. Así que es razonable aceptar que todos los grandes codificadores producen mucho código, incluso si no todos los voluminosos resultados fluyen de los grandes codificadores.

Si aplicamos un poco de teoría de conjuntos, a partir de esta verdad básica también podemos concluir lógicamente que los codificadores que no producen mucho código están por definición excluidos del conjunto de los grandes codificadores.

Esto está quizás mejor ilustrado por la siguiente anécdota del libro “Arte y Miedo”: 1

El profesor de cerámica anunció el día de la inauguración que dividiría la clase en dos grupos. Todos los que estaban a la izquierda del estudio, dijo, se calificarían sólo por la cantidad de trabajo que producían, todos los de la derecha sólo por su calidad. El último día de clase traía su balanza de baño y pesaba el trabajo del grupo de “cantidad”: cincuenta libras de macetas calificadas como “A”, cuarenta libras como “B”, y así sucesivamente. Los que se calificaban en “calidad”, sin embargo, sólo necesitaban producir una olla – aunque perfecta – para obtener una “A”.

tiempo de clasificación surgió un hecho curioso: las obras de mayor calidad fueron todas producidas por el grupo que se clasificó por cantidad. Parece ser que mientras el grupo de “cantidad” estaba ocupado haciendo montones de trabajos y aprendiendo de sus errores, el grupo de “calidad” se había sentado a teorizar sobre la perfección, y al final no tenía más que mostrar por sus esfuerzos que teorías grandiosas y un montón de arcilla muerta.

2

La experiencia viene de la práctica, y cuando se trata de la práctica, el volumen puro es muy importante. Si creemos que la ingeniería de software cae dentro de la clase de vocaciones “artísticas”, entonces debemos asumir que también se rige por las mismas máximas artísticas.

Los codificadores que no producen mucho código están por definición excluidos del conjunto de los grandes codificadores.

Entonces, ¿cómo se relaciona esto con las líneas de código?

La RdC como un proxy para el conocimiento del dominio

Cuando aprendes un nuevo lenguaje de programación, gran parte del conocimiento de otros lenguajes es transferible. Pero aún así, hay matices y sutilezas únicas en cada lenguaje de programación que requieren cierta práctica para dominarlos realmente.

Este mismo concepto se aplica cuando se une a un nuevo proyecto. Cada nuevo proyecto requiere un período de formación sobre patrones desconocidos, diferentes normas de codificación, convenciones de nomenclatura, etc.

Es bastante fácil imaginar que las líneas de código aportadas a un proyecto particular, o escritas en un lenguaje de programación particular, serían un sustituto razonable del conocimiento específico del dominio asociado a ese campo.

Al igual que el ejemplo anterior en el que “tirar muchas ollas” hace a los alfareros experimentados, escribir mucho código tiene la tendencia de hacer a los programadores experimentados. Como cualquier otra profesión, la verdadera experiencia se obtiene en el campo no de un libro. Para los ingenieros de software, escribir código es el campo.

Esta es una idea importante si buscas ser un programador: escribir mucho código es probablemente bueno para ti.

Sin embargo, esto no significa que sea algo que se pueda utilizar para incentivar a los programadores, o que los forasteros puedan utilizar para juzgar el trabajo de desarrollo. Aquí vemos el verdadero problema: los datos matizados requieren un intérprete matizado.

Por ejemplo, aunque es casi seguro que más código hace a un mejor programador, para la mayoría de los casos de programación, lo contrario es cierto: ser económico en cuanto a la cantidad de código utilizado para abordar cualquier problema también es bueno.

Los datos sólo son peligrosos en manos de idiotas

Cualquier veneno que se encuentra en las líneas de medición del código no proviene de la información en sí, sino del actor que la utiliza.

Consideremos de nuevo la historia del profesor de cerámica. Incluso en ese ejemplo, que está explícitamente a favor del volumen, la medida de la calidad es externa: no dice “hacer más cosas es inherentemente bueno”. En su lugar, la lección es que “hacer muchas ollas es una buena manera de aprender a hacer ollas de calidad”.

El trabajo de los estudiantes – y el resultado del experimento en sí – fueron evaluados por los ojos de un experto experimentado. Y así debería ser para un equipo de ingeniería saludable: el trabajo de ingeniería siempre debe ser evaluado por un jefe de equipo que sepa lo que está mirando.

Es un hecho desafortunado que esto no es ampliamente aceptado en lo que respecta al desarrollo de software. Varios métodos populares de gestión de los trabajos de ingeniería suponen implícitamente que todo el trabajo de desarrollo de programas informáticos puede ser gestionado de manera puramente procedimental por un administrador relativamente ingenuo. Esto significa que no es una experiencia poco común que quienes dirigen a los desarrolladores no son, ellos mismos, programadores experimentados. Es este hecho – no la preocupación por que se les pida que escriban mucho código – lo que desencadena un sentimiento de desesperación cada vez que el jefe de pelo puntiagudo sugiere medir las líneas de código.

La preocupación por las líneas de código (u otras métricas “duras”) no es en realidad una preocupación por los datos o por una mayor visibilidad, es un signo más amplio de que la retroalimentación que reciben los desarrolladores es de baja calidad, y con demasiada frecuencia proviene de personas ajenas que no entienden realmente los matices de la ingeniería de software.

Pero tenga en cuenta que la solución a este problema no es desterrar ciertos tipos de datos del debate. En su lugar, tenemos que ser mejores en la selección de las personas que diseñan las condiciones de éxito de los equipos de software, y que dan retroalimentación sobre el trabajo de los desarrolladores.

Estas personas, tanto en la ingeniería como en otras disciplinas, deberían ser siempre verdaderos maestros del oficio practicado por los equipos que dirigen.

Notas:

David Bayles, Art & Fear: Observations On the Perils (and Rewards) of Artmaking (2001) ?

Foto: Dan Finnegan, ¿Una semana de 100 tazas?