Quiso la casualidad que al día siguiente de publicar un artículo en el blog de SQUaC sobre una propuesta para aplicar un impuesto al software inseguro, empezara a leer este libro:

Y, cómo no, he encontrado cosas en él que se pueden aplicar perfectamente al software.

La propuesta sobre el software sugiere que las empresas productoras de software paguen un impuesto proporcional al número de defectos que éste contenga; en concreto, se refiere a los problemas de seguridad, que suponen un coste importantísimo para los usuarios. De ese modo, se conseguiría que esos desarrolladores tuvieran un incentivo para testear el software que, ahora mismo y a la luz de los problemas que todos sufrimos, parece insuficiente a todas luces.

Pues bien, esa propuesta encaja exactamente con la idea del libro de Tim Harford: aplicar un impuesto sobre los efectos secundarios nocivos de determinados productos (lo que llama "externalidades") es una manera práctica de medir lo que parece imposible de cuantificar. Y tanto el artículo como el libro usan el mismo ejemplo: la lucha contra la contaminación de las industrias.

¿Cómo cuantificar el daño medioambiental que produce una industria? Simplemente, cuesta lo que las empresas estén dispuestas a pagar por permitirles hacerlo. Cuando la EPA (agencia medioambiental de Estados Unidos) subastó licencias para emitir una cantidad de azufre a las empresas energéticas, resultó que estas estaban dispuestas a pagar relativamente poco por ellas, bastante menos de lo que se había previsto. ¿Por qué? Porque descubrieron que reducir esas emisiones les resultaba tan barato que no merecía la pena pagar las licencias; no lo habían hecho antes, simplemente porque no habían tenido necesidad de hacerlo.

¿Por qué no aplicar el mismo principio a los defectos del software? Es posible que aplicando un impuesto por ellos las empresas desarrolladoras empiecen a aplicar técnicas (sobre todo de testeo) que los reduzcan, y es incluso probable que se dieran cuenta de que hacerlo les cuesta bastante menos de lo que pueda parecer; no se hace ahora porque… no hay una motivación para hacerlo. Los usuarios sufren los defectos, y eso les sale casi gratis a los desarrolladores (eso cuando no les supone ganancias por actualizaciones que corrigen unos errores y provocan otros nuevos).

Visibilidad e información asimétrica

Un posible efecto secundario (positivo) de este tipo de medidas sería que los errores del software se harían "visibles". ¿Tienen los clientes alguna idea sobre el número de errores que tienen un software antes de adquirirlo? Muy poca y, desde luego, menos que los vendedores del software. Este tipo de situación es la conocida como "información asimétrica" que tan perjudicial resulta (según dicen los economistas) para el mercado en general.

Igual que al comprar un coche conocemos su nivel de seguridad según una determinada normativa, y se convierte en un factor a la hora de elegir un modelo u otro, ¿por qué no podemos tener una información similar al adquirir un software?

¡Ah, por cierto! El libro está entretenido, aunque supongo que le resultará bastante trivial a los más puestos en economía. Para el resto, su lectura casi puede convencernos de que el sentido común y la economía son compatibles

Guardado en: TECH, errores, testeo de software, economía
Suscripción RSS a los comentarios de la entrada. | URI para TrackBack. | ( 990) | Añadir a: