Transcript
Voice check.
Is that okay.
Okay, everybody. Let's kick off. I'm Adrian King. I'm CTO at elements dot cloud, and I'm gonna talk a little bit about supercharging DevOps. And what I mean by that is actually how do we actually, actually do less DevOps.
And you'll understand why when I I talk through.
I had the, the the pleasure of being here last year when I got down I was downstairs, and we actually did, I did five minutes when I actually was talking about this.
The annual waste in the software industry is about one trillion dollars a year. And, you know, there's a whole bunch of, analysis which has gone on, across just, you know, the scale of failed projects, why they fail.
Since that, since last year when I talked about this, the fact, you know, this is an enormous industry wide problem of the fact that as a as an industry, we, we waste an extraordinary amount of money.
Since then, we've actually done quite a lot of research within elements about, Salesforce orgs. We've got access to, a lot of metadata, and we've done a lot of, using anonymized data, understanding of what's in that data.
And one of the really shocking things that we discovered was that, of new custom objects on the from the orgs we looked at, from new custom objects in twenty twenty three, fifty one point two percent of custom objects created did not have a single record in that object.
Just think about that.
Just over fifty percent of the objects created. Now it is a slight outside chance that it might be an instant object, and that's a really good thing. Okay?
But I bet you the majority of it, it was quite a few thousand custom objects. I can't remember the exact number. Actually, did not have a single record in them.
And then you go into a bit little bit more detail, which is if you start to look at the fields on the objects, those objects which actually have some data, on the standard objects, forty three percent of the custom fields added to those objects don't have a single piece of data in any record.
And it's marginally better on the custom objects that were created. It's only forty percent of fields don't have data in. But think about the implication of that, the amount of work that has gone into building all of that content, the amount of time that a deployment has moved that field from sandbox to sandbox to production, and it's never ever had any data put in it.
So let's go into just some of the other things. These are just a little bit of analysis of the custom fields against standard objects.
What are people doing?
Eighty eight point five one percent of the custom fields put onto the event object has no data in it. I still don't understand why people are putting custom fields on the event objects in most cases anyhow, by the way. But, you know, even Dan, I mean, campaign, pretty good. Forty eight percent of the fields have no data in it.
I I have to admit that when, Zavri, who did this piece of work, my head product management came and showed me the data, I actually told him to go back and check it. Because I knew that things weren't great, but I couldn't believe they were this bad.
And it is actually a shocking, shocking testament to the state of our industry when we are building stuff which does not get used. When half of what we are building doesn't get used, there is a very, very significant problem out there.
If you're interested, QR codes to download the report. It's actually very interesting reading, and there's several others in the research series.
We're we're actually going through looking at aspects of, you know, metadata and Salesforce orgs at the moment. We've done one on permission sets and profiles.
It's a quite scary read, to be honest.
So people who've who heard me speak before, know this sort of slide, which is, for me, the scariest word in the Salesforce world is just. And by the way, I've done it so many times myself. I'll go and go and talk to my admin team and to the my my Salesforce well, actually, my my IT team, which is primarily Salesforce.
Guys, could we just do x?
And it's so dangerous. Because the problem with Salesforce is it's too easy to try and just implement x. The problem is that probably what I actually need is never going to get used, and I've become one of that statistic.
So and and we have it all the time. Could you just do something?
Which is why it's the worst four letter word in the dictionary. Absolutely. Could you just go and do something?
And I actually first came across this cartoon, I don't know, thirty years ago or so, quite early on in my career. And it still resonates with me, which is we are, as an industry, really bad at going and doing this. It's we'll just start coding. It's just too much fun to go into setup and start doing stuff in Salesforce.
And you wouldn't go and start I mean, I was looking I was looking at the the, the very impressive skyline looking across the city. You wouldn't start going and building a skyscraper there without actually having done the architectural work to make sure you knew why you were building it and how you were going to build it before you actually started building it.
We have a tendency to go, I'll go and find out whether or not we need a skyscraper and how many floors. But you guys go start putting the foundations in, shall you?
That wouldn't happen in virtually any other industry, but it happens in ours. And it is a massive problem.
Okay. So, you know, our mantra elements is you need to build the right thing and then build the thing right. And as an industry, we have spent an enormous amount of time, I think, focused on this. And it's very important.
You know, you want to because long term, you wanna make sure you've, you know, coming back to the skyscraper. It's all very well actually getting all the architectural blueprints and know exactly what you want. And then if you build it very shoddily and it falls down, there is a problem. But it's even if you if you don't know why you're building it and what you're building, don't even start building it.
And I say, you know, I've quite a few number of us have got gray hair here. I certainly have quite a lot. It's it's not just a Salesforce problem. It's actually an industry problem, and it's one which forty years ago when I started in the industry was a problem. It's actually worse now, I believe, in many ways. And I think there are, you know, the I started my career in big waterfall projects, where and this this one gets people, particularly in the modern world where Agile, which is from starting a project to the first release was thirteen years.
Okay?
You know, that was well, it was a big big big defense project.
But, actually, the pensioner was swung so far too agile, etcetera. There is a tendency for us to just go and build stuff at this try and iterate to this to to the solution. And we don't actually spend anywhere enough time making sure, are we building what is actually required by the business?
So this is very simple life cycle. I think most people can relate to this. Everybody probably has maybe a slightly different flavor to it. But, you know, the the idea that you actually you actually need to capture and validate the requirements. What is it that we actually need? And by the way, we fail to do that spectacularly in most cases. Even internally, we actually we spend an enormous amount of time before we even start trying to actually work out what the changes are going to be, trying to capture and validate the requirements.
It's it's it's actually very, very challenging to do that well.
But number of times when because and I'm sure all of you can relate to this, that end users don't have requirements.
End users have wishes, and they are fundamentally different things.
A end user will come say, I would really like to be able to do x.
And if you just go and build x, it's probably not what they really need or want.
What you actually need to do is to drill into what do they really need. And we're massive proponents of using, you know, five wise type technique of just drilling through to what the underlying requirement actually is. Quite a few times, we've discovered what they really need, we've already implemented. They're just not using.
That, by the way, is the cheapest development you can do.
And and and and you may joke that there have been a number of times that but we built that for you three years. You just haven't used it. And, actually, that's one of those issues of the waste that is going on. And, you know, that really, really drilling through to understand what people actually need is the cheapest way to do development. Because you often find what they actually want is either supported or not really needed by the business.
You then need to and and that's about genuinely understanding the business processes. It's understanding about what data you actually need. It's it's open to that traditional business analysis type work, from which you can actually go and determine what have you actually got to go and change. And then you've actually also got to go and assess the impact of change, and that is particularly important in the sales. It's actually important in every technology landscape, but in the Salesforce landscape, it's really important.
I don't know actually how many hundreds of metadata different metadata types there are, but I think we're all aware of the dependencies between them. And the best description given of a Salesforce org to me and change the Salesforce org a number of years ago was, it's like playing Jenga.
Every time I take a block out, is my org going to crash down on me? And, actually, you want to make sure because the number of times I've gone and gone well, actually, this is probably gonna be four days to implement, relatively small. And then when you start to go and understand the impact of the change, you go, oh, that's interesting.
We got this flow that we were going to change, but if we change this flow, there are three other flows impacted by this. And then that impacts this. And what was a four day change is now a forty day change. And if you don't do that, you will start doing that, and your four day change will turn to forty days without you understanding why.
So the actually being able to assess the impact of change is absolutely fundamental.
The challenge is lot of organizations like, I've I've drawn the red line from there to there, but actually, the red line, in a lot of cases, should just come from somewhere in the ether.
They actually haven't even done that. Or what happens and and it's in another business I was involved in, what actually happened was they went and asked the users and they went, we're gonna find out what the users for stories are. And they went and actually got a whole list of user stories, and they went and implemented them. They didn't actually do that bit. They just did that straight to that.
And each individual story works, but the business didn't work because the set of user stories were neither complete nor consistent, which meant that, actually, it didn't work. It was waste. It was part of that one trillion dollars. And in that particular instance, a build which is supposed to take four months finally was turned on and working after two and a half years because the iteration time to actually, in the end, they actually had to go back and do that, not very well, but well enough this time to go and work out what the missing user stories actually were. They still didn't do that bit, which caused them lots of problems, but they were then able to actually build something which basically worked for the business.
And something I'm I'm quite passionate about is this idea that when we're talking about waste, there are two types of waste when it comes to software. There's what I call quiet waste, which is you go and build something and it never gets used.
And you have spent thousand dollars, ten thousand dollars, a million dollars, whatever was to build for that piece of capability, and it didn't really meet the needs or wasn't really needed, and it just never gets used. But it's quiet because it just sits there never getting used. Or there's noisy waste, which is waste where you've actually done what happened in that case, where you built stuff, it wasn't right, you had to go back, it still wasn't right. And if they'd actually done the work the right the first time, they would have done it in a fraction of the time, in a fraction of the cost without the waste.
So there's not you know, what's the noisy waste happening in your organization? What's the quiet waste? The interest me about the quiet waste, you just don't know about it in a lot of cases. It isn't until you do that analysis and discover that thirty six percent of your objects have got no data in it, why did you build it?
And I remember talking to, a platform owner for large multinational who admitted, you know, pretty your big organization, team of a hundred people, She believed that probably fifty percent of her user stories added no value, because they actually hadn't done the does is this what's needed? But they were in this constant pressure cooker of being told by the business, we just need this. Do it. Just need this.
Do it. And they were in the cycle of, well, we're told that we have to do this because the business needs this. And, you know, probably, you know, the assessment was it's probably two and a half to three million euros, European company, of completely and utterly wasted development every year.
Now at Elements, you know, I won't tell too much about what we do other than we provide a platform to try and help maintain all the information in one place, what we call a change intelligence platform to help you actually manage this life cycle, particularly the purple. Because where our focus is on build the right thing, so you can actually build the thing right here.
And we're massively complimentary to gear sets in terms of, you know, we actually, we we're gear set users ourselves and internally, which is great. But the ability to actually have make sure that what you're putting into the deployment process is actually things which are of value is absolutely fundamental.
So, I mean, many of you most of you in this will you know, this is a fairly standard type different view of the development life cycle.
We're talking about here about the plan. The interesting thing I find about this is that, one small segment is actually the the front end of this, which is actually where I believe so much of the value gets destroyed or created in the life cycle. Is plan is a very sort of innocuous word that there is an enormous amount to before you go into actually coding and merging and testing and releasing and managing this all around with the source code management and deployment management is make sure you actually know what and why you're building something.
This is a very, you know, the traditional, shift left, and I'm sure most of you are familiar with the concept of shift left, which is how do you identify the challenges early on in the, earlier on in the life cycle. And depending on the industry, depending on the type of software, depending on the project, the the ratios change from the the analysis out there. But the idea that, you know, if it costs you one dollar to actually fix the problem at the beginning when you're trying to actually do the business analysis and then show you requirements, by the time you get to actually finding that problem in production, ten dollars, fifty dollars, a hundred dollars of cost.
You should be trying to pull the problem identification further and further left in the life cycle. And a lot of shift left has been about earlier testing, but the real value in shift left is actually to make sure that you're actually building the right thing in the first place and that you understand what you're building and that you can actually then make sure that when you're testing, your testing does it actually support what the business requires.
However, I actually think that in terms of waste and cost, this actually misses a very, very large part of the problem because we basically are talking about, you know, the cost of fixing something in production.
That's fine. But what about the quiet waste? One of the things which I came across some time ago, which I thought was really, really interesting metric is, what's the total cost of ownership of a line of code in your organization?
If it costs you ten dollars produce a line of code or I call that cost to produce. And I'm gonna go back to so effectively, the cost to potentially basically get it into production.
Through the lifetime of that code, what does it really cost you?
And depending again on the industry, etcetera, the view is that the total cost of ownership line of code is between two x and ten x, the cost of developing that line of code. And the reason for that is if that line of code is in your production, in your source code, every time you make another change to that source code, you have to take account of what's already there. And if fifty percent of what is already there is not being used, you're still having to take account of it.
So the cost of impact, the cost of the cost of making changes to stuff which is never used that you don't know it's not being used because of a change is immense.
So every time you build something, it isn't how much it costs you to build it. It's the total cost of ownership of what you have built, which you should be thinking about. And and it was a number of years ago when this concept was brought to me, and it was actually quite eye opening. You know, I own the I own the budget for building stuff, and I was looking at going, okay.
This makes me think really, really hard about, you know, we built something. And we try very hard elements to only build stuff we need, but occasionally, we still get it wrong. And I look at that and go, not only have I wasted ten thousand dollars of development time, but I wonder what that cost in every other development after this is going to be to me with the impact of what's now in the code base. What it has done, by the way, is it's forced us to get very, very, very good at budgeting now for cleanup because we try not to leave stuff we don't use in the org any longer Because every time if we have a flow which isn't used, but the developers of a new admin doesn't know it's not used, they go in, they try and they say, oh, I'm changing I'm adding a pick list to this this field.
It's used in this flow. I've gotta go and understand what this flow does. They have just spent minutes, hours. They might even go and fix the flow to go not knowing that it's not used any longer.
Or it's it's used because it's in production, but it's not used because nobody in the business actually uses this flow to do any real work. That has enormous cost to the business.
And, if there's if there's only one thing I'd ask you to take away from this presentation, it's this one slide. Because it absolutely made me change the way I thought about what we were building, was that the cost is not the development cost. It is the total cost of ownership of what you have put into the org.
So interestingly, because it's on the forefront of everything we do these days and, is that AI can help, at the moment in terms of speeding up. Because it's all very well going, right, we need you to do more planning, more upfront. That feels like cost. Well, my my first reaction is think about cost. Think about time to value, not time to delivery.
If you're worrying about time to delivery, you're worrying about the wrong thing. Because if you're delivering something no one's gonna use, there is zero value in it. Therefore, there is no return on investment in the work you're doing. So it should always be about thinking about time to value, not time to delivery.
Therefore, actually doing work upfront to make sure you're building the right thing is absolutely fundamental to that.
AI can definitely help on the journey though. You know, so if we come back to this life cycle yeah.
You know, for example, you know, we're now generating process diagrams for text and images. It's incredibly powerful way of getting that analysis done remarkably faster. If you're interested, go and see our stand downstairs, by the way. It's pretty it is actually pretty cool what we're doing there. Actually, it's more than pretty cool. It's really, really cool.
But, actually, one of the problems that people often have with the analysis is a blank sheet of paper. Trying to actually understand what the process is is pretty intimidating from a blank sheet of paper. If you can actually just give a few lines of what you're trying to do, amazingly generous AI is amazingly good at producing the first customer process for you. And once you got the first cut, it's really easy to get people to collaborate on what's already there. It's also really interesting, which is because AI did it, everybody's happy to criticize it.
Now it's really interesting psychologically. There isn't it isn't like you're going and attacking somebody's work. You're attacking OpenAI's work, and we're all happy to do that.
Generate stories and tests from the processes. The ability to go to a process diagram and generate from an activity the user story.
Boob is the first bit of AI we've released in our product, works incredibly well. What's interesting is that the user stories generated probably get a score of about seven out of ten in terms of quality, which you may not think is that good. When we actually start to go through a whole bunch of user stories generated by humans, the quality range between about two out of ten to about eight out of ten.
Actually, this gives reasonably good quality user stories and actually some fine tuning. We're getting them better at the moment, but they're a lot more consistent, interestingly.
Another area which we're doing oh, sorry. The screen. But, finding relevant existing finding relevant existing. I've typed that relevant existing relevant metadata. I was they really didn't read through my own own slides properly there.
Yeah. The ability to actually look through the org using AI to go and say, well, if you're trying to implement this story, you've already got these twenty eight bits of metadata which might be relevant to this story.
Oh my goodness. Does that help not That helps take out technical debt because the tendency is to go and build the fourth field which does the same thing.
I mean, I'm sure you've all been in there and looked at orgs where you've gone, why have I got four fields with the same label?
And it's because people didn't trust what was there and just built another field.
It's incredibly powerful way. So, actually, there's there's lots of other places in this process where we're using AI to augment the process. But actually, there is given given what you're actually doing is generating new artifacts around this life cycle, generative AI is incredibly good at generating artifacts from previous information. So at every point of this step, you need humans in the loop.
But at every point here, generative AI is dramatically improving the productivity of making sure that at this point, you're actually hopefully gonna be building the right thing.
Okay.
One of the answers is just say no.
It's not necessarily gonna be actually what the business needs. Just joking. I'd say, actually, the single most important thing to ask is why.
You've just you've asked me to just build something. The response is, why do you need that?
And drill through. So actually, when you come into the top level of that cycle, you're actually making sure that you actually have a business justification for doing the work.
That's our QR QR code again. Thank you very much, Asafe. There's one thing I'd like you to take away from this is the enormous waste which we have in our industry, which we have in our orgs, and we can all do something about that by just being more disciplined about how we start the process. And, understand that waste is actually the building stuff which doesn't get used is an extremely expensive process for the business because of that total cost of ownership of a line of code.
Every time you put something in there which doesn't get used, it still carries an enormous ongoing cost to you. So, you know, the the title of the talk was, you know, improve your process by a hundred percent. Well, if you actually didn't build any objects which you didn't need, you've probably improved your process by a hundred percent. Thank you very much.
I've got a few minutes for any questions. So if anybody's got a question?
Otherwise we can no?
Okay. Thank you very much, everybody.
