Listen to this episode:
About this episode
In this episode of Behind the Data, host Matthew Stibbe talks with Scott Ambler — consulting methodologist at Ambysoft, co-creator of Disciplined Agile, creator of the Agile Modeling and Agile Data methods, and the person who coined the term data technical debt. Scott explains why 99 times out of 100 a failed data project is a people problem, why it should be trivial to change a legacy production database and what it says about you if it isn’t, and how to build the financial case for fixing data at the source rather than cleansing it six times downstream. He also argues that LLMs hallucinate 100% of the time by design, and that the only real question is whether the hallucination is good enough for the job in front of you.
Meet the guest: Scott Ambler
Scott Ambler is a consulting methodologist at Ambysoft, based in Toronto. He is the co-creator of Disciplined Agile with Mark Lines, the creator of the Agile Modeling and Agile Data methods, and the person who coined the term data technical debt. He spent several years at the Project Management Institute after it acquired Disciplined Agile, leaving four years ago to return to his roots in data and AI.
Scott is the author of more than 30 books, starting with The Object Primer in 1995 and including Refactoring Databases: Evolutionary Database Design, written with Pramod Sadalage, which sets out 65 common database refactorings along with the source code to implement them. He wrote some of the original material on object-relational mapping in the early 90s, and recently completed a master’s in AI. His latest book, Not Just Data, is a novel about building an enterprise data pipeline at a large Canadian bank.
Key takeaways
- 99 times out of 100, a failed data project is a people problem. Scott can point to exactly one project he would call a genuine technology failure, and even there the decision to use that technology was a management call. Legacy debt, missing data literacy and short-term business decisions do the damage, not the technology.
- If changing a legacy production database isn’t trivial, look in the mirror. The fear that altering a schema will break a thousand applications is what props up serial development and months of up-front design. Database refactoring removed that excuse 20 years ago, and once the fear goes, the process built around it starts to fall apart too.
- Cleansing data downstream is financially indefensible. Ask the CFO how many teams use a given dataset, then point out that every one of them writes cleansing code, maintains tests for it, updates it whenever something changes, and almost certainly does it inconsistently. Cleanse it six times, or cleanse it once.
- Fixing data at the source is a five to ten year cultural commitment, not a project. And that’s if you’re lucky. The hard part is keeping an organization focused for that long on something that is high priority but not remotely sexy.
- LLMs hallucinate 100% of the time, by design. They make probabilistic guesses, so every output is a guess, whether it happens to be right or not. The useful question isn’t whether it hallucinated, it’s whether the quality of that hallucination is good enough for your situation. That’s a human judgment call.
- Have real data scientists, not people with data science in their job title. An LLM is one option among many. Insurance fraud detection might call for an entirely different algorithm, with an LLM bolted on at the end only to turn the answer into plain language or into 20 languages. Without someone who knows when to choose what, you have a serious problem.
Chapters
- 00:00 Introduction to Scott Ambler and his background
- 02:03 Why Scott returned to the data world and his recent book
- 04:08 Challenges of legacy data sources in large organizations
- 05:54 Common failure modes of big data projects
- 07:52 Management and organizational issues in data projects
- 10:05 The concept of continuous enterprise data
- 12:04 The importance of continuous integration and deployment in data teams
- 13:58 The relationship between DataOps and DevOps
- 15:49 Cultural barriers and the 'we are special' mindset 17:57 Database refactoring and changing schemas safely
- 20:12 Adopting agile practices in data management
- 22:12 The state of data coaching and organizational agility
- 24:08 Addressing data technical debt and fixing data at the source
- 28:14 The impact of AI and LLM hallucinations on data reliability
- 34:01 Preparing data teams for AI and generative models
- 36:53 Final thoughts and key takeaways
Episode transcript
Matthew Stibbe (00:01) Hello everybody and welcome to Behind the Data with CloverDX. I am your host, Matthew Stibbe, and today I’m talking to Scott Ambler. He is a consulting methodologist, excellent job title, consulting methodologist at Ambysoft based in Toronto. He is the co-creator of Disciplined Agile with Mark Lines, creator of Agile Modeling and Agile Data methods, and the person who coined the term data technical debt. It’s absolutely fabulous to have you on the show, Scott.
Scott Ambler (00:32) Well, thanks for having me here. I’m always happy to help out.
Matthew Stibbe (00:38) And doubly welcome, and I have to say to listeners at home, he and I share an absolute enthusiasm for 8-bit Atari vintage video games and computers. And that’s a modern recreation, so that’s a particular plus for me. And I also have to say, I don’t normally wear the headphones, but I’ve got a builder outside. So if the audio is a little unusual, just bear with me. These are not my ears, these are headphones.
Somebody once said about Bing Crosby, his ears are so big from behind he looks like a taxi with both doors open. It’s the same with me. Scott, you wrote The Object Primer back in 1995 and you’ve published 30-odd books since then. But recently you’ve described going back to your roots in data. What pulled you back into the world of data?
Scott Ambler (01:34) Well, it was always an interest. So I didn’t really leave the data world, rather than just not focus quite so much on it, due to my work at the time in Disciplined Agile. So once I left PMI, I guess four years ago now, I had to decide, what do I want to be when I grow up? And how am I gonna keep myself entertained? So I went back to the data space and the AI space.
But like I said, I’d really always been staying involved in that space, even while I was doing DA. I was always the data guy when I was consulting with Disciplined Agile Inc. and was doing some training on the side when I was at PMI, and conference-type training sessions and good stuff like that.
Matthew Stibbe (02:28) I suspect like a lot of our listeners, being the data guy sticks with you, right? Everyone’s got you labeled. So you’re a prolific writer, which I’m very impressed by, and you’ve got a new book out called Not Just Data, which is in the long tradition and noble tradition of writing novels about technical subjects. Can you tell us a little bit about the book and what inspired it?
Scott Ambler (02:54) Yeah, so I’ve been teaching a workshop for a long time about how do you build a data pipeline when it gets down to it. And so I figured how to communicate this work, because it’s difficult. And so I decided to write a book on it. And then I very quickly realized, well, wait a minute, why not write it as a novel? And to try to make it interesting. Because I think the challenge with a lot of data books, they’re pretty dry. And so I figured novelizing it would be a good thing. So I told it as a story at a large Canadian bank, because being in Toronto, you end up working for tech companies and for banks. It is what it is. Because there’s bank headquarters all over the place in downtown Toronto.
And so anyway, it’s an amalgam of my experiences working for very large financial organizations, because to me they’re enterprise class. And when you’re doing enterprise-class stuff, you don’t have the advantage of smaller startup-level organizations where everything’s clean. So in banks, you’ve got hundreds or often thousands of legacy data sources.
Scott Ambler (04:14) Some of which are well designed, some of which are not. You’ve got just legacy technical data all over the place. Even the well-designed databases, it doesn’t really matter because the semantics are different, the naming conventions are different, it’s different technologies, different people at different times with different priorities. So even if you had a thousand well-designed databases, it would still be a dog’s breakfast. And this is the reality that professionals face. So that’s what I wanted to write about. So, how do you actually deal with that sort of a situation in the reality of a Fortune 500 company, with the reality of all this legacy debt, with changing requirements, with AI on the horizon, with management that might not be fully aware of the implications of what they’re asking for? And I’m being polite on that one. But there’s a few management changes in the book.
Matthew Stibbe (05:11) You’ve outlined a few of the failure modes there of these big bang data projects. Are those the typical reasons they go wrong, or are we able to invent new ways of screwing up big projects?
Scott Ambler (05:27) Well, fundamentally I think we’ll always find new ways to screw things up. But many organizations are still struggling with issues that we were dealing with in the eighties and nineties. Because it hasn’t gone away, right? There’s still all this legacy technical debt. There’s still the lack of data fluency or data literacy in organizations. There’s a lack of wanting to invest in quality and understand the implications of decisions. You’ve got business leaders that don’t really understand the tech, can’t take the time, and they never will. They don’t really understand the data and they never will. And they will make short-term business decisions that make a lot of sense to them that really shoot them in the foot for the long term, particularly on the data side of things.
And then everybody suffers from that. So they kick the can down the road and nobody really cares. But then when you’re trying to build an enterprise data pipeline, you get to deal with all of this. And of course it’s all your fault. And it takes time, and there’s no real easy solutions when it gets down. Hey, there’s great tools and new techniques and good stuff like that, but at the end of the day, it’s still hard work. And at the end of the day, you’re still being undermined by the rest of the organization.
And at least at the enterprise level, you run into the messes and you run into all these warring factions in the organization, all of whom have valid points, which they don’t agree with each other, they never will. They’re always the most important group. And they’ve got whatever their data sources are, they’re probably not supporting you well, and yet they want you to fix all their problems magically, instantaneously, and read their mind and all that good sort of stuff. And one of the things in the book is the requirements change. I don’t make any assumptions, I don’t just do wishful thinking and “yes, the requirements will never change.” None of that. So the entire book is all based on real-world stuff. This is what happens, it is what it is. Deal with it.
Matthew Stibbe (07:49) It’s a fundamental of Agile that the requirements are never settled. They are going to change, isn’t it? I’m interested in something you said, though. I remember reading years ago, and don’t ask me who said it, but famine isn’t a food problem. It’s a political problem. And it sounds like you’re implying that big data projects that go wrong aren’t a technology problem. They’re a management prioritization problem. Might be overstating.
Scott Ambler (08:20) Yeah, 99 times out of a hundred, it’s a people problem, a management problem. I was on one project that I can honestly say it was a technology problem, although there was a very good argument that the decision to use that technology was a people problem, and that was definitely a people problem, because we would never have used that technology if it hadn’t been for management.
But other than that, there’s some interesting technology problems. But yeah, it’s always people problems and we just have to deal with it. It’s just the reality on the ground.
Matthew Stibbe (09:01) In researching this, I was struck by the phrase that you use, continuous enterprise data, and the word continuous is the bit that intrigued me. Can you unpack that a little bit for me?
Scott Ambler (09:14) Yeah, so there’s some complexity there in that word. Because I used it in two different situations. One situation was the fact that it’s an enterprise. You’re running 24-7 or close to 24-7. So your data is changing continuously. And when you have hundreds or thousands of data sources, you’re guaranteed. And you’re operating at scale, and the scale is increasing, volume’s increasing, the rate of the incoming data is increasing. Everything’s just hitting you continuously. So you can’t really assume you can do things in batch. There might be batch jobs still running, but more than likely they’re going away and they’re being replaced with real-time systems. But yeah, at the enterprise level right now, most people are still dealing with some batch data coming in. So you get just this, but it’s still a continuous flow, right? It’s an hourly batch job, a daily batch job, whatever it happens to be. So you’re still getting hammered continuously by that single batch job, let alone the other hundreds of batch jobs or feeds or whatever it is you’re getting. So from the point of view of an enterprise data pipeline, you’ve just got continuous data change. The data is changing continuously and you’ve got to be able to deal with that. Because if a piece of data changes in your live system, there is a reasonable expectation of your end users that that change gets reflected on their dashboards, in their AIs, whatever it is that’s at the usage end of that data. And it should be there fairly quickly, if not instantly, or darn close to instantly.
Matthew Stibbe (11:03) I certainly want that for my bank balance.
Scott Ambler (11:05) Yeah, exactly. This is a reasonable expectation these days, and so that was one definition. That was the one usage of the word continuous, but the other usage of the word continuous is on the team, from the way of working of the data team itself, right? So you should be doing continuous integration and continuous database integration and continuous database regression testing and continuous database deployment, and all this sort of stuff. So you’re no longer working in quarterly releases or annual releases. That’s just too darn slow. Even working in two-week sprints is just breathtakingly slow in my world. Why can’t we release… if somebody’s telling us about a new report or a new dashboard widget or some new weird AI thing they want to do, why can’t we provide that data by the end of the day or by the end of tomorrow or in some reasonably short period of time measured in hours or days rather than weeks or months or years?
Matthew Stibbe (12:20) You’re talking about the continuous supply from a data team to the rest of the business in this.
Scott Ambler (12:23) Continuous work cycle, yeah. So if the requirements are changing today, why aren’t we reacting to them today?
Matthew Stibbe (12:32) Yeah. And what proportion of data engineering teams do you think are capable of operating at that pace?
Scott Ambler (12:41) Five or ten percent, maybe, maybe more. Yeah, certainly in smaller organizations it’s reasonably common. The DataOps has become reasonably routine in a lot of organizations. But for the larger orgs with lots of legacy data, the people get in the way. They make some strange assumptions about how we can’t possibly do this here because we’re special.
No, you’re not special, at least in any sort of positive sense of that word. And it’s like, suck it up, buttercup, learn to do your job, right? There’s nothing special. And this is one of the reasons why I chose a bank, because you’re a financial institution, for the book. And there’s nothing special with that. It’s just that you expect a legacy financial institution to have underlying challenges in the ways that they work. And weird cultures that stop them from being effective. And we explore some of those issues in the…
Matthew Stibbe (13:46) And to what extent is this phrase DataOps really just DevOps, but brought forward in time to data, and to what extent does the data engineering community actually need to learn DevOps and apply it?
Scott Ambler (14:04) Exactly. So there’s two ways to look at DataOps. Either it’s DevOps for data work, or it’s the data aspects of DevOps. I prefer the latter. I prefer to think of it as just the data aspects of DevOps. And it’s interesting, if you look at DevOps pre-DataOps, the ops side of DevOps was mostly data stuff. Because operations of non-data stuff is not that interesting when it gets down to it, other than maybe a few security challenges. But the dev side of DevOps, the data stuff in the first decade or so was basically ignored. And this is where all the Agile data ways of working came into play. But the problem was DevOps, just like Agile, came from developers, it didn’t come from the data folks.
Scott Ambler (14:59) So the developers, the source of the leading-edge software engineering techniques, didn’t really have a data background. They didn’t understand data. They underestimated the importance of it and the complexity of it. They didn’t understand the long-term implications of data. And as a result, they didn’t focus on it, or they had very naive thinking. It’s like, yeah, we don’t have to worry about the database, we’ll just encapsulate access to it. Whatever, go fetch me a coffee, right? You’re doing too much damage. Just go fetch me a coffee and we’ll work through what you need to do here. And database encapsulation is okay, don’t get me wrong. I actually wrote some of the original material on object-relational mapping in the early 90s. So yes, encapsulation is important, but it’s not the full picture, right? So we need to do a little bit more. So, anyways, the good news is that DataOps is real. We’re seeing good tooling for it, we’re seeing an understanding of the importance of it. Because I would work in organizations… one of the reasons why I was the data guy in Disciplined Agile was I would go into an organization and all of the IT group would be moving to Agile, except for the data guys, because they were special, right? And they were almost always some sort of bottleneck. Nobody liked them. They were always a problem. They’re always the problem child. But none of the Agile consultants knew what they were talking about. So then the data guys could get away with the “we’re special, the rules don’t apply to us” nonsense.
Scott Ambler (16:47) So then I would often get brought in to say, no, the rules do apply to you, and here we go. So that I think is the… and it’ll always be the same, right? They make these weird assumptions that you can’t change production databases. If you’re scared to evolve a legacy production database, you’ve got a serious problem there. And it’s you. Look in the mirror; you’re the problem. If it’s not absolutely trivial to change a legacy database, you’re doing something very significantly wrong. And I say that because I have never run into a situation where that wasn’t true. I have run into many situations where “we’re special because we’re a bank or we’re a military organization or we’re some big tech vendor or we’re this or that.” But yeah, so what?
Matthew Stibbe (17:40) To what extent is this defensiveness, we’re special, you can’t change the system, gatekeeping—it’s like, my special knowledge is so valuable and I don’t want to surrender. What’s the thinking behind that? Because I’ve seen it before, but it’s…
Scott Ambler (17:57) Well, yeah. I think a lot of it is they realize the damage that gets caused if you just randomly change a database schema in production, right? “I wanna rename a column.”
Matthew Stibbe (18:10) Then they’re not completely wrong, right? You could blow something up if you get it wrong.
Scott Ambler (18:15) Yes, that’s right. If you get it wrong, so let’s get it right. And that’s what database refactoring was all about. So about 20 years ago, Pramod Sadalage and I wrote the Refactoring Databases book in response to the spectacular amount of whining that was coming from the data community that database refactoring wasn’t possible. And it’s like, yes, the adults in the room have been doing it for a long time. So Pramod and I wrote the book.
And basically it’s a reference book, right? It’s boring. It’s a boring read. But it’s still solid. And so we presented 65 common database refactorings and the source code to implement them, and written in… it was an Oracle 8 or something, and an open source database just to say we could do it. But we didn’t use any special features of Oracle. It was all just basic, straight SQL when it got down to it that just happened to run, because that was our test bed. But our entire position was, here’s how you do it. Shut up. Come at us, right? You don’t like it? Show us how our code doesn’t work, because we have just shown you how to refactor a production database schema with hundreds or thousands of systems touching it, on any platform that used to support SQL. And these days SQL isn’t a requirement either. But yeah, back then, reasonably, it was. But yeah, I’ve done it in IMS, for example. So anyways, it is possible. So what happens is when you take away this fear of, if we change a production data schema, we’re gonna break a thousand applications, if you show, no, here’s how you do it safely, then suddenly what happens is all of these traditional data techniques that are based on this false assumption that you can’t safely change a database schema start to fall apart. And because now, wait, it is fairly straightforward to do this, particularly technically. There’s some serious cultural issues, but technically it’s a no-brainer. Then suddenly it’s like, well, why are you doing all this? There’s absolutely no reason anymore to do serial development. We don’t need to… and there’s some good reasons to do upfront thinking, don’t get me wrong. But I certainly don’t need to spend months of upfront database design in order to get it right. Days, yeah, you bet. Months? Hell no.
Matthew Stibbe (21:01) So you created this Agile Data method decades ago and you’ve just touched on the idea of serial development and wanting to… What did the data world get right in adopting Agile thinking and what did it get wrong?
Scott Ambler (21:19) Well, the stuff that it got right, there’s some of the easy Agile stuff like working together more collaboratively and being flexible. They’re getting that right. The DataOps world, I think, has gotten a lot of the stuff right. So they understand the techniques, they understand… here’s all the technical techniques you need, like database refactoring and database testing and database integration and database deployment and let’s automate the living heck out of all of it. So they’ve gotten all that right. There’s still cultural issues, particularly the “I’m special” issue needs to be dealt with. But the big challenge, I think, for the data community is the lack of coaching. So it’s phenomenally difficult to find an Agile coach who also has a serious data background. Because invariably, if the data coach can’t intelligently speak to data issues, and there are some important data issues, and if you can’t show how to do the work and be able to do the work in their environment, in their special nit-noid world that they’ve got going on that they think breaks the rules, which never actually happens, if you can’t show that, then rightfully so, they’re not gonna listen to you. And they’re not, because they’re still special, right? Because you can’t show them how not to be special. So the coaches need all those skills. There’s very few people with those skills out there. A lot of them work for Thoughtworks, or used to work for Thoughtworks. But yeah, it’s pretty still these days. There’s more and more good DataOps coaches out there. And there’s a few good Agile data coaches too, but they’re still few and far between.
Scott Ambler (23:10) Well, and then now that the Agile community has imploded, the concept of hiring an Agile coach is kiss of death right now. But these organizations need people to do this.
Matthew Stibbe (23:20) Say more about that.
Scott Ambler (23:39) Well, three or four years ago, all these organizations getting Agile coaches, every Agile team had a coach or somebody pretending to be a coach. They often weren’t coaches, but they claimed to be a coach. But a couple of years ago, everything imploded, right? Organizations are no longer, for the most part, paying for the Scrum certifications that you can buy off the shelf, the SAFe certifications. So it’s really tanked. So nobody’s hiring Agile coaches and haven’t for a couple of years, for the most part. There’s still a few here and there, but not like it used to be. Three years ago, every organization on the planet was desperately trying to hire Agile coaches. Now it’s maybe…
Matthew Stibbe (24:08) Because they think they’ve already got there? Or because the value of coaching has been debased or replaced by AI or something?
Scott Ambler (24:14) I think they started measuring the value of the Agile coaches they had on staff and they realized they weren’t getting value for it. And I think because there’s a lot of people claiming to be Agile coaches and they really weren’t.
Matthew Stibbe (24:28) So I’m interested in this concept of data technical debt, and you’ve argued that the fix perhaps in part is to repair data at the source, not to keep cleaning it downstream. And I can imagine that’s a really hard sell when somebody has got a really vested interest in defending their 25-year-old ERP system and their special knowledge and “we’re really important” and blah, blah. So how do you make the case to not that person who’s got a vested interest in not changing, but to the CFO or the CIO who’s going to mandate the change?
Scott Ambler (25:04) Yeah, that’s a great question. It actually is a financial issue. And I would rather have those sorts of conversations with the CFO. Because just run the numbers. Data cleansing at the point of usage, as downstream as you typically do it, is indefensible from a financial point of view. The numbers just don’t work out for that.
And the reason why is if you’re cleansing it at the point of usage, just before producing a dashboard or cleansing it for your AI system, if you’re the only team using that data, okay, fine. You’re doing it once. But if it’s enterprise data, more than likely that data is being used in multiple places. So if you have to clean it, so are all these other teams.
So this is the argument that gets the CFO. Because I’ll just say, well, how many teams are using this data? This team, this team, this team, this team, this team. And they’re all cleansing it, right? Yep. And they’re all writing that code, right? They’re all maintaining the tests for that. Anytime something changes, they all gotta update, right? And let me guess, they’re probably not consistent, are they? And you’re getting different answers out because it’s being cleansed in different ways at different points and times. If it’s being cleansed at all, right? Yeah, and then you get a bitching session for about half an hour. So then after that, okay, well, let’s run the numbers. So we know for a fact that you’re cleansing it six times. You probably cleansed a few in a few other places you don’t know about because frankly you don’t track very well. But we know it’s being cleansed six times. I’m proposing it gets cleansed once and once only. Run the numbers. The conversation is now over. And now it’s like, okay, now we got to hammer on those six teams. We’ve got to hammer on seven teams. We hammer on the six teams that are doing it downstream. And frankly, they probably don’t want to be doing it anyway. So that’s an easy discussion. And then you hammer on the upstream team, or teams in some cases, that own the data. And you start saying, well, wait a minute, why are you producing this crap data to begin with? And they’ve got lots of excuses and woe is them.
Scott Ambler (27:21) And more than likely not being funded well. So anyway, let’s put the money where it needs to be, right? Clean it once, clean it up, get it out of the way. And whatever the reason for the dirty data to begin with, and it’s probably bad application code or some yo-yo is hand-jamming things or whatever, fix that problem too, right? Get it dealt with. Pay down your technical debt. So you’ll have pure technical debt on whatever applications are messing up the data and you’ve got some data debt there, pay that down. And then suddenly you’ve got all this clean data. And this is going to take time. So now we end up in a cultural issue, an organizational issue, of can we change the culture of the organization to understand that cleaning things downstream is a bad idea. Let’s clean them as far upstream as we possibly can and let’s fund this and let’s get it done over time, right? So now we have to change our organizational behavior and we gotta stick with it for five or ten years, right? Because you’re not gonna change this overnight and it’s not a project.
Matthew Stibbe (28:32) So that’s the kind of time horizon we’re talking about.
Scott Ambler (28:36) Yeah, if you’re lucky. If you’re lucky, it’s only five to ten years. And how many organizations can stay focused for five or ten years on something that’s frankly very boring? So this is not a high… well, it’s a high priority, but it’s not sexy. And so, yeah.
Matthew Stibbe (28:51) Yeah. I think one of the things that might make it a bit sexier than it has been for a while, and maybe I’m wrong about this, is I think every CIO and every CEO suddenly cares a lot about AI, and the AI bit seems to depend on good data, the more data, the better. So I wanted to ask you, because you did, presciently perhaps, an AI master’s in 2025. And you have some fairly strong opinions about AI. And I just want to spend a few minutes exploring that and then we can talk about how that addresses this data debt issue. The first thing I’m interested in is your blog post from a few years ago that you said, “LLMs hallucinate 100% of the time.” And you’ve just told me earlier that you think that is still true. Can you unpack that a little bit and explain what you mean about that? And how does that impact on the world of data? Or how does the world of data impact on that?
Scott Ambler (29:59) Yeah, so the fundamental nature of the architecture of LLMs is that they’re making guesses, right? So it’s a probabilistic game. And so what they’re doing… and they’re getting better, but they’re still making guesses. So every so often they guess wrong. So what’s happening is… I’ll use, I don’t know, Claude or something, right? And I’ll say, hey, I want a picture that looks like this, blah, blah, blah, blah, blah. Hit the button. So poof, here comes a picture or something, depending on the product, several pictures. Well, what is that? Well, those are guesses, right? So when they’re creating art, it’s obvious, right? Because you’ll get several answers. Or if you even give it the same prompt, you’ll get a different answer again, right? So it’s making a guess. So that guess is a hallucination, right? So what happens is, I give it the prompt, I get a picture, update the prompt or give the same prompt again and get a different picture, and so on. So I home in on… find, that’s a pretty good picture. So then I’ve got my little artwork that I have… I have no artistic ability. So I have no hope of doing something that good. But it’s a pretty awesome picture from my point of view. But it’s still…
Matthew Stibbe (31:09) Yeah, I bet like me, you’ve got some pictures of your dog doing weird things.
Scott Ambler (31:14) Doing weird things, yeah. Well, actually I can just take a normal picture of him doing weird things. He’s a weird dog. So anyways, that’s still a hallucination. It’s the same thing with text, right? I could ask it… my daughter’s about to go on a job interview, right? So write up some good questions, job interview questions that a vet might ask you, right? So it’ll hallucinate a bunch of questions. Now, it’s an amalgamation of things stolen off the web. But you run the prompt again, you’ll get a different set of answers, right? So what happens is we keep asking the question until finally we get an answer. Yeah, that’s pretty good. But it’s still a hallucination. And so the issue is, how good is the quality of that hallucination? Is that picture good enough for me? Yeah, it is. Okay. Or no, it’s not, run the prompt again. How good is that set of interview questions? Okay, run it again or tweak the prompt and get a different answer. So this is what’s going on. So yeah, they hallucinate 100% of the time. It’s just how good.
Matthew Stibbe (32:23) Data engineers find that quite hard to… by default, we’re thinking in terms of deterministic outcomes, and put this information in and you get the same result out each time. That’s not, yeah.
Scott Ambler (32:35) Yeah, it is not… LLMs are not deterministic. And that’s okay. Just know that that’s the case. There’s nothing wrong with that, but just know that they’re hallucinating a hundred percent. So this is why I tell people they hallucinate a hundred percent of the time. And because it’s a wake-up call that they are getting a non-deterministic answer, because people believe the stuff that comes out of the AI, and even I do now.
If I wanna look up a fact, I’ll see something on the internet. That can’t be right. I’ll go to Google and I’ll type in a prompt. And the Google AI comes up and it says, well, blah, blah, blah, blah, blah. But that’s a hallucination. Now, hopefully it’s just stealing it from the real source on the web, which it often does, but not always, right? And then I look at the answer, yeah, the hallucination matches what I was told. Okay, fine, right? So maybe it’s good enough. But still it’s a judgment call for the humans: is this hallucination good enough for me in this situation that I face?
Matthew Stibbe (33:44) So this brings me to, I think, my last question, given the time—we could keep this conversation going for hours, I think. Given a probabilistic, non-deterministic AI world that everyone is excited about and has lots of promise of LLMs…
Scott Ambler (34:01) Of LLMs. Yes, other models are not that. So yeah. Different models have different answers for it.
Matthew Stibbe (34:11) What does that technology availability, that affordance, imply for data teams? What do they need to be doing now with their systems and their data and whatever to be AI ready or AI minded, or bring some reliability into these systems, if anything?
Scott Ambler (34:37) Yeah. So have some real data scientists on your team, right? Not just people with the data science in their title, but actual people with a data science background. Because one of the things you’re doing when you’re building a solution based on some sort of AI technology, you need to understand the business process. What are they trying to accomplish? And then part of the overall development process is we need to choose the right algorithm for this problem.
So, if I’m doing insurance fraud detection, for example, there’s a certain collection of models that would make… or algorithms that would make sense for that. So then we would develop our model based on those algorithms, based on our data, and then hopefully we have a good enough accuracy rate or F1 rate or whatever. Whatever you’re into, whatever metrics you enjoy, for the situation that we’re in. And so this is data science 101-type stuff, right? So you learn about these various algorithms, at least if not in your first data science course when you’re in school, certainly in your second. So it’s all pretty basic stuff. But right now with the hype… so like you’re saying, I went back to school to do a master’s in AI. So I made that decision in 2023, or was it 2022? Must have been 2022. And literally a month or two before ChatGPT 3.5 was released.
So then, because I went back just to do something interesting and learn some cool stuff and refresh and all this. And then we went with this horrendous hype cycle, right? And then LLMs just took over everybody. So now when you say AI, people are really only talking about generative AI for the most part and LLMs, or agentic AI. But many, many other algorithms are really useful that you do want to use every so often. But if you don’t have people on staff that know about them and when to choose them, when not to choose them, you’ve got a serious problem. That’s what data scientists do. Well, one of many things that data scientists would do.
Matthew Stibbe (36:53) Yeah. So if your only answer is an API call to Claude or ChatGPT or OpenAI, then you’re going to get that outcome. If you’ve got a data scientist, you can have an array of other perhaps explainable or machine learning technologies that might give you a more deter… I’m not trying to put words in your mouth. I’m just trying to understand if that’s the point you’re making.
Scott Ambler (37:11) Yeah, that’s exactly… or combinations thereof. So in the data fraud detection thing, you might have something based on, I don’t know, random forest, probably not the best idea. But anyways, maybe you do it. Maybe it is the best idea. So you’ve got… the fraud detection engine is a random forest for whatever reason. It spews out an answer and then you put that through an LLM to turn it to voice. Or to translate: here’s what we believe has happened, and we can translate in 20 different languages because you have different staff, right? Whatever the answer is. But the point is that you might use a combination of algorithms or a combination of tools in order to build whatever this new business process is. And so it’s not just an LLM play.
Matthew Stibbe (38:04) And I think that’s a very thought-provoking and encouraging point to bring this conversation to an end. Scott, it’s been absolutely delightful having you on the show and I feel like we could talk for hours more, but we’re gonna bring it to an end there. Thank you very much.
Scott Ambler (38:19) Thank you. My pleasure.
Matthew Stibbe (38:21) And for everyone listening, that brings this episode to a close. Thank you very much for listening. If you’d like to get more practical data insights or learn more about CloverDX, please visit cloverdx.com/behind-the-data. Thank you for listening and goodbye.
Resources
- Ambysoft — Scott Ambler’s consultancy
- ScottAmbler.com - Scott's website
- Scott Ambler on LinkedIn
- Not Just Data — Scott’s new novel about building an enterprise data pipeline at a large Canadian bank
- Refactoring Databases: Evolutionary Database Design — written with Pramod Sadalage, setting out 65 common database refactorings and the code to implement them
- Agile Modeling — the method Scott created
- The Agile Data method — Scott’s method for Agile ways of working with data
- Scott’s blog post on LLMs hallucinating 100% of the time — the post Matthew references
Related content
More from Behind the Data
-
Ethics, alignment & the human side of data with Mirela Mart, CFO at Articulate Marketing
-
Automating the mundane, liberating the humans with Nick Liles, IT Manager, Sisk Fulfilment Service
Share
