Voice of the DBA

Category: Editorial

  • Your User Manual

    Many of us have spent time looking through manuals or the documentation for some software or product. I know I’m on the MS docs site regularly for work, and there is no shortage of times I’ve used various manuals to help me fix something around the house. We usually use a manual when we want to learn how something is supposed to work, or how to get it to do what we want.

    I saw a post on a personal user manual that I thought was a good idea for some people, maybe many people. This isn’t a manual for how you should live your life or work, but rather, how others might interact with you. This manual describes how you work, what motivates you, stimulates you, what pleases you, and even the environment in which are most productive.

    Whether or not this is something you might give to co-workers (or your boss), it likely is a good exercise for you to undertake personally. I do think this might be something you give out, but only if you have a lot of confidence it will be taken seriously and well received. Just going through the process, however, might help you better understand yourself, and you might learn something about what matters to you. Sometimes the things we think we like or want aren’t really the things that actually make us happier or more productive. I know I enjoy traveling, but too much creates a lot of stress. I like speaking in front of an audience but within certain boundaries. I like running, but my joints and bones will tell me that I really can’t have that in my life anymore.

    I’m going to make a quick, outline of my manual here. I like independent work, creative work, and the chance to decide how to do things. I like to work with deadlines, but without micromanagement. I want to be at home much of the time but go to an office and other places to interact with people periodically and regularly. I like working asynchronously most of the time, but synchronous brainstorming sessions are valuable. I like feedback to be written overall and with some thought and reasoning behind it, not a like/dislike/emotional response to my behavior.

    I think I could better flesh out different ideas with more detail and organize things better, but I enjoyed taking five minutes and thinking about my first reactions. Now I need to go back and revise this draft with a little more insight and consideration.

    Let me know today what you would think your user manual should say.

    Steve Jones

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

  • When to Use Zero

    I’m not great at building charts and graphs. I can build a basic chart, but I often depend on the tooling I use to size, scale, etc. appropriately for whatever I’m graphing. That, or I just use a basic graph that starts from zero and has some sort of linear scale. Or I just present a table of numbers.

    There are plenty of misleading charts, especially used by the media that want to show some particular aspect of data that suits the story they are reporting. Many of these misleading charts often don’t start at zero, and they end up scaling in a way that can confuse people.

    You wouldn’t think it was hard to decide whether or not to scale a graph of data from zero or not, but it can be complicated, as this post shows. There is a flowchart to help you decide when to include zero, or even when to have an inset chart that better explains the data. As many of us know, it can be easy to misinterpret data, especially when someone else is deciding what to show.

    In this case, the post talks about some examples of when the data doesn’t graph well because the scale is too large and the range of data too small. Or when the scale distorts the relative size of two values in a graph. In all of the examples, it makes perfect sense why you do or do not include zero on your axis, but I don’t know that I know when I should or shouldn’t do this.

    Part of the problem for me is that people often glance at visualizations and charts without spending enough time to really study them. That’s part of the idea of a visual, in that we can get information quickly from a picture, as opposed to a chart of numbers. However, it is still easy to look at a broken scale or inset chart and not spend the time to comprehend that one value isn’t twice another, but instead realize the chart is zoomed in because the scale changed. There isn’t a perfect way to present information, but there are ways that might work better.

    To me, a lot of misunderstanding gets cleared up when we discuss the chart and the data in a group. Often one person will realize when others are not reading the scale when drawing their conclusions and remind others that Canada isn’t twice as large as Brazil. That works if people speak up and if others listen. That isn’t always the case, especially when the boss is making a mistake. The other issue is that many of us might look at a chart by ourselves. and we are unlikely to tell ourselves we are misreading the values.

    There isn’t a good way to ensure people read a scale and factor that into any decision they make regarding the chart. I do always like to include some data with a visual, that way I can see raw numbers on the same report, or by drilling in. The combination works well for me, but I’m a geeky, numbers person. I like seeing data, which is why I like working with databases.

    Steve Jones

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

  • Moving Away From MySQL

    I like SQL Server as a database. I think it’s very complete, solves most of my problems, and is easy to use in work. It costs money, but less than some others. It’s also more complete to me than some of the open source databases out there. That being said, I think most of the top five or six relational platforms would work for me and I wouldn’t hesitate to use them.

    I ran across a post from Steinar Gunderson, who worked at Oracle on the MySQL team. It’s on his last day there, and it’s a bit of a why did he leave. I like that he notes he found a better opportunity, but he digs in deeper. Why did he look for a new opportunity?

    The answer seems to be that MySQL was a shockingly primitive piece of software, according to him. He felt there was lots of room for improvement and change, but people seem to like and accept what MySQL is and does. He is proud of what he has done, but felt that this was a product that was vastly inferior to other database platforms.

    That’s interesting, because I think MySQL works fine and is in use in many situations. While there might be plenty of things that can be improved, I’m a practical guy. If the technology meets my needs, and those I can foresee, I see no reason to change. That being said, I wouldn’t reach for MySQL to start a project. If it wasn’t SQL Server, I’d lean towards PostgreSQL.

    There are a couple of examples in the post, and it’s certainly a good post to write on your last day. If you published it when it wasn’t your last day, it might quickly move in that direction.

    If you use MySQL, I’m curious what you think. If you don’t, would you if SQL Server weren’t available? Would you learn MySQL for a new job? Or are you a die-hard, this is my platform kind of person?

    Steve Jones

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

  • The Backlog

    Software development is complex these days. Maybe it’s always been complex, but the shorter timelines and greater vision of what is currently happening in development teams mean that we can see a lot is going on at any particular time. Really, once you get beyond a handful of developers, the coding changes look like a chaotic ballet that may (or may not) be in sync across developers. Modern work tracking tools make this easier, and for any particular developer, it isn’t too hard to look at a Kanban board linked to a git repository and track the changes that have taken place.

    There is always more work to tackle than can be done at the current moment, so it is important to add new tasks to a backlog. Building those, and tracking what is needed, is a bit of an art. What do you write down, how much detail, and what level of effort is needed. Paul Andrew wrote a good post on what makes a good backlog story, using an example from his work. He looks at the need for infrastructure in this case, but that would be a common request these days when DevOps and the cloud require some blurring of the line between code and the resources it runs on.

    I like the completeness of this request, and I do think this level of detail is important, with the inclusion of criteria to measure the work and test that it is done. I just don’t know if this is required when we add the work to a backlog. The rapid changes in our software, as we adapt and work with customers’ feedback, mean that we might get many more ideas (or issues) than we ever build. In fact, some requests/suggestions/desires that get sent to developers or project managers might be no longer needed or forgotten by the time they reach the coding stage. I know I’ve certainly requested some features at SQL Server Central that I later decide aren’t important or needed.

    My view is that ideas ought to be captured, and triage ought to include enough detail to estimate how important and hard the work may be. Once we get to the point of actually performing work, then we need to flesh out details on what constitutes done and what tests can verify this. For very small levels of work, this might be just a few light tests, but even noting that a new column is in a table and associated stored procedures can help developers remember to check for dependencies and avoid simple mistakes.

    Building software and managing the process across a team and over time is hard. It is easy to lose control, and it can be hard to make decisions about what to build and what to defer. A backlog is critical, and managing that backlog with regular review and attention to detail is important. However, just as we don’t necessarily want to prematurely optimize code, I also don’t know that we need to build out the complete story when someone has a request. Grow your stories as you grow you code with an agile approach over time.

    Steve Jones

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