Matemáticas de los costes de la programación

Leo en esta bitácora de Peter Hallam un muy interesante ensayo, “Y entonces, ¿qué hacen los programadores”, —a su vez, segunda parte de otro gran ensayo, La vara de medir— sobre la distribución de tiempo que pasa un programador haciendo tres actividades principales: crear nuevo código, modificar código antiguo, y entender todo un código ya existente.

La respuesta, promediando lo que él dedicaba en 1988 programando en dBASE III, y en 2006 programando en C++ (las respuestas no son tan diferentes), sería:

*  4% – Crear código nuevo
* 23% – Modificar código antiguo
* 73% – Entender código

De donde se obtiene la conclusión de que, al ser 15 veces más importante el entender el código que crear código nuevo, y tener tan poca importancia relativa la creación de código nuevo, herramientas como la compleción automática de sentencias, y otras herramientas similares, que ayudan a crear código, en realidad apenas ayudan a la productividad, y que si se eliminaran esas características, y en su lugar se facilitara el entender el nuevo código —o se disminuyera la cantidad de código que hay que escribir— sí que se produciría un auténtico incremento de productividad.

En sus propias palabras:

Está claro que deberíamos centrar nuestros esfuerzos [a la hora de mejorar Visual Studio] en hacer más fácil el que los usuarios entiendan el código, pero la conclusión, de hecho, es mucho más fuerte. Si pudiésemos reducir la cantidad de tiempo necesaria para entender código en un simple 10%, eso le ahorraría más tiempo al usuario que una reducción del 100% en el tiempo dedicado a escribir código nuevo. Pensad por un momento en lo que eso quiere decir. Si inviertiésemos toneladas de trabajo en mejorar Intellisense, los diseñadores gráficos, y los asistentes fuesen tan buenos que escribir código nuevo no llevase nada de tiempo. Cero. Un interfaz de percepción extrasensorial… Aún así, eso tendría menos impacto que una reducción del 10% en el tiempo dedicado por los programadores en entender el código con el que trabajan. La otra conclusión que se saca de lo anterior es que cualquier característica nueva que dificulte al desarrollador la fase primordial de entender código es casi seguro que producirá una pérdida neta de productividad. De hecho, iré un paso más allá, y diré que recortar características existentes que dificultan la capacidad del usuario de entender el código dará como resultado programadores más productivos.

En cierto modo, esto se puede traducir en que las características que convierten al programador en robot que no entiende su código —como Intellisense, por ejemplo, para tardar menos en escribir llamadas a funciones o datos—, y que se perciben por la mayoría de programadores como la auténtica medida de lo que aporta en productividad un entorno de desarrollo, son las mismas que dificultan el entendimiento del código, al centrarse exclusivamente en facilitar la escritura.

De otra parte, Cocoa, que tienen APIs relativamente sencillas y potentes —imaginemos Cocoa Bindings, Core Image, Core Data, WebKit, etcétera—, y una forma sencilla de separar los comportamientos entre objetos y delegar entre ellos, hacen que sea más sencillo entender el código —aparte de tener que escribir menos—, aumentando la productividad neta, incluso aunque se use un entorno que no aporta tanta sencillez a la escritura, pero sí al entendimiento del código, como Xcode.

ps. Por cierto, “Peter Hallam comenzó a programar en BASIC con un Apple II”:http://blogs.msdn.com/peterhal/archive/2004/04/21/117771.aspx 😉