EDITORIALS

Sharpen the Axe

I started this topic yesterday on keeping your tools sharp. Today I start with a comment from Dilip with some thoughts on this topic.

Dilip writes:

Here, are my thoughts for your upcoming series for Being Efficient:

1. You wrote about sharpening the axe first, i.e. the best tools to be used but what if we don't know

as to what is to be achieved?

2. The first and the foremost thought that comes to my mind whenever a new project is assigned to me is

that of getting AS MUCH CLARITY ABOUT IT AS POSSIBLE.

3. Further, whether it is going to be a Client specific or whether it can really become a PRODUCT with

a potential to sell it to other clients also.

4. A famous German Pharmaceutical Company has a wonderful slogan: We Think of Tomorrow Today.

5. This then helps to identify the best tools and the best skills to be used amongst best developers.

Dilip, this is great input. I always appreciate getting reader input on things like this, because there is often a completely different perspective. Nicely done.

As I was thinking about this series I was looking at some things you can do that are a bit more generic, but just as important, although I agree with Dilip 100%. Here are a few bullet points of things I would start with:

First, establish version control. Select a version control tool. Establish a repository. Even if it builds off an existing tree. Establish branching and versioning methods.

Now that you have version control in place, you could even stub out your build server. At least identify the hardware you are going to use, and the build engine that will perform the builds. Maybe you even need to identify and install software for scheduling or performing the builds if you don’t already have an established mechanism.

If you don’t already have development standards, this would be a good time to establish them. Established standards will help the team to collaborate more efficiently. I prefer to make them as detailed as necessary to optimize collaboration, and as simple as possible to allow uniqueness where appropriate.

These three steps are real axe sharpeners that prepare you to do the work of a project. If you are implementing a canned package these three steps may still be quite relevant; especially if you are integrating with, or customizing the external software. A good example of this would be deploying an instance of the Sugar CRM open source software solution.

Perhaps you have other things you find important for Keeping Your Axe sharp. Leave a comment or send an Email to btaylor@sswug.org.

Your own direction: keeping current as a DBA

Your own direction: keeping current as a DBA
I wanted to reach out to everyone today and see how you're working through the huge directional swings with SQL Server (and databases in general). Yes, there certainly are common grounds, but let's face it, it's not just a database platform choice any more. You get the select from on-premise, cloud, hybrid, the database platform, relational, non-relational...

There are quite the number of choices. How do you choose? I believe it's clear that cloud has to be part of your DBA skillset. You need to understand how databases and services that work against your data, are deployed to the cloud. An important skill right now, because it's so in-demand, is the ability to build hybrid solutions. These are essentially the stepping stone to the cloud - part of your solution in-house, part in the cloud. It's new-enough to be tricky, but it's key enough to be something that's not going away (and will get simpler) going forward.

My thoughts on the whole DBA scene as a complete picture, are that DBA-types (data professionals, data scientists, whatever you'd like to call us all), are more and more important than ever. I say this because the data is flowing so fast, in such volumes and with such importance to our businesses and clients, that it's critical that it be done right. I think some of this is getting lost in the ease that some ad-hoc solutions can be deployed.

I can feel people bristling as I write that. The fact that it can be deployed ad-hoc means it still needs attention, still needs some structure to the access and control of that information. Where we so often get into trouble is when people deploy these solutions to address a quick issue, the solution becomes integrated into the overall information fabric of the company, then no one looks back to see if it's taking into account the things it should. I think this is so important.

These (and more) are critical from the time you start taking in information to the time it's destroyed. The tools that touch it need to be known and understood. The implication of those tools and their use is important too. In the "good ol' days" this was an Access issue. "Oh no, they're deploying a new departmental database... is it at least backed up??" Similar issues abound today. And they take an information and data management role to help make sure they'll continue to deliver.

What say you? What is your approach? Where are you putting your learning and "keeping up" time?