Voice of the DBA

Tag: software development

  • The Art of the Code Review

    The inspiration for this was a piece about the art of the good code review. Throughout my career, I’ve seen code reviews grow and change. From formal meetings to automated notifications and asynchronous discussions to complete lip service to the process. I’d like to think that most organizations are beyond the latter and there is some sort of review beyond the developer, but I still see a lack of other eyes looking at code before it’s deployed, especially database code.

    The article above opens with the idea of why we review code. The main reason is to create ownership, or more specifically, shared ownership. I had never thought of it in these terms, even though I think the ideas of standards and patterns are certainly shared items. Having everyone take ownership not only keeps quality high but could help you share knowledge and also ensure everyone feels a responsibility to safeguard all the code. This also helps everyone keep an eye on the larger picture of the entire codebase.

    I know lots of modern application developers are very familiar with pull requests, though I think these are still somewhat rare in the database world. This is a notification that someone would like their code to be put together with everyone else’s code. A good code review does start with a good pull request, as the idea is to have enough information to let the reviewer decide if they should approve things. PRs should also be focused, so if you are making a major change in one object and refactoring another, make those two different PRs. That way I can reject one without the other.

    Overall I like the suggestions in the post, but I worry about one of them. The author notes that if there are minor changes requested in a comment, you should pre-approve the PR and trust the author to address the issues. In today’s very busy world, and with the challenge of changing code once it’s deployed to a database, I don’t know if I’d follow this for SQL code. Maybe for C#, but if I have to live with your code for a decade, I don’t want mistakes deployed that could be prevented.

    Steve Jones

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

  • Take A Vote and Accept Your Loss

    I feel differently today than in the past about many of the things I’ve seen technical people argue about. I’ve written about Tabs vs. Spaces and Singular vs. Plural, and others have debated commas before or after among other topics. While these might be interesting sidebars at lunch, I see them sometimes devolve into time sinks with teams revisiting the issues over and over during their daily work.

    These types of religious wars stifle a lot of productivity and often can linger for years. However, in many cases what I see is debate across weeks or months and then time spent to shift the way that large groups of people work inside of a company. In the last few years, I’ve seen customers argue about which VCS to use, which new CI tool to choose, or even about which secret store to use for their database credentials. Often these debates happen when there is already a technology in use.

    In most cases, the differences between many of these arguments are negligible. Lots of teams fall down on either side of a debate and find themselves very productive. Or not productive, but it often seems the difference is the staff, not the tool, platform, language, or style. Good people are productive no matter which way we choose to work.

    My view is that for most of these items, we ought to have a (relatively) short meeting. Give each side a few days to prepare, but then one spokesperson for each side gets 5 minutes to present their case on why the group should adopt their idea. Once everyone has presented, we debate for a limited time, maybe 15-20 minutes, vote, and then move in that direction. Ultimately, we’re trying to get software written (or deployed or managed or something) and not trying to decide the best way to format that code or choose a tool for CI/CD.

    This teaches people to communicate and learn to present a rational, coherent, succinct idea, which is a valuable skill. This also teaches us to work as a team and learn to accept decisions that don’t go our way. None of us wins 100% of the time in life, so make a good effort to lead others in your direction, but accept that they might choose a different path. In that case, learn to support the team in their efforts.

    The caveat to all of this is that inside of an organization, we often want a standard, so if something is already heavily used, just adopt that pattern or technology.

    Steve Jones

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

  • Re-Evaluating the Cloud

    Last year 37 Signals (makers of Basecamp and Hey)  announced they were leaving the cloud. I wrote about the decision, and wondered if they’d look back at this as a great decision or one they’d regret and backtrack to the cloud again. They planned to build their own tooling, buy a bunch of servers, and run their own data center (or rather, rent space in someone’s data center).

    Recently there was an update, in an FAQ, about how the transition has gone. In short, very well. One of the founders, David Heinemeier Hansson answered several questions about the move and the financial status. They didn’t hire more people, so their payroll is the same. They used a service to unpack and rack their servers, so they could just connect to them remotely and not deal with hardware. They built their own redundancy across two data centers where they rent space, and they think they will save well over $7 million in the next 5 years. They had a $3.2million cloud budget per year, so that appears to be halved (3×5=15 – 7 = 8ish) with their move.

    There are some answers to various questions, which are likely of interest to many data professionals who might feel pressure to move to the cloud. First, they discuss resource optimization in the cloud. I think that’s really hard, to do well and if they gave the details of what they’d done, that might help others decide if 37 Signals did a good job, or if there are things others could do. I think many people might struggle to optimize their usage, especially if you are only responsible for one thing, like the database. In many orgs, once something gets deployed, or developers build a PoC using some cool, new service, it’s hard to get rid of it or even change how it’s used. I think 37 Signals has some agility here that many orgs struggle to implement.

    Rewriting things are cloud-native is the way to go, in my mind, and I do have customers and clients who see applications working better in the cloud. However, I might argue that rewriting applications is hard and expensive, and many companies aren’t great at writing software that’s efficient, so rewrites are hard. I also think in most organizations, developers struggle to understand what cloud-native means. I think DHH is a little off here, as their developers probably could make better software written for the cloud, but they didn’t want to spend the time and/or money.

    The points about security and reliability are fair, but I think those are a function of having good people implementing systems. You can get good security and reliability in the cloud or poor implementations of either. The thing about security is that the overall protections that detect some of the DDOS or attacks are better with Azure/AWS, but simple SQL injection or open firewalls are still a problem. Authentication and security are just hard for most people and often people do this poorly in the cloud. To be fair, most people don’t do this well on-premises, so at least in the cloud, there are some services/scanners/checks that let you know when you’ve messed up. Whether you change or implement their suggestions is another whole debate.

    Is reliability better? AGs are hard in SQL Server, as are distributed clusters. The cloud services do this better for most people, but maybe not for you. That brings me to his super engineer point. He doesn’t think he has super engineers on staff, but I disagree. I think they can pick good people, especially because of their profile, and they don’t need a lot of people, so their average engineer is likely better than the average engineer at most organizations. They built some great software, and they’ve built an amazing framework and tooling to deploy their software. Don’t tell me that’s even close to the capabilities of the staff at many organizations. We have really good engineers at Redgate, and I think we’re above average as well. I don’t know how we compare to them, but we haven’t had people publicly write and release code that thousands of other developers use. At least not at quite the same high profile level.

    The cloud has its place. It can work well and it can be very expensive. This journey is worth sharing with your management if they want to move to the cloud, especially if they want to lift and shift. That might create some flexibility and CapEx/OpEx changes that are worth it, but you ought to debate and question whether that’s reality or marketing hype from a vendor. After all, it’s not clear if a cloud move is really something that returns an ROI or one that reduces your profitability.

    Steve Jones

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

  • Fixing Poor Programming Practices

    I see a lot of poor programming practices in real-world code. I’m sure I’ve written a few myself. I’m also sure that many of you see the same thing and sometimes wonder how that code got deployed.

    One of the things I told myself over the last few years was that I had to accept the reality of situations. It’s easy to complain and say that code should be written differently or entities should be modeled in another way, but I (or you) can’t change that situation today. And it ignores the fact that we are stuck with this environment and we have to move forward from here, not try to rewind the clock and go back in time to design things better at the start.

    Today I’m wondering how you’ve adapted to poor practices and fixed them. Do you have stories to share that might help others deal with their situations? Post comments below, and to help, I’ve got a few stories from my past. Both of these deal with third-party software products that (poorly) use a SQL Server database.

    One company purchased a new accounting package with very poor security practices. The installation noted that the software needed to use the sa account. I couldn’t think of a reason why an accounting package needed sa on an instance, especially as we were installing this on a production server with another database.

    I called the support line and we discussed what was happening. They said that for the accountants to add new users, they needed to add a login and thus needed sa. This was in an older version of SQL Server, but that still didn’t make sense. It was lazy developers not understanding the security model and wanting sysadmin to make things easy. We showed them that we could add a login ourselves and a public user mapped in the database, which the software would pick up and allow finance people to assign rights. Poor practice mitigated.

    In another piece of software, we found a view being used that was querying other views and tables. As you might expect, performance was poor. We decided to “fix” the view with better code, but first, we created a new schema (with our company name) and added their view to this schema. That way we kept their code around. We rewrote their view to run more efficiently, and if we had a support call, we’d replace our better view with the original one from the previous schema. We even had a proc in our schema to do that for us. Of course, our view was kept in our VCS, as it should be.

    If you’ve got stories, let us know in the comments today.

    Steve Jones

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