Voice of the DBA

Category: Editorial

  • Priorities and Productivity

    Time is a resource for all of us, both at work and in our lives. As I get older, I think time might be the most valuable resource I have, the same amount each day, but an ever decreasing set in my life. As a result, I try to avoid wasting time and taking advantage of what I have when I can.

    At work, we often have more tasks than we can complete in any point in time. I have rarely been without work, though certainly there are slower times when deadlines aren’t providing pressure to get things done. For many of us, we can struggle to manage our work, especially without strong management to help us.

    There was an interesting blog from Trainline, from a technical worker that was promoted to manager and had a whole new set of tasks and responsibilities. He decided to adopt some of the same agile principles he used as a developer to manage his time. It’s an interesting read, and perhaps one that might help some of you better organize your own work.

    The principles of Lean Thinking and visualization are two of the items he used, along with building a Customer-Value map. You can read the basic descriptions, but to really understand how these concepts work, you will want to do more research and spend some time practicing the concepts. However, there are a couple of other techniques in the post that I think are worth pointing out.

    The idea that work has an effort and value you can use to help determine which tasks are worth tackling is important. I think sometimes we consider value without effort, but organizing tasks into grid is useful. There is also the concept of important v urgent tasks, and how these two may or may not be related. As I read about these, I realize that I often do this internally with my work.

    I know there are important things to do, many of which aren’t urgent. Finding time to get those done is useful, not only because they get off my plate, but the more often I can avoid creating urgency, the less stress I have. I also find that urgency can sometimes be my own fault for procrastinating a task.

    There are certainly many times when managers will prioritize work for us, but I often find for developers and DBAs, that we have a fair amount of autonomy. Many of us also have a known backlog of work. Developing some skill and techniques to manage your own workload will serve you well, and you might consider adopting some of the ideas in the post in your own career.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Very Hot Patches

    “At best it would crash” is not a phrase I’d like to have to use as a data professional. That’s a quote from an article that the Azure team wrote about hot patching SQL Server. While this sounds very scary, it’s actually something being used now to patch the SQL Server code running Azure SQL Database.

    Years ago I read a book where the hero was a programmer that had to alter and hack into live code on a mainframe, making changes to thwart the villains. It was a neat concept, and certainly daunting. As someone that had to write assembly code at one point, I had trouble keeping track of instructions when I could map them out on paper. Doing this on live code would be very scary.

    The SQL Server code is not being changed live by a human, but code is being patched without stopping the sqlsrvr.exe process in Azure. There is a blog on the hot patching process, which I appreciate, though I’m not completely sure I get the minute technical details. Still, it’s an impressive feat of engineering to me, and this does make me wonder to what extent platform engineers might structure their code to allow more of this in the future.

    Deploying changes is already a challenge for many of us with database code. Making changes, evolving our schema and adding functionality without downtime or excessive blocking is a challenge. Many customers that look to move to a database DevOps software development process often assume that our tools will just do this for them. They won’t, because any DevOps tools that help with automation don’t magically get around the limitations and restrictions that Microsoft has built into the platform.

    Making changes in real time, without interrupting workloads involve some engineering challenges, but whether at the SQL Server platform level or the database code level, they are possible. It takes some work, some flexibility, and more importantly, some understanding of how changes can be made and the patterns that enable uninterrupted changes. There is often a space and time trade-off, and certainly no magic, though to our customers, it might appear that way if we do our jobs well.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • T-SQL Context Switching

    Studies have shown that reading someone else’s code can be both stressful and time consuming. Developers that pick up unfamiliar code find themselves spending much more time comprehending the code than with more familiar projects. I think this might be one of the reasons that so many developers want to build things themselves from scratch, or in least build new things in their team. They find their own code easier to understand.

    This might be less of an issue with SQL code, which is often more straightforward for simple queries, but I  do find that complex queries can be confusing to many developers if they didn’t write the code. This can especially true when another developer has used some rather uncommon trick. I’m also sure that plenty of people will cut and paste solutions, from places like SQLServerCentral, without understanding how the code works, but even decoding the answer to a question you’ve asked can be hard, even if another poster tries to explain how the code works. Hopefully most developers make an effort rather than coding a poorer solution or deploying code they don’t understand, but I’m sure some don’t when facing their own pressures to get work done.

    With staff turnover and the need for developers to work on multiple projects, time spent interpreting code can be a drain on the efficiency of all developers. In addition, since individuals often find code easier to read in certain formats, tools like SQL Prompt can help, but there are plenty of easy ways to keep your codebase readable for staff. Dr. Greg Low has written a nice post on standards, which I think outlines some of the things I like to implement in a team. Having a known way to structure our code can help us communicate intuitively in a group, rather than require extra communication.

    Actually, I don’t care what standards exist in a company. I don’t have strong feelings about any particular way to structure code. I prefer spaces, but if we decide on tabs, I think that’s fine. I’ll work within the framework we’ve built. What I do think is very important is that you have some standards. They don’t have to be perfect or exhaustive, but they do need to be followed.

    If you don’t have standards, I suggest you start creating them. Add them as needed, when a developer finds a reason to make a decision, get consensus from the rest of the group and document the standard. Like other things in DevOps software development, we can grow these over time as we need them.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Republish: Documenting with Tests

    I’m at SQL in the City Summit – Sydney today, likely loaded on coffee to get through 2 days down under. In any case, you get Documenting with Tests