Tech Talks Daily
00:04:56 · Ben Grinnell
[00:04:56] S1: Well, it's just been an evolution, hasn't it? I mean Yeah. If you look back twenty years, we were outsourcing a lot of that and offshoring it. And then we had the DevOps movement where you said, okay. Well, let's make sure developer can deploy stuff so we can get faster iterations. And I think 2007, was it 10 deployed today at Flickr, famous conference with John John Allspaw. And, you know, that always fascinated me. And I look at now and I think, okay. So now I can put one of my consultants in front of a client, and I can have the same person listening to the problem as the person's building the solution. And if I think about the effects of that, as you become more and more agile, less and less waterfall in your delivery, then the the speed of the iterations is all that matters. So how fast could these iterations be? Well, if you remove the handoff to the developer or especially when there's a contract involved in that handoff, then you've literally got someone building and experimenting with the client's thinking on the fly. And what that removes is you always lose a lot of context when you describe what you heard to another person, And people have different understandings as well, so it's a bit like Chinese whispers. So get rid of the Chinese whispers. So the person building a solution has the full context. There's a lot of cognitive load when you have to describe to another person as well, so you remove some of that cognitive load. And then the context, the the cost of the coordination of one person is the problem and one person is doing the work, that goes away too. So you end up with an ability to build the right thing faster. And in the world we're in, that's so important. So I think the the thing you don't want to do is when you build the right thing faster, get caught in there. Well, I've just really... I've coded this thing for the client. They can see it working. It's finished. Because, obviously, there's a ton of security, nonfunctional requirements, and architecture that gets frequently lost in that. So there's definitely a need to make sure that I... I'm trying to make sure that I put the guardrails around those sort of client facing developers so they could develop safely, which is exactly what I did in the DevOps world. I put guardrails around... You know, I I automated operations so the developers could do it.
00:07:05 · Ben Grinnell, Neil C. Hughes
And, again, that was an extension of world where people had to build servers once, and then we had the cloud, then we had DevOps. So it's just a continuation of that journey, but now it's reached a point where it's literally one person sitting in front of a person that's actually describing a problem that can solve it for them. [00:07:24] S0: And I must admit, I've been in enough stakeholder meetings with IT and people from around the business to know that traditional projects can lose important context as that idea moves from a a business team and then onto the technology specialists and the project teams there. So for what you're seeing and hearing here, where does AI shorten that journey, and where is specialist engineering still essential? Because those days of IT team taking, I don't know, eighteen months to two years to deliver a project, those days are long gone. They need to move faster now. Right?
00:07:58 · Ben Grinnell
[00:07:58] S1: Yeah. And the the biggest problem is the world's changing so fast. So if you do take eighteen months to do a solution, even if you got the requirements right at the start, it's definitely wrong by the time it comes out. So we have to be in a world where we deliver iterative value very, very fast. And the AI can speed up all bits of that. So I know we've seen live coding and some of that work speed up the development cycle. And we have got tools like Blitzy that allow legacy code bases to be looked at and to bring that context in. So a lot of the early problems with via coding have now been solved. But I was with a group in San Jose in April where we were writing some thought leadership papers on how you automate the testing bit of that work and how you can get models set up to challenge the the code that's been written by a different model and make that bit faster as well. And whereas a year ago, maybe six months ago, you couldn't really ask the model about the architecture or to get the architecture right. Now you've got a very good architecture coach in a lot of those models. So I think the the speed's brilliant. AI can... AI AI AI can speed up any element of that pipeline, but only if the person controlling it or directing it knows what questions to ask. And that's where it all goes wrong. If you don't know to ask the right questions, if you don't know to ask about what nonfunctional requirements should I consider, if you don't need... Know know to ask, how should I make this a modular architecture so it's easy to maintain? Then you won't get that.
00:09:31 · Neil C. Hughes
[00:09:31] S0: Yeah. And looking back, if we go about, what, ten, fifteen years, we had BYOD, then shadow IT. Now we're hinted at shadow AI. Just the thought of employees creating their own AI tools or workflows ten years ago would have been unthinkable, but this is where we are. So what kind of guardrails are needed now so experimentation doesn't accidentally drift into introducing security data or or even governance problems.
00:09:57 · Ben Grinnell
[00:09:57] S1: There are some interesting parallels, aren't there? Because we had all employees creating Excel spreadsheets with macros, which are, I would say, more difficult to maintain than a lot of the solutions people live by coding in Python now, particularly access databases. So we had the shadow IT sort of wars back then. I think we are a place where we can vibe code things that are much more testable and maintainable than some of the previous versions, but we do need to make sure that we've got IT knowledge aware of them. I think for a long time, I've been working with clients to help democratize IT into the business and bring IT closer to the business because coming out of the days of offshoring a lot of that because IT is just a cost center, which was was... We were in that world for a long time. Yeah. If IT is business critical and if it's not, I have a question which business you're in, but I think it's business critical for a lot of businesses now, then you want to keep some of that capability in house and some of it very close to the business. So stop thinking it as a cost center. And if I'm in the IT function, I need to be working very closely with the business so I'm closer to the the profit and the revenue because, otherwise, I'm going to get stopped. A lot of the projects that start off in IT run quite well, and then there's a downturn in the market or something, and they get mothballed for a period of time. Or they go too big and they build a lot of momentum, and then they can't keep that up. So I think having IT in the business with the people that know IT, actually working closely with their business counterparts and delivering value early and iteratively is the way we should all all been going for a long time. So this is just making that something that you have to do faster because otherwise, you're gonna lose control of it in entirety.
00:11:54 · Neil C. Hughes
[00:11:54] S0: And just to bring to life some of what we're talking about here, especially for people listening. Let's let's try and walk through something here. Why can starting with one narrow, very real problem, how can that create more momentum than launching a a large company wide AI transformation program where everyone tries to boil the ocean? Well, if we start with that one real problem, tell... Walk me through what could happen there.