Voice of the DBA

Category: Editorial

  • Coaching the Digital Transformation

    One of the challenges for me when working with customers is getting them to think about how to change their software process. Often they want to solve their problems, but no one wants to alter the way they work. Whether that’s the protocol for capturing code or managing servers, it seems that changing the way we work is hard for many people. They want everyone else to change. Or they want a magic tool that solves problems without them changing the way they work.

    Unfortunately, I’m not a magician.

    This is a common problem in many organizations. We want to be more efficient and effective, but actually changing our habits and culture is hard. Management should lead the charge, and they want to, but they can struggle with how to do this. Often they focus on changing technology, and not actually improving the way their company works.

    There’s an interesting article on digital transformations and whether the efforts are worth the investment.  In many companies, someone makes a good argument for a course of action or a project and then drives it. Others participate, but often a person pushes this forward, usually because they have some stake in the outcome. A bonus, a reputation, or just pride, whatever matters to them becomes the reason for continuing, even if there isn’t enough value from the effort. This can be because of an institutional culture that wants to finish projects, wants to find some success in a course of action. Whether a human or an organization, pride and inertia often keep us moving forward, often without any other support or analysis of how well things are progressing.

    Effective dashboards enable everyone to see current status and progress, and to make better course corrections, helping to move from a command-and-control model to a coach-and-communication orientation. Many organizations have adopted KPIs, dashboards, and other ways to analyze parts of the business, but this isn’t always something we do well in software development. We tend to look at metrics that management cares about, and on which we are measured, rather than metrics that might help us improve how we work.

    Part of digitally transforming a business is also transforming how technology is used. Part of that is us, as technologists, learning to be better and more effective. Whether this is in development or operations, we can often improve how we function. We need coaching, and in many orgs, that coaching has to come from within, from the people in a team asking others to do better. And to allow others to ask us to do better .

    Coaching is often teaching from a different perspective. It’s helping someone see what they don’t see themselves. This might be new knowledge, but many times it’s just reminding the individual of something they know, but aren’t doing. As we are asked to do more, be open to coaching and be willing to help coach others. Become a role model that helps transform how your organization uses technology.

    Steve Jones

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

  • Outsourcing Operations

    When I first started working in technology in the 90s, it was a time of outsourcing lots of work overseas. Many large companies followed the wave of manufacturing in the 70s and 80s by many companies, including lots of semi-conductor manufacturers. I watched as a number of jobs moved overseas, though fortunately not mine.

    In the early 2000s, I worked at a company as a manager, where I was involved in some of the discussions about outsourcing a lot of our IT operations to another company. It was a scary time for my friends, as the move would have left a lot of them looking for work. The CIO tried to say that many would get jobs with the outsourcing supplier, but couldn’t say how many.

    I commented in a meeting that it would have to be less than 100% of people for there to be any profit. That statement ensured I needed to look for a new position, which I happily did. The company didn’t outsource at that point, but being involved in the discussions helped me realize how different management and workers often view the business of IT.

    There was an article on when to outsource, which talks about the benefits and drawbacks. For most of the benefits, the reasons why you do this are very similar to why you might move infrastructure to the cloud. There is speed and flexibility, as well as simpler internal operations, when another organization handles those functions. The downsides are that your organization needs to manage another, and you might not have the control you desire.

    The same thing you could say about the cloud.

    The costs could be lower, with outsourcing or the cloud, if you can reduce unnecessary resources. That can be hard to do internally, especially as you hire staff. Each additional person might be necessary in the short term, but if when they are no longer producing a positive ROI, it can be hard to get rid of them. Consequently, with an outsourced company, often contracts dictate the staffing levels, and those contracts aren’t amended or renegotiated often. That could leave you with lacking services you need or paying for those you don’t.

    I don’t know that it’s easy to decide when to outsource. My view has often been to keep some level of in-house staff, but augment them with some sort of managed service provider that can provide additional resources when you get busy. Whether this is a DBA service, like https://dallasdbas.com/, or a development effort, like Crafting Bytes, adding staff in limited quantities is often the best way to move forward.

    These smaller groups also provide opportunities for some of you that might want to find a different type of employment arrangement. Usually more flexibility, a warm, friendly atmosphere, and the chance to grow with a small business.

    Outsourcing might sound like a bad idea to many corporate employees, but it does provide opportunities for you. Keep working on your skills, network with others, showcase some knowledge with a blog/article/speaking slot, and you might hedge your bets in the event your employer makes a decision about outsourcing that doesn’t work for you.

    Steve Jones

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

  • Coding Magic Values

    It’s 2023. I would hope all software developers would learn that hard coding specific values in your system is more likely to cause issues than not. Across the years, we’ve learned not everything is installed on the c: drive, or that not everyone wants to put all data in a Documents folder (or in OneDrive). We’ve learned that any sort of magic number is poor practice, and we ought to know that hard-coded names are problematic as well.

    Yet, we still see it happening.

    This week I was reading about an admin issue in the Microsoft TechCommunity. This is related to Azure Managed Instance, but it’s really an In-Memory OLTP issue. That was introduced in SQL Server 2014, so I know the code for this was likely written in the 2011-2013 timeframe, but how can this type of issue get through code review and be released?

    In this case, the name of a filegroup is set specifically to XTP. It’s a logical name, and I’m sure that some developer thought that things might be faster with a known location. That doesn’t make sense, and while this might not be an issue for most customers, I’m sure there have been some databases built with a filegroup called XTP. After all, there are companies named XTP. What about if this feature evolves to allow a second filegroup, maybe because of some distributed architecture need in the future? Are there then code paths looking for XTP or XTP2?

    As much as possible, avoid coding values in your code that a user might enter as data. Names, paths, etc. Just don’t do it. Use variables, which are in every language, and let those values be read from the environment. This ensures that you don’t end up with weird support requests from customers because they chose the same value you did.

    Steve Jones

  • The Senior Advantage

    The senior advantage means more to me all the time, though often I feel there are more disadvantages to being around longer than advantages. Getting older is hard, especially physically, and I struggle with that. Having more wisdom, more tolerance, and more patience, are good things, but I’m not sure I would consciously make that trade.

    In a business, senior often equates to more experience and time working on systems. Sometimes it means more skill as well, but usually, the internal knowledge of how our systems work inside of our environment is more valuable, even though it can be hard to get management to realize that fact.

    The last two years have had many technology workers at home, doing the same work they did in an office. Over the last year, there has been contention between some managers that want people to return to the office and many workers that want to remain remote. While lots of people don’t have a choice, there are some who do, and they are often the senior, skilled people. Lots of them quit, which creates a challenge for managers to fill their slots.

    One would think that management would work to retain and keep more employees, but in some cases, the response is to find ways to make it easier to hire new people. One positive thing that happened is the relaxation of the rule for tech workers to have a college degree. That’s good for many people that are talented and don’t want to spend tens (or hundreds) of thousands of dollars on a degree. A little disheartening to me and others who think that this further devalues the experience of current employees.

    There are some great employers out there, as well as some great managers that care about their staff. My company is one of them, and I appreciate how we run the business effectively while treating employees fairly. However, there is no shortage of poor employers who do not care much about their people, their training (or re-skilling), or whether staff leaves. They will continue to lean on whoever is still employed while replacing staff with cheaper, and less knowledgeable, new hires.

    In thirty years, the one thing I’ve learned is that I need to be responsible for my own career. That means learning often, working on my tech skills, polishing soft skills, and burning no bridges. I need to be prepared and ensure I have opportunities and choices in the future.

    That’s my senior advantage.

    Steve Jones

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