Tag: republish

This editorial was originally published on Jul 4, 2016. With Steve on holiday, this is an interesting look back almost a decade into the past at AI technology.

There’s a fascinating piece over at O’Reilly that looks at what we might consider Artificial Intelligence (AI) to be. The discussion looks at Deep Blue, Watson, and AlphaGo, all of which have defeated humans in game competitions where we might expect some intelligence is needed. We could argue that, but certainly, these computing machines have done more to display knowledge than the best humans at certain endeavors.

What is interesting is that each of these machines, while very competent in its area, is specialized. AlphaGo can’t play chess, nor can DeepBlue play Go. Each has been tuned to a specialized area, and also trained to excel in that area. This isn’t fundamentally different than humans that train and specialize themselves, though certainly we find humans have more capabilities in a general sense (for now) than machines.

As we look to grow intelligence, however, there is one thing that’s commonly needed in both artificial or machine intelligence and human intelligence: data. Whether a human is training themselves to solve a particular problem, compete in a game, or even excel in a sport, they need lots of data. We gather this with our senses as well as by examining what others have one, contemplating actions, trying out different actions, ideas, or concepts, and then adjusting to improve.

This is what researchers are also trying to do with gaming machines, with self-driving cars, and even with bots. That last item is interesting to me, as I haven’t paid much attention to bots. A long conversation with another SQL professional got me interested in, and intrigued by, the idea of software robots that might handle various complex tasks better than the FAQ method that so many applications and websites use. I wasn’t sure these would be useful, but I have found the Slackbot to be more helpful than the help or searches for some tasks.

There’s work to be done, and I know the Slackbot (and other machine intelligence software) needs to be trained better. This requires data. Lots of data, and possibly lots of hand holding from a human. For many areas, such as relatively low-level customer support or problem solving, I wonder if a bot could be trained to work better than the simple decision tree algorithms like those found in the Windows Troubleshooter.

There are various ways we might grow this software to help us, and make no mistake, we will need to grow it. Plenty of businesses are becoming excited about machine learning, the R language or Python, software bots, and more. In all the cases of implementing these systems, the one demand that will impact many of us is the need for lots of data. Data that’s organized, that is relevant, that we can use to separate out successes from failures, and evaluate our particular problem better. We will need to group data into knowledge and then feed it into software.

I think this is a bit different than how most of us have used data over the years. We’ve often collected, manipulated, aggregated, summarized, and spit data back out to (ultimately) some human that can make a decision. Most of us haven’t worked with sending data to a machine intelligence and somehow then helping it to understand how to respond on make a decision.

My suspicion is there will be lots of work for us in the next decade in helping machines to use data and understand it, maybe even to use them to help us gather, organize, clean, and manipulate data better ourselves. It’s an exciting time to be a data professional, and I’m sure some of you will work on a few very exciting projects in the future.

Steve Jones

I was in the UK last week and since I was gone for a week, I’ve decided to take a day off with my wife.

You get to read Practice Until You Don’t Get It Wrong, which is something I believe in. Or listen to the podcast: https://traffic.libsyn.com/voiceofthedba/PracticeUntilNotWrong_92_v2915.mp3

It’s another Monday off for me, this time likely catching up on some fall maintenance before it gets really cold. Plus, I’m gone in the UK next week.

While I’ve likely doing something with my hands, and concentrating outside, you get to read about doing that inside:  Limiting the Ability to Concentrate and Collaborate

Still in Italy, so while I’m sipping wine, you can Start Fixing Your Database with Better Code.

I realized I never put this on the blog, so here it is:

Start Fixing Your DB with Better Code

I ran across an interesting article from Gitlab. They host git repositories for companies that develop software, and of course, part of their hosting is tracked in a database. They use PostgreSQL for their data, and were not happy with the performance of their database backing the system. Up front they admit part of the issue is their own coding, which is likely the problem in so many software projects.

Gitlab accepted this, and certainly many database developers or consultants will let management know that the problem causing poor performance is often poorly written code. Jeff Moden constantly explains in his articles how better code can dramatically reduce the load on your SQL Server, yet fixing code is often the one thing few organizations want to focus on. It’s easier to buy more hardware, which often just hides the problem for am all-too-short period of time. Or just complain and try to write new features that take the place of old ones.

I’m sure many of you have heard your parents or teachers tell you it takes about as long to do something right as wrong, so do it right the first time. Often taking a shortcut doesn’t really save time. I’m not sure that’s true with development. Often it’s quicker to do it wrong because doing it right takes a little more planning, and perhaps some testing, likely a bit more time to carefully construct code, and certainly more time to learn how to write code better. That last item is the issue, as so many of us learn to write code poorly, without examples that give us good habits from the start.

The best developers have spent lots of time writing code poorly and learning how to improve their work. They know the tips and tricks in their language(s) of choice. That might be better SQL to create efficient queries, better C# to avoid constantly hitting the database, or something else. However, as most of us learn to write code, we don’t learn the best way. We learn the ways that are easiest to teach a user concepts, most of which don’t scale well.

If you’ve made the investment to learn about writing better code, then it doesn’t take any longer to write good code from the start. If you’ve made the investment, and if you practice what you’ve learned. Jeff has lots of great articles on writing better code, as do many of our other authors. Take a few minutes today and learn to build better SQL code. Your database (and users) will thank you.

Steve Jones