Voice of the DBA

Category: Editorial

  • NCAs and NDAs

    This editorial was originally published on Mar 12, 2008. It is being re-run as Steve is on holiday.

    It’s getting close to March Madness, but this editorial has nothing to do with basketball. I saw a career newsletter recently that answered a question someone had about negotiating non-compete agreements (NCA) and non-disclosure agreements (NDA). The basic answer was that you might want to negotiate reasonable limits to these agreements to protect yourself.

    I’m under a few NDAs, one as an MVP, one as part of Red Gate, and I still have a NCA as part of the sale of this site. I’ve also signed some in the past, but I’ve been careful to read them and negotiate the terms to be more fair, at least in my mind what was fair to me and the company. Often the original agreements I’ve seen are heavily in favor of the company and should be changed.

    The MVP one with Microsoft actually seemed fair to me and mostly covered releasing information that we get as MVPs in advance of Microsoft’s disclosure. So I always ask before I repeat something I’ve gotten through their channels.

    I don’t think that NDAs or even NCAs are that commonplace as a condition of regular employment, but you should be careful and read them carefully. The exceptions might be if you’re a consultant (often an NCA will be given to you) or you work in a company that’s going some type of research or invention, including software. In these cases, I think you might see a standard one.

    However you feel about them, usually they’re required as a condition of employment in those cases, however you don’t necessarily have to accept them as is. I highly encourage you to read them and ask for changes that you think make sense. Usually this involves limiting the distance, time, or scope of the agreement. I definitely advise you to limit time frames to no more than one year for most time limits, a reasonable distance limitation (50-100 miles), and scope out specific companies for which you cannot work (for example, current customers or even only those you have contact with).

    One thing I’d also mention is that don’t look at these agreements as ironclad. I know consultants that have gone to work for current customers of their employers by negotiating the transition. Often the contractor doesn’t want to anger its customer, so it may let an employee go as a gesture of goodwill. Of course you probably have to work for the company, not be your own contractor.

    Just keep in mind one thing if you ever want to get around the NCA or NDA. You need to ask and negotiate again, which just might get you what you want. If I’ve learned one thing in negotiating anything, it’s that you can’t get it if you don’t ask.

    Steve Jones

  • The Copy Cat Poll

    This editorial was originally published on Aug 3, 2012. It is being re-run as Steve is on vacation.

    One of the interesting facts I saw a few years ago talked about storage in enterprise environments. There was research that showed many enterprise applications had 6 or 7 copies of their large databases inside the organization. In addition to the production copy, there were many other copies in use, resulting in an explosion of growth. That wasn’t surprising, and it was one of the drivers for implementing compression in many databases.

    While the cost of storage is constantly coming down, it’s still expensive for enterprise class hardware, especially in a large SAN device. Today I wanted to ask those of you that work on real world systems to make a quick count of your own system, and let us know. I can’t decide if 6 copies of a production database is high, or low.

    How many copies, on average, of your production databases are in your company?

    I suppose you could count backups as a copy, since it’s disk space usage and you have to pay for it. If you count backups, let us know, but I’m thinking just about the test systems, development systems, HA or DR systems that might receive copies of the data. Some of those secondary systems might be in use for other purposes, such as reporting from readable secondaries in an AlwaysOn scenario. Whether they are or not, they are still copies of your database.

    I used to think that four or five copies would be a lot, but with the advances in technology that allow different DR options, and the cheap local storage available on today’s desktops and laptops, I wonder if seven or eight copies might be more accurate.

    Take a count today; you might surprise yourself with the results.

    Steve Jones

  • Time Off

    This editorial was originally published on Aug 20, 2012. It is being re-published as Steve on vacation.

    As a US citizen, I’m lucky to work for a UK company. I get a generous allotment of vacation, and desperately try to use it all each year. I haven’t been successful yet, but I’m getting closer. If we could only get a little more snow at the beginning and end of the season…..

    Last year a friend told me that they lost 6 days of vacation. Over a few years this person had accumulated extra vacation by basically working too hard and when the year ended, some of their vacation was lost because of carryover limits. This person vowed to change this year and use all their vacation, but with a busy job at a small company I’m not sure that will come true. Unfortunately, I’ve all too often seen this same behavior from many people in IT.

    This piece shows that all too often people are not taking their vacation, or they’re not taking it as a complete break from work. I’ve been in both situations, and over time I’ve learned that I’m not being more productive in either case. I’m unbalanced, and over time I become less productive. That’s especially true if I’m doing creative work, like writing, or developing code.

    There’s no shortage of poor managers out there, and there are plenty of them that will work you as hard as you allow. I don’t have any great solutions for dealing with them other than scheduling vacation every year, insisting you get to take it, limiting contact with work, and if all else fails, looking for another job.

    Life is short, too short to spend more of it as work than you have to. Take advantage of your vacation to relax and recharge, even if it’s a stay-cation at home. Getting away from work is not only important, it’s something you owe to yourself and your family.

    Steve Jones

  • Rogue Algorithms

    This editorial was originally published on Sept 5, 2-12. It is being re-published as Steve is on vacation.

    I have always thought that computers do some amazing things, but they tend to do what we tell them to do, even if what we tell them to do is not what we want them to do. In those cases we usually find computers are helping us make mistakes faster than ever before. As we automate and link more and more systems, this can become a bigger and bigger problem in the world.

    I ran across this short link on a rogue algorithm that caused a fluctuation in a number of stocks. It looks like this was a case of poor analysis and poor QA at one firm, but imagine if we had some type of “update” released to a large number of companies? This type of problem could cause a dramatic short term fluctuation in the stock market, which shouldn’t affect most of us in the long run, but you never know. If this caused a company to go out of business, and they were the company holding your retirement savings, you might feel differently.

    This isn’t necessarily a problem that affects just financial institutions and their custom software. This is potentially a problem in any business that writes its own algorithms. That includes many of our companies, and many of us. We write queries, reports, and develop algorithms that help “the business” analyze data and make decisions that can affect our companies.

    This is worrisome to me, especially when we have companies that press for more and more analysis, with algorithms written more and more quickly to respond to business events. Success in this area often depends on the developer having an understanding of the nature of the business and the meaning of data, and strong working relationships with the business analysts. That comes over time, and is easily lost when employee turnover is too high.

    I hope that companies are learning that there is value to retaining employees, especially those that work with data and have invested effort in learning more about their business. Unfortunately I think that it take a disaster like this for some managers to understand the value of retaining employees and their knowledge. Even more unfortunate is the fact some managers never learn that.