Voice of the DBA

Category: Editorial

  • I Hate To Send This Email

    I use TrueDelta to report my car status every month. It’s a nice service, allowing car owners to see what experiences others have, and think about which models and years might be a good fit for me. I’ve tracked multiple cars with their service for the last 3-4 years, with reminders from them every quarter to update any repairs I’ve made.

    Recently I got an email from them with this opening: ” We hoped never to have to send this email. A few days ago we learned that TrueDelta has joined the increasingly long list of organizations whose server security has been breached by hackers.” The email went on to note that names and passwords to taken, and that everyone needed to perform a password reset. I applaud them for including “Security breached” in the subject as well as immediately changing everyone’s passwords so old ones wouldn’t work.

    I’ve been hacked at SQLServerCentral, though to our knowledge no data was stolen, merely vandalized. We haven’t ever been able to track suspected data breaches back to SSC, and I hope we never do, but I’m not naive to think that we never will. I hope we don’t, but hackers make determined efforts to gain access to data. At least we are aware of security measures, have a small staff with administrative access, and try to not allow any simple attack vectors.

    Not every company does a great job at securing their data, especially from phishing attacks. There’s a spectrum of how carefully data is protected by organizations, and as we’ve seen from haveibeenpwned.com and plenty of media reports, more and more companies lose data all the time. Some of those companies notify customers (some have to), and I would guess more than a few people have had to send out emails they never expected to send. More of us will dsend those emails in the future, and we should think about that today. Is there something we can do to avoid having to send those notifications?

    There probably isn’t something to ensure it never happens, but we can certainly work towards improving our security. As developers, we shouldn’t have short limits or character choices for passwords. If you wonder why, there’s a great answer at security.stackexchange. We shouldn’t be writing our own authentication schemes, but incorporating code that’s been written, vetted, and reviewed. And make sure we apply patches. Most of the security holes in software are known and patched, but without being deployed. Certainly if new patches become available, we should be able to incorporate them quickly. Above all, learn what SQL Injection is and don’t allow unvetted user input in queries, including those in hidden form fields.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Launching Products

    Over the years I’ve seen a lot of products launched. I still remember the fanfare around Windows 95, and the efforts to make this an event of sorts, back when virtual events didn’t make sense. There have been a few Windows or SQL Server launches, some of which took place at large conferences, but quite a few were launched in different communities with small physical events. In Denver, there were a few times when Microsoft rented a hotel conference space and scheduled speakers, some from Microsoft, and some local. These would be all day events, showcasing new features, with customers talking about their experiences in previewing the product.

    Just a few weeks ago, Microsoft launched Visual Studio 2017, with some fanfare, and two days of virtual events. I watched one, and hope to find some time to watch a few of the second day’s events. While I don’t necessarily learn a lot, I go get a bit excited seeing new technology and how different people use it. It’s inspiring to see demos and solutions work well on stage. I think it’s a welcome respite from the drudgery of dealing with my own or other people’s code, and the various problems it presents, as well as the various bugs and limitations of the tools and IDEs I use. It seems there’s always some devil in the details that slows me down.

    However, for a short time, I get rejuvenated and excited by the new features. I want to dig in and experiment. It can be a struggle to find time, but watching someone demo a new way of working reminds me of the things I love about computers and technology. I think this is one of the reasons I love attending SQL Saturdays or other conferences and watching other presenters talk. I always see some new and interesting things that generate ideas and excitement. I’m really looking forward to SQL Bits in a few weeks (still time to register), and a few days of seeing what others have been accomplishing with SQL Server.

    I also have pride when I’m a part of the company launching a product. At Redgate, we’ve had a number of SQL in the City shows, which I’ve been honored to be a part of in many cities around the US and UK. Last year we tried a streamed version, which was yet another experience, but one I hope we repeat again. And, in fact, I get to be a part of another product launch next week. We’ve already release SQL Clone, but we have a live-streaming launch coming next week. I’ll be traveling over to Cambridge and getting ready for a few presentations that will hopefully inspire you to try the product. If nothing else, check out the stream and see if we show anything that sparks an idea in your mind.

    I know many of us work inside companies, and our product launches are small, to relatively few customers that are often our fellow employees. Some of you work with companies and the results of your work are visible to lots of others. No matter which environment you work in, I hope you feel the same pride and excitement I do when you release a new idea for your users to enjoy.

    Steve Jones

    The Voice of the DBA Podcast

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

  • We are All Data Companies

    I have seen more than a few people note that every company is a software company. Or that every company should be a software company because software is becoming so important. I’m not sure that’s true. My mechanic certainly uses software, and he competes well with other businesses by tracking my car, reminding me of issues, and keeping in contact through integration between his point of sale system and some sort of email management software. However, this is a small shop, probably less than 20 employees, and I’m not sure they’re ever going to be in the business of software. They are consumers, and they need support, but they aren’t in the software business. My wife’s company is similar. She needs a website, needs to schedule events and take payments, but she’s not going to develop software to help her. Nor am I going to write code, because that might be a never-ending job.

    It’s easy to get out of touch and think that many larger companies need to be software companies. That might be true for some businesses, especially when they need to manage some infrastructure, but for many smaller businesses, I’m not sure that’s the case. Software is critical to small medical practices and retail stores, and service people, but only as a tool. Not as something they’d want to maintain or even customize beyond a simple look and feel.

    Is that true for data? If many companies aren’t software companies, are they data companies? I think so. Data is important, and having some way to look at data and manage it becomes important for them to run their business well. My wife struggles with data, but realizes that managing her mailing list and tracking the contacts is valuable. It’s hard, and her bits are stored in disparate applications, but she recognize the value of data. The same for my mechanic. They’ve seen plenty of value in treating a string of disparate transactions from me across multiple cars as those from a single customer. They also have learned that finding software to understand me as a customer, as well as string together recommendations and past work on single vehicles allows them to provide better service.

    Many companies want to track us through email, phone, or some other identification data because they realize that many people have come to expect a business to know something about us. We might not like them sharing or selling that data, but we do want to them to provide a better experience for us. I’m still surprised when there’s good integration between disparate systems, or a customer service call allows the company to recognize something about me and provide more value. I believe my kids and future generations will expect this to always be the case, shunning companies those that don’t provide customization.

    I worry about data security, data privacy, data integrity, and more, but I do also think that as more companies realize that they are data companies, and data drives many of their interactions, they will see data as more valuable. What they do with that, I’m not sure, but I can only hope they start to treat our data as a valuable resource worth protecting.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Why DevOps? Employee Satisfaction

    DevOps is being embraced by more and more companies, but still a minority of organizations that perform software development. There are plenty of software developers, project managers, and operational staff that are comfortable with their own process, even as they may struggle to produce software for their customers. I think DevOps is a better way to build software, and today I want to look at a benefit beyond faster releases. Today, let’s talk employee satisfaction.

    The State of DevOps report shows that companies who have implemented a DevOps process have more engaged and happier employees. According to the eNPS (e Net Promoter Score), the employees are more likely to continue to work there, and recommend the company to their friends. That endorsement of the organization comes with two benefits. Employees are more productive, and they bring other good employees to work. After all, how many employees recommend someone they don’t want to work with or don’t think can do the job?

    More deployments, easier deployments, the ability to get your code used by customers while you still remember how it works. These are the keys to helping employees enjoy their jobs. When employees are more engaged, and when they are satisfied with their jobs, they work in a more focused manner, trying to ensure their work produces results that help others in the company. In other words, more valuable code.

    DevOps isn’t new; it’s a name given to a number of productive, effective practices that the best software developers have been following for years. The idea of DevOps is being more and more widely embraced, resulting in better software, along with happier employees.

    Steve Jones

    The Voice of the DBA Podcast

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