Yesterday, in an email exchange with a fellow DBA I used the term “they’re trying to make an omelet without breaking any eggs” and this got me thinking.

Several years ago I was working with a client that was moving their development process to an agile process. Or more accurately, that was their goal. They started off fairly well, we had daily stand-up meetings where folks actually stood up and the entire thing was kept short.

But things started to change. Our user stories started to get more complex. The cycle between when we’d receive our story and deploy it grew longer and longer. Pretty soon we were talking about going back to an annual release, and only an annual release.

I started to call this agile-waterfall. It was clear they were simply falling back on their old habits and that their agile goal simply wasn’t going to happen.

More recently, I’ve had another client I’ve been working with to make some security changes to their databases. This is generally a good goal. But, it means some radical changes in a few of their processes. Meanwhile another manager in the company is pushing back on all the many of the changes because some would be disruptive to their current processes and arguably break how certain things are done. And breaking such things would have an immediate financial impact.

Now, I like a good hard-boiled egg. In fact I had one this weekend.

I also like a good omelet. Maybe I’ll make one this coming weekend.

Neither is necessarily better than the other. But you can’t make them the same way. You can’t really make an omelet out of a hard-boiled egg, and you can’t really hard-boil an omelet.

If you really want a omelet, you’re going to have to break a few eggs.

Just make sure you understand up front if you’re breaking an egg or not, because once broken, you’re pretty much committed that omelet.

And sometimes it’s necessary to make that omelet. Change can be necessary and good.