Subscribe
Share
Share
Embed
Things always change. Bad original designs, new tech, emerging process models. We're constantly confronted with necessity to change our ServiceNow instances, sometimes fundamentally. In this episode we talk about coping strategies for The Drift.
Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk
[00:00:00] Duke: Hey everybody, welcome back to another CJ in the Duke. My name is Robert, the Duke Fedoruk
[00:00:04] CJ: I am Corey, CJ Wesley.
[00:00:06] Duke: Dude, how about that new intro,
[00:00:08] CJ: listen, when I first heard it drop, man, let me tell you, right? That's it right there. I didn't think we could replace the original, but I heard that one. I was like, yeah, that's it. That's us.
[00:00:19] Duke: Kudos to our performer. Chills. Music will have a link in the description below if you want to contact him. My goodness, , we went to this guy talk about ServiceNow and iem, uh, I T S M and custom apps and self-improvement and I was like, how good could a wrap about that beat?
[00:00:35] CJ: Right,
[00:00:36] Duke: you know, so,
[00:00:37] CJ: Like who raps about service? Now we do
[00:00:42] Duke: Big, huge thanks to Chills music.
We'll have links to his work, , in the description below.
[00:00:47] CJ: Yeah, no doubt. No doubt. Big shout out, man. Thanks for, we appreciate that.
[00:00:51] Duke: Also, huge shout out to our sponsor.
All right, Corey, what are we talking about today?
[00:00:57] CJ: today we're talking about the drift
[00:00:58] Duke: The drift
[00:01:00] CJ: Yeah. Yeah. People are at home are like the drift. What's the drift? Right? Like the service. Service Now drift. Like a lot of people are nodding like, yeah, I know the drift. They don't know the drift. They have no idea what we're talking about. Duke, , what we're talking about with the drift is that phenomenon that happens that when you build something, and it could be best practice today, in a year, two years from now, something has surpassed it, right? Like you've, you've built on top of it.
Or ServiceNow has built something that's out of the box versus, something custom that you did because it didn't exist on the platform or just a new paradigm , has emerged in terms of how you do development or how you manage, teams, whatever the case, right? Like technology has advanced as it is want to do, And the thing that you did, 18 months ago was best practice is no longer best practice.
[00:01:49] Duke: Yeah. Or just not a good idea or, maybe it was a great idea at the time. Right, and it's.
[00:01:53] CJ: Right.
[00:01:54] Duke: things change, and it's not like, not even just your preferences, your preferences might be the same, but other stuff might have happened in between. So a couple examples, I guess to just really drive it home.
I mean, for those of us who are real timers, right? 20 years ago was like, I till I, till I, I tell, I. And then, Agile comes along and there's contention between the two frameworks. Like, do I till No Do Agile, and then DevOps comes in and C I C D comes in and they all have ideological overlap about how stuff gets done.
[00:02:23] CJ: Right.
[00:02:24] Duke: but I a lot fewer people were talking about C I C D or DevOps 20 years ago than were talking about i l But these frameworks emerge these ways of working that people want to do. And it's like, but ServiceNow is, built the better part of 20 years ago, back when I was the thing.
[00:02:41] CJ: Yeah, that evolution from one thing to a ne to the next,
[00:02:45] Duke: And another, , source of drift is in technologies. old timers on service Now, remember a day when we were talking about c M s, when we wanted to have a great user experience, right? It was like, well, we have to build something in the content management system.
[00:03:02] CJ: Yes, the good old content management system with jelly included
[00:03:08] Duke: Oh, jelly. Yeah. Hmm. Gonna have James Neal on the show to talk about how awesome Jelly is sometime.
[00:03:14] CJ: Think about it though, dude. We started off and that's where we were. We were dealing with, , things in the jelly language. Right. And , now we're at service portals and, , the now experience and, , things continue to move forward, right? That's the drift that we're talking about.
You might still have a c m CMS site and it might still be perfectly functional, But if you want to go ahead and update that thing, Every time you go to think about updating it or trying to maybe implement something new, you have to have this, conversation with yourself. And it's like, is now the time to upgrade?
Like, has, is, is this thing been passed by to such a degree that it no longer makes sense to put in the effort on the old thing? And should I now be thinking about going to the new thing?
[00:03:56] Duke: to put it bluntly, nothing's future proof, right? Or the fu the, the, the future proofness of your thing. Diminishes over time.
[00:04:05] CJ: Yes, exactly. Inevitably. Inevitably in technology, the future proofness of your thing diminishes over time. That's it concisely.
[00:04:13] Duke: those are just some examples of drift. So there's process examples. Itel, agile, DevOps, C I C D. There's technology. Drift via c m s to service portal to, next experience. We also see it in, workflow on ServiceNow. The,
the what was the very first workflow engine on ServiceNow
[00:04:33] CJ: Oh man. See that one predates me even a little bit. I know what it is, but I never used it.
[00:04:40] Duke: A lot of people would think, oh, it's legacy workflow. No, there was a time when we had execution plans and execution plans were basically like think about flow designer, but no graphical interface.
It was all just forms and related lists. and it was way less cool than even that sound.
Sorry, we're totally getting on a tangent here,
[00:05:00] CJ: I think it's spot on, right? And it illustrates the drift that happens in an instant, even when you're doing the best practice thing of the moment, you can be all in on execution plans, because , that's best practice then.
And then the legacy workflow, editor comes out and by the. At the time, it wasn't called Legacy
[00:05:18] Duke: Yeah. Yeah, right. . It was just workflow.
[00:05:20] CJ: It was just workflow, right? And so now you move in all at some point you move all your execution plans to workflow. But before you start moving them, you have to have this conversation about is now the right time to move them?
right? Is this workflow thing gonna stick around? Is ex our execution plans. Now, I, I know how to do these things with my eyes closed. Maybe I should just stay on this stuff, right? what am I missing out on? Then you get to a point where now the technology gets deprecated and there's no longer support for it, and then you have tos.
Start maybe making those decisions or not still right. Like that's the drift and that spawns all of these crazy decisions and all, and sometimes issues with your instance over time, right?
[00:06:02] Duke: It's, you can't get to a point where it's like, we're safe. This is what it's gonna be. Right. Because you, you know, the system's always growing and so it's really just the art of it all is becoming good at, future proofing big air quotes cuz we're not entirely future proof, but also internalizing the idea that this is going to change and we should rather get to the point of the doomsday scenario episode that we had that will be in the description.
[00:06:25] CJ: Yeah.
[00:06:25] Duke: Where you, you basically have to build the whole thing from scratch, but can we take this on as operational skill so that we are just better and better at changing the system rather than, rebuilding the system every three to seven years. And just before we go, there's like, we covered process frameworks, tech frameworks.
I think there's two other drift sources that are worth mentioning before we go on. Coping with Drift. and that is bad ideas from the past. So literally, like, we should have just built this better. , and two, the stuff that you build that ServiceNow now has a solution for. So with those examples of Drift, now let's talk about coping strategies.
[00:07:04] CJ: Yeah. Like now that you got drift, right? Like how, how do you dig yourself out of
[00:07:08] Duke: yeah, exactly. And you will get drift, right? There's no, like, we don't have drift here. That doesn't, that's not a thing.
[00:07:14] CJ: Yeah. Yeah, exactly. Everyone has drift on the instance. I bet even if you, if it's a freshly minted instance and you just went live yesterday, you have drift, right? Because at some point during the uh, implementation, you decided that this version is probably good enough for go live, right? I'm not gonna implement this patch or this new hot fix and do all of this regression testing.
Right. Now where we are is good enough, And we'll deal with the rest of it after we go live. That's Drift, Yeah. So I mean, even if you think you're not gonna have it, you are already having it. Most likely.
[00:07:48] Duke: It's like, it's kinda like aging almost, right? . So maybe instead of like framing drift is, drift is a big, bad thing. No drift is just a reality of, life.
[00:07:57] CJ: Yeah.
[00:07:57] Duke: like, it's, more like how do you, your postures and procedures for dealing.
Versus it's a bad thing. We have to stop it. You can't stop it.
[00:08:05] CJ: Yeah, I mean, , you know, my one, one of my favorite expressions is right, like, you know, universe is trending towards, entropy, right? Like where everything is, , essentially going to die. Well, I look at this as a little bit as a reverse, where, , technology is trending towards, , efficiency.
And the further way you get from your similarity point, your point of creation, right? The more things get sophisticated or, more technologically sound or efficient, And you have to start making those decisions on where you are in the drift cycle and what you need to do about it, right?
And that's why we're talking coping strategy. So, duke, go ahead with the first one,
[00:08:37] Duke: Uh, uh, It's funny that you said this one. So the first coping strategy is drum roll please. Documentation
[00:08:52] CJ: What
[00:08:54] Duke: Surprise. The first thing we talk about in 2023 is documentation
[00:08:58] CJ: documentation?
[00:09:00] Duke: Yeah, but that horse doesn't quite look dead enough, so let's just grab the
stick and beat that. Just beat that dead horse a little bit more.
[00:09:07] CJ: No. I mean, last time I looked at the horse it was still . Running around, dude. So we gotta go in on it.
[00:09:11] Duke: It's still wild and untamed. Okay. But, I go on and on and on about it, but I go on and on and on about it for a reason. And so, as you decide to deal with the drift in your organization by either realigning with. Certain out-of-box principles or rebuilding apps or significantly changing the nature of stuff that you have deployed.
You have to know where the bodies are buried. You have to know where the minds are. , and there's no better way of doing that than by keeping up a good memorialized documentation of how this thing is built. And I'm still shocked to this day about how resistive. Some people are to this, Oh, it takes so much time, not as much time as having to figure it out when you need it. Now,
[00:09:59] CJ: Right,
[00:10:00] Duke: it's not nearly as inconvenient as not having it when
[00:10:04] CJ: Duke, you you know what surprises me is not so much how much the engineers and architects are resistant towards it. It's how much sometimes the organization is resistant towards it, or why this is sometimes such a struggle to be mandated at a, at a project level, right?
Or, group level. Or a product level, right? , and especially in the ServiceNow ecosystem, there's a lot of, , systems in internally, in, in most organizations that have a lot of documentation because they are thought of as business critical or mission critical, right? Like your DR system is obviously gonna be documented, right?
Because if worse comes to worst, you need to be able to fail over. and how do you fail over without documentation or knowing how to do that? ServiceNow seems to be still treated in a, in a less than equal , standing And documentation is still an, an afterthought, , not just with the engineers and architects, but also with the organization.
And so when you have people who, like you and I, who come into an organization and they say, first thing we do is make sure we got documentation. And, and by the way, do you guys have documentation or any of this? Can you provide me with what you have so I can understand how your instances built?
And they all kind of look around the table at each other and what does befuddle look like? Documentation. What's that? Right? And you're like, okay, well fine. First thing we need to do right, is establish how I'm going to document this product that I'm gonna build for you guys. And they're like, well, no, no, we don't wanna do that, that's gonna take hours.
Like I want you to build stuff, right? And then,
[00:11:26] Duke: Yes, exactly. Like you should be building, you shouldn't be documented a a as if they are of the same scale, right? I spend way less time document , I've been building an app for a company for the better part of last year, at some level I've been like, you know, gently designing this app for them and.
You know what I mean? I've spent so many hours building the app, but it's like I put together the documentation in a handful, I'd be shocked if it was 5% of the total effort.
[00:11:55] CJ: Yeah.
[00:11:56] Duke: it's it's not even worth worrying about. just do it.
And we also talk in it about business continuity and business, resiliency and all this kind of stuff. And those are big boardroom type discussions. And we come in as ServiceNow folks, all
serviceNow is a big boardroom discussion too. And ServiceNow can do business resiliency and business continuity. And except for the fact that it's a minority of people who will leave you with documentation when they do.
[00:12:21] CJ: Yeah.
[00:12:22] Duke: Talk to me about business resiliency and continuity. If you're not gonna leave any documentation with how you built this stuff,
[00:12:28] CJ: I know and, and well, you know, and folks, have that crutch, They think, because it's in the cloud. Right. That they don't have to think about that. Right. No, it's in the
cloud. It'll
[00:12:35] Duke: code, right? It's low code, Anyway, we can't overstate it though. We can't overstate it. What are you supposed to do? If I just pie, charted all the hours that I did last year, of the apps that I had to replace or significantly alter, I'd say like 50% of all the time I spent on that stuff was spent trying to figure out how and why it was built.
[00:12:58] CJ: Hmm
[00:12:59] Duke: And I'm not talking like five, I'm talking like 40, 80 hours to back engineer this stuff before I do work.
[00:13:06] CJ: this is a really good point, right? Because let me tell you why documentation is actually not an additional effort, right? But why is, an effort saving feature? Because when I come in and you want me to build something for you, The first thing I need to do is understand what you want me to build, how it works, how your internal system works off grid already.
Right. And while I'm doing that, that is the documentation production process, or at least a part of it, right? So at the end of those sessions, what we should have, is some kind of. That's documented about how that process works. We should know the touch points. We should know, who and what are inputs and outputs, things like that.
That's documentation. And that's gonna save me time in trying to build it because now I don't have to have countless meetings with stakeholders asking them. And so what group does this go to again?
[00:13:58] Duke: All right. We got some other coping strategies here, but I think that one's the easiest, lowest hanging fruit to help you against the drift that just clearly isn't being done.
[00:14:06] CJ: absolutely. You gotta know what you're building and, and why you built it. next one, duke Design for Replaceability.
[00:14:14] Duke: Hmm.
[00:14:15] CJ: I like this one because it encompasses, \ , modular development, techniques, right? Like strategies, right? It, it kind of lends itself towards agile development.
We're building things through stories, right? Where every unit of work should be individually testable. Right, and, from that perspective, you should be able to go in and microservices, right? As a whole, microservices push. That started a long time ago and it was maybe, I don't know if it's catching up in the Service now but, you know, it, it is a, a, a thing that a lot, I know a lot of good developers do, right?
A lot, especially in my circles. so, Take design techniques and design patterns , from, , some of these things, and you start designing things in this kind of micro way where they interact with each other, modularly, They can also be replaced in that modular micro kind of perspective, right?
So if you need to replace something, so you build the. whatever it is a function over here and it, does this thing, and there's a new way of doing this thing. It's now ServiceNow, switched all the state models to an internal scripting clue. For example, , right? Like if you built that for Replaceability, you can plug in their thing and take your thing out of the loop.
And kind of keep it moving with minimal effort. , so that's what we mean by like design for replaceability. Never assume that the thing that you built, no matter how proud of it you are, will still be the thing in 10 years that is state of the art and that will be used, ? It's possible that something else surpasses it, that the functionality gets incorporated into the platforms on and so forth, So you should design these things so that it can be easily subbed out with better, with bigger, better technology, more efficiently and whatever,
[00:15:46] Duke: Yeah, and I think, part of that is documenting, part of that is, , really understanding the catalyst, like what makes it start It's integrations with other systems, it's logic.
It's just like understanding that app and make sure it's compartmentalized. Like I think scopes I know they aren't perfect, but keeping an app in a scope is, a great way to design for replaceability.
[00:16:09] CJ: Yeah.
[00:16:10] Duke: like, imagine. The stuff you just build in global, it's not bound by anything common. So if you're like, that one paradigm that we had to design for and it touched all these other things, how would you bundle that all up and shut it off you can do that conceivably in a scope, but you can't do that just by building a.
[00:16:28] CJ: And, and that leads itself to building these , microservices, That you can, Swap in and out, Because you know, they're in this scope, they're in the sandbox, right? And you've got like the inputs and outputs documented, And now you can build them differently or you can swap in a ServiceNow service that they're now included in the platform.
And now you don't have to maintain your code. So that's one piece of drift that you no longer have to worry about, Because now it's baked into the platform and you can let Service Now worry about that. we're calling this kind of coping strategies, but, but a lot of these are kind of like planning strategies too, thinking about how you do the project and how you do the thing before you start to do the thing. Honestly, I'll be real here. , I don't think. Most of us spend enough time thinking about how to do the thing before we actually do the thing. and I'll be honest, like I'm the first one to admit that sometimes I'm the person that's like, oh yeah, bright and shiny, let's get started.
and not spending nearly enough time thinking about like, , what's the best way to do this? Or what's a way to do this that, will future me like three years from now, , won't wanna slap past me. Right? Like, cuz I've had that happen a lot and I know we all hate our old code, but I've really painted myself into some corners.
It sucks
[00:17:37] Duke: well some of this just came to me right now, like just bringing together some of the content from our other episodes. How would I design something to be replaceable besides documenting it? Right.
[00:17:48] CJ: Take a shot every time we say documentation
[00:17:52] Duke: That's the new rule for 2023 shot every time we say documentation,
[00:17:55] CJ: Amen.
[00:17:56] Duke: 18 for this episode. Some
[00:17:57] CJ: Yeah. Right?
[00:17:59] Duke: now,
[00:17:59] CJ: Yeah. Swap out some of those award shots for this episode.
[00:18:03] Duke: but, if I said we should probably replace this application we built on ServiceNow years ago, how would I know if that's a good idea? Even if I know that the technology will. And it would be because I understand the outcomes that we're trying to achieve.
[00:18:17] CJ: Right.
[00:18:18] Duke: like I built a A project management utility in ServiceNow age is before I TB M came along and when I T B M did come along, I knew it would work as a replacement because it was there to build work breakdown structures.
Right? What are all the tasks and when do we have to.
[00:18:35] CJ: right.
[00:18:36] Duke: you know what I mean? Like somebody may have made an HR app, which was exclusively for say, anonymous reporting. But HR V one from ServiceNow came out and didn't have that feature. So it's like, well, they're both hr. No, they're not. They're, they're satisfying completely different outcomes.
So you have to library your outcomes and keep on remembering them so that you can replace it with something bigger and better when the same outcomes can be achieved.
[00:19:01] CJ: exactly, exactly
[00:19:03] Duke: And then, then you have your compartment, right, your little scoped. or maybe you're building a second scoped app, but you basically have a way to encapsulate it all. So you know what the app is from a mechanical scent, what gears and
[00:19:15] CJ: Yeah,
[00:19:15] Duke: widgets and whatever. Make this thing the thing.
[00:19:18] CJ: All right, so next one, duke, ask sooner and more frequently if now is the time to switch from your custom thing to your out of the out of the box thing.
[00:19:29] Duke: Well, that was a good transition, It's almost like we planned this out ahead of.
[00:19:36] CJ: knew but look tech debt, , is a fact of life and it's is something that you can't avoid and drift over time. Looks like tech debt, So when you think about it, you need to be asking yourself. early and often, Whether or not the thing that you built is still the thing that needs to be running and whether or not it's time and it's possible.
To switch to something that will incur you less tech debt going forward, that's really what it's about. Right? And the reason that you wanna look at that early and often is because if ServiceNow, we're gonna just use ServiceNow's, pension of building out of the box stuff, because I think what they do right is they, they get understand that they're customer base. and when you know enough of us are needing a certain thing, then they go and build it. Right? They don't build stuff that not enough of us need. Right. It's a kind of a waste of resources. So let's say, you know, like it T B M, right?
Enough of us are needing this thing and then they build it. But you've built the custom, Do you wait three years before you ask yourself if you sh if you should migrate to that thing, or do you wait three months, That's the question that you should be asking yourself, and the only way to know if you should wait three months versus three years is to be asking yourself that question.
Every three months or every six months, you know what I mean? Instead of waiting every two years or every three years to ask yourself that question, ? Because ultimately what you want to do, , to reduce drift here and to reduce this tech debt is you want to be able to pass the thing off that you have to maintain to somebody else to maintain it. Right. Like that's how, that's how, that's how you reduce drift, right? Like, you, you gotta pass this off to service down and maintain, right? I, I built this custom, this custom thing, right? And, and now I gotta think about like whatever service down's gonna upgrade or, or whatever changes they make to the platform.
And whether or not my stuff's gonna be compatible, I know their stuff is gonna be compatible with their stuff because they built it.
[00:21:26] Duke: Yeah, well the, the chances are just better, right? we have this crazy custom app, and it basically means that we always have to have somebody who's always waist deep in it
[00:21:36] CJ: Right,
[00:21:37] Duke: to sustain our own knowledge of what the thing is. And again, I'm dealing with a customer like this right now where they have this huge app, they use maybe 20% of what they had built for it to do,
and almost nobody knows how it really works.
basically, we're spending tons and tons of time. Five x the time, 10 x a time, getting to the point where we can modify it. sorry, I'm totally going on a tangent there,
[00:22:01] CJ: Nah, you go for it, man.
[00:22:02] Duke: But basically, if ServiceNow came out with something that did that, we'd want to immediately start asking now the time is now the time because it's better that ServiceNow engineers figure out precisely how this works and keep that discipline over on their team so that I can free myself up to worry about other stuff.
[00:22:20] CJ: Yes.
[00:22:21] Duke: have to worry about this, anchor I've got tied to my.
[00:22:25] CJ: Yeah, yeah. You don't have to manage the drift, right? Let them manage the drift.
[00:22:30] Duke: and this, I think this bleeds into the next point of, you know, you're gonna ask frequently, earlier and frequently, Is this something we should rebuild ourselves?
Is this something that ServiceNow has an out-of-box solution for? Should we do it? And , instead of just waiting until it's a disaster, ask it more frequently. And the asking more frequently is basically operationalizing your posture against your, I can't believe I said operationalizing, but but
you know what I
[00:22:59] CJ: going to Accenture's gonna send you a pen on that one.
[00:23:02] Duke: oh, nice. I need another Accenture pen. You know what I mean? I force myself to spend a little bit of my own kt, keep the lights on time, making sure that I'm staring drift right in the face.
[00:23:13] CJ: right.
[00:23:14] Duke: , otherwise if you don't do it that way, it's just when will the disaster strike?
[00:23:19] CJ: and we've talked a lot, about the technology aspect of Drift, but it's not just technology, It's also business process and business business alignment, right? Like your solutions and your outcomes that you're looking to get out of the technology. You know, we should be asking the questions.
Does the business still need this thing that we built?
[00:23:37] Duke: Oh man. And tell, show me a three year roadmap or a ServiceNow instance that hasn't changed every year of that three years.
[00:23:44] CJ: Exactly
[00:23:45] Duke: Because something new comes out, it's like a new disaster. covid right now, everything's shifting from, oh gosh, we gotta optimize our assignment rules to, Hey, we need an app to do contact tracing or, or some new compliance framework comes out and the government's gonna take all our money if we're not A B C D E F G compliant.
[00:24:04] CJ: Or we sold that division that did the thing that we had the app for, right?
[00:24:11] Duke: so yeah, making sure there's kind of an operational, view of this.
[00:24:15] CJ: ultimately, drift while we often think of it from a technology standpoint, and we often, often implement it using technology like it also, you have to step back and, and think of it, , encompassing of the business strategies and the business, , outcomes as well.
All right, so the last thing on this list I think is don't overdesign.
[00:24:33] Duke: Yes. Don't over design. We've all been in that situation where There's lots of stuff that you can add to ServiceNow that quote unquote, would be nice,
[00:24:42] CJ: Yes.
[00:24:43] Duke: And it's usually driven by someone's persona, some one's persona. So yeah, it would be nice if we had a sub subcategory
[00:24:51] CJ: Yeah, yeah,
[00:24:52] Duke: But just in this one, just in this one instance, right? You can hide it for everybody else, but for us, we want this.
[00:24:58] CJ: yeah.
[00:24:58] Duke: And the more of those that you entertain,
[00:25:02] CJ: Yep.
[00:25:03] Duke: the harder it is to deal with drift. And like those people go away, their interests change over time. , and I'm not saying this is an easy thing to do, especially for beginners man, but,
[00:25:16] CJ: you got, well, that's the art of saying no. Right? And, and I think we've d we, I think we've talked about that a lot on some past, episodes. but that just bears with saying again, right, the art of saying, no, you gotta know how to tell your stakeholders that you don't want to do this and make them believe you.
[00:25:30] Duke: but the, the gray area is that some of the stuff could be good, it could be convenient, but is this the kind of thing that's gonna last? a long time. And if you're in the habit of entertaining Team whims, whims is the wrong word, but like a team says, oh, just do this for us again.
Make sure you're documenting it and make sure that as a part of your everyday life, you say, do we still need this solution? Can we rip it out? Can we get rid of it? because the more you overdesign and make things super, super, super nuanced, the less flexible you make it for the.
[00:26:04] CJ: Absolutely. And the more brittle you make it for the future, right? , and what we know about ServiceNow is that it exists in the cloud. And we know, also know that ServiceNow has a roadmap that they've committed to, that they hit almost without fail, Two major releases per year. That means, you've got two opportunities there where code's going to be refreshed on your instance and. By going through these exercises, you can ensure that your instance isn't too brittle to take the n the the next version of service.
Now that might offer something that you'll find valuable,
[00:26:36] Duke: Man, there's something who said in there too, because remember, there's that n minus one policy. So it's not
like to some it might be an opportunity to others. It's we just caught our breath You know what I mean? And, and we have a brittle instance full of stuff that we don't really know about ourselves.
[00:26:53] CJ: Yep.
[00:26:53] Duke: and has more, probability of getting, a failure on because we went super, super, super deep and nuanced and not just minimal, minimally viable. you know, for them upgrades aren't cool and fun and quick and easy for them. Upgrades are like, basically, there's a third of a year gone for project.
[00:27:13] CJ: Yeah. Right,
[00:27:14] Duke: Maybe even more than that. Um, there's companies out there and I see more and more of them. so much more of their year dedicated to just keeping up with N minus one. Forget all the other value propositions.
[00:27:26] CJ: You know, dude, and I think we should cover that, right? In a, in a future episode, we should talk about how do you keep up with N minus one, right? Because there's some stuff that you can use, and we talked, we touched on a few of those things, today, right? Documentation being one of 'em. Take a shot. , what we didn't talk about was instant scan, right? Which is another one that helps you maintain, your flexibility and your speed of upgrade, There's a few things built into the platform that allows you, to move with a bit of speed, To keep up with N minus one. I think it might be worth a separate episode. What do you think?
[00:27:57] Duke: Uh, I think we should do it. All right, by speaking of next episode, we are 36 minutes in for recording, so we're gonna drop you off here. Thanks for watching. Hope you love the new theme song. Give us a comment and a like,
[00:28:07] CJ: Smash that light button out.