Voice of the DBA

Category: Editorial

  • It’s Natural to Avoid Problems

    The hardest part of transforming to a lean, efficient process is the culture change necessary to get a team to work together. It doesn’t matter if the team builds software or vehicles, the change to working in a new way, into disclosing problems, admitting issues, working without blame to fix them, these are very, very difficult changes to make.

    Dr. Edward Deming and his work with the Japanese have been the source of many ideas on how to improve a manufacturing process and increase quality. The ideas and principles are incorporated into The Goal, a novel that inspired The Phoenix Project. I recommend both those books for people interested in DevOps because building software is very similar to the manufacturing process used for other goods.

    Toyota has been one of the leaders of quality manufacturing and the Toyota Production System has been used as a model and adapted by many industries, including software. One of the ideas used in manufacturing is the ability of anyone to highlight potential problems. In car plants, this has been implemented with an andon cord, a way to stop production and have others help diagnose and solve a problem early in the process.

    Some have thought this is a culture issue where the Japanese might be more willing to highlight problems and work as a team, something that many Westerners have struggled to do. At the lean blog, they talk about how this isn’t the case. In fact, the Japanese, in general, seek harmony and might be less likely to raise potential issues. In fact, I think most workers are hesitant to raise potential issues, for a variety of reasons. Often anything that slows down work is frowned upon by management, which often leads to issues lingering on, or substandard products being produced. This also happens in software.

    I might argue that changing culture for developers is hard, but even harder for managers. We often don’t train managers well, and certainly we don’t often have good systems for coordinating work between and among knowledge workers. The systems that help with manufacturing give us a base, but they don’t apply quite the same way when your “machinery” is another human. Culture change for DevOps must include management and that means less oversight and interruptions, blameless reviews, and embracing mistakes and small failures. Those are often very hard for managers but necessary if you want to improve your software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Unreliable Data Sensors

    I like data, and I like cars. I think there have been some really creative and useful integrations between the two. I also think there have been a lot of gimmicks and poorly architect-ed systems, including those that insecurely allow access to vehicular systems. I even worry (very slightly) about the integrations of networks in airplanes.

    The US NTSA has said no to cameras and displays in place of side view mirrors. These are on the new Audi e-tron SUV, and would use a camera and a display on the door to show the rear view. While this certainly might help mileage, and it could allow for technology to perhaps sharpen or identify something in the display, I also worry about a couple issues. If you want to know what this looks like, here’s a review that shows this.

    First, there is the safety issue. I find backup cameras, even very new clear ones, to be harder to look at than a rear view mirror. Granted, these do show a view the mirror can’t show, but I wouldn’t want to use these when I was moving at anything above a slow 5mph backup speed. The ability to gauge distance is much harder. I would worry that I’ve both look in the wrong place, and also struggle to see the display in some weather conditions. Not to mention potential dirt, water, etc. on the camera lens. Already my backup camera is often too dirty to use.

    The second issue, and this is the bigger one for me, is that this technology isn’t anywhere near reliable enough to use in this situation. While it might work well at any point in time, I find too many issues with advanced electronics in cars that fail more often and with a much higher cost. At just over 4 years, when the warranty in my current car expired, one of the cameras in the side mirror failed. While it doesn’t appear to be hard to fix this, it’s a an expensive part (US$400). And an annoying, albeit unimportant, error on the display.

    I’m all for new technology, and I think things like the lane change warning and other tools are fantastic. ABS and traction control are lifesavers. Backup cameras have saved me or others a few times. Adjusting mirrors and other responsive improvements are fantastic, though I certainly want to ensure these devices let me know if there is any failure. Others have been less exciting, like locks that don’t operate without power.

    We know there are issues with lots of data, and we know that sensor data also needs to be checked and verified, as well as occasionally discarded. Vehicles have dramatically opened up our world and given billions abilities to access goods and services they might never otherwise see. However, there are safety issues that should override any new technology that hasn’t proven itself not only to operate at a very high reliability level, but also in a way that operators can easily adapt to using.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Is Data the Future of the Vibrant Web?

    Data privacy is a fascinating subject. Since the GDPR was passed, I’ve had a lot of conversations with people about the GDPR and the way different people feel varies dramatically. Moreover, the way an individual feels often varies depending on the situation. I know plenty of people that want their own data completely private, but they also want no restrictions on what they do with data inside their organization. Others feel the exact opposite.

    One type of data that many people don’t think about is the cookie data that is used by Google and Facebook (among others) to track a user across many browsing sessions. This tracking is one reason that I see Redgate ads on a movie site or a new site. If I happened to search for SQL Compare, which I do sometimes to get a link, I might later see related ads on a site that has nothing to do with technology or SQL Server.

    Apple, Firefox, and Microsoft have been experimenting with ways to give you some tracking protection in your browser. This should allow less data about individuals being captured, stored, analyzed, and then it couldn’t get lost/stolen/hacked.

    Google has a different approach, and one that I think benefits them and their paying customers more than the rest of us. The idea is to have some sort of data cap for types of information, above which the browser would return generic information. Potentially it could return inaccurate information, but I can’t see that passing any sort of business relationship test with Google customers.

    The goals here are relevant ads, and of course, information about you in order to serve relevant ads. While I think this goal will be met, I’m not sure it’s much more private than the situation today.

    Data privacy means allowing users to decide what data a company, including a tracking company, is willing to share. The way browsers have changed in the last few decades is complex and confusing. I have no idea what information they track from my system(s), and I’m not sure I would even understand the implications of enabling certain rights. While most of us wouldn’t want to share our email, there are lots of other data that we might not be sure of the way it might be used.

    Like most of the data privacy issues, I have no idea what to do here. The issues are complex and confusing. I would hope that Google would remember its “do no evil” origins and help us increase our ability to keep data private.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Working in Smaller Teams

    I don’t know what the average size of a team is, but I know I’ve worked in all sizes in my career. I’ve had teams of 1-3, which is common in database work, but I’ve also been on a 20 person Ops team. I’ve been in 2 person development teams, 25 person teams, and everything in between. At Redgate, it seems most of our development teams are less than 10 people, but I’m sure we’ve exceeded that at times.

    I do think smaller teams are better, and they are certainly easier to keep track of what everyone else is doing. Once a team becomes large, even with regular status reports or meetings, there is too much information to easily hold in one’s memory about tasks other than our own. Knowing what others are working on can be invaluable in coordinating and avoiding conflicts. This also ensures that the team can more easily ensure code is written in a similar fashion and knowledge is easily shared.

    There is research that seems to indicate that smaller teams are better. This article talks about some of the reasons small teams seem to perform better. These all seem to intuitively make sense to me, and I’ve certainly experienced people behaving in these manners. In the second piece, there is advice on how to get teams to be more effective. The biggest advice seems to be a lot of what we do at Redgate. We empower teams, give them tools, and don’t manage them in traditional ways. We hold them accountable to get work done and meet goals, and we challenge them, but we want them to move forward, not work in a particular way.

    Building a team is hard, and getting a team to perform at a high level is very hard. I do think that the internal talent and motivations of individuals can make a big difference, but I also think that management can bring out the best in people, or it can ensure you never get anywhere near the potential of team and encourage under-performance.

    It constantly surprises me how often I find managers and their organizational culture built to control and not inspire employees to do their best. I think it’s a holdover of years of working a certain way, rather than supporting and encouraging each person supervising others to get the best from others. I hope this changes, but it’s certainly something I try to detect in interviews before I ever commit to a new position. I hate working for micromanagers and never want to do it again.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.