Communication is bad

Is my title a bit harsh?  Yes, probably.  I heard something at work today, something that has bothered me for a very long time and now that I have a place to write my thoughts I realized that there was no need for me to just dismiss it.  How often have you heard “we need to communicate better.”

It is an oft repeated mantra of why the organization fails to live up to its potential.  “If only we knew that in advance we could have reacted.”  Well, no kidding!  If I were omnipotent I could anticipate everything as well.  Communication sucks.  For every person you add to the conversation, the result gets worse and worse.  Take the example of 2 people talking.  Each one can talk to the other so we have 2 paths of communication.  If you add a third person the number of communication paths increases to 6.  Add a fourth person and it increases to 12.  The general formula is N(N-1).  5 people, 20 paths of communication.  10 people, 90 paths.  And it has a nasty growth curve.

I cut it off at 45 people just so you could see a nice curve, but you do the math.  100 people and you have 9,900 possible paths of communication.  How can it be that we reasonably think that even a small sized team is going to talk to each other?  It doesn’t make sense.

Worse yet, consensus isn’t a great thing!  Think large government for a good example.  Compromise doesn’t yield the best results.  In fact, by design it yields sub-optimal results for a given goal in order to provide a benefit to the other party.  In the case of work, compromise usually involves combining everyone’s ideas into a massive heap of garbage because you don’t want to leave anyone’s ideas out.  Worse yet, we replace competent individual thinking with group-think.  Bad business analysts are covered for with JAR sessions; bad designers with JAD and Agile (flame away oh agilistas, I know you want to).

For once I have an answer to my rant.  I believe it lies in interfaces.  Provided that any given programmer is reasonably competent (can produce a small program that does the right thing), interface based design may be the solution.  Forget communication, this is a strictly walled approach to development.  It allows for massive parallelism because it eliminates the need for any individual worker to know what the other is doing.  Rather, we set up a central designer.  S/he is responsible for breaking down the system design into isolated components - let’s call them objects.  S/he creates the interface spec for each component - what inputs it expects and what outputs it will provide in return.  It is this person alone who is responsible for the integration of components.  Within the walls of the work any individual is given, that individual can do as he wishes as long as the interface is faithfully implemented AND no side effects are used to enable communication across the interface.

There are shortcomings to this model.  Off the top of my head, it sub-optimizes.  It may be ideal to take advantage of the work of one object to speed the processing of another, but I’m willing to make this trade-off.  As Steve McConnell said in Code Complete of code optimization, you’d be surprised as to what needs optimization and what doesn’t.  Plus the advent of more powerful and continually cheaper hardware allows us to be somewhat wasteful of this resource.  It is plentiful, after all.

I have no idea if such a model is unique.  I certainly doubt it, but I can’t recall a formal methodology name for it at the moment (like waterfall, spiral or agile).  The idea of a surgical team approach to software development was presented by Fredrick Brooks in The Mythical Man Month and Microsoft’s early years were shaped by the concept of a Master Designer (I’ve read, but can’t recall the source at the moment).  Both of which emphasize the idea that a single individual control the overall design and delegate work out to subordinates.  Fredrick Brooks sees the subordinates as specialists (a tools person, for example) where the Microsoft approach is structurally similar to my (probably unoriginal) proposal but I can’t say explicitly calls out the idea of interfaces as the boundaries of units of work.

This model of development is certainly supported by Service Oriented Architecture, which creates clearly defined boundaries via web services, allowing developers to assemble greater value from smaller components (at the core of Web 2.0) plus encourages reuse (which I could care less about for the purposes of this entry).  So while the architecture of systems seems to be moving this direction, I haven’t seen an example of organizing a team around the same concept - that each individual will produce a smaller piece of stand-alone work that can be integrated by the central designer to build up a complete system.

I think this model comprises some of the best of all worlds.  Waterfall methodologies suffer from a lack of parallelism and rely on heavy intra-team communication to divide and conquer the work.  However, they benefit from the fact that there is no need to keep a business person engaged throughout the entire effort to make decisions.  They can be off doing other activities that are value added and trust (hopefully) that an adequate specification will result in an acceptable system.  On the flip side, Agile relies excessively on communication to make all decisions.  By forcing people into the room side-by-side poor individual decision making is compensated by assuring no individual ever need to think for himself - he can defer to a decision maker.  Of course, the downside is that your decision maker can’t do anything else while they make constant decisions about the project.  And what happens if he goes on vacation?

It is impractical to think that everyone can talk to everyone to compensate for a lack of individual foresight.  Organizations running on this model move sluggishly while they attempt to get the right people in the room just to make a decision.  But a model of development which mimics the hierarchical structure of businesses makes a lot of sense to me.  Rather than a manager being at the top of the structure, it’s a lead developer who drops developers into project roles to build small pieces of functionality with well known interfaces.  Developers gain a great deal of freedom to do as they wish in their space, achieve efficiency by allowing for massive parallelism and independent thought.

So there you have it, a rant with a solution attached.  Again, I make no promises that my idea is original or all that good, but it does seem to deal with the impracticalities of communication issue within a development team.  One can reasonably extend the concept to believe that “throwing it over the wall” might be a reasonable behavior if the acceptable interface (think entry criteria) were well defined.

source: processrants.wordpress