This editorial was originally published on August 22, 2006.

My son asked me about physics the other day and what it meant. He's been on a bit of a science kick, looking to understand and explain his world. I can understand that because most of us are curious about how things work in our world, not necessarily in a scientific way, but just in general.

I somewhat butchered the definition because I was caught up slightly in the actual concepts, but one of the things we talked about was inertia. Maybe because I'd seen this article on overcoming institutional inertia the same day.

We all have things at work that we do a certain way. Maybe we learned it that way, maybe we're more comfortable, or maybe someone yelled at us daily until we did it that way. Regardless, fighting the way people work is a difficult thing to undertake. The article gives a few examples of process changes and how they were effectively moved forward and how the issues were resolved at a high level. It's common sense if you're wondering, use diplomacy and take your time.

I've seen changes occur from both sides of the fence, from someone trying to implement change and from someone who was told changes were occurring. I was never completely comfortable in either situation mostly because with change there's usually conflict. Someone doesn't want to change.

As DBAs we often try to control our world and ensure a high degree of stability, often at the cost of slowing or severely impeding changes in our systems. While I think it's good to aim for a stable, reliable environment, I don't think this should necessarily impede change.

Understanding the business needs and goals is critical both for DBAs in protecting their systems and developers in building new applications. In either case, it also means that the needs of your organization need to dictate how quickly things change.

Not an employee's personal feelings.