technical debtKids, it’s 2020. That it means it way past the time to kick the can down the road. Most of us in IT have been around long enough to see us shift from a centralized CPU (mainframes) to decentralized (client/server) architectures back to a centralized approach again (cloud). That means we have encountered problems and we have ignored problems, and those ignored problems have a name. It’s called Technical Debt, and the check is coming due.

Technical Debt

We all have it, and it tends to bite us right in the ass. It causes us to make compromises and other less than stellar decisions about how to handle it. What we need to do is start addressing the debt, figure out ways to minimize the impact of the debt. Stop covering it up with more hardware, crazy monitoring schemes, and automated fixes that just treat the symptoms and ignore the problems.

Just start working on it already. You’ve known about this debt for years/decades and it’s not getting worked on. Stop ignoring and start spending some time refactoring. Your customers will thank you, your developers will thank you, and your staff will thank you.

Change ControlThis post maybe a little “ranty”. It seems in the past few months, I seem to have encountered a number of instances where changes to the database were made without a Change Request. Which has sparked a few conversations with developers over why there is a need for change control in the first place. Not to mention the one vendor who just arbitrarily logged in, made change, and then lied about the changes when called out. While this isn’t unusual in the sense it never happens, it does seem to reflect a pattern.

I’m not sure if it’s the Spring weather, kids getting out school, the impending solar eclipse, or what. But I do know, this rash behavior needs to stop forthwith. The purpose of Change Control is to make sure all changes are documented, both for troubleshooting and audit purposes. It also is a great way to communicate to other teams/business units that changes are going to be made to a system. It also gives those other teams/business units a formal method of validating your change or even rejecting it.

Water torture

That’s right, water torture. Water torture should be used on anyone that violates the tenets of change control. Any willy nilly change, any configuration or schema alterations should be announced and vetted in a formal process. Why such an extreme method of punishment? Because it fits the crime. Have you ever had a stable system just start performing badly, or data go missing like cigarettes on fishing boat? Only to troubleshoot the issue and discover someone made a change and didn’t 1) document it and 2) let people know he was going to do it? Ever spent hours/days working problems like that? It can all be avoided by using Change Control.

Yes, it adds steps. Yes, it may add a meeting. It’s still better to add the meeting and lose the minutes to paperwork than to lose hours troubleshooting blindly. Especially if the party responsible suddenly goes home for the weekend/vacation. Yep….water torture. That’s time you’re not getting back, that’s stress you didn’t ned to endure. It doesn’t matter if you a company of 25 or 25,000, you should be using formal change control processes. For no other reason, than it helps stabilize your environment as well as tell you exactly what is going on with your environment.

Failure to use change control kills kittens. You’re not a kitten killer are you?Don't kill the kittens

Good ProcedureProcedure and Technique

One of the things I do when I workout, or drive alone, is to listen to podcasts. One of the podcasts I subscribe to is the Art of Charm, which they describe themselves as providing social skills training for Top Performers. In short, they talk about all kinds of self-improvement stuff from social skills, entrepreneurship, business, and fitness. This time the podcast was about procedures vs technique.

During one of my drives to work, I was listening to episode number 505, with Karen Baetzel. In that episode, she discusses her career as a Naval female aviator, one of the first. She also discusses communication, leadership, followers, and other constructive ideas she learned in the military. It’s an informative episode, and I would encourage anyone to listen to it.

One of the topics Karen mentioned in the podcast was the difference between technique and procedure. She defined procedure as a standard regulation that can’t be arbitrarily changed. It’s the policy, or rule, governing how an action is carried out. Whereas a technique is a way, an individual carries out a procedure in any manner they choose, so long as they stay within the guidelines of the process.

Why it’s important

Having been in IT for nearly 20 years and a DBA for the last several, this struck a chord with me. We are all very aware of change management, and how change affects our environments. We should all be adept at documenting how we make these changes as well. One of the things I have noticed, though, is there isn’t a standard on how to create documentation. I’ve worked for organizations where the quality of documentation fluctuates wildly from department to department. While I understand the technique portion, I think it gets applied too liberally at times. In this case, how documentation gets created.

Procedures, policies, and in some cases, work items should be thoroughly documented so that anyone can walk right in and take over. However, a document standard/template should be created as an organization, and each department should do their best to meet that standard. The technique can vary with writing styles. If a team, or an organization, needs access to historical information, the last place that information should be is in a mailbox of someone who is off or no longer with the organization. Storing this type of information shouldn’t be left to technique.

Just say no to being a manager

DBA? What?

I assume, like some others, my IT career started when a few of us got together to attempt a LAN gaming party. It then evolved into jobs like supporting dialup internet users for GTE and later on as a desktop tech. From there, I moved up to become a Sys Admin who swore I had no interest in programming and wanted nothing to do with being a DBA. And yet, here I sit, loving my job as a DBA and working towards getting better at development. Somewhere along the line, I decided I wanted to remain technical and stay out of the ranks of management. Irony ensues, it seems, and the harder I work to avoid participating in a management role, the deeper I go as a DBA, the more into management I seem to get.

What do I mean? How often are we asked about impacts on the data? Or about licensing? How often do we spec servers and not think about the costs of these servers in terms of money and resources? DBAs are always making decisions based on costs vs. return, do we not? How often do we sit in meetings, or on calls, identifying risks and trying to protect the database servers? It doesn’t matter if you are the Senior DBA or the Junior DBA, we are all doing the same thing.

Senior DBAs spend more time in these meetings than the rest of us because they know the environment so well. Those DBAs are in there protecting the data and managing risks to the environment to the best of their abilities. Meanwhile, the rest of the DBAs are doing the technical work and occasionally attending the meanings/calls. Outside all of the external meetings, the DBAs are always talking amongst themselves about the data or servers…just a continuous internal meeting. Yeah, Meetings!

DBAs are more than technical

So what’s my point? DBAs spend much of their time on calls or in meetings? To point out the internal discussions are meetings as well? No…that wasn’t my point. My point is this, do you think the only type of training you should be working on is technical? If DBAs have to spend all this time interacting with people, shouldn’t we as DBAs get better at it?

Years ago, when I started down the road of becoming a DBA on an AS/400, I worked with a couple of people who lacked interpersonal skills. It was always my way or the highway mentality. One of these people would go as far as to shout and yell in meetings, to bully people into his way of thinking, no matter how right or wrong he was. This person even treated team members with that mentality. It made for an unpleasant work experience. It also gave them horrible reputations, and worse yet, other team members got horrible reputations just for being a part of the department.

Develop other skills

If your goal is to be a better DBA, a more well rounded DBA, or to have a good reputation as a DBA, take the time to invest in interpersonal skills. I’m not saying you have to change into an extrovert with a sales attitude overnight, nor do you have to get all HR touchy-feely either. However, it would be beneficial to make people feel like they can approach you and leave with their heads still attached or not feeling worked up about their interaction with you. Too often, IT people get stuck in the technical end of the business and forget there are other aspects to the job. It might explain why IT departments are located in separate buildings, in basements, or some dingy corner of the office.

snoopyGo out into the sunlight, attend interdepartmental happy hours, jump into a GoT discussion. Take a few minutes to talk about sports, the weather, or ask how someone is doing before and after meetings. Don’t mention one technical thing during these “events,” just work on your small talk. Maybe check out some podcasts like the Art of Charm or read a book on management. Better yet, read a book about the other departments. Why? You might learn something about what other departments or managers have to do and why. Then you might start relating to them a bit and understand the direction of some of their decisions. You will evolve personally, and your career will grow. You can still avoid management responsibilities, but you’ll gain some skills or insight that may be useful somewhere else.