Values are the social principles of the organization, the things people care about. Attitudes are the ways people think about organizational facts. Beliefs are the things you think are true about your organization or about the world it inhabits.
Here are some common values, attitudes, and beliefs in software organizations:
A vision statement
A mission statement
A values statement
It's so hard to get anything done around here during the workday. That's why I come in at 10 PM.
How's the pig doing today? (This in reference to the financial database system you're about to deliver to 10,000 slavering customers.)
That's marketing's job, not ours. (This is in reference to someone requesting a requirements model for a new product.)
The market won't buy anything but software that runs under Microsoft Windows (UNIX, the Mac, whatever).
The market insists on software that runs on any operating system (presumably including RSX- 11M).
My manager wants us all to work weekends.
We succeeded beyond our wildest dreams with this latest system!
We can do better than that [expletive deleted] system you bought!
Reflect on these examples for a moment. What is their common thread? Purpose. Without values, attitudes, and beliefs, the members of your organization must be very uncertain about what they should achieve, much less what they can achieve. Core values of an organization, as represented by vision, mission, values, and objectives statements, are vital in establishing a set of values aligned with the goals of the organization as a whole. Most database people have very strong belief systems, having gone through extensive preparation for their priesthood. This is, of course, a metaphorical stretch; nevertheless, database designers and programmers have a strong set of beliefs that qualifies them for their profession. Some are adherents of the mainstream relational religion, while others belong to smaller cults such as OO databases or dBase worship, an almost extinct religion that pops up every now and again in odd places. Anyone who has ever confronted an Oracle DBA with the need to denormalize a database schema understands the religious nature of these values and beliefs. Moving to design using UML is, to a certain extent, a challenge to these values and beliefs, so I'm trying to make it as easy as possible to say, "It's really the same thing, just a different notation."
Rituals
A ritual is a repeated pattern of social behavior. Related to norms, rituals establish routines that you follow. Sometimes rituals exist to channel behavior that might otherwise violate norms, such as expressing less-than- serious visions of your boss. The formality of the ritual comes from its source (upper management, teams, or other level of authority). Here are some examples of rituals in a software organization:
Christmas parties
Team lunches
Communication meetings
"Open door" meetings
Friday breakfasts
Casual days
Development method processes
Quality assurance system tests
Structured walkthroughs
Dunking the boss on carnival day
In modern American software organizations, you can divide rituals into three types: outlet, purposive, and magical. An outlet ritual is one that serves as a way to blow off steam or to integrate out-of-the-ordinary elements of life into
the organization, such as a party. A purposive ritual is one done for a reason—the reason being empirical in nature, such as a structured walkthrough or a system test. A magical ritual is one that serves a protective or instrumental purpose without the benefit of empirical evidence, such as a management review or communication meeting. Regardless of type, the main point of a ritual is to repeat the behavior, usually in the hope of achieving some goal, whether real or magical.
Database rituals are everywhere. In design, the normalization process is such a ritual. As Chapter 11 discusses in detail, it is very easy to put your database into fifth normal form with a simple, direct design (strongly related to the OO design methods). Because the usual ritual proceeds very differently, however, I've found it difficult to persuade some DBAs to do this. Instead, they insist on going through the stages of normalization (first, second, third, BCNF, fourth, fifth) and arguing Talmudic points the whole way. Pilpul aside, normalization is a ritual, and often not a particularly useful one. Nevertheless, it's one you have to deal with in large organizations.
Another ritual is optimization. As they gain experience (go through ritual torture), DBAs and database designers create small rituals that exist to propitiate the database performance gods. Creating a bitmap index here, enabling dirty reads there, using unique column names even though SQL scopes names to the table, not to the database, and so on—these are all rituals with the purpose of developing shields against "doing it wrong." Usually, there is little or no empirical evidence for the value of these. Sometimes, the DBA will go so far as to say that it is just the "right thing to do" and leave it at that. As your organization moves from a ritualistic, magical culture into a feedback culture, you see measurement start to appear. As an anthropological observer, you can distinguish these cultures by their actions: Do DBAs benchmark their databases and change them based on the results? Or do they simply assert that using VARCHAR is slower than CHAR and you shouldn't do it? Magic rituals work as long as you don't have the time to tie your system to empirical reality, but eventually the problems and scope of the database expand beyond this kind of ritual.
There are useful rituals too, of course. As you experience, you learn; as you learn, you ritualize. You begin to understand how to install Oracle reliably through a sequence of very specific steps repeated many times, hopefully not all on the same weekend. You learn that translating a data model consistently into a schema requires specific transformations in a certain sequence. You learn that using single-attribute surrogate keys is often preferable to using multiattribute primary keys, so you ritualize the design in a pattern that you apply to most tables. As you gain experience, you sediment and abbreviate the rituals into processes or actions that become second nature—until someone challenges them and you must expand them again. As you ritualize, you create folklore to support your rituals, and it's that folklore that emerges on demand when you get a challenge to your rituals.
Folklore
Folklore is a set of symbols and stories about the organization. Folklore often transmits organizational or personal values and norms as part of the socialization structure of the organization. One major purpose is to show status. Another is to show achievement. Yet another is to represent some value the organization holds in high regard. Here are some symbols and stories common in software organizations:
The product T-shirt or coffee mug
Stories about the early days of the company
Stories about other parts of the organization (sometimes known as "rumors")
War stories about past projects at the company and elsewhere that caution against something
Fables that promote some behavior as good
Slogans and mottoes ("Sooner is better than later.")
Meeting minutes
Functional specs (a special kind of fable, with or without the implication of being imaginary)
Team award trophies
Project wall charts
Window offices
Corner window offices
Folklore is all about transmitting other aspects of culture. Without folklore, you have no way to communicate the culture without depending on dry, academic descriptions of the anthropology of the organization (such as this section).
Database work is full of folklore, both good and bad. Anyone who has worked in databases more than a year has war stories about Oracle, Informix, Sybase, or whatever system they've used. Most designers have a repertoire of analysis patterns (see Chapter 8) with accompanying stories about how the patterns worked in practice on various jobs. Most people have their DBMS vendor coffee mugs prominently displayed, or T-shirts from the last users' conference. Some of us have even worked at DBMS companies and thus have a good range of war stories and fables to explain some of the quirks of the products we worked with or built.
Most people don't realize, for example, that PL/SQL (Oracle's built-in programming language) comes from Ada, the 1980s' military software engineer's choice. The architect of PL/SQL was an Ada guru hired into Oracle to manage
development projects and grew into the role of language guru for the company. The Ada story tells people why certain things are there (packages, for example, with overloaded procedures, and exceptions), putting the language in a broader context than just a database programming one. Folklore contributes in a big way to shared language by providing common symbols and stories using that language.