Consistent code infrastructure

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

— Martin Fowler

I’m currently working on a project in which I’m trying to deconstruct a database. In doing so, I’ve come across a number of things about it that, in the scope of databases, appall me. Who the hell creates a relational database with no defined primary or foreign key constraints??? And this thing is in a production environment, no less! While that’s a big part of my frustration, that’s another rant for another time. For this article, I want to focus on something else.

A big part of my task — and my frustration — is trying to figure out what the data columns are and how they’re being used in the application. I did come across a table that contains data as to what primary keys are defined (I have no idea why whomever built this thing didn’t actually create the primary keys), and I’m spending a lot of time trying to figure out how these tables relate to each other. As I already mentioned, there are no foreign key relationships defined. So a lot of my time is being spent trying to figure that out.

This is where my frustration — and the purpose of this article — kicks in. Whomever built this structure used names like “DataCounter,” “CrossReferenceCounter,” and so on, to define their “primary keys.” (I put it in quotes, because, like I said, they’re not actually there. And who uses the word “counter” to define them?) What I’m finding is that the corresponding foreign key isn’t exactly the same. For example, while the entity table uses ” DataCounter” for its “primary key,” other tables reference it using ” DataIDCounter.”

This might not seem like a big deal, but when you’re trying to figure out how to map large numbers of data tables and columns, you start questioning whether or not the relationships are correct. And I came across several others whose naming conventions are even worse.

Some of you might be saying, “that’s not a big deal. What’s your problem?” Well, trying writing an ad hoc query where you type in what you think is the column name, and it turns out to be something completely different. You end up wasting your time going back to look it up and trying to figure out what it is.

I remember a previous job in which I was looking at a piece of JavaScript code that contained two nested loops. You would think that the increment counter would use words that would make some sense, right? Wrong. Whomever programmed it named the variables “dog” and “cat.”

Explain to me how that is helpful to somebody trying to troubleshoot or edit the code.

In my previous life as a developer, I would write what I referred to as “open-ended code” — that is, I wrote it with the idea that it would likely be rewritten somewhere down the line. I wanted to make it easy for me (or someone else) to go back and edit or change the code, if necessary. I like to think that other developers have this same mindset, but, all too often, I come across examples like this that tell me that that is not the case.

If you’re a developer — whether it’s for an application, website, database, network, or whatever — keep your naming conventions and infrastructure consistent and meaningful. You will save another developer or support analyst a great deal of grief, frustration, and time.

Expect the Unexpected with DiRT

Steve‘s article reminded me about the first time I gave my Disaster Documents presentation at a SQL Saturday.

At the end of my presentation, one attendee started an argument with me. He kept saying that paper was dead, everything was online, and there was no reason to keep hardcopy documents. I argued, what if you can’t get to your online documentation?

Not surprisingly, he gave me a poor evaluation.

The bottom line is this: even documentation needs a backup. Other than, say, getting lost in a fire, paper documents can’t break. At a minimum, have hardcopy documents that instruct how to get minimal services back up and running, and back up other recovery documentation so you can recover it later.

Voice of the DBA

Disaster recovery is one of the core tasks that many DBAs think about on a regular basis. Ensuring that we can get our data back online, available, accessible, and intact is important. More than a few DBAs that haven’t been able to recover systems, find themselves seeking new employment.

That’s not to say that most DBAs perform perfectly under pressure. Plenty make mistakes, and there may be times when they can’t recover all data. There does seem to be a correlation between how often DBAs practice recovery skills and how well they perform in an actual emergency. I know that at a few companies, we scheduled regular disaster tests, though often with simulated recovery of a systems that didn’t expect to actually take over a workload. Arguably not a good test, but better than nothing.

Google takes things a step further. They have annual, company wide, multi-day DiRT (Disaster Recovery…

View original post 359 more words

Want to learn something new? Get off your butt, and go get it!

A few weeks ago, Monica Rathbun wrote a ‘blog article about pursuing education or learning opportunities. It had been shared and retweeted a number of times by a number of people. I had meant to do the same, but it came out right around the same time that my father-in-law passed away, so the timing was inconvenient for me. After a few weeks of dealing with family issues, not to mention a week away at PASS Summit, my life has settled back into a state of semi-normalcy, so now I can go back to boring all of you with ‘blog articles and posting things I find interesting.

Additionally, Steve Jones came out with an article this morning about the benefits of conferences. Conferences are a great source of learning and networking. Some, such as SQL Saturday, are even free. If you ever have an opportunity to attend a conference or a seminar, I recommend it highly.

People, all too often, make excuses as to why they don’t learn anything new. Monica’s article lists out many of those excuses, and goes on to say why they are all invalid. She goes on to list resources you can use to further your education. It isn’t just about getting a degree or a certificate credential; it’s also about attending conferences and user groups, reading ‘blogs and articles, talking to people and networking, going to your local library, and getting involved with activities. Go read Monica’s article; it’s a great read.

I’ll make another suggestion: consider starting your own ‘blog. One of the best ways to learn about a topic is writing about it, even (and especially) if it’s a topic you don’t know. Writing about something you don’t know is a challenge, and it can sometimes be uncomfortable. But you won’t get anywhere unless you step out of your comfort zone.

Education is important, and we are always learning. Don’t use lack of money or lack of time as an excuse not to learn. There are many learning resources out there that you can do on your own time and require little or no money. If you’re seriously interested in learning about some topic, take the initiative and go get it. Otherwise, you run the risk of remaining in the same routine rut for the rest of your life.

What do you do for an encore?

“The reward for work well done is the opportunity to do more.”

Jonas Salk

As a Syracuse alumnus and sports fan, I’m looking forward to this upcoming football season. Orange fans are excited for this season after last season’s 10-3 breakthrough, the first time that Syracuse has won ten football games in a season since 2001. Season ticket sales are up this year (and I’m happy to say that I am one of those season ticket holders). I’m looking forward to attending games this season!

In a recent interview, Syracuse football coach Dino Babers said that getting the team to break through with a great season (after years of mediocre ones) was the “easy” part. The harder part, he said, is maintaining it. As he often puts it, he wants to be “consistently good, not occasionally great.” Breaking through is a great thing, but after you’ve done so, how do you maintain that success?

I thought about this recently in regard to SQL Saturday presentations. One of my friends and fellow speakers gives a great presentation, but I do have one concern about it: it’s only one presentation. I’m not sure how long he’ll be speaking at SQL Saturday if he keeps submitting the same presentation again and again. I’d like to see him do more presentations, and I hope to see him at more events. Yes, he has a good presentation, but what does he do for an encore?

It’s for that reason why I look for more presentation ideas. As of this article, I have a brand new presentation idea that, right now, only exists in the back of my head. I listed it so that I’d remember to work on it. If I come up with what might potentially be a good presentation idea, I’ll set the idea aside so I can work on it. I want to make sure that I have fresh ideas. I love speaking at SQL Saturday, and I’ve been doing it for four years. I want to keep doing so. To do that, I want to make sure I have new material. While I do occasionally recycle my presentations (it’s unavoidable), I try not to resubmit the same presentations over and over to events.

For those of you who are looking to get your career off the ground, the same holds true for career endeavors. A great job that you did on a single project will often be enough to get you in the door. But once you’re in the door, how do you stay there? Breaking through on a project is the easy part; the harder part is sustaining that success. Once you’ve achieved something, can you do it again? And again?

If you are able to sustain success, you develop a reputation as someone who can deliver. That’s how you build a career. Achievements are great, but once you attain them, what do you do for an encore?

Don’t discount old documents

For those of you who have application development experience, how many times have you come across old code that you’d written and said to yourself, “what the F was I thinking?!?”

As someone with development experience, it’s happened to me more often than I can count. And as someone with tech writing experience, I can tell you that it applies to documentation as well.

As a technical writer, I’m often tasked with rewriting old documents that are out-of-date or no longer applicable. In the old days (i.e. before I knew better), I would essentially overwrite old documentation with the new, and often deleted the old. Now that I have more experience under my belt, I know now that that was the absolute worst practice that I could have done.

For starters, I used to have the mindset that the information in old documents was no longer relevant. The processes have changed, I used to tell myself. Why should I keep these documents around?

If you have this mindset, as I once did, I urge you to purge it. It is a poisonous attitude to have. As it turns out, old documents are extremely relevant, even if their information is out of date. Old documents are important for reference. I’ve often found myself referring back to previous versions when rewriting documentation.

I recently wound up a project that involved a rewrite of an application document. The application had been rebuilt from the ground up, and the documentation had to be rewritten to accommodate it. While documenting the testbed, I came across a number of functions that, with the limited testing dataset, didn’t seem to do anything. I went to the predecessor documentation and found what I was looking for.

Old documents are often also important in answering a simple question: why? As in, why was such-and-such process designed this way? What was this originally supposed to do? Why was this function changed? Many of these cannot be answered just by looking at application code; often, the answers are found in old documents.

These days, I make it a point to not overwrite old documentation. I back up old documents and either rename them or put them into an archive folder. I haven’t yet implemented a version control system to archive documents (we use Git in my office). If anyone makes use of version control systems such as Vault, Git, Subversion, or MS Azure DevOps (formerly TFS) to maintain documentation versions, feel free to mention it in the comments.

So if you are rewriting documentation, make sure you set aside the previous versions. You never know when you’ll need them again.

Ransomware and DevOps

Another post by Steve Jones that I think is really important…

Voice of the DBA

Ransomware.

A scary topic and one attack that is apparently more common than I suspected. Before you go further, if you haven’t restored a database backup in the last month, stop and go verify your DR plan works. That’s one of the overconfident issues facing lots of government and businesses. While this might not help your entire organization, at least you’ll have some confidence in your process and that you can recover a database.

This is a great article from Ars Technica and worth reading: A take of two cities: Why ransomware will just get worse. I’d recommend you read it and think about a few things. First, do you have insurance because things (or substitute your own word here) happen? Second, have you really tested a DR plan for some sort of software issue like this? You might think about a way to restore systems in an air-gapped…

View original post 356 more words

Companies that adapt and survive

I’m working from home today. As is typical when I work from home, I’m sitting in my living room with my laptop in front of me and the TV on (and, every once in a while, Bernard — our tuxedo cat — curled up on the recliner between my legs). If there’s one thing I’ve learned about working from home, there’s nothing good on TV in the middle of the day on a weekday. To steal a line from Bruce Springsteen, how many channels and nothing on? Thankfully, as I write this, Wimbledon is on ESPN, and Roger Federer is putting on a clinic. (He lost the first set, but since then, has been absolutely dominant.)

Well, obviously, as you might have judged by my article title, I’m not here to talk about TV. So what does TV have to do with this article?

A little while ago, I saw an ad for Western Union. For whatever reason, I started thinking about Western Union’s history: it started out as a telegraph and telegram company. It made me think: in this day and age of internet, social media, and nearly instantaneous mass communication, how has Western Union managed to remain relevant?

I looked up Western Union on Wikipedia. I didn’t take the time to read the entire article, but to make a long story short: Western Union adapted with the times. It stopped delivering telegrams a long time ago, but has since become involved in internet communications, as well as financial services. As their ads bill themselves, they’re “the fastest way to send money.”

Western Union still exists because they changed and adapted with the times.

They’re not the only ones. A number of companies continue to exist because they managed to change with the times. Off the top of my head, The New York Times has de-emphasized their print paper and is largely an online news source. While Apple still produces personal computers, they became much more successful after diversifying and becoming a provider of products such as smartphones and music players, among other things. There are countless other examples as well; at the moment, these are the ones that stand out in my mind.

Even from a personal standpoint — I’ve written about this many times before — I’ve practically made an entire career out of adapting to my environment. Even in one of my very first ‘blog articles, I wrote about how change is inevitable.

I’ve said it before, but it bears repeating. Change will happen. The question is, how will you adapt to it? In order to survive, you need to be able to roll with the punches. The environment around you will change. What will you do to adapt?