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.