Honeybees and Spiders

What happens if you remove a honeybee from its hive and isolate it? It will die relatively soon, even if food is available. Honeybees are inherently social creatures and cannot live in isolation. But spiders are different. Except for 2 species in the world, spiders are not social creatures. They live alone and normally avoid each other except to mate. What happens if you force 100 spiders together into a "community"? Ah, eventually you end up with just one spider -- a very fat, well-fed spider.

Modeling is an activity for honeybees, not spiders. Modeling is a communal activity. If you try to develop your models by yourself you are doing two disservices. First, you will not benefit from the insight that others will bring to the problem at hand. Second, they will not benefit from your insight.

Because modeling is a communal activity--a group adventure in discovery--I actively listen for the "buzz" of the hive when I am teaching OO, or working with a project group. In a classroom context I can listen to the noise level of the teams developing models and get a sense of how aggressively the students are exploring their models. And I can pretty effectively predict the overall quality of their models. The more buzz there is, the more options are considered, the more interaction there is, and the models are better.

Buzzing teams usually have a single "gold standard" model that one member scribes as the whole team interacts. But when teams do not buzz, I usually find each team member doing his or her own version of the model in isolation. There is little or no interaction, and insight is limited to the brilliance (or absence thereof) of the isolated individual--in other words, spiders.

New college grads have trouble being honeybees. They just re-entered life from 4 or more years of being forced to exhibit individual achievement. If a manager does not recognize that team members are taking on a spider persona, that manager may not take steps to introduce those spiders into a honeybee hive. In software development, cross-species transformation is a good and desirable goal to pursue.

All of this means the social culture of modeling is at odds with the cultures of many organizations. Some organizations isolate project members physically: the tyranny of the "cubicle" is very pervasive. And cubicles are not a bad thing. They offer privacy, isolation from many distractions, a sense of personal space and retreat. But they do not encourage cooperation, interaction, or a sense of community and shared investment. I have had the frustration at several client sites of having the client actively and purposefully resist creating a community space for the project members, a geographically open space where the team see and hear each other and are compelled to interact. The resistance has been manifested in various guises. One client said they would not create an open development area for our project team because it would be "elitist" since no other group had such an environment. That was a particularly cynical response from a Vice-President who shared this view while I was sitting in his elegant, mahogany- and cherry-appointed corner office. Another client resisted removing the partitions between the Hermann-Miller cubicles because it would violate the Facilities Manager's conception of how the office area should be laid out. Somehow, I suspect the Facilities Manager had never developed software, and did not take into his office plan alternate geographies for the cubicles to support the what should have been the strategic goal of this client--software, not meeting an appearance specification. Others have resisted the prospect of establishing space for a hive because they just could not think outside the mental box they had grown up in, and lived in for the past two or three decades.

It is reasonable to ask what kinds of honeybees need to be in this project hive? Lots of different kinds. Just as a hive has a queen, and worker bees, and sentinel bees, so the software development hive must have different constituencies. First, it is valuable to possess a specific sub-species known as the Modeler bees. These are not required for the life of the hive, but if present, they enhance the lifestyle of the hive. These bees have the skill to capture the thinking of the project from multiple perspectives, and to communicate those perspectives in a common notation--usually UML, with additional symbolism as needed. They are also unique in having no constituency of their own, rather they are driven only the needs of the hive. Without Modeler bees you can still complete a project, but you will not have the unifying insight they bring, nor the clarity and economy of expression that can be obtained only with some level of abstract representation of the goals of the project hive: i.e., the project models.

Second, you need the Development bees who are producing the software. They need to have a collaborative process and geography since today's software is just too complex for individual understanding. Truly, we need a "community mind" to fully comprehend the problem to be solved, and the selected design approaches. Most non-Development bees think that all Development bees are alike (nerdy, weird, ...) but there are dramatic differences in this population: programmers, designers, interface specialists, etc.

Third, you need Business bees, who can bring clarity to the problem to be solved, who can explain the business drivers behind the technical implementation, and who will obtain answers for the questions that inevitably arise during a project no matter how much time and effort you expend in gathering and documenting requirements.

Fourth, you need Customer Bees -- or someone who represents the customer and end users. After all, the end users are the ones who will use what you are building and if you don't meet their expectations and goals, then your development has been a failure. And the customer is the one paying for your development, so you better make sure you understand any constraints or expectations the customer may have.

Fifth, you need Quality Assurance Bees and Documentation Bees. They may not be continual residents in your hive, but they need to visit on a regular, planned basis.

All of these Bees must return to the hive regularly. I advocate hive meetings. These are much more than status meetings; these are life-support gatherings. Each group of bees, or representatives of each group, meet every few days (or daily) to take the pulse of the project, to determine if one of the groups needs additional support, or if the life-signs of the project are showing a terminal prognosis. Sometimes the hive is found to be fouled, and it must be cleaned of misunderstandings, animosity, rivalry, or jealousy. Sometimes the bees find that one group needs help and the other bees pro-actively engage their services to assist, knowing that if one group falters or dies, the whole hive is in jeopardy.

Software -- and especially software modeling -- is a communal activity. If your organization is run by spiders directing other spiders, try some genetic engineering. Transform your project from a set of webs and into a dynamic hive. Listen for the buzz: it is the sound of life on your project.