At Redgate Software, we've been looking to "level up" our internal security game. While we have had very good security during the 16 years I've been there, there have been a few security issues with our products. The speed at which we address things, as well as the communications with customers, has impressed me.

We've had almost no problems with our internal systems, unlike a few other places I've worked. We haven't had the phishing/virus/breach/ransomware issues that I've seen at other employers or heard about from friends. I do think our IT staff is diligent and careful, as well as forward-thinking. It also helps that we've had a relatively small employee staff that worked in physical offices for most of our existence.

Read the rest of Practicing (Annoying) Better Security

Early in my career as a developer, I was required to follow a formal process to get the code I'd written deployed to production environments. Each time I'd written code, I had to document what I'd tested and then print out the relevant sections of the codebase. I needed to find two other developers to spend 10-15 minutes with me in a meeting, going over my code, each of us with our own paper copy. Almost like a dissertation, I had to answer questions and defend my work, with problems being marked on paper for me to go fix.

Over time, I learned that different developers reviewed code in different ways. Some spent more time on standards and formatting. Naming and the visual structure were more important to them, so if I wasn't confident in my work, I'd pick them and spend time ensuring the formatting was correct. Or sometimes, I'd mis-format it, so they would tell me to go fix that and not look at what the code actually did. Others were better at examining algorithms, and I often used them to help me learn, with them digging into my logic and helping me understand whether I'd included enough error handling, considered edge cases, or written code that performed well.

Read the rest of The Code Review Checklist

I was working with a customer recently and they said they didn't want to set up a pipeline. Somehow they wanted magically to see changes that developers made to their database appear in their production database without making any effort to build or configure a pipeline in a tool like Octopus Deploy.

As I was thinking about how to find them a solution they would accept, I realized that I've always had a pipeline for software. Early on, this was a copy of all the files in a folder sent to the client for Clipper and dBase apps. Later, my pipeline was copying around all the VB6 files from a .zip file and executing a few SQL scripts that were sent to me in emails.

Read the rest of You Always Have a Software Pipeline

I was browsing online the other day during a break and stumbled upon an article on the modern architecture stack for a startup. It's not a bad read, and as someone who's worked in startups, it's interesting to see what others think. As with many of these articles, it has a lot of practical advice, and it's also not relevant for many of us because we don't often work in greenfield development.

However, we could view adding something new to our application as greenfield. It's not completely the same, but there are similarities when we start a new feature that doesn't exist anywhere. Some of their advice, like docker-izing everything, won't apply, but there is one thing that does apply: data.

Read the rest of Modern Development

Over the years I've had the chance to work in a lot of companies, and I've seen a lot of different team-building attempts take place. In restaurants, these were often nights out with too many adult beverages. At a power station, we had some large outdoor BBQs, where again, sometimes there were too many adult drinks consumed.

When I came to Denver, I worked in a company that had a small fund they used for team outings once a quarter. A movie, bowling, maybe a meal, usually during an extended lunch hour or an early end to the day. At Redgate, we have a Feel-Good-Fund in each office and teams can make use of this for an activity periodically where they engage in something together. I rarely get to participate because I'm so remote and it makes me a little sad, since I see pictures on Slack of escape rooms, punting (boating), visiting museums, archery competitions, and more. However, we have taken the time to do a few things when Grant, Ryan, and I get together. Most recently, we went to a science museum in Cambridge one afternoon.

Read the rest of Building Bonds with Entertainment

One of the things that happens with many companies that start adopting DevOps is that they release new features constantly. They publish their lists of changes, and they try to attract customers and grow their businesses. They may make some mistakes, but they fix those quickly and keep pushing forward. That's the idea, and it works well.

However, many of the developers (and most managers), don't think about the security side of their changes. This piece looks at the way hackers and criminals view DevOps, often using release notes and feature changes as a target to focus their efforts. In this way, they exploit holes and vulnerabilities in software to attack data storage. The examples include S3 buckets of storage and Elasticsearch, which is notoriously poorly secured by many people.

Read the rest of The Need for DevSecOps

There was a failure recently at an Azure data center in Australia when a utility power sag caused equipment to trip offline at one of the Azure data centers in Australia. You can read about it here, but essentially the headline is that there were only three people on site when the incident occurred, and that caused them to be unable to restart the equipment in time.

In a little more detail, there weren't enough people to quickly restart the equipment chillers after the incident. The staff had to access the equipment on a roof when 13 of the units didn't restart. They were able to get to 8, but when they got to the last 5, the temperature of the water had risen to a level that wouldn't allow a restart. So they had to power down some computer equipment and go through a more lengthy process to get everything running.

Read the rest of A Staffing Disaster

Many of us work for some organization and we're responsible for managing a database or coding some application or some other data related position. Perhaps we ensure reports work for our users or move data around. In many cases, we have customers, whether they are internal to our organization or perhaps external from another business or even the wider public.

However, many of us see our jobs as a part of the org/business and not that we are actually providing some service to others that we are responsible for. While I've certainly felt that way, I learned at some point that if I were an app dev, I ought to treat people using my app as customers, even though they don't pay me in currency. They often pay me in praise, or better yet, with praise to my boss. As a DBA, I treated both app devs and users as customers. That helped me take pride in my work and learn to view my position from other points of view.

Read the rest of Running a Service

The AI revolution is happening. I don't know how successful it will be, but regardless, people are trying to get AI into everything. That might be good or bad in various situations, but it has people worried about AI. This piece looks at a survey from the American Staffing Association that says 47% of people somewhat or strongly agree that their job is replaceable by automation with an AI. There is more data to dig into, but that's a lot of people who worry about their jobs.

Most people do think that tech is generally a good thing. I do find that many of us in tech, and some other industries, are buried in work. There's never a shortage and we could easily work 60, 70, or more hours a week and not complete everything. The flip side of that is a lot of work doesn't necessarily need to be done now and could be delayed, so I think it's hard to decide whether we need more help or more patience.

Read the rest of Are You Worried About AI?

There's a great scene in Field of Dreams where James Earl Jones says that people will come. It's in response to the voices Kevin Costner hears early in the movie. This is the climax of the movie, where Costner makes a financial decision to trust his instincts and hope his farm will be saved.

In many cases, organizations do just this. They build something, assuming people will come. They may have some data, research, or other reasoning as to why why people will use what they build. However, that's not always the case. Sometimes they build something and hope people will come, much like Field of Dreams.

Read the rest of If You Build It, Will They Use Linux?