Voice of the DBA

Category: Editorial

  • The Test of Time

    This editorial was originally published on June 25, 2011. It is being re-run as Steve is out of town.

    IBM turns 100, and in , they brag about bench pressing more other companies half its age. That’s a great headline, and I still remember when IBM was not only the premier hardware vendor of the computer world, but also the largest software maker as well. The “Smarter Planet” ads that IBM puts out there are great, and they are a diverse company, covering so many different industries and locations that it’s hard to comprehend everything they are working on.

    The culture and mission of IBM has changed in 100 years, but it’s still amazing that the company has survived. I think back to the tech companies of my youth, and many of them are gone. Who remembers 3COM? Anyone set up a Wellfleet router? DEC becoming Compaq, and now HP. Apple is still around, but Sun Microsystems is disappearing into Oracle. Microsoft is only 30 years old.

    I once worked for a hundred year old company, one that embraced and remembered it’s history, even as it evolved in the modern world. The President of the company had worked there for his whole career, taking over for his father that had worked there almost his whole life and still came into the office a few days a week at age 80. There was a sense of history, tradition, and pride that kept people working there, with the vast majority of the company having worked there over a decade when I was hired.

    The modern world is fast paced, rapidly changing, and evolving quickly, but there is something to be said for adapting to fit in, while maintaining your mission and ideals. I hope that more companies would look beyond their next quarter or year and make the attempt to build a business that they are proud of, and can survive a hundred years into the future.

    Steve Jones

  • Does It Count?

    This editorial was originally published on Jan 28, 2011. It is being re-run as Steve is out of town.

    I wrote a blog recently about downtime and SLAs, and the need to have not only downtime SLAs, but also a data loss SLA. Thanks to Paul Randal (blog | @PaulRandal) for clueing me in to the need for having both. In the comments someone mentioned that scheduled downtime ought not be counted against your uptime measurements. That’s a debate I’ve had in the past with employers, and I thought it would be a good Friday poll:

    Should scheduled maintenance be counted against your downtime SLA?

    There’s an argument that says since the outage is scheduled, and people are informed, that this shouldn’t really count against your work in keeping servers running. The flip side is that when the database instance is down, it’s not useable, and of limited use to the business.

    I know that companies that calculate the usage of their vehicles, and maintenance counts against usage time. While it’s necessary, the idea is that mechanics should be looking to minimize it, and perhaps ensure that extra checks are done when the vehicle is being worked on to help prevent future issues. A similar argument could be made for database servers.

    Do you feel that scheduled maintenance is downtime? Is it calculated that way at your employer? Let us know this Friday.

    Steve Jones

  • More Regulation Coming?

    This editorial was originally published on Jun 22, 2011. It is being re-run as Steve is out of town.

    Recently Citibank had hackers access a large number of credit card numbers and account details for their customers. It was all over the news, but there was a great piece in the New York Times (registration required) about how this seems to be a nagging problem. We’ve had data breaches before, and banks have had security issues, but they don’t seem to be learning. A number of government officials in the article are quoted as seeking new regulations for data security.

    As data professionals, we are often charged with ensuring data is safe, yet accessible to authorized individuals. That responsibility can be hard to manage, especially when our management often doesn’t want to increase our budgets, or accept more restrictive ways of authenticating users or even slower access. I certainly don’t envy the IT folks working at banks and healthcare companies, and am not sure I’d even want to take a job in those industries in the future.

    I don’t think that more regulation is necessarily the answer, at least not direct regulation. Technology changes so quickly, systems are implemented in diverse ways, and direct regulation often leads to rules that exist to help some vendor profit, not provide better security.

    Whether we get new regulation or not, I think that most of us need to learn more about what security methods work well in our systems, the implications of picking a specific type of encryption, and in which ways we can be audit our systems to detect issues. In the days of limited budgets and apathy from management, a little education is the best way to improve the security of your systems.

    Steve Jones

  • Five Minute Refactoring

    I’ve listened to, and been a part of, no shortage of arguments about the technical merits of a particular programming solution. I’ve seen two (or more) developers argue about the way to solve a particular problem for hours, even days at times. The Internet is full of discussions and debates in forums on the “best” way to write code for all sorts of specific issues.

    These arguments are sometimes referred to as religious wars for the devotion and belief that each proponent has in their solution. I tend to try and avoid becoming embroiled in any sort of zealotry as I am always cognizant of the fact that I need to be effective. I need to get things done and can’t spend a lot of time arguing about a solution, whether for or against it. i need to get work completed.

    When I was managing people I tried to limit the devolution of my staff into a never ending argument, but I ran across a better solution recently. Al Shalloway wrote a blog about limiting discussions to five minutes. He notes that two level-headed people ought to be able to come to a consensus in five minutes. Beyond that he says it’s likely that one of them is arguing about covering possibilities rather than current realities.

    That’s interesting, and like many rules, I’m sure there are exceptions. A manager can make a decision to continue a discussion if they really think that it is warranted. However as a default, the idea that a team should choose the easiest solution to implement if they can’t decide makes sense. It’s the least amount of work that might be wasted, and we want to avoid wasting time and work when we can.

    We won’t always agree, and despite our best intentions, we will make mistakes and we will make poor decisions. Don’t let indecision continue indefinitely and don’t rashly make decisions, but don’t let the fear of mistakes prevent you from choosing a path. Be decisive and move forward, adjusting as you learn more that helps you refine your solution.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.