Voice of the DBA

Category: Editorial

  • I Want Stupid Employees

    This is how I've done most of my training.

    It seems that the vast majority of people that I talk to in the technology field have trouble getting training funded. It doesn’t matter if it’s a conference or a class, it seems that companies don’t want to spend money training people. I find that many companies use one of two excuses. Either they say employees should already know how to do their jobs, or they worry that training will empower employees to go find other jobs.

    Or in other words: I Like My IT Budget Tight and My Developers Stupid.

    That’s the title of an article and it’s a good question for managers that don’t want to pay for training. The article talks about the choice between being “concerned that if people know what they’re doing, they’ll leave. And if they don’t know what they’re doing, they’ll stay”. It’s actually not a bad argument to make with your boss, though I might reword it in a different way.

    There are a certain percentage of people that will not be happy at your company. Perhaps the job is not a good cultural fit, the employees might be ambitious and looking for new challenges, or maybe they are always looking for someone to pay them more. There’s nothing you can do about those people, and withholding training isn’t going to keep them around.

    There are also a percentage of people that are unmotivated, uninterested in their jobs, maybe marking time, or just wanting to get through each day and go on with the rest of their lives. Training can be wasted on this group as they aren’t likely to use the skills they’ve learned at work. It’s possible they might not even learn any skills, just sitting in class as an excuse to get out of work. You can’t do anything about this group either.

    However I think that both of those groups are the minorities at most jobs. I believe most technology people are interested in what they do, like to learn new skills, and more importantly, like to solve problems. They will take advantage of training and look to use their new skills, especially if you challenge them to do so. And most of these people aren’t looking to leave your company. They might stay forever, but the vast majority of people want to keep their jobs and accomplish something.

    And if most people don’t want to stay, perhaps you ought to examine your company’s culture. Maybe it’s the problem. Withholding training isn’t the answer, and you can’t expect people to know, or learn, everything they may need on their own. That’s a recipe to ensure your company isn’t as competitive as it could be.

    Steve Jones

    The Voice of the DBA Podcasts

  • How Many Times Will This Happen?

    Laptops are being stolen with important data on them. Unencrypted.

    This editorial was originally published on Jun 6, 2006. Steve is traveling in the UK this week and we are reprinting a few pieces.

    Or is it a sign of the times and something that we’ll have in the news on a regular basis for the next few years? Another laptop theft with data, this time from Hotels.com. It was actually an Ernst & Young laptop, the firm that audits hotels.com, but still.

    This makes me feel silly for complaining about JD Edwards laptops and the required Pointsec encryption we had to put on every laptop. I didn’t like it at the time, but it wasn’t a horrible intrusion and these days I think a necessary one.

    With all of the hype on identity theft, data privacy, and portable computers, I cannot believe that every company that allows any data to go outside of their physical office, whether on a backup tape or a laptop, doesn’t require encryption or some type of protection. At least do something to protect it. Most thefts are random and the thief probably wasn’t looking for credit card data, so a simple password might protect the data in most cases.

    If governments want to do something about identity theft and privacy, pass that law. Force everyone to encrypt their data and us in IT to come up with good ways to protect it. I didn’t like encrypting backups with Litespeed, the only choice a few years ago, but it was worth it to protect backup tapes. Now with more choices at very reasonable prices, and MSDE/SQL Express able to use them, every database that contains individual data, and especially financial data, should have its backups encrypted.

    Steve Jones

  • Outsourced = Laid Off?

    Offshoring has been used in many industries, including technology

    This editorial was originally published on May 3, 2006. Steve is traveling in the UK this week and we are reprinting older pieces.

    It seems like career week in the editorial department, but I found a bunch of articles recently on careers. According to the Department of Labor employees whose jobs are outsourced should be treated the same as laid off workers. Maybe we shouldn’t be helping factory workers if their industry moves, though I think I’d argue that point, but if we treat the guy rolling steel or sewing fabric this way, why not software developers?

    Losing your job just stinks. I’ve had it happen and it’s a horrible feeling and really can impact your family, emotionally and financially. As the economy moves more globally, corporations increasingly look for ways to become more competitive. The price of moving goods, once way to keep things slightly more level, has fallen so low in the software business that on straight a dollar comparison, everything should move to India or any other country where the wages are lower.

    But it’s not that simple. As many companies have learned, the savings have costs that are not worth it.

    I think providing more benefits for the relatively few people that get outsources is a good thing. It helps to keep the economy going here because those people have assistance to keep buying food, paying their rent, keeping their car, etc. All things that benefit this country locally.

    However if you are out of work for over a year in the IT field. Perhaps you should change the type of job you are looking for or move to a new field.

    Steve Jones

  • DRI or No DRI?

    This editorial was originally published on Feb 19, 2006. We are reprinting pieces this week as Steve is traveling in the UK.

    There is a great debate going on in the forums about using PKs/FKs to enforce RI, in other words, declarative referential integrity (DRI) as opposed to using code logic to ensure that proper relationships are maintained in a schema. The opening post is a DBA stunned that developers in his new company do not use DRI. The reason given is performance is degraded, and that’s one that I can buy. There is additional overhead for checks with DRI, but it’s minimal and actually David Poole has a great article about this topic coming soon.

    It’s interesting that one of the questions is about how many 3rd party applications do not use DRI in their databases. Who knows why, though my suspicion is that they can easily “fix” issues with the applications with backend updates rather than maintaining good DB design practices. Or that they can easily alter the application to meet changing needs at various customers’ sites.

    I think it’s mostly the latter reason. That and laziness. I think the vast majority of developers are lazy by nature and dealing with DRI constraints when building an application is a pain. It’s a pain for me, but I still think it’s a good idea. Just like stored procedures add some overhead, so does DRI and many developers I have seen, both building shrink wrap and corporate software, don’t want to deal with the overhead.

    Personally I like having DRI implemented for the same reason that developers use objects, libraries, functions, and other consolidation techniques. It centralizes the “rules” about your application and ensures that they are always used. I agree there is overhead, but it’s a minimal amount and if you are seeing this on most servers then you are probably underpowered.

    My big concern is that often multiple applications or even multiple modules of a single application often need the same business rules: like no orders unless we have a valid customer number. If you depend on the application to enforce this, then you are gambling that every developer will do it correctly and the same way. In small, tightly controlled and managed environments, this works great. But as you grow your development teams, then it is easy for someone to forget to implement some RI rule or implement it differently than others.

    And those bugs are hard to find.

    I don’t think that every application needs DRI setup in it, but if you choose to not implement it, be sure you understand the consequences of your actions. And your boss does as well.

    Steve Jones