Category: Editorial

  • Searching for Answers Inside

    How easy is it for you to search your codebase, especially across projects, and find out if there are dependencies, similar code solutions, or even other incidents of similar problems? Do you feel comfortable that you can find out what you need to know across and throughout your organization?

    Or is it cumbersome for you and others?

    In the 2019 State of DevOps report, one of the important areas that designated high and elite performers was their likelihood to easily find internal information. Those users were more productive when using internal sources of information to find knowledge related to their work. They also know how to, and are able to use external sources as well. I certainly know that if I needed to write T-SQL everyday, having access to the SQLServerCentral forums would be invaluable for me, and I’m sure it is for many of you as well.

    I think one of the very hard things for inexperienced people in any organization to do is find information. So often knowledge is gained over time by employees that have spent significant amounts of time working on systems. No matter how much we might preach and mandate documenting things, many items won’t be written down. Over time, many of us internalize lots of information that might seem obvious and unimportant to us, but is necessary for more inexperienced people to succeed at different tasks. If you doubt this, just look at any DR test where someone tries to follow the directions written by experienced pros. They’ll fail almost every time because we don’t document every step.

    I’m not sure we should even try. I think the idea of trying to help others more easily find information is a better solution. Having tools to enable this can certainly help new people get up to speed quickly, as can group programming (or administration) efforts like pairing or mob style work. We might not easily ensure someone could pick up the pieces if no staff were around, we can make it easier for those that want to learn and succeed to seek out the knowledge they need.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • 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.