Category: Editorial

  • How Important is Software?

    I have a mechanical gaming keyboard, not because I’m a gamer, but I did want to tactile, mechanical feel and I like the idea of lights on the keys. I’ve enjoyed the experience, but the software leaves something to be desired.

    I thought about my experience as I read this review of a more complex keyboard, with the title that notes it’s so pretty you can almost forgive the software. The poor UI and the complexity of operations, not to mention the splitting of the remap functions being unnecessarily complex. That was my experience as the only thing I cared about was remapping the home and end keys to the places I was used to them being on Logitech devices. I have spent a few hours across the last year learning how to map keys, and then relearning when my profile is lost in an upgrade or hardware glitch.

    How much does software matter to customers? I’d argue it is becoming more and more critical all the time. The experience of using hardware, or really any device or service, is impacted by the software that drives it. Software is eating the world, and I think we need to understand that better software design and quality is needed.

    I find that the most talented hardware companies sometimes have the worst software. It’s almost as if they assume their customers will be as talented as their hardware engineers and don’t spent enough time understanding how to better design a user experience for their products. Keyboards, routers, motherboards, and more often use archaic, confusing methods to have customers configure or update the systems.

    I know UX is hard. This isn’t even about graphics or visual appeal. In many cases, it’s about just better understanding of how others view the process and what information they take from what appears on the screen. Over the years I’ve learned that this is not only hard, but also that it takes time and debate, just like features do. I enjoy these moments, and I like to think that I help my employer produce better software for our customers with my feedback.

    I urge developers to have others look at what they present on the screen, and spend time learning from users, both experienced and novice. We often forget how something appears to others when we look at it every day and rush through workflows as we test our latest code. It’s easy to gloss over daily changes as minor when the sum of all changes can be a jarring experience for our users after an install or upgrade. UX is important, and it’s worth putting effort into our software designs, our data models, even the metadata we expose to others.

    Steve Jones

  • Cloud Databases

    Most of us are used to a database that lives on a server somewhere. It might be in our data center or a VM that exists somewhere, but it’s really an on-premises type of infrastructure. Even if the VM is in AWS or Azure, this is a single system on a server that we control. We can add HA capabilities to this system, but the model is the same as if the database were on our development workstation.

    Note: this doesn’t matter if this is an RDBMS like SQL Server or PostgreSQL or a NoSQL type system, such as MongoDB or Neo4J.

    That’s a comfortable system, and it’s how we’ve built many applications over the years that support our business processes. Many of us default to architecting and thinking about our applications with this model.

    These days there are cloud databases, which can be used in this model, but which also have other capabilities. I ran across a piece that noted cloud databases ought to be a part of our modern tech stack, and I tend to agree. These days the need to be more flexible, available, and secure are important for applications. An on-premises database might not meet these needs.

    A cloud database is typically a system designed to be more of a PaaS service, with replication, built-in HA, scaling, and more. Azure SQL Database might be considered cloud-native, but I think it lacks some of the features that we might take advantage of in CosmosDB, Couchbase, or CockroachDB. Things like the availability from various types of connections, quick and easy failover and sync from different regions around the world, and low latency for users anywhere.

    A few examples are in the article, and I see these types of requirements coming about more and more often as our clients start connecting from different devices in different locales, and at scales that are harder to handle with a single on-premises (or clustered) database system. While you might be able to handle the workload, is it worth it for you to manage some of the infrastructure and administration that a cloud vendor can do instead?

    That is why I think you ought to learn about and understand where a cloud database might be useful. While not all of us have clients all over the world needing real-time access from various devices and applications, we might grow into that need. Whether it’s clients that are employees or customers, there are increasing demands for flexible ways to handle the growing workloads on our databases. You want to be prepared for when you might exceed the capabilities of the platform you’re used to,  that way you can decide when adopting a cloud database might make sense.

    Steve Jones

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

  • Republish: The Right Connection

    Today I am on holiday. My last day in Venice, Italy with my wife, so you get to re-read The Right Connection

  • The Communication Channels at Work

    Recently a friend started a new job that didn’t have Slack used as a communication vehicle. The new employer was considering Teams, but most of the communication among employees was done through email or a live meeting.

    At Redgate, we use Slack extensively. I also use Teams for some work with Microsoft, and in general, I find I prefer Slack. That might be because I don’t spend enough time in Teams, but regardless, I find myself preferring email for discussions with MS employees over Teams. That’s my preference, but really, what I value is the instantaneous, yet async, nature of using messaging tools over email.

    I think one of the reasons I like tools like Slack is the separation of topics into various threads based on some subject. We have more channels at Redgate than people, but this is because there are different needs. For example, there are a few different “ask” channels. One is for advocates (Grant and I), one for tech questions, one for licensing, one for each country, and one populated by queries coming in from customers. We have a public channel for each product, as well as one or more private team channels for their daily work. We have automated channels updated by releases and deployments, and we create quick channels when there is a sales discussion or internal issue to keep our conversations focused on an issue.

    Perhaps focus is the real reason that I find these messaging tools handy. If everyone is online, we can have a real-time discussion. If people are not available, we can leave a message and hope they see it later. The one downside I’ve learned is that I can’t assume someone has read a message if they don’t reply or leave a reaction. If I do need someone, I message them in some other way to ask them to look at something in Slack.

    I also extensively use messaging options on Linked In, Twitter, Facebook, and other platforms as well. While I do find email nice for many things, there are a lot of short exchanges that work well in another format. Email tends to work better for me when there is a need for more than a couple of replies and we need to keep track of the discussion. A fast-flowing stream of messages in Slack or Teams can be hard to sort through after a few days.

    In some sense, I miss the old days of walking to someone’s desk or calling a short meeting and having a discussion. I still take those opportunities when they present themselves, but most of my communication takes place electronically, and messaging dominates.

    Do you feel the same way? Does your company or team use messaging tools? Are they handy? How do you decide where to post things, and is there a good separation of topics and subjects for you? Let me know today.

    Steve Jones

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