Voice of the DBA

Category: Editorial

  • Encouraging Innovation

    I was working with a client recently and one of the managers said they wanted to encourage innovation inside their organization. That sounded good, but as I thought about it, I wasn’t sure what this means, or if it’s really something that matters. Let’s take a few examples and think about this in a modern organization that builds and operates software.

    If I am a developer, I get a series of requirements or tickets where I have to write code. Perhaps I need to take inputs from a user, query a database, and produce a result. I might write code in C# 7 instead of C#6. Maybe I’d use a lambda instead of creating a new function. Perhaps I decide to ensure I use the stored procedure type with named parameters rather than submitting SQL as a batch. Is that innovative? It might be a better way to write code and improve the quality (or security or maintainability) of the code, but is it innovation?

    Another example. I’m a DBA and I need to run scripts against production. All the DBAs use SSMS, but I decide to change. I store the scripts in a folder and use Flyway to execute them against production with an automated system like Octopus Deploy, which manages the security. Is that innovative or just adopting a more DevOps-y practice?

    Jason Fried says innovation is overrated, which I think is true. At least when that’s an aim or we expect to build something radically different. I know there are sometimes we might come up with something new that our organization hasn’t done, but most of the time work is work. It’s tedious mundane, and it can be very repetitive. That’s why the urge to do and try something new pervades most development organizations.

    I do think that you can regularly innovate in your workplace. You might not create something that’s never been done anywhere in the world, but you might get people in your org to try something new. To adopt a new technique or habit, to create higher quality code with a small change. That’s the type of innovation that I like to see and foster. That’s what DevOps encourages, experimentation and learning. It’s also what I think my examples above show. It’s innovation in this particular space, which hopefully makes work more interesting and enjoyable.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Technical Debt

    We all experience technical debt when building software, especially software that has been around for years. Most of us have likely encountered code that we are loathe to touch and modify. At least, we don’t touch it twice. We might change things once, but when it doesn’t work as expected, most of us put it back in it’s previous state and move on to something else.

    At the same time, it’s hard to define what technical debt is or point it out to managers, who often can’t grasp the concept of why technical debt matters to a development team. They can’t understand the reasons why new code built on older code takes longer and longer to produce. It’s a nebulous concept that can baffle both people new to software development and those with years of experience.

    I ran across a few articles that talk about technical debt. This one notes it’s commonly used as a phrase and also, it’s inevitable. There’s a short video from Ward Cunningham, who is said to be the inventor of the term. It’s interesting because the explanation isn’t bad code, it’s more that we don’t always understand the problem when we write code, especially at the beginning. As we have a disagreement between what’s coded and what’s needed, we accumulate debt. Ward talks about refactoring regularly as we gain understanding.

    There is another piece that uses the Chernobyl disaster as a comparison with software development. This one looks at cost-cutting in both situations. The emphasis in software development is something Jeff Moden will appreciate: developers not writing robust code. There is also a section on designing to meet only 95% (or less) of perceived use cases, which I think is just reality. We can’t write software, in any practical sense, to cover 100% of use cases.

    The final section talks about incomplete testing. While software development has gotten better here, there is still plenty of work to be done, especially with database software. I find far too few database engineers wrap tests around their code and often have problems with new data or when code is refactored. A few more tests added early often prevent issues later, or at least, save time when debugging. This is one place I think AI might really help with labor savings by writing these tests for us.

    Technical debt is a reality of life. We have imperfect engineers, we have the pressures to get things done, the increasing complexity of software systems, and perhaps most of all, the pressure to keep moving forward with something new instead of refactoring something old. I don’t have any great solutions, but I also do see software developers working better than they did in the past. That gives me hope for a future where software is embedded in more places and used more every day.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Startup Advice

    Many technical people dream of starting a company and having it grow to an IPO. The history of computing is littered with the successes and failures of companies that attempted this. As a young man in high school, I saw the explosive growth and success of Apple, dreaming of working for them or duplicating their success. In the late 90s and 2000s, I tried a few startups before I founded SQL Server Central with my partners. I had success with that company, though no IPO :(.

    I’ve seen many friends start companies, often consulting ones, though a few have built products. Building and running any enterprise is hard, and startups are no exception. There was a post on Hacker News looking for advice and business lessons from others, and I enjoyed reading the responses. I wouldn’t read much deeper than the first level of responses, as many of the subsequent comments are less interesting.

    This response was something that caught my eye, especially as someone that’s had to do more than the technical part of running a business. A lot of the challenges I find in startups are business related, especially when technical people are in charge. It’s good for them to understand that core business, especially sales, skills are important. Even more important, home life matters.

    It’s easy to assume that your technology matters. Is the bidding technology at eBay better than uBid or eBid or even Craigslist? They are now, but 20 years ago many of these sites were similar, and some had arguably built better systems. Was the tech behind Amazon in 1999 that far ahead of Barnes and Noble or Borders? Certainly, Amazon continued to invest in technology at a scale that exceeded many other companies, but they built their success because of execution in business, not technology.

    Starting a company is hard, and it takes a lot of work. Whether you create a product or you are the product. I’ve seen many over the years, worked with some, and often the best products, tech, or people aren’t the ones that succeed. The ones that are best at running a business succeed.

    If you want to try and start a software company, go into consulting, or perhaps create another business, I urge you to learn a lot about how to run a business. Basic sales, marketing, and accounting skills will go a long way towards helping your endeavor succeed. For many of you, the tech is the easy part, so don’t spend all your time there.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • The Public Perception of Security Issues

    It’s my fault.

    That’s what I think if there is a security incident with my employer that involves the database. It’s almost my first thought when I hear about issues at other organizations, thinking a technical person is at fault. Since I’ve been a developer and administrator, and I know how complex systems are, I usually stop myself and try to learn more before I assign blame.

    The public and your customers also think that it’s just your fault. At least, that’s what I see and hear from friends. Non-technical people are very quick to assign blame and get upset. They can’t understand why some companies get breached and others don’t.  To them, it’s because the staff or management are lazy and haven’t done a good job keeping their systems secure.

    However, even my technical friends get upset. I’ve had more than a few of them chastise an organization for getting breached when they themselves haven’t always kept up to date on patches. I mean, how many of you are sure every SQL Server you have is at the latest CU level? How quickly do you patch? Are you sure your firewall people haven’t accidentally misconfigured a rule for port 1433?

    Anyone can get breached, as noted in this article. However, a good response can set you apart, and I wish that more management and technical people would be prepared now for a data loss incident, a ransomware attack, or really any security issue that might occur in the future.

    It’s easy to panic and make rash decisions. The best time to draft your response is now, when you have a clear head and no pressure. Have a few people start to game out how to react, what words and message to send, and who will take responsibility for communicating with customers. It’s worth a little exercise to discuss some possible responses to events and at least have the outline of a plan.

    And no matter what, be sure you have a copy of the plan air-gapped from your network. On a few flash drives, saved to a separate OneDrive/Google Drive/Dropbox account, or even printed out. The last think you need is for all of your work to be inaccessible because of something like ransomware encryption.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.