It was not long ago that the hats that people wore at work signified their roles in society. Two people wearing similar clothes with two styles of hats might have vastly different jobs in the business hierarchy. It is still the case with firemen, the police and the military that you can discern much about a person’s role by their head covering. Of course, in today’s world, most computer programmers won’t be required either by our vocation, social convention, or exposure to the fusion reactor in the sky to wear a physical hat, but we do often wear many metaphorical hats as we work through the many tasks that are required for managing the data assets of an organization.

Depending on the size of organization you work for, in any typical day, you might wear many metaphorical hats. You might, for example, gather (or a least verify) requirements, design a solution, write the code to solve a problem given in requirements, and finally test the solution. Each of the steps is definitely linked by a common theme, but each of these requires a different mindset to complete without affecting (or cheating) the quality of the next. To do the very best job, one needs to compartmentalize, or put on a different metaphorical hat in order to not poison the work being done in any steps. Of course, if it helps to actually wear different hats to better compartmentalize, feel free but don’t share that information on a first date.

When you are working with requirements, the primary goal is to understand what the customer needs. Customers almost invariably have no need for software per se, but have a business requirement that, lucky for you and I, can usually be met more optimally with software than with pen and ink. Even if you work with a software company, requirements will usually be more optimally stated in a non-technical manner. “We need the query processor to go faster when dealing with situation x, because it fails in y manner.” Not: “line 330098 of queryoptimizer.c is slow, make it faster” Anything involving a query optimizer is at its core a very technical problem, way beyond the skills of this humble writer, but I can easily fathom the problems of a query processor that is not dealing with a situation correctly (and have come upon that very situation more than a few times in the past 20 years). If you accidentally wear your coding hat to the requirements session, the actual problem may not be understood well enough because you will already be trying to code the solution before you even have comprehended the problem.

Once you understand the problem, it is time to work out how to solve it by producing a design. During design, the goals shift and you must focus on the solution to the problem. The task of designing software varies greatly from discipline to discipline, but the focus is on determining how the software is to be built. For relational databases, our typical design goal is to provide a data model that follows the patterns of normalization. By following this pattern, we provide a design that not only provides a good chance that the programmers will be able to meet the requirements with data integrity, but which can also be tuned for many typical OLTP usage patterns. A great mistake is to attempt to tune the solution before code has even been written (denormalization is prefixed with de- and not un- for a reason).

A great design covers what needs to be built using known patterns and algorithms, without trying to tune the forthcoming code before it is written. Even if the problem is strictly performance-related, very often the solution will start with thinking about how best to solve the issue. And much to the chagrin of your coder hat, that may mean recoding the overall solution to fix the problem. The hat changing process continues throughout coding, system testing, and even into the support phase. Generally speaking, the fewer hats worn simultaneously, the less likely it is that one role cheats and starts guessing what will make the other role happy (and by that I really mean complacent).

The hat metaphor isn’t perfect of course, and we often find ourselves questioning the design as we code, or fixing requirements even as we test. It is at this point it turns out to be the most important to respect the role. Many times as I am working on code, I realize that something in the design or requirements is just bugging the heck out of me. About this time, a little pitchfork wielding dude on my shoulder starts reminding me that it is going to take many hours to correct the problem effectively, just use a dirty hack and get done. He may sometimes be right, but more often it is far better to bite the bullet, stop, fix the requirements, adjust the design, and fix the code. It means that my coder hat is probably going to be worn more than my night cap, but in the end, the product is that much better and will reduce the amount of time I wear my support hat when I would rather be wearing my Mickey Mouse ear hat.

* If you want to know more about the history of hats, two things are true. First, this link will lead you to an interesting article on the social meaning of hats and t-shirts. Second, sharing that you have an interest in the social meaning of hats and t-shirts is going to impress far fewer people than you might initially expect.