Voice of the DBA

Tag: software development

  • UX Matters

    When I was early in my career, VB v4 was popular, and easy. So many basic apps were built by not only software developers, but people in other departments with an interest in programming. Through VB v6, I found so many apps being built, often with complex and un-intuitive interfaces.

    I was reminded of these apps when I saw a story about a mistake made by Citibank. Apparently an employee was supposed to send interest payments of US$7.8mm to creditors, however, the employee paid $500mm to Revlon, the entire amount of the loan. A mistake, and one for which Citibank is likely liable.

    Apparently there was a UI (user interface) issue. If you read the article, you’ll see a bad user interface, and one that is confusing. If you use this application regularly, it not be a big deal, but staff changes, and having useful UI matters. As I get older, and use more and more software applications, I really see the value in UI being well designed.

    Most of us data professionals tend to work with our tools, some of which are well designed, some not, but often we’re in a code editor, so we might not care as much. Writing code is code, though many of us do appreciate add-ins or extras that make it easy to organize our code.

    I do think for administrators, or anyone that is looking at the status for their systems, good UI helps. Even if you deal with just data and text, having things displayed in an easy to understand format is important. This is also certainly true for most end users of software.

    I’m not a UI/UX (user experience) person, but I know people that I can all for questions or hire for their experience. Over time, I’ve learned that paying attention to the UI/UX can make the difference between customers really enjoying what you’ve done and them feeling that you haven’t really finished your product. I’m sure that Citibank, and many other large orgs, might be re-thinking the emphasis, or lack thereof, they place on this part of software development after hearing about this story.

    Steve Jones

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

  • Do it. Try it. Fix it.

    “Do it. Try it. Fix it.” – Sam Walton

    That quote is interesting, and while I don’t think Sam Walton was thinking about software, this is the loop that I, and many others, follow. We see a problem, and we try some things. If they work, we move on, if not, we fix things.  At least, that’s the approach most of us would like to take when we see an issue. Sometimes management gets in the way of us following a simple process.

    The key part of that quote is the first part, the part Sam Walton talked about was acting in some way. Doing something, making a positive move towards improving something. Many of us want to take action, especially when we see a problem. Again, however, management can get in the way if the problem isn’t prioritized.

    There’s one part in DevOps and software development that comes after the “fix it.”. We need to ensure we don’t repeat that type of mistake. This means that when we find a solution, especially a better pattern of building something, we share it. We use the feedback loops and learning ideas in DevOps to ensure others in our organization don’t need to do their own “Do it. Try it, Fix it” loop and repeat our work.

    One of the hardest things to convince smart (or very busy) developers to do is change their work habits and patterns to implement something new. While it can slow things down, or create other work, in the long, or even medium term, we can all be more productive if we take the time to share what we’ve learned. We also need to take the time to learn what others share.

    Of course, proving your way is better can be a challenge. You need to be sure of yourself, gather evidence, and learn to present a convincing reason why someone else should change. If you can do that, you will have more success.

    Steve Jones

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

  • Live versus Stored Data

    I’ve been working with various technologies as experiments over the last few years. I’m curious how useful I find them, as well as how they might help the clients and customers I run into at Redgate Software.

    I think Jupyter notebooks are a technology that has a lot of promise, and their use is growing in many organizations. One of the interesting things with notebooks is they can store results inside them, which allows a transfer of information in an interesting fashion. If I re-run a cell, the results can change and comparing them is challenging, but that is a separate issue. At least I can capture the results and share them.

    I’ve also been working with Power BI at times. I saw a demo of a query from PBI to Excel, where the data was then stored in the PBIX file. This query was disconnected, but it could be refreshed. You can also configure how this works, so you get the choice of live or stored data.

    If you are distributing information to users, those of us in the database world often think about having live data available and queried from a database, but often the same data gets queried over and over, which creates a load on our system. I know the data is often cached in these situations, but cache is a previous resource, so limiting the repeat queries can be valuable.

    I do think this is a decision point for some applications, where we might choose to limit the amount of live data v stored data. There are times when speed matters more than having exact data, so cached or stored data works well. Sometimes the most current data is critical, and you need to query the database.

    How do you decide when you want a live connection to a database, and when stored data is acceptable. I don’t know that I have any rules, but I evaluate each situation and try to work with users to make a decision. I suspect most people do the same thing, but if you always use live data, let me know today.

    Steve Jones

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

  • The Devil is in the Details

    Some of us have run into perplexing technology  problems, where we had to dig deep into an application to solve a problem. We might need to work with our own staff, vendor support, perhaps even coordinate people across multiple different organizations. This can be even more challenging when we don’t have access into the internals of all the code.

    I ran across a neat story from Netflix, where an engineer had to dig into an issue with one of their partners. In this case, there were hardware and software components, and four different companies involved. The problem involved a playback issue, with deadlines and finger pointing over the issue.

    Eventually the root cause discovered was a thread level issue in the Android OS, but the tale of how the engineer asks questions, looks at good, sets up tests, and more is a good examine of how to dive into an issue. While many of us wouldn’t get involved in threads on the data platform, we do need to understand the code and use metrics and data to narrow down the issues. It’s certainly possible we could discover a bug, but most of my experience is that I’ve found a problem in developer code or insufficient hardware resources.

    The story is a nice read, and the final paragraph made me smile It had this quote: ” This story really exemplifies an aspect of my job I love:…” It’s always inspirational to find someone truly enjoying their job, and I find myself thinking about the things I love about my job, with problem solving being one of the best parts.

    Steve Jones

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