The Deceptive Complex Problem

| |
| Complex Communcation arises

when everyone "communcaties" with

everyone else all the time. |

A while back, I wrote about the "really big" problem that companies faced and how they were looking to tools like SharePoint 2010 to aid them in solving it. In my post I made reference to an article in Inc. Magazine, written by Joel Spolsky, CEO and founder of Fog Creek Software. The title of the article is A Little Less Conversation and by way of a brief overview, the article explains that when you are working in a group on any given problem its best if the group can be small, and if it can NOT be small then try to keep “control” over the communication channel.

As I’ve pondered on the “really big” problem, a.k.a. Communication within a group, I’ve come to appreciate another perspective brought out in this article, which is that everyone needs to respect other people’s expertise in a specific problem area when working at a large company. As noted in the article, at large companies people tend to be highly specialized, meaning that they focus on a specific domain area, such as Databases, Server Administration, Networking, Security, etc.; however, what I’ve come to appreciate about approach is that it creates a deceptive complex problem in the communication front. Or to put it another way, it creates a “hidden” problem. The reason I say hidden or deceptive complexity is that with all the specialized people it would seem like you don’t need all the team members to really have a complete picture, or do you?

Often people will seem to think that each team member has to focus on their little section of the puzzle and doesn’t need to concern themselves with the whole picture. I don’t mean to say that you don’t want everyone to have access to the full requirements or write-up of what the problem is; however, when you create this segmentation of responsibility it can result in a culture where everyone is “only” responsible for a small section of the puzzle and thus no one is really responsible for the entire puzzle.

So how can you address this deceptive complex problem? As is the case with most problems it would seem communication is the key. When projects begin it is typical to bring in the team to identify what is being done and who will tackle each section; however, it would be unwise to think that a weekly “team” meeting with EVERYONE should be held and the reasons are noted in the article in Inc. Magazine in terms of communication cost. Instead, it would be best to identify where the sections connect and then “encourage” those smaller groups to collaborate on the resolution.

At this point if you’ve worked on software development projects before you might begin to visualize an intersecting web of parts, databases, application servers, web servers, end users, etc. and then the people responsible for the pieces and how they interact and you would perhaps draw the same conclusion that I have which is that as a developer you are the center piece which will require all those pieces to come together. So am I suggesting that a developer should play a key role in ensuring that the communication within a team happens in a meaningful manner? YES.

As developers we should concern ourselves with every piece of the overall solution. Why you may ask, well what does the code we write impact… EVERYTHING. Another way to express this thought, is to ask what is needed for an application to work? At least a single server and CODE (technically you need users otherwise why are you doing what you are doing, but that’s a topic for another post). You would probably like more than 1 server, and it would be nice to separate out concerns like security and networking to others that focus on these areas, but as a developer all the pieces come together around what you are working on, and if you don’t think that you’ll need to communicate effectively to accomplish the evergreen goal of ever developer to “ship the code”, then please connect me so I can steer clear of your projects because I’m fairly certain that you’ve succumbed to the deceptive complex problem.