Voice of the DBA

Tag: DevOps

  • Sabotage at Work

    I caught a link to the OSS’s Simple Sabotage Field Manual from David Perell. It was written as a guide to destroying organizations during WWII to be distributed to citizens of enemy states. The OSS later became the CIA, but their goal was to find ways to disrupt the governments of enemy states.

    What was surprising to me was that some of the advice seemed to still be in use in places I worked in my career. Such as the advice for managers: ” To lower morale and production, be pleasant to inefficient workers; give them undeserved promotions. Discriminate against efficient workers; complain unjustly about their work.”

    This might seem to be human behavior, and it is, but it also destroys organizations. Too many people in authority don’t seem to do a good job of evaluating those that perform well and drive our software forward. While I do think this is subjective, often the group view from workers and the managerial view of who is efficient can be quite different. Being transparent and open with expectations and evaluations can help here.

    Working in committees and large groups is all too common, at least in US organizations. We hold meetings and have discussions with large groups instead of making decisions. I do agree with getting opinions from a large group, but discussions should be relatively short and then decisions made. We don’t want a dictatorship nor a large democracy of debate, but something in between.

    Maybe one of the more interesting ideas is the work slowly. I don’t know of many workers that want to work slow. Some do, and sometimes we all struggle to get things done, but so often management doesn’t want to invest in tools for workers. Tools can make a job much easier, and much more efficient. Part of DevOps is learning to use tools and become better. Or fabricate your own tools, something we can do in software easily. Too many managers don’t want to budget time or money or build or buy tools.

    It’s easy to self sabotage ourselves, and too often, it’s easy for managers to destroy an organization from within. This might be an interesting manual to review in a meeting and debate if our rules, protocols, and decisions are helping or hurting our organization. Unfortunately, too many managers aren’t willing to perform that self-evaluation.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Teams That Ship

    These days there is pressure on many software development teams to ship software more often. With the growth of DevOps and the numerous stories about companies that update their applications regularly, more managers are putting pressure on their development teams to perform. This can be a challenge as the culture changes needed to alter the way we work and achieve frequent updates are difficult to achieve.

    I saw a post from an entrepenuer, Naval Ravikant, on building a team that will ship software. This is advice for a startup, which often has different goals, challenges, and structure than more mature teams. Certainly I’ve seen the way we’ve built software at a few employers change. Even at Redgate Software, what we do to build software wouldn’t the same as what we did as a small company with 10 people.

    As I read the list, I can imagine why some of this advice is there. The need to push forward and get software working and in front of customers is strong. Sales, marketing, and certainly the users of the application want to see things move forward, features added, bugs fixed, and a reason that someone will pay money for the software. This rapid pace requires some decentralization, some lack of control, and trust in your developers.

    However, at some point this isn’t the model that a more mature organization needs. While we do want people that get work done in small teams at Redgate, we’re also more mature. Allowing developers to work on whatever they want isn’t in our best interest, and it could mean some products wouldn’t get any attention. We also have somewhat large codebases, so a person per project isn’t ideal. In fact, we often get code done in groups.

    I think I might be more inclined to adapt some of these goals with a startup, and certainly in a PoC or early access/beta product. However, once clients are invested and paying, I think a little more coordination and collaboration is likely needed. Not a lot, but a little.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Power of Git–Getting Code

    I find git to be incredibly useful, and this is a quick example of one of the ways that this matters to me.

    This post is also available in video format here: https://youtu.be/Drwt6nseeJM

    I got this link from Jes Pomfret for a Jupyter notebook she’d built: https://github.com/jpomfret/demos/blob/master/Notebooks/dbatoolsMorningChecklist.ipynb

    I see this on GitHub, but this isn’t easy to download, though this could have just been a file share.

    2020-03-25 10_47_31-Window

    However, since it’s on Github, I can easily get this as a copy of code that stays updated. To do this, I’ll copy, or “clone” the code to my machine.

    First, I go to the root of the repository, which is really a folder of code. This is the “demos” repo in this case (https://github.com/jpomfret/demos)

    2020-03-25 10_48_20-Window

    There’s a large green button on the right, that is the Clone button. Click the clone button and copy the URL.

    2020-03-25 10_48_41-Window

    I’ll do this in a cmd prompt, though you could use the open in GitHub desktop, or any git client. I prefer the cmdline, because this is really how I learn and get used to doing automation. GUI tools make this easy, but the cmdline is what I want to remain familiar with for DevOps. I can clone this with easy code:

    git clone https://github.com/jpomfret/demos.git

    You can see the results here.

    2020-03-25 10_49_57-Window

    I have all this code now on my machine. I can open this notebook in Azure Data Studio (ADS). Here I’ve picked “Open File” in ADS and browsed to the folder.

    2020-03-25 10_50_39-Window

    And I see the notebook.

    2020-03-25 10_50_45-Window

    If I don’t like this, or want to get rid of it, I delete the folder.

    rmdir demos /s

    And the code is gone.

    2020-03-25 10_51_35-Window

    There’s more to this, because I can keep the code up to date with Jes’ changes or even copy the code to my own workspace on Github and keep it up to date there with my machines, or share with others.

    There’s a lot of power to Git, and you can easily get started by doing what I did here and testing Jes’ notebook. Install git today and try this out for yourself.

  • A Data Controversy

    Quite a bit has changed since this article about airlines and the US government.  Since very few people are flying, or even can fly, perhaps this disagreement is moot, but I bet it comes up again. Now, separate from the idea of the actual disagreement here, there is an interesting discussion about the data involved here. In short, the US government wants airlines to collect data about passengers to help track the COVID-19 virus. Airline executives say they can’t easily get this data, other than on paper, without spending a few months on development.

    Certainly having a way to gather additional information in a digital form can require some development work. There are all sorts of software decisions to be made about when, where, and how users might input information. We have mobile devices, kiosks, laptops, and more, all of which might require separate interfaces for software changes. There is also the testing, validation, and verification we want to ensure the software works well and doesn’t introduce instability.

    In today’s world, with growing legislation, there is also a question of privacy. These requests may or may not conflict with other laws that airlines are bound by. There is likely to be more conflict here as the world changes and laws are slow to change and converge in some type of consistency. Rapidly changing requirements, as have been pushed during the COVID-19 pandemic, can potentially put us technical people in a difficult position. We have to balance the urgency of meeting requirements with the potential liability of violating privacy. I’d hope we could find some balance there, especially in a crisis.

    We do need to be flexible and ready to adapt to changing requirements. If regulations change, our organizations ought to be able to prioritize these changes and rapidly deploy them. In today’s world, where many high performing DevOps companies can get new software out in hours or days, governments may expect large companies to be prepared to follow suit. In that case, especially where new data is needed, having a software development process that includes the database is critical.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.