In arm chairs across American universities, philosophers are pontificating on the merits of a relatively new theory in political philosophy: deliberative democracy. The theory can most easily be explained from two angles.
The bottom up view goes something like this: if a democratic institution is to be successful, meaning, roughly, that it maximizes the collective good of its citizens while protecting their basic, natural rights, then the citizens themselves must be informed to some elemental level
There's also a top-down view. In a democracy, the authority granted to government officials is derived from the will of the people – i.e. they work for us and not the other way around. As a result, they have an obligation to openly explain and justify their decisions to us, so that we may decide whether they are in fact serving what we deem to be our best interests. If, for example, a president decides to invade Canada, but keeps the reasons for invasion a secret from the people, then the president is violating his responsibility to the people - even if invading Canada is actually in their best interests. Essentially, deliberative democrats believe that the reasons are just as important as the act itself. In some cases, these reasons should be given prior to the act itself, allowing for a public deliberation of the issues, and possibly preventing an ill-advised policy (like invading Canada!). If expedience is needed, however, then public deliberation can wait – but not forever. At some point the representatives must pay the piper and publicly explain their decision the people who elected them, so those same people can decide whether they should represent them again.
Introducing Deliberative Development
Ok, so what in the world does deliberative democracy have to do with software development?
Software organizations, you will say, are completely different than democratic nations. First off, they're voluntary associations – unlike citizenship, you can quit if you don't like what you see. Second, a software organization's goal isn't to maximize utility for their employees or to protect anyone's basic liberties (though this could be a periphery motive), it's to make lots and lots of money (specifically, in this case, via the creation of quality software). Third, executives and managers aren't elected by their underlings (us!), so, debatably, the same moral obligations that exist between citizen and government official are probably nill. And last and perhaps most important, software organizations demand speed and agility in their decision making – months of democratic dialogue won't cut the mustard when change needs to happen now.
Despite all these differences, however, I still think that deliberation could (and does) work for software organizations for the some of the same reasons it works for democracies.
To be clear though, I'm not proposing this as some new, heavy-weight, sliver-bullet methodology that'll answer all your programming prayers and give you eternal salvation to boot. I'm simply saying that as a guiding principle of our software development processes, it could be helpful – in the same way that the principles of "simplicity" or "feedback" help drive XP's practices.
I'm also not saying that we should abandon our laptops and talk the day away. Deliberation needs to be used wisely.
Given these caveats, let me first explain why deliberation works for software organizations, then how it could work.
Why Deliberative Development?
First, deliberation leads to better decisions. The software we build affects many stakeholders, and as smart as any one developer is, no one can see each person's point of view. Without some open discussion, developers miss things that should influence the decision - options, costs, risks, or perspectives that need to be considered. For example, developers are notorious for building user interfaces without consulting the users
Second, deliberation tends to yield greater acceptance, even if it doesn't produce agreement. People by nature are more motivated if they feel their input is considered than if they feel decisions are forced down their collective throats. If, for example, an architect unexpectedly chooses to undergo a major UI migration from JSP to Flex without consulting the developers who write the code, even if moving to Flex is the "right" decision, the developers probably aren't going to respond well. "WTF! Flex'll never work. Gripe, complain, this sucks, yada, yada, yada".
Deliberation also leads to a greater flow of information through an organization, which results in more consistency in development practices and less redundancy in efforts. When you and your fellow developers sit in cubicles all day with head-phones on and never talk, you have no idea that Joe created a utility class that does exactly what you need and are about to write on your own.
Lastly, deliberation forces accountability. Developers and architects stand their ground for a decision, give reasons why they think they're right, and defend their point of view from the detractors (you!). They say publicly "I'm solving this problem, in this way, for this reason". And when the future plays out and the solution is a success, we can credit them for their wisdom and learn from their reasoning.
How does Deliberative Development Work?
Some organizations already tacitly embrace deliberation in the form of design reviews, code reviews, usability studies, and brainstorming sessions. These organizations know that deliberation is valuable, even if the benefits are difficult to quantify. Encouraging open discussions amongst stakeholders, they understand, makes their products more maintainable, usable, extensible, and of better quality, and makes their people happier and more invested in the success of the company.
Obviously, all deliberation isn't good, however. When ill-managed, deliberation can suck time and breed contention and indecision. This goes without saying of course – you don't need me to tell you that pointless, rambling meetings are a waste of time.
The question then is, how can we make deliberation effective?
Philosophers (as philosophers do) have thought pretty deeply through this issue, and so it's here where I think software organizations could take a few plays from the deliberative democracy handbook. Here are a few helpful insights:
Deliberation must have a definite goal: to come to a conclusion about some significant decision (e.g. "we choose option A over B because it will be more maintainable and extensible, though less scalable"). Deliberation that is too open tends not to be effective. For example, in an open-ended design review, everyone wants to share some different opinion about some different part of the design, and the result is a mish-mash of random advice – i.e. design by committee. Good deliberation is different. In the case of a design review, some specific, important decision within the design should be of central focus, and the designer seeks input from others to illuminate all the available options and their relevant pros and cons.
There also must be some mechanism for making the decision. In deliberative democracy that mechanism is obviously voting, but for a software organization, most likely the final decision rests with one person. This is fine. Deliberation development doesn't mean we all decide together, it means we all have a chance to voice our points of view so that the decision maker can better understand all angles of the decision.
Good deliberation requires a relatively diverse cross-section of opinions. If different points of view aren't solicited, then really deliberation isn't much more effective than a decision in isolation. Obviously, this comes with the caveat that the opinion must be relevant. Getting your accountant's opinion on your SQL query probably isn't going to add much value, but if you're designing a user interface for a general audience, then her thoughts might be useful.
Lastly, the deliberation must not be dominated by just one or two people – each person should have some opportunity to voice their opinion. Deliberation does not mean presentation or soap box. Again, the purpose of the discussion is to explore all angles of the decision, so the more opinions the better.
Conclusion
I realize this is all a bit of a stretch. Your BS-detector may be flickering red when you read this – and in truth, mine was too a bit when I was writing it. In the end, though, I still think there's a morsel of merit here. Building software, I really believe, is all about making good decisions, and making good decisions means understanding trade-offs, seeing risks, and considering different scenarios. To do these things well requires vision; vision that's not always accessible to us in isolation, but requires us to talk with others and think about the things they see that we don't.
Let me what know you think! Does open communication lead to better decisions? Are there times when deliberation doesn't make sense?
Resources
When I started my philosophy program a few years back, I did a little research in deliberative democracy with Dr. Robert Cavalier. Dr. Cavalier is a big proponent of James Fishkin's deliberative polling technique, and is actively developing technologies to support deliberation in an online medium. Very cool stuff. Here are a few good booksthat got me started:
- The Paradox of Mass Politics
- The Voice of the People
- Why Deliberative Democracy
- Debating Deliberative Democracy
