Strong opinions, weakly held

The pros and cons of transparency

Larry Lessig writes about transparency in The New Republic. Here’s his argument:

How could anyone be against transparency? Its virtues and its utilities seem so crushingly obvious. But I have increasingly come to worry that there is an error at the core of this unquestioned goodness. We are not thinking critically enough about where and when transparency works, and where and when it may lead to confusion, or to worse. And I fear that the inevitable success of this movement–if pursued alone, without any sensitivity to the full complexity of the idea of perfect openness–will inspire not reform, but disgust. The “naked transparency movement,” as I will call it here, is not going to inspire change. It will simply push any faith in our political system over the cliff.

His argument is lengthy and nuanced, but what it comes down to is that all the transparency in the world doesn’t change the fact that people draw spurious conclusions because people don’t pay enough attention to fully understand the information they’re given (for perfectly rational reasons). There’s another version of this argument in Malcolm Gladwell’s article on Enron from 2007, OpenSecrets.

I’ve seen something similar in my own work running software projects. I’m a fan of transparency, and I generally try to set things up so that anybody can figure out how the project is going. I set up a bug tracking system, version control, and notifications that are sent out when code is checked in. My theory used to be that if I did those things, there’d be less need for meetings, email, and other hand-produced communication. Non-programmers could track the progress of the project through the tools I provided, and everybody would be happy.

Unfortunately, that has never turned out to be the case. Even if you give people access to the code repository and the bug tracking system, they still don’t have the needed context to make any sense of what they’re provided with, and even if they did, trying to keep up is a lot of work. It’s easier to just ask a developer for a short summary of what’s going on. I still think that the transparency is helpful, but it doesn’t provide the benefits I originally envisioned. And sometimes it’s painful because people look at a few data points and draw incorrect conclusions that require even more effort to deal with.

As someone who strongly and often uncritically favors transparency, I found Lessig’s article an interesting and provocative read. Check it out.


  1. In my last job, we were developing some products that would pull together data from systems such as defect management, source control, requirements management, test management, process it and present it in such a way that upper management can get a good, quick idea of the status of their IT projects. At the highest level, this would result in a dashboard listing each project with a green, yellow or red icon next to it. The consumer of this dashboard could then ‘drill down’ into the data that informs the dashboard to get more details.

    My opinion was that abstracting this complex data to that level of simplicity reduced it to the point of being nearly meaningless, and furthermore–pertinent to your post–that high-level managers (e.g., CIO) have no interest in taking the time to do this analysis, or if they do, they don’t draw the correct conclusions.

  2. Lessig seems to be arguing that with transparency comes some good and some bad. We ought to be aware of the bad. Well, duh. But just like with the printing press and the internet, the good outweighs the bad. We will just have to adapt.

Leave a Reply

Your email address will not be published.


© 2016 rc3.org

Theme by Anders NorenUp ↑