What is the end goal for automation and AI?

I’ve been a big proponent of automation over the years. I recognise that automation will cause the loss of some jobs, but I’ve always assumed people would move on to other things. A consistent theme of mine was, why waste humans on mundane work when they could do something of more value?

I recently read The Naked Sun by Isaac Asimov and now I feel rather uneasy about automation and AI…

I don’t want to give too much of the story away, but we are told fairly early that the planet Solaria only has 20,000 humans, and millions of robots. The robots do everything as far as the economy is concerned, and the humans are essentially idle custodians. Rather than having millions of people doing a variety of occupations, there are only the elite sitting at the top of the pile…

As I was reading this I was thinking about the economic elite on our planet and I started to feel some concern. My dream of a post-scarcity society is one where we are all equal, but I can’t imagine there are many people at the top that want to be equal. They would always want to be more than equal. Call me a pessimist, but when I think of Elon Musk calling himself the emperor of Mars, I wonder if a future post-scarcity society will be less like Star Trek, and more like Solaria…

Of course, the AI could just turn into Skynet and kill us all, but I have this feeling that greedy humans using AI and automation against the majority of the population poses the greater threat. Why have “them and us”, if there could just be “us”? 🙁

All of a sudden automation has lost some of its lustre…

Cheers

Tim…

HP-UX and Oracle 11g : Don’t let the door hit you on ass on the way out…

We had a pretty momentous occasion recently. We finally got rid of the last of our HP-UX servers, and with it the last of our Oracle 11g databases and Oracle Forms apps.

We use VMware virtual machines running Oracle Linux for nearly all our databases. We pushed really hard over the last couple of years to get everything migrated to 19c. Despite this, there were two projects that were left behind on HP-UX and Oracle 11g. They were effectively dead projects, from the time before we moved to Oracle Cloud Apps, about 5 years ago. We couldn’t get rid of them because people wanted to look at the historical data, but there was very little appetite to do anything with them…

Finally, over the last year we’ve had an archive project running, which involved moving the databases on to Oracle Linux and upgrading to 19c. That bit was easy. The other bit of the project involved building two new APEX apps to replace a 3rd party application and an old Oracle Forms 11g app. Those went live a few months ago, but there was still a lot of reluctance to actually decommission the old systems.

Recently we finally got the approval to turn off the old systems, and decommission the old HP-UX kit. When the change went through the Change Advisory Board (CAB) it was such a relief…

The kit is now decommissioned, and I’ve just been clearing the agents out of Cloud Control, so it’s finally over. No more HP-UX. No more Oracle 11g. No more Oracle Forms…

Now all we have to do is replace a whole load of Oracle Linux 7 servers, and get ready to upgrade to the next long term release of the database… 🙂

Cheers

Tim…

Search Trends and Oracle

Please read the update before jumping to any conclusions. 🙂

I was chatting with some folks the other day and the question was raised about if we had seen a decline in our website activity. Since the vast majority of my website traffic comes from Google searches, I figured the obvious thing to do was to look at what is happening on Google Trends in terms of search terms. That way we were not focusing on the popularity of a specific site, but on searches in general. That resulted in this rather alarming graph showing a trend over the last 20 years.

I guess we all thought this decline was at the expense of another engine, so our obvious next thought was to compare against the other relational database engines. One of the guys suggested we also compare the word “database” as well, just to see. This is the resulting graph.

It should be noted we tried variations on “sql server” and “postgresql”, but they didn’t affect the searches. Feel free to try for yourself. 🙂

So the decline in searches was not restricted to Oracle. You may notice this is related to “All Categories” of search, and the word “oracle” is not specific to the database, so I tried in “Computers & Electronics”, and we got a similar result.

For subsequent searches I switched back to “All Categories”.

If we switch to the last 5 years, things seem to have levelled off somewhat.

So the next question was if NoSQL databases were eating into the relational database market. A straight search looked interesting.

But what happens when we add Oracle back into the mix. Does the rise in popularity of some NoSQL databases account for the drop in searches for relational databases?

It doesn’t look like it. The gains in some NoSQL databases are insignificant compared to the reductions in searches for relational databases.

So we are left with a question. Why is there a drop off in searches for relational databases, when there doesn’t seem to be a corresponding uptick in alternatives?

Update : So what is really going on?

The graphs are not absolute search numbers, but normalised compared to the total Google searches that happened. Back in the day only geeks were Googling, so tech searches were a comparatively high percentage. Now everyone is Googling, the proportion of tech searches is much lower compared to the random stuff. Check out the FAQ about Google Trends data. So in our case, the trend over time of an individual term is not so important as the comparison between two search terms over time, as both should be affected in a similar way by the normalisation…

What we can see is over time the searches for different relational engines have got closer. If we are using the number of searches as a proxy for popularity, then it seems it’s a much closer game now than before.

Cheers

Tim…

PS. Thanks to the folks that pointed me in the right direction about Google Trends.

PPS. I noticed the switch from 12c to 19c searches over recent years.

The Oracle ACE Program : My 18 Year Anniversary

It’s April 1st, which means it’s my 18th year anniversary of being an Oracle ACE.

As usual I’ll mention some of the other anniversaries that will happen throughout this year.

  • 29 years working with Oracle technology in August. (August 1995)
  • 24 years doing my website in July. (Original name: 03 July 2000 or current name: 31 August 2001)
  • 19 years blogging in June. (15 June 2005)
  • 18 years on the Oracle ACE Program. (01 April 2006)
  • 9 years doing videos on my YouTube channel, with some breaks of course.

Fingers crossed for next year…

Cheers

Tim…

Social Battery

For years I’ve mentioned my issues with social gatherings. I used to come back from conferences or large social gatherings and crash for a few days/weeks. When trying to describe it, it would often sound much more serious than it was. The term “social battery” is so much better for explaining things, as it doesn’t sound like I’m trying to self-diagnose some deep seated problem. 🙂

I have talked about being different people in different contexts, like “conference Tim”, “work Tim” and “home Tim”, which can sound a little schizophrenic, but I’m really just describing coping mechanisms most of us have when dealing with situations. Introverted people don’t all act in the same way. Some people are really quiet, but some people, like me, become almost hyper when they are in a group setting. I think the term “extroverted introvert” is possibly what I am. That behaviour comes with a cost. It’s so unnatural for me that it drains my social battery, and it takes a long time for that to recharge. I know other people who seem to charge their social battery by being in group situations, and their battery drains when they are alone. Everyone is different in this respect.

The pandemic made me even more aware of how my social battery works. The switch to working from home and the break from conferences was a game changer for me. I had never spent so much time alone, and it was fantastic. So much so that I still work from home, and have stopped doing conferences permanently (probably).

This is one of the reasons I rant so much about company attitudes to working from home. We are all different, and if you want to get the most out of people, you have to recognise that and use it to your advantage. I think companies that value diversity in all its forms, including neurodiversity, have a long term advantage. That’s just my opinion, and maybe I have a vested interest in believing that, but that’s how I feel. 🙂

Cheers

Tim…

AI Prompt Engineer (AI-fu). The new Google-fu?

The other day I came across the term AI Prompt Engineer. It was in the context of being the next big thing in the job market. I did a bit of Googling and sure enough there are courses about it, and a number of jobs being offered. These seem to break down into two main types of role.

  1. A technical AI development role, involving understanding of AI and coding against various AI backends via APIs.
  2. A person who types in stuff to get the right outcome from specific AI tools.

As mentioned, the first is a technical development role, but the second seems like AI-fu to me…

Google-fu

Here is the Wikipedia definition of Google-fu.

“Skill in using search engines (especially Google) to quickly find useful information on the Internet.”

https://en.wiktionary.org/wiki/Google-fu

After all these years I’m still surprised how weak people’s Google-fu is. Searching for information requires knowing what to include in your search criteria, as well as evaluating the results to make sure they are actually what you need.

If you don’t understand how to filter the results using targeted search terms, you may get incorrect or misleading results. If you don’t understand the subject matter, you have no way of validating correctness of the responses.

AI-fu

I’ve made up the term AI-fu. I can’t see any references to it on the internet. The closest I can find is ChatGPT-fu, which I also made up here. 🙂 I said Google-fu is about providing the appropriate inputs, and validating the outputs. I would suggest that AI-fu is very similar.

If you’ve played around with ChatGPT you will know there is a degree of “garbage in, garbage out” involved. You have to refine your inputs, either by altering the original question, or following a chain of thought (CoT) process.

How do you know you have a suitable result? Well, you have to understand the subject matter, and do some fact checking to make sure you are not generating garbage. If you don’t understand that a human hand typically has 5 digits, you can’t tell if that 7 fingered monstrosity you’ve just generated is wrong. 🙂

Thoughts

I suspect those people that have acquired good Google-fu, will also acquire good AI-fu. Those people who have proved to have consistently weak Google-fu, are unlikely to ever developer strong AI-fu.

Cheers

Tim…

PS. If you want a certificate in AI-fu, please send £500 to my PayPal… 😉

Automation : Increasing pressure on an existing constraint

Yesterday I tweeted that I was reminded of this post.

I was reminded of it because of something that is happening to me at work, so I thought I would talk about it here.

Production lines

If you’ve read anything about DevOps you will know it came from manufacturing. If you didn’t know that, check out The Goal, which was the basis for The Phoenix Project.

Manufacturing typically uses production lines made up of multiple stations, where each station performs a specific task, and the product moves forward through the stations until it is complete. If one station is slower than the others, it will become a blocker. Product will start to queue up behind it, and downstream stations will become starved. So production lines only work well if they are planned to enable a consistent flow.

What’s more, you can only sell the product when it is completed, so we could describe the product as having no value until it is finished and with the customer.

It’s not just about manufacturing

The processes born out of manufacturing also work really well for other industries. I would suggest most things can be described like a production line, and as soon as you do that, a similar approach can be adopted to identify and fix the constraints.

Tech is an obvious one, and variations on DevOps have grown in popularity because of that. My sister in law works in a medical practice, and we’ve discussed the processes used in the administration side of it. As a result of our discussions she’s started to use Kanban boards to visualise the flow of work.

Back to my problem

So with the concept of production lines and constraints in mind, we jump back to my problem…

We are in the process of replacing loads of Oracle Linux 7 servers with either Oracle Linux 8 or Oracle Linux 9, depending on vendor support. The first three links in that production line are as follows.

  • VMs are provisioned.
  • Operating system customisations are run.
  • Database or app server is installed and configured.

We are not perfect, but we’ve got pretty good at this part of the production line. When we are finished, the systems have to be tested, and go through various processes to get them live and used by the business. Those parts of the production line that follow us are slow due to a number of factors. So our improvements in the production line have just made things harder for those steps that follow us. A simplified view of the Kanban board looks something like this.

The obvious thing to do here is focus on the constraints and start working on downstream links in the chain, to improve the overall flow. That’s where we hit organisation and culture barriers, so we are pretty much stumped…

Thoughts

I’m pretty happy with what we’ve done over the last few years. We’ve definitely improved several aspects of our systems because of automation, but at the same time I can’t help thinking we’ve achieved nothing because ultimately the work is not getting completed as fast as it’s started.

I wrote here about reframing the goal, and I have to do that as copium. Unfortunately copium only goes so far… 🙂

Cheers

Tim…

Business As Usual (BAU) vs Project Work

I’ve had this conversation so many times over the years, and I’m sure I’ve written about elements of it several times, but I’m not sure I’ve written about it specifically before, so here goes…

In every organisation there are conflicting demands from project work and business as usual (BAU) tasks. In case you’ve not heard the term BAU, here’s a definition.

Business as usual (BAU), the normal execution of standard functional operations within an organisation, forms a possible contrast to projects or programmes which might introduce change. BAU may also stand in contradistinction to external events which may have the effect of unsettling or distracting those inside an organisation.

Wikipedia

Swimming to stay still

I’ve written about this before in a rather angry post here. Working in tech is like swimming upstream. As soon as you stop swimming, you’re moving backwards. Let’s say today I have fully patched, secure and supported systems. How long can I do nothing before that is no longer the case?

  • Patches: For the operating system we may be talking days. For the database or an application server it may be months.
  • Support: Depending on where we are in the product support cycle, this is likely to be years, but we are fast approaching some important deadlines for Oracle Linux 7 and Oracle Database 19c, so we can’t wait much longer before we have a lot of work on our hands.

Standing still takes effort. If you are not putting in that effort, you are moving backwards, even if you don’t realise it.

BAU is invisible. Project work is shiny!

The problem with BAU is it is invisible to the users. Often you patch or upgrade a system and what they get after all that work is “exactly” what they had before. Of course, it’s not exactly the same, but from their perception it is. That can seem like a lot of time and effort for no perceivable gain, especially if you are asking for their resources to test things.

In comparison, project work often gives them something new and shiny to play with. It has perceivable value.

Faced with allocating resources between the two, you know there is going to be a lot of pressure to deliver new and shiny stuff over keeping the lights on…

Automation doesn’t solve all BAU tasks

Automation can certainly help with a lot of BAU work, but not everything. Even if you could magically upgrade a system without any downtime, somebody still needs to test the systems against it. Automation also brings with itself some additional BAU. Here are some examples I’ve seen recently.

Terraform: Providers change on a regular basis, which means you might be provisioning your kit using an old version of a provider. Over time you will start to see deprecation warnings, and have to update your provider. In some cases this will break your builds and you will have to do some refactoring. You need to revisit your Terraform builds on a regular basis, or put your automation at risk. Even the updates of the Terraform executable can introduce issues. One upgrade desupported a backend provider, which broke our project.

TeamCity: We use TeamCity for some on-prem automations. There are regular updates to this tool, usually because of security issues in some of the components such as Java or Tomcat. We have similar issues with Jenkins.

GitHub Actions: Have you seen that list of warnings and deprecation notices for those actions that are currently working fine? You are going to have to revisit those, or your lovely automations will break!

Cloud Platforms: If done well, cloud platforms can alleviate a lot of the operational BAU work, but they are not immune to issues around upgrades and deprecations. Many of us have lived through the desupport of previous generations of cloud architectures, and upgrades of underlying tech still have to happen, and require your systems to be tested when they are.

This is not meant to be an exhaustive list. Just examples.

BAU as internal projects

Just process your BAU as internal projects, and then they can be scheduled like any other project, right? That sounds fine, but someone still has to prioritise the projects, and BAU is not shiny! It’s still going to come in second place.

Education is the key

The only answer to this is education. The business has to understand that BAU is not negotiable. You have to be strong enough to push back on unrealistic demands, to make sure that systems remain up to date and safe. This can only be successful if you educate everyone on the importance of this boring and often invisible stuff…

A word about Oracle

It would seem wrong to finish this post without a mention of Oracle.

Most of the database upgrades I’ve done in my life have only happened because of the pressure of needing to stay in support. They have not been because people want the shiny features that are offered by the new release. That’s not to say they won’t end up being used down the line, but that is not the driving force a lot of the time. Stable and bug free beats new features every time!

In Oracle, just like any other company, there are competing pressures. I think most of us customer need to have 23c available so we can start the upgrade process to stay in support long term. There are no doubt a small number of important customers demanding features that will delay the release, and probably introduce bugs that affect all of us. There are also features that would sound cool for the sales teams and in keynote presentations. Who wins? Probably not me as I’m not working for an important customer, and I’m not in sales and marketing. 🙂

Conclusion

BAU is boring and often invisible, but it has to be done!

Cheers

Tim…

APEX : Keeping up to date is so easy…

Over the years I’ve extolled the virtues of Oracle Application Express (APEX) because of the ease of development. I think low code tools are a massive boon to productivity. Of course there are some tasks that need alternative tools, but for many scenarios low code tools are awesome.

Something else I find really appealing about APEX is the ease of upgrades. I’m not talking about how easy it is to apply the upgrade itself, because updating Java and Tomcat versions on a server is really easy too. I mean how simple it is from a wider perspective.

I was the first person in my company to use APEX. I used it to write some utility type applications, when it was still “forbidden”. Some of these applications were written over a decade ago, and they are still working fine. In that time we’ve had regular APEX upgrades, and they’ve just kept going. No refactoring. No drama.

Of course, they aren’t using all of the new features that were added in subsequent releases, but the important thing is all that development investment was not impacted by staying on the latest APEX release and patch set. In comparison, updating some of our other platforms and frameworks is a nightmare, requiring substantial development effort and testing.

So it’s not just about improving productivity during the development phase. It’s also about the reduction in the total cost of ownership (from a development perspective) over the lifespan of the application.

Just thought I would share that thought, as I upgrade & patch some production systems… 🙂

Cheers

Tim…

Continuous Improvement : It’s easy to get lazy…

I like to think that continuous improvement is always part of my process, but occasionally things crop up and remind me that I am just as lazy and set in my ways as everyone else. Here’s a little story to illustrate that…

The Issue

The main thing I’m supposed to be focussed on at work is server rebuilds. We are moving a bunch of stuff from Oracle Linux 7 (OL7) to Oracle Linux 9 (OL9), or OL8 if the vendor doesn’t support OL9 yet.

Anyone who follows my Vagrant builds knows I’ve got loads of scripts that build things, but because of our company organisation structure, there is only so much I can do without pinging requests to other teams, so full automation on-prem is not currently possible for me at work.

As a result of this limitation, there is a bunch of things I can do in Vagrant that I can’t do at work. The fact that work is semi-automated for builds has indirectly made me lazy in respect to continuously improving my build processes. In my head I guess I’ve been saying, “What’s the point if I can’t finish it?”

Making Progress

Due to the large number of rebuilds we are working through now, I’ve taken a step back and started again. I created a new build repo at work, and populated it with all the relevant stuff from our existing build processes, and some bits from my Vagrant builds. It’s still not fully automated, due to the company organisation issues mentioned before, but every step in the process is up to date with the best we can do, and the process is documented in the README.txt of the repo.

Along the way I noticed a bunch of things that were pretty crap in my original approach. It worked, but it wasn’t something to be proud of. 🙂

So What?

This just goes to illustrate the point I made in the title of this post. It’s easy to get lazy and let things start to slip, even when you know better. This is especially true if you have a “completionist” mentality like me. The thought of being able to finish something is quite compelling to me. Unfortunately, when I know I will not be able to complete something, I find it really hard to make the effort, because it all feels kind-of pointless. 🙂

Reframe The Goal

I guess this is really about reframing the goal. Rather than thinking that completion is when I have a fully automated process, it should be that I’ve got everything up to date and as far down the automation path as I can get at the moment.

The funny thing is I wrote about this in a previous post, but it seems I’m not always capable of taking my own advice. 🙂

Cheers

Tim…