Join us as we gather around the hedge, where we dig into technology, business, and culture with the finest minds in computer networking.

Well, hello, Jonathan.

Is it Jonathan or John?

Or do you Jonathan.

Okay.

Jonathan.

Alright.

Jonathan Adams.

And you were telling me before we started recording that you are aware again?

You are Western Tennessee.

I think you said Murfreesboro.

Is that Yeah.

South Nashville area.

Okay.

So Middle Tennessee.

Middle Tennessee.

Alright.

Middle Tennessee, which is odd because you're in a different time zone than I am, and I'm in Eastern Tennessee.

But a lot of people don't realize Tennessee is a very long skinny state.

And so Very long.

We have two Yeah.

Very long.

So we have two time zones in there.

My wife and I were in Nashville, oh, two months ago, three months ago, for various reasons.

We didn't spend well, we spent some time.

We went to the Ryman, which is always a lot of fun.

I really like the Ryman because it's historical and the hole is cut in the floor where they replace the the piece of wood.

I don't know if you've ever been to the Ryman.

Oh, yeah.

But it's acoustically perfect.

I mean, they didn't design it to be.

It just is.

And so, it's a really, really cool place, I think, the Ryman is, just the history of the place and everything else.

I've actually sang on that stage when I was in high school and in the high school choir, and on the Grand Ole Opry's current stage.

So I've been in both places.

So anyway, so you're Southwest Of Nashville, South Of Nashville, which is really cool.

And what do you your degree is in mechanical engineering.

Correct?

Yeah.

I have a degree in mechanical engineering.

I also have an MBA, but, yeah, most of it's been in mechanical engineering.

Which is very interesting because now you do?

More data science type work right now.

So what what attracted it to me was a lot of the algorithms and applied mathematics.

Okay.

Most I think most data science kinda struggle from that end because they come through it from the coding window, so to speak.

And I'm picking it up from the reverse, reverse warranty.

Yeah.

Oh, it's weird.

Because I'm a network engineer, but I started in electronics.

And so my background actually helps me a lot to be able to say, oh, look, that's physically how this signal is transmitted.

Right?

And most people in network engineering don't know modulation.

And yet when I come to SATCOM systems, I can nail the modulation system because it's what I did for a living for many years.

So Tim has just joined us.

Hey, Tim.

You can jump in.

I wanna see where you where you are physically.

Where are you?

Oh, yeah.

Sure.

I'm in, RTP here in North Carolina, actually.

Okay.

Yeah.

Of course, I've lived in Cary for many years.

So oh, you're in Wake Forest.

Alright.

Yep.

That's right.

I went to college in Wake Forest for a couple of years, so I kinda yeah.

Kinda live in that area.

Southeastern Baptist.

Yeah.

It's a great place.

That's a great campus.

Southeastern Baptist campus is unbelievably beautiful.

It's such a great place.

Yeah.

So, anyway, so we're talking about planning.

Alright.

So, Jonathan, talk to me about what you see in the field in your experience.

Of course, you're coming from more data analytics and more from the mechanical or the mechanical side.

But talk to me about what you're seeing with planning in the field.

Like, you wrote an article on LinkedIn about the problem with planning and how we're not doing enough of it.

Talk to us a little bit about that.

And then Certainly.

Well, one of the things that I've observed here is that, especially with the large push with AI and everything else, is we're so quick to go to development that we don't really stop to plan.

It's how fast can we get the code up?

Can we throw it against the wall?

Debug it?

Does it work?

Execute, push, move on, do our commits.

We'll fix it later if the problem arises.

And for some reason, years ago, I had ran across parts of the Fortran code that NASA utilized back in the sixties.

And I thought, well, wouldn't that make a great article if I could actually pull up one of those entire code sets?

And I was looking to write an article from my personal website, and I thought, well, no one's really gonna wanna see this.

And so, anyways, I searched for it and I found it.

It was a technical document from, 1963.

It's about 98 pages.

And as I read through it, I was kind of blown away because they spent the first 30 pages just laying out the physics, which, you know, you would have to do.

But the rest of the booklet, with exception like the last four or five pages, which actually showed the Fortran code, was all about laying out how the code was gonna progress.

It was this is gonna be all the variables.

This is the variable types.

Here's the table showing the variables.

Here's the nomenclature for the variables, and it was very clear.

If you had this bulletin in your hand and you went to go sit in front of the monitor with this code, you knew exactly what was going on.

And I thought that is so lacking today because we're in such a rush to put code in a file instead of actually sitting down with pen and paper and actually thinking about what we want it to look like, what we want it to do, and why do we want we want it to do it that way, that we're missing out on a lot of opportunity.

And I'm not certain, I'm not certain that we have a lot of time savings in doing this the way that we're doing it today.

I believe the time savings would be go think through it once, Plot it out like you want it to be done once and then go put it in.

But Yeah.

Because because our, computer hardware is so advanced and because memory is is cheap, everything's cheap, and it's inexpensive, we just do whatever.

Yeah.

We do.

And I think there is validity, like, part of what you're talking about here is the agile method, because that's what agile does.

Right?

Mhmm.

We do scrums.

We do that.

Mhmm.

And we just try things.

And part of this is the this culture of Silicon Valley is move fast and break stuff.

Just break it and see what happens.

I think there's some validity in that model, but I think there's a lot of problems that we don't think about.

Like, I am constantly blown away at our lack of risk assessment.

Mhmm.

We never ever I have seen so many architecture processes now and software development life cycles from different companies and different places.

There is almost no risk assessment in, in fact, not only is there almost none.

There is no risk assessment done on there is no failure mode layouts.

There are no what can we do to not have that failure mode.

There there's nothing.

It's complete chaos.

Let's just do it.

So I don't know.

Tim, anything from your end on that?

That's Yeah.

No.

This is great, actually.

This is great.

I like I like what Jonathan said about the idea of, like, nowadays, it's all about race to the the quickest conclusion.

And and I actually, it's great that you said that, Russ, about agile development because that's actually what I was thinking at the same time.

I was like, it's it's kind of a the the waterfall versus agile methodology, and I think there's actually validity in both models.

But then thinking as a as a network engineer myself or an architect or whatever you wanna call it, you know, the infrastructure engineering is all about, you know, risk assessment and then planning for resiliency and all of that.

But you're absolutely right.

From a software perspective, you don't usually see that level of resilient, engineering.

Right?

Yeah.

Yeah.

And just to speak to that point, you know, I come from, an area where I've done waterfall for almost twenty years and have, you know, looked into agile.

And I've seen agile implemented, lots of times incorrectly.

And and agile is great in theory, and it's great in certain, situations.

But when people start utilizing it as an excuse to not plan Yeah.

Yeah.

It it really falls apart.

It's like, well, we're just gonna do this the agile way, and that way we don't have to hold anyone accountable to deadlines or planning or thought.

Well, no.

That's incorrect.

You need to have agile somehow structured underneath the umbrella of a waterfall project and actually have some sort of rings on this project to actually keep it going and keep it under control.

To have certain parts of your project where, yes, this is gonna have to be an iterations because we don't exactly know how to do it yet.

Sure.

Put agile in that spot, but don't just go to agile because of laziness.

Mhmm.

Yeah.

I think the other place this shows up all the time, and I've been talking about this a lot recently, just because I run into it constantly now, is I'll use the example of a car manufacturer.

And if you've heard me, you can just ignore me because I say this all the time now.

If you take a given car manufacturer, there was a time when every car model was unique, but you take a current car manufacturer.

They have three platforms, three or four blocks for their engines that are compressed to different ratios, and maybe one is blown out a little bit.

You know, it's a little bit larger cylinder size or longer stroke or whatever.

And then they'll throw they'll throw a turbocharger on it, you know, or they'll retime it.

But they only have basically two or three engines.

And they have two or three, what they call chassis, which is gonna be wheelbase, things like that.

You know, you have a certain drive train and all the components are certain lengths and stuff.

And then above all that, you throw all sorts of weird sheet metal on it and all sorts of weird features.

Right?

Oh, I throw this sheet metal on it, and it's an SUV.

I throw that sheet metal on it, and guess what?

It's a station wagon.

And then I throw that sheet metal on it, and it's a sports car.

And it's not that that's wrong.

It's that it's brilliant.

It's brilliant.

It separates the complexity of making the car go from the complexity of catering to the market.

Networks.

We don't do that network engineering.

We we don't even like we're nowhere near that at all.

So I don't know.

I think that's very that's very true.

What I've noticed is that over time I mean and and, you know, as the technology has improved over time, you try to build towards that.

But there's so many snowflake like, think about I mean, think about the underlying thing that network is supporting, like, you know, different locations, different It's very hard, I think, actually, until the businesses themselves become some modicum of of cookie cutter to some degree to to build the network that supports that business that would be similarly modular.

Well, we we overblow certain platforms.

BGP.

Right?

Like, please stop adding features to BGP.

Just stop.

If you're out there and you're thinking about adding a BGP feature, don't do it.

Just stop.

Address family.

Yeah.

Please stop.

But then we totally ignore other things.

So, like, again, car manufacturers have three platforms they use.

Right?

Mhmm.

Well, we have IGPs.

We have EGPs.

But we just use them all the same.

We munch everything together.

And really, there should be an IGP platform.

There should be an e b e EGP platform.

There should be there should be platforms and we and there may be more of them.

But I don't know.

Jonathan, does this speak a little bit to what you're talking about in terms of planning as well?

Think so.

Yeah.

Absolutely.

Because, you know, back to your point, the car manufacturer.

Just an example.

This is a real world example.

My Dodge truck, the window switches in it are the exact same as are in a Maserati.

They're purchased from the exact same third party vendor.

Fiat Chrysler did not do that on accident.

They did that on purpose.

Mhmm.

There is a reason they do that because the auto manufacturing industry is so capital intensive.

No one really wants to be in it.

Everybody wants to be in software as a service, recurring revenue streams, everything else.

Networking is the same way.

If you really look at networking as capital intensive Mhmm.

For you not to go in and actually try to shave off some of the cost by actually doing good planning on the front end, you're only hurting yourself.

Yep.

Yep.

Yeah.

I agree with that.

And the market is coalescing to some degree, Broadcom chipsets, no Marvell chipsets, whatever they are, So that we're starting to get kind of this platform stuff in there, but it's unintentional, and in some ways, it can be less than ideal, where the market settles.

So that's another entire realm of thinking about how this works.

But going back to planning, I mean, I I know that the pushback on the idea that we need to do more planning is going to be, you can't plan because you can never gather all the required all the requirements, and you're gonna get so many changes that you can't you just can't get them all in there.

That's the problem with the waterfall.

So, Jonathan, in the real world, do you see people who just get trapped in the I'm gathering requirements phase forever and forever because it the requirements are changing faster than you can gather them?

Yes and no, but probably mostly no.

And I will say this, most of us know, know, especially that have some experience, in our respective industries, whatever that are, is we already know the complaints that are gonna come down the pike.

We already know the people that are going to, after the fact and after the project has been done, is gonna come back and ask for something else.

So we know what something else is going to be, and we even budget for that.

So for us to say that it's gonna be a completely iterative process, we have no idea up front whatever to plan for is ridiculous.

We know exactly what to plan for for at least probably 85% of the things we're gonna run into.

Let's start planning for it instead of just saying agile all the way.

Yeah.

I agree with that.

I actually like what you're saying about the, make agile be more of a directed thing.

Like, you know, use it for this thing where we need to prototype something because we haven't done it before and we don't know what it's gonna be.

And then use kind of that more plan plan model for the pieces that we know are 85% the same.

Right?

Yeah.

Because your the amount of time it takes to actually implement is gonna expand to the amount of time that you give it.

If you actually put hard stops, you can get there faster and get there more effectively, and that takes planning.

And planning is not a time sink.

Planning is a time savings if done properly and directed properly.

Yeah.

And I think we I see that all the time in the world today.

I see tons and tons of people, tons and tons of projects where people are saying, we don't need to think about five years from now.

Just get the product out, get the product making money, get revenue on it, and then we'll figure out where it breaks, and then we'll figure out how to fix it.

It's all software.

It's so easy to fix in the future.

And it's It is lazy.

I like the word I like the word you use, Jonathan.

When you said lazy.

It is and and to the point when I say that I understand you need to get revenue in the door.

I absolutely get it.

But there is a and, yes, sometimes you do have to do that.

You you have to force production.

I get it.

But there is also the when you do that, you know you're lying to yourself.

You know you're not gonna go back and fix it.

Oh, yeah.

Ahead of time before stuff breaks.

You know that you're not gonna go back and and be proactive towards maintaining it.

You're gonna move on to the next fire.

I'm sorry.

I didn't mean to interrupt you.

Go ahead.

Go ahead.

But I just I mean, what we're talking really is is what the more you develop and then get revenue for a for an, for whatever the software, you're you're, you know, getting stepping on the rake of the innovator's dilemma as well.

Like, you know, if immediately, I've got this.

My customers are not paying me.

They expect this thing to work.

They expect their features to be prioritized.

You know what I'm talking about.

Right?

Like, you're stepping on the rake.

Innovator's dilemma right in the face as soon as you start accepting revenue for what you want are trying to build.

Yep.

And and I think and right, Jonathan.

We never go back and fix anything.

It's a joke.

Honestly, it's a joke.

We just let tech debt pile up.

We throw it's like it's like sometimes I feel like we're a bunch of kids with erector sets.

Like, we just go, oh, I'm gonna build a bridge.

Okay.

Great.

Let's just throw stuff together and make a bridge.

Oh, by the way, I want the bridge to be two lanes.

Oh, I didn't think of that when I first built the bridge.

So now I'm gonna make a two lane bridge by throwing this other nonsense on there.

And, like, is that gonna support the wait?

I don't know.

We'll try it.

We'll drive a car across it.

Let's see.

No.

What are you doing?

Like, it's just mounds and mounds and mounds of tech debt, And we just don't even start to think about it, the risk levels.

And go back to the risk assessment question.

We don't even think about the risk levels of what we're producing.

And, like, I I don't like anyway, you can tell I get I get really frustrated at this.

This is like a a thing with me.

More than band aids than Johnson and Johnson.

I I get it.

It's just cobbled together.

But, you know, we don't when we go into a project, we should say, hey.

This is something that we're gonna have to expand and build upon.

We need it to be robust enough that we can do that.

We want it to be robust enough that this is going to be the main platform framework we're gonna utilize for the next five years.

Let's start planning from that end and build it out correctly.

Yeah.

And even if even if we don't know what that use looks like in five years, again, the reason BGP has had all this stuff added to it, and the reason that ISI is frankly, I might may may be make people a little bit cranky about this, but the reason ISIS succeeds more than OSPF does in the real world is because they are platforms.

They are flexible platforms that will do lots of things.

And they were just yeah.

They were designed to be that way.

Yeah.

I know that.

And that's Exactly.

Yeah.

Making them extensible was why people have continued to tack things onto it.

Yes.

It's because they became yeah.

You totally nailed it.

Yeah.

So, yeah, I I I didn't mean to jump in there, Jonathan, but that's that's, I think, your future planning idea, and that's we just don't do that very well.

We build everything as a closed loop, and I don't know.

Yeah.

Look at JavaScript.

We're trying not to.

Yes.

We're trying not to.

Exactly.

We we live with the evidence of this every day.

And, you know, we still do it.

So, you know, you know, you know, there we go.

Yeah.

It's why it's why a lot of our customer facing systems right now are so fragile.

People complain about it all the time, but that's why.

Why is my banking app so fragile?

Java, Java beans.

Need I say more?

Like, what do you expect once, once you've done this?

Like, I don't know what you expect.

Yeah.

And you know, no risk management, no risk analysis.

No.

How could it fail?

No.

Why would it fail that way?

No.

How is it gonna look if it fails that way?

Nothing.

Just let's go build it and and have that.

It's it's a little maddening.

It's funny to hear you talk about this, Russ, because I know we're talking about software, but I immediately think of the fact that when you're building networks, this is almost always the case.

Nobody you you don't very very few enterprises have it.

Like, let's build it in a lab and test network and put applications on.

That never happens.

Right?

We always test in production.

No.

It's always it's always we have a new site to bring up.

We're the two closest sites.

Let's throw some links out to those sites.

We'll make them on queues.

And what for right now, it'll be enough.

Mhmm.

Like, what?

That's how you end up with the Snowflake Netwisher you're talking about where there's no standardization.

Right?

Is it just kinda over time Yeah.

It becomes a disaster.

So I don't know, Jonathan.

Maybe we've gone wandered too far off the topic.

I have no idea.

But so from your perspective, when you read these Fortran manuals and you look at this, which is a very neat idea, by the way.

I love going back and reading old engineering books.

I go back and find engineering books from the early nineteen hundreds on mechanical and and other engineering.

Because just the way they approach problems is just so different than what we do today.

And they built big things.

I'm always astounded.

So I do a little bit of millwork.

I, I actually used to have a mill and I'm going to buy another metal mill here in the next two years.

I hope, and go back to doing metal work and I build furniture and stuff like that.

I know people think this is crazy.

Like I do mill work anyway, whatever.

And we built the space shuttle without glass scales on mills.

Like that is, that is crazy.

There was no way on those mills to, I mean, you had to know the backlash on the knob turns.

You had to know what a thousandth felt like.

Yes.

And we we did that.

We built things to thousands tolerance based on people knowing what a thousandth feels like on a scale.

No real time measurement.

Like, there's something to that.

Yeah.

There definitely is.

And and to your point, the the older the book, the the better it is most often.

You know, I remember in some of the graduate studies I was doing on, aerodynamics and boundary layer theory, Some of the Germans that wrote about that in the fifties, and their heat transfer and thermodynamics understanding was just fascinating.

An old heat transfer book back in the sixties, I think, was, by a doctor White, I believe.

Excellent textbook.

Far and above better than any textbook probably out in, universities today.

Their understanding was concise, direct, and very readable.

And and it it's it's really is amazing.

But they they fully understood the problem.

I mean, because I think they sat with it for so long without solutions.

And I think they had a a greater appreciation for the solution when it came about, when they're able to get it, and they explained it more thoroughly and sit with it.

Today, I don't think we do that.

I don't think we have an appreciation for the problems that we have because we believe we really had the solution.

I mean, just take, for instance, the 600 simple as I need to sit down and write an article.

We appreciate nothing about the writing process.

We appreciate nothing about the words we choose.

We appreciate nothing about the thesaurus because we have the AI genie inside of our, hard drive that's just gonna make it all go away and make it easy for us when we move on to the next task.

We have no appreciation for what we're doing.

And that shows up in our work, and it shows up in the longevity of our work.

Yeah.

Yeah.

Yeah.

And writing is also really bad.

Yes.

Writing is a perfect example.

People don't take care of your writing anymore.

They don't learn to write.

They just well, the AI said to write it this way.

I'm done.

Yeah.

No.

Fast productivity is not the solution to this.

There was a oh, sorry.

Go ahead.

You know, to that point, I I listened to somebody say that they're actually having large problems with this in the humanities and arts classes, even in the, large Ivy League universities, and they don't know how to tackle it.

And this one professor I was watching, he said, we need to bring back the entire concept of teaching rhetoric.

And I thought, well, wouldn't that be insightful?

You know, actually having to convey an argument and defend it.

And what better way to actually get people to write better?

But lots of them are just Yeah.

Just gonna embrace AI.

And I I I can't I I understand it's coming.

It's gonna stay with us, and you can't put the genie back in the bottle, and that's okay.

But to have an entire generation of students graduate with no ability to understand an argument or a clause or anything.

Make one.

Yeah.

Or make one is how are they going to communicate with each other in new commerce?

Yeah.

I mean, or just or solve a problem.

The number of times I mean, again, philosophy degree.

Right?

You know?

The number of times I approach a problem and I think if I can just build a sillism out of this, if I can just build a logical flow of argument, and yet I approach other people with that logic, and they're like, what what is this format you have here?

Like, what is what is that you're doing?

Why why should that be that way?

Because this is the way you make arguments.

It's funny.

Yeah.

I just, recently within the last, six months or so at the, job that I'm, actually leaving, but they pushed to do, like, x number of blogs per week.

Like, that was the metric that they wanted.

And I'm I'm a TME, so they wanted they wanted a bunch of blogs.

Not gonna speak to whether I agree with that or not as a as a method of engagement.

But the point is it got to the point where I was like, you know, if you wanted to sit down and write a a useful, thoughtful blog that actually conveyed something of value, like, you're just not gonna be able to kick it out in the the the amount that they wanted.

So I was like, alright.

Well, I've written a few books, so I can I know how to write?

So let's just let AI fill in the blanks for me.

And, after, like, I don't know, four or five of them had come out, and I was like, okay.

I went back to actually start writing something, like, writing something and not not the blog, something completely different.

And I stared at the screen for a second, and my brain was not responding.

You know?

Like, this is a there's the MIT that recently did the study, with, like, showing the brain patterns of people who've been using AI, and brains are atrophying, you know, from the skills they're handing over.

It's pretty crazy.

It's real.

Well, taking that back to planning, that's part of the problem.

Like you said, Jonathan, people sit with the problem.

They think about it.

They stew over it.

They stand over a water cooler and argue with people, and they think about, oh, but if you solve it this way, I do risk analysis, and I see the trade offs, and I think about it.

We don't think about it anymore.

Right?

And that's, I think, part of the problem we're facing.

People complain about the next gen not having a next generation of network engineers.

Part of the reason that we're struggling with this is because you don't have to think about it.

You rack and stack stuff and things just work, and there's no there's no troubleshooting because, you know, whatever.

So I don't know.

That's I think this all loops back to the whole planning thing you're talking about, Jonathan.

Yeah.

Yeah.

One of the things that, you know, we're all faced with no matter what industry we're in is just, you know, take, for example, all the different languages that we use and have to communicate with each other through all the different processes and say, like, a production facility or a warehouse facility or what have you.

You know, you may end up having, you know, from your, HVAC systems all the way to your PLCs, to your IT, to your network, you know, all these different languages talking.

And they just work now because we've been able to build libraries or patches or something that some person decided to make so that we could do this.

And when that person goes away, who's going to maintain it?

That library gets a bug in it.

How do we fix it?

And the amount of people that are out there who actually know where to even look for this or to make it better than what it was or more robust are are becoming fewer.

And the incentive to do so is becoming less because what works today, move on.

Yep.

Produce something new because you make more producing something new.

By the way, a great a great, fantastic book describing this is called The Soul of a New Machine.

I don't know if you've ever heard of that book or not.

But it's about one of the early deck computers.

And basically, they trace the guy, they follow the guy who's doing nothing but interfaces.

And so all these teams come in, well, I've got this line card, well, I have this interface, I have I have this this hard drive, I have that, I have the other thing.

And this one person who's the manager is sitting in his office building interfaces, and no one knows what he's doing, and they all think he's doing nothing but managing.

But in the end, they put it all together, and it works because he spent the whole time doing nothing but building hardware and software interfaces.

Like, the importance of that, and that again goes back to planning.

The more planning you have, the less interfaces you need, the less the interaction surfaces have depth and breadth, the more you can constrain the interaction surfaces.

As far as their depth and breadth goes, the easier it is to build components around that, and the easier it is to remove and eliminate tech debt.

That just is, like, so obvious to me looking at it from the outside of the system.

I don't know.

I think that's the name of the book anyway, is The Soul of a New Machine.

It's cool.

I have to I have to look that up.

I'm gonna make sure that's correct down here in a second.

Yeah.

Of course.

I mean, planning so I mean well, you know.

I mean, how how often is it where you can do planning where you can go to application owners and say, hey.

What are latency requirements for your latency requirements for your application so I can build the right network for it?

Or how what is the you know, there's there's a it's really hard to plan out things like networks because so few people first of all, there's so many stakeholders.

Right?

Like, everybody's a stakeholder in when you're building a network.

And so it's very difficult to go to to find all the stakeholders that can give you all of the information that you need to do a proper job of planning, an effective network that's never gonna have to change on top of it.

Yeah.

Yeah.

Exactly.

And that's why I think where the way the planning needs to be done is we think of planning as being, I need to nail down every variable.

I need to really what planning needs to be is, alright, I need this class of thing.

Let's go figure out how to make that class of thing fit in this system, and understand the interfaces and understand the risk levels, and all the things that can happen, and build around that.

And maybe today, you can't do variable level planning.

Maybe you can't say every variable I'm gonna need.

Maybe you can for some things, but maybe not for other things.

And that's okay.

Because, you know, because again, that's where the agile part comes in.

Right?

But the big overview needs to be, I've got to solve this set of problems.

And these are knowns.

And even saying these are unknowns is still planning.

These are potential problems.

100%.

100%.

And we don't do that.

We don't look at these are potential problems.

Right?

That's something we don't we don't actually do very well.

Yeah.

And I think most people, if they actually thought about it just as you described and actually went and did it, they would understand that they knew a lot more about the project they're getting ready to take on than what they thought they did once they got it down on paper.

It's like, well, we don't have as many unknowns as we thought.

Mhmm.

Or we have way too many.

Well, perhaps we have way too many.

We have we're way off base here.

Yeah.

You would actually once you get on paper and see it or on screen, however you wanna do it, then you can actually make an assessment as to what you need and how much to allocate and and where agile works versus waterfall and how you need to approach it.

But until you actually do that initial planning and actually lay it out and just try to get as far as you can with what you have today Mhmm.

Knowledge wise, you you should reserve judgment until you've done that.

Yeah.

Yeah.

And, again, even knowing what you don't know, knowing the possibilities.

Okay.

There's a gap here.

There gonna be a new product in there in five years.

I don't know what that product looks like.

I don't need to know right now.

What I need to know right now is how to plan so that that product in five years will be the easiest thing to produce.

Mhmm.

Or build the build the correct connector in it so that whatever comes along in five years, as long as there it's built with that connector in mind, like the interfaces thing you're talking about.

Right?

Yeah.

They'll build an effective interface.

Yep.

That's that's the way it seems to me.

So, Jonathan, anything else you wanna add before we wrap up and well, I appreciate y'all having me on today.

And, you know, I I think that was a great conversation about planning.

I certainly enjoyed it.

And, yeah, if, if anyone ever wants to see any more of my work, then you just go to my website, johnathanadams.pro.

Other than that, you know, I had a great time.

Thank you for having me.

Me.

Okay.

Cool.

I was gonna ask you where people get in touch with you.

So jonathan@adams.pro.

And do you also I I suppose you you're available.

Are you reachable on LinkedIn?

LinkedIn as well.

But, yeah, there's a contact form on the website as well.

So however they wanna get a hold of me, they can.

Alright.

And, Tim, where can people find you?

Yeah.

Sure.

Well, I'm on LinkedIn as well, obviously.

Okay.

I do have a website I haven't officially launched yet, but might as well go ahead.

It's, carpedmvpn.com.

So carpedmvpn, like carpedm.

Yeah.

Okay.

Awesome.

And what are you gonna write about there?

Right now, it's actually mostly a collection of the stuff I've already written and, like, where you can find follow me on social media or connect with me and and stuff like that.

That's not bad, actually.

That's pretty much where rule 11 is now, is I don't write a lot on rule 11.

It's just more of, I'm speaking here.

I'm teaching this.

I'm doing that type of stuff, which I think, you know, is good to have even if you don't do as much, straight up writing.

I might go back to doing more writing on rule 11.

It's just I'm so busy with other training right now and stuff, it's kinda hard.

That's weird.

So I'm Russ White.

You can always find me here at the hedge @rule11.tech.

You can find me on LinkedIn.

I do log in to x every now and again as routing geek.

And, we know that we live in an attention driven economy, that, you know, your time is really of listening to this this program is really what makes things count right now.

So we appreciate you listening all the way to the bitter end of this episode of The Hedge.

And thank you for listening, and we will catch you next time.