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, Tom. How are you? Hi, Russ.
I'm doing great. How are you doing?
Fine. We saw that you were trying to
read all the books.
Yeah. I decided to podcast. Try to cram
in this morning and read everything on my
shelf so you couldn't harass me, but I
failed. So
Could you just find something else? I would
find something else. No worries.
So I was saying
on no. It wasn't a this it wasn't
a podcast. I was saying that I went
to my aunt's house
and over last weekend, whatever, a couple of
weeks ago, and
she was like, I'm getting rid of all
my my husband's books because he passed away.
And so
I went back in the in his shop,
and he did electronics. So I bought I
picked up, didn't buy, picked up, didn't bring
home with me a couple of electronics books
because they're, like, from my childhood and stuff
as well. I mean, these are old, old,
old books on electronics.
Old books if they're from Russ' childhood. Yes.
From my childhood. Yes.
And I realized that actually one of them
is
a book that I had on my shelf
when I was a kid that somehow migrated
to his shelf
and has now migrated back to my shelf.
And another one was had migrated from my
stepfather's shelf to his shelf.
So it's it's just kind of like, wow.
That's that's just
odd.
So
Yvonne is with us.
Yvonne Hello? She shed.
I am. I'm always here.
Does the she shed have a circular door
like a hobbit?
I do not have a hobbit door. No.
That's just really sad. I know. I just
have a regular door, but I do have
a frog lamp.
I do have a plant that's off screen.
You know, I've got my books.
Yeah. But you need a
dolls. You need a and my He Man
toys,
all the relics of my childhood.
Yeah.
Well, so you don't like Skeletor. Is that
it? I don't have a Skeletor. No. Actually,
I just have,
Teela.
If you remember if you watched, you know,
she was the the female character
in He Man because all of those stories,
they at least had one girl.
And so for He Man, it was Selah,
so she's on my shelf back there.
Okay. Well, good.
So let's start today. This is just a
roundtable show
with this blog post from Thinking Sideways,
talking about the software documentation trifecta.
And, you know, I know we all love
to hate documentation.
Some people like it. Some people like it.
Well Depends on if you're using it or
creating it. Exactly. Yes.
Yes. Exactly.
I was gonna say, Tom, if you actually
enjoy creating documentation,
I just don't know if we can even
be friends. Oh, am I not allowed to
admit that publicly?
Oh my goodness.
This should be the tagline on this episode.
It gets real with Tom and Russ.
Russ learns something about Tom that makes him
question everything about it.
That could be.
So
I thought it was interesting, this article talking
about first of all, this this the blog
post starts talking about it's from thinking sideways
for anybody who wants to look it up.
Talks about the three kinds of documentation,
documentation
for developers, customers, and management.
And when we think about document you know,
we can convert that to network engineering. This,
of course, is a coding blog
that we're we're looking at here.
But documentation
for
what would we say?
Operations?
Yeah. Let's say operations is the equivalent of
developers in this context. Yeah. Well, actually, I
would split developers in two. It would be
operations
and
the why,
future designers,
or design documents, maybe.
And then management, what would that look like?
Like, that's a little that's a little I
think that would be more high level,
documentation
diagrams. I know that, I was once asked
by a leader
to put together
a a diagram,
and,
you know, the the response I got back
is, like, take all these IP addresses off.
Take all you know, like, it's it's got
too much information on it. Like, I want
a a a notional diagram or something that's
more business focused that gives us a very
high level view of what's going on, but
I don't want any of the specifics. Nobody
cares about those.
It's like and and so there's a there
is and and sometimes that can be extreme,
but there is a level of documentation
of your environment
that
helps provide a conceptual
overview
without all of the implementation details. So I
think that's,
that's one level that might map to,
to management. And and the other is still
the same that's here, like issue trackers, project
plans,
schedules, things like that,
status documents.
All of all of that is still important
for management of a,
you know,
a a a operational networking team or an
engineering team or any of those things. Yeah.
I thought when like, what are the clear
features? And when we think about this, the
problem for management is
management thinks of features as products
that are shipped to customers.
But that's not really what we're talking about.
We talk about networks.
We talk about features like
a virtualization overlay that enables products
to me
rather than the products themselves.
I face this all the time.
What products are there? Well,
you know, they wanna think about things like
what applications are being supported.
Well, that's not really
a feature of the network.
The feature of the network is whatever enables
that application to be supported,
not the application.
Virtualization
or
quality of service or traffic steering or traffic
engineering.
And and what I think you'd find if
you start looking at that way is that
almost all networks have the same set of
things
that they support
in one way or the other in maybe
with different levels of emphasis.
I think what you would find so the
level of interest that different audiences have in
the in the knowledge that's available about a
given network versus code base,
you know, a manager doesn't really care what
variables are named in code
or or what how the data structures are
laid out. That that doesn't really matter. Those
are those are below the level of a
feature to them.
And and I think the analog in the
networking world would be like like, I don't
I don't really care about an l two
overlay.
What what probably what what a business leader
cares about
is what revenue stream does this enable. And
that would to me would be the the
equivalent of like a feature. Like if you're
looking at a code base and you're purely
just software development.
Like, the feature is the thing that makes
money for the business. That's what the that's
why customers buy the thing.
You know, and and with networking, it's kinda
it's one layer hidden below. Customers don't buy
overlays. Customers buy,
caching services or customers buy, you know, the
content delivery network. They don't they really don't
the inners of it. Like, when I go
to buy a car, I don't buy a
spare tire. I don't I don't buy an
engine. And so I think at least and
the one of the things I think is
interesting about this article, you look at the
volume of words, the one that is the
biggest by far is the management focused one.
The rest of them are it's just it's
it's small. I think that's really interesting. Yeah.
And I and I agree with you about
the car. But on the other hand, if
I'm documenting
what the car does or or I'm documenting
the car to the management,
I'm not gonna say,
the car gets groceries.
I'm gonna say the car enables the application
of getting groceries.
How does it do that?
It has an engine.
It has wheels.
Right? It has things that make it able
to go do that. Or I mean and,
actually, that's not even true either. I would
actually say, how does the car enable me
to go get groceries? It is a trunk.
It is a place to store groceries.
It is a place to put people.
It has a places to do things.
And so I think we think of the
network as either this detailed,
like I said before, wheels and engine.
That's not really what management cares about. But
on the other hand, management doesn't necessarily
we shouldn't push to management.
It's
it it it's for you know, it gets
groceries.
Like, not just what we apply it to.
What features of the network allow it to
be enabled to enable you to go get
groceries?
And and why are yeah. I I agree
because because the thing is they're gonna be
they're gonna be decisions they have to make
in those components. They're gonna be cost differentials.
Right? There's gonna be,
a certain engine is needed to carry a
certain size of a trunk. And so, yeah,
the trunk is is what you care about
from your balance sheet. But there there is
some cost to this particular trunk, and here's
why. That's that's the thing that I like,
good documentation skips over the nerd stuff insofar
as it doesn't serve the purpose of getting
money for the thing that drives the revenue
is is the way it's it.
Well, I think the the inherent,
you know,
the the entire focus of this audience
or this document is
who's your audience. Right? Who are you writing
for, and what's the right context? I think
the part of the reason the management section
is so long is that a lot of
the things that are covered in here are
not things that we necessarily think of just
as documentation.
They're not
static pieces of information that describe
either what the code is doing
or what it does or why it exists.
There it's it's status of a project. Right?
Like, you know, are are there are there
blockers that are are stopping the progress from
going forward? Is there a bottleneck? What's our
capacity as a team? Are we over overloaded
or underloaded? And and all of these,
really, this management documentation
section is a communication of the state
of a project, is really what's communicate is
is being outlined here. You know? And and
that,
you know, as as a now manager, like,
those are things I'm really concerned about. I'm
not so much concerned
about all of the the specific details that
my folks talk to customers about. I'm certain
that they know all those things, that they
understand them. What I'm concerned about is
if I get five more of these requests
in tomorrow,
am I gonna have the right distribution of
people
to respond to those requests?
And that's a very different information set
than
what my folks need to go do their
day job.
Right. Yeah. Yep. Yeah. I think and I
I think some of the questions they ask
you are like, is anything at risk?
Okay. Well, I mean, I deal all the
time, like Tom was saying on the management
side that
I deal all the time where you wanna
add this technology to the network. Why?
Well, let me tell you about the business
cases you're making to me
and how I can enable
those business cases.
You give me five business cases. I want
to enable those business cases in the simplest
way possible.
That's why this technology solves all of those.
But, again, you can't even really put it
in terms of technology.
Right?
It's all about capability,
and that's and that's the thing.
Yeah. And and
the other things that are in here on
the management side are really you know, teams
are under loaded or overloaded. Right? Like, you're
talking about Yvonne. Right? That's really
a big deal. Are we on track?
What kinds of changes have been made to
these features,
and why?
Like, what what has evolved about
the
status of the network? What new things have
we done, and why have those things been
done?
So I think I think those are all
very
good questions we can convert into the network
world. And people always say,
how can I relate to management? How can
I get them to invest in the network?
Well, there's your answer right there.
This is your answer.
Thinking about them as an audience and figuring
out what that what that looks like.
I really liked the, the last section customer
documentation.
Customer documentation is highly beneficial as it helps
prevent customer issues and makes the software easier
to implement, which in turn makes it more
valuable.
I I really like that documentation makes the
product more valuable. What? Yes. Totally. I totally
agree with that. Yeah. And who's the customer
for a network?
That's always a question we forget. We we
don't tend to think about a lot.
Who is the network's customer?
I would say it's application owners.
I wouldn't say it's the business.
The biz the the applications customer is the
business.
The business's customer is the customer.
The network's customer is the application owner.
That's the way I would think of it.
I don't know. Yvonne's
thinking about it. I think I think,
certainly. I also think it depends on how
you break up your organization. Like,
is is there an infrastructure team that's also
like, or is it is it the people
that are deploying, building, maintaining
the servers and infrastructure
in your organization?
Are those customers of your,
network? They very well may be.
Are there,
is there any automation that's built inside of
your network that other teams interact with? Is
there
I'll tell you who else could be a
customer
is,
finance or billing. Like, if you if you're
running a,
if you sell network services,
there are absolutely logs and data that come
out of your network infrastructure
that feed into workflows for your, you know,
billing, accounting,
operations teams that they need. So there can
be lots of customers depending on your organization,
what what you do. Yep. Billing is actually
a big one too. I always think of
application owners, but
I do interface a lot
with billing people
in my current job.
It's not something I'm really accustomed to. But
Well, in some and I think I think
app the concept of application owner can stretch
even a little bit
further. So if you're
say you're running, like a little eyeball network,
a regional network, regional ISP,
you still have application owners. It's just that
there's one of them per subscriber.
And the application
is whatever application they're using from their home.
So and and in that case, it it
gets really interesting because you you could call
the customer the application owner because they're using
your network to move their bits.
But then but then also, I mean, they
they are a customer
of another application,
most of them. And so I think that's
I I think it's another way to look
at it. Like, even if you're totally commodity
just moving bits for a living,
you still
you still have, application owners and you have
as you get to more as you get
to a subscriber centric like that like an
ISP type of business,
you get less and less control over what
those application owners are doing with your network,
which I think is also an interesting property
of documenting a network. The other thing I
would always point out is that documentation
in the network world he doesn't talk about
it in this article,
but documentation has layers. There are layers
of documentation.
I the number of times I've walked into
a situation when I was on global escalation
and said, give me your network documentation, they
walked me into this conference room, and there's
these
flip charts
of physical connectivity.
And you're like,
yeah. I didn't need to know your circuit
grooming.
Seriously.
Like,
BGP and OSPF and EIGRP
and IS IS, they don't care about circuit
grooming.
Okay? That's not where the problem is.
And so that's a very common problem as
well, I find, is that people don't know
how to write documentation
in layers
per se. Well, the there's and and and
we can talk through those quickly. Right? There's
the physical layer that is, you know,
the
this physical wire is connected
to this physical port on this physical device
that lives in this physical rack, in this
physical room, in this physical data center. Like,
there's all of that.
And then you've got your more logical documentation
that's
all of these things are connected to one
another in in this sort of arrangement. It
may not represent what it looks like in
the physical world, but it helps you understand
logically what's going on.
And and then there's overlays that you might
have over top of that, which is a
completely different logical diagram. And then at each
of those layers, there are different
protocols that could be in play.
Separate from that are things like IPAM. What's
what's what's your IP address scheme? Where is
all of that? How are you tracking all
of that information and documenting it? There's configuration.
There's automation,
which is which is another place where there
could be documentation.
Should be absolutely be documentation.
I think I'll get a hear you from
Tom on that.
You absolutely need to document your your, automation.
And and then there's like, what do we
actually accomplish with this thing? Right? And and
there are all those different layers that have
all these different audiences,
and you you have to have some concept
of what the documentation is, who the user
is, and what it's gonna be used for
before you even know how to write it.
But there's a lot. There's a lot a
lot. Yeah. Yeah. I think so too. So
alright. So any other hits on that one
before we move on to our next little?
I'll just say I
my experience with documentation mostly it's just like,
what most people would call boring work, but
I have had times
when it the stuff that I that I
documented was
was it had to be up to date
because I was proposing changes, and so I
did it.
And that had had some surprising,
political conversations.
And, like, I I've had bosses take my
documentation to other people
and say, this is what we're doing.
And,
we talked about this on the phone, and
I know you're not used to us actually
taking any notes, but we wrote it all
down. Here's the documentation, and so we're moving
forward with this. And they're like, wait. No.
No. No. No. And it's like, well, sorry.
It's written. This is it's here. It's recorded.
And I was I he told me he
did this this when this happened, he told
me he did this after the fact and
I was like, woah. That's pretty bold. But
if it's written, if it's there, it it,
you know, it trumps what's in somebody's mind
and what they believe and what they think
and Yeah. So, I mean, we can't just
A %.
Yep. There was a book I read once
about a market crash,
like a big financial market crash, and it
was brought on by some hackers who had
broken into the market and caused havoc.
And
the solution they came back to was,
well, if it's not written down, it didn't
happen.
They just literally
rewound the market
to five minutes before the hack
and said,
go.
I thought that was that's a pretty creative
way of of looking at it. If it's
not written down, it didn't happen.
So
alright.
So the next thing we're gonna talk about
is legacy versus EOL versus tech debt.
I don't know. I have very specific definitions
for these and that y'all probably
have different definitions.
Well, let's hear yours first, Russ. Oh, no.
That's no fun.
Well, legacy just means it's been here a
long time.
Yeah. Legacy just means But often,
legacy means this is a thing that's worked.
Yeah. Right. Often, people see legacy as bad.
It's not bad
necessarily.
Legacy is just what's been here for a
while. Right? And sometimes it is bad.
Oh, we've always done it that way. That's
a statement of legacy.
Oh, no. Don't do that. That's nonsense.
Right? Or that old AGS plus has been
sitting in the corner for ten years.
Why don't don't fix it because it ain't
broken.
No. No. Those are not those are not
good either. Right? So legacy has positive and
negative
connotations,
and we take it as negative,
like, 90% of the time.
In our minds, legacy means I need to
replace this.
No. That's that's that's not true. Right?
It just means something that's been there. I
can't tell you how many customers I've talked
to who say to me almost apologetically
that they still run a mainframe.
But the thing is,
it's all of them. Yeah. Right?
Any company of any sufficient size
that's been around for a few decades
has one.
And
unless they have a very clear business case
and a
very driven project plan,
any attempt to replace that thing
is a fool's errand unless folks really know
what they're doing and they have a very
committed plan. If it's just like somebody's wild
hair, like, oh, this year, we're gonna replace
the mainframe.
The those just don't go well.
And it's because those systems
do what they were designed to do, do
it well, and have been sitting there running
for decades.
Yep.
I mean, COBOL still exists, unfortunately.
It's a horrible language. But anyway,
there I mean,
I worked for BASF for some period of
time, way back in my
you know, Yvonne figured out how how old
I am, and she's like, no. It can't
be, but it is. Anyway
and
and one of the things that BASF tried
to do way back in the days just
after I got out of the air force
was to replace their
mainframe.
I believe it was an s three ninety.
I could be wrong, but I believe it
was an s three ninety.
By the way, in the Air Force, we
ran a Burroughs mainframe
with TN thirty two seventy terminal emulators.
I mean, way even before IBM s March.
And I worked in another company where we
had a bunch of IBM minis instead of
having mainframes.
And we had all this fancy middleware that
combined
queries from the different minis to get to,
like give me this is, like, really crazy.
But, anyway, they had an s three ninety,
and they were gonna replace it.
Okay. Fine.
It took
two years
and an entire department
of people,
and they were bringing people out of retirement
because no one knew how certain things worked
to replace that s three ninety.
Now in the long run, was it worth
replacing?
I don't know.
Sometimes you just think,
let it just sit there and do its
thing. And as you build new stuff, you
don't build it on that.
You build it on on new new platforms.
And it might take twenty years for everything
to rotate out of being useful.
Oh, well,
like, really?
Is it hurting anything?
Yeah. But but but the tax you pay
for that I hear you. But the tax
you pay for that is interop
because your new systems are going to come
online and they are going to have to
interoperate.
To me, if you can put something on
an island and never and not have strong
dependencies and infrastructure, then, yeah, just let it
let it go. And, you know, the finance
people will love you. It'll you know, it's
it's,
as it, depreciates,
over a much longer period of time, you're
gonna it's it's good for the business. But
but that's not for free. You you have
an interop,
surface on almost every system.
And that's where I think I think where
people are like, well, we don't let's just
keep the old thing. Sometimes I think we
don't take into account the interop tax and
because it doesn't become apparent until later.
That and just finding people to work on
it. Right? That's the other thing is, like,
at some point you reach this critical mass
where,
you know,
is is it
is it supportable, maintainable, and all that, which
will lead us into our our next topic.
But legacy in and of itself is not
bad if you have the support that you
need and
the capabilities that you need. I mean, but
in and of itself, it's not bad.
Yeah. So EOL is the next thing you're
talking about. Right, Yvonne? End of life? It
is.
Yeah. What does that mean?
To me, it means you can't get support
for it anymore.
That's really what it means. It doesn't mean
the manufacturer
has declared it EOL.
It means you can't get support for it
anymore.
Right?
It's a mechanism
that the vendor is using to drive a
purchasing cycle. Yes. At the end of the
day,
it is a way for the vendor to
force you
to buy the next thing.
It is it is its own kind of
planned obsolescence.
Now sometimes there are good reasons
for technology to go end of life. Either
it's it's difficult it gets to all this
difficult to patch. There's newer technology that's gonna
function a lot better. There's all kinds of
reasons for that. But at the end of
the day, when something's end of life,
that really just means the person you bought
it bought it from is no longer is
saying I'm off the hook for dealing with
this thing.
Use it. Use it at your own risk,
but don't come to me asking for patches
or asking for help. You're on your own.
And the reason that works is because most
organizations
aren't willing to assume that risk.
Yep. That's exactly right. Yeah.
As a matter of fact, again, an old
story from Cisco,
we had a
customer come to us,
and they had purchased a particular brand of
routers, Bay routers.
Wow.
Bay routers.
Does anybody remember Bay routers? The user interface
on Bay routers was the SNMP tree.
You literally had to go in and
query the SNMP
nodes in the tree and change them through
a CLI
to change the configuration. There was no configuration
language or anything. Anyway, whatever.
And they were having bugs with it, and
Bay was out of business.
And they were like, we can't justify
replacing these routers
for another five years,
but we need somebody to support them.
If we got you the source code, could
you support
these bay routers for us?
We were like,
no. And the sales rep said for a
fee. Yeah.
You just set your price
higher than the cost of replacing them. Right.
You know? I don't know what to say.
It's those types of things happen.
But, yeah, end of life
to me
can from like you said, Yvonne, from a
from a vendor side, it means I'm not
gonna support this. I want you to buy
the new generation.
And there are valid reasons for coming to
that conclusion as a vendor.
On the other side,
end of life can mean,
for you as a network operator,
that equipment or that software is end of
life.
It may be supportable.
There may be a vendor that will support
it, but we're not deploying more of it.
You can flip the tables on it and
say,
I don't care what the vendor's doing. We're
end of lifing that in our network.
And that's more of what people think of
legacy as. I I think there's an
there's also, a software aspect to this. A
lot of people, when they think of end
of blights, they think of hardware failing, which
is an important part of the equation. And
if you can't get that that chip anymore,
to repair it and you don't have, any
units on the on the shelf to replace,
then obviously, I mean, that's that's I think
a lot of people think of hardware as
as that, but there's also, I think, a
really important software conversation about this.
This as a software supply chain
speeds up and accelerates,
you know, just keeping up with things and
how much software is out there and how
many dependencies every project has.
It can get it can get really crazy
and it can get I feel like it's
a lot faster now than it used to
be that you go to upgrade a dependency
and then, you know, four others aren't ready
yet. And so it's the whole thing is
sort of stuck. And then by the time
you get all those other four other all
those other four already, now you have to
leave the old ones behind because there's incompatibilities.
Like, there's a lot of,
software supply chain sort of things, I think,
that are becoming more complex,
sort of requiring us,
whether it's more secure or not, requiring us
to stay closer to the front edge, the
the leading edge of of development these days.
When we talk about security, there's also,
you know, encryption and the ciphers that were
deployed on that box and whether the hardware
can support the new methods of encryption and
all and all of those things which become
incredibly important,
in in our totally connected world. You know,
you you've got to be able to patch.
You've gotta be able to secure your environment,
and those things also become critically important. And
that's
more a function of software than hardware,
although,
you know, if if your hardware has not
got the the power to support it, then
that's a related
issue. So the third one, which is tech
debt. And to me, this is the most
misused
phrase
in all of the tech world.
The way I think people use tech debt
is
some combination of legacy and EOL.
Tech debt is old stuff.
You know, it's basically equivalent to legacy,
but it's all the bad legacy.
And that, to me, is not what tech
debt is. Of course, I'm I'm looking at
it from a purely coding perspective.
My definition of tech debt comes out of
programming. It doesn't come out of networking.
But when people say tech debt, they mostly
mean they seem to mostly mean when I
hear them use it. They say,
well, that
that router is five years old. That's tech
debt.
That needs to be replaced because it's tech
debt.
What tech debt really means to me
is the differential between my understanding of how
the system works
and how it actually works.
Tech debt is
my level of
the network works a certain way, but because
things have changed in the network over time,
no one really understands how it works anymore.
That is tech debt. Because you go into
a situation troubleshooting
or making changes,
and you think it works one way, and
it actually works a different way. So you
push the red button on the right,
and it turns out that it makes the
car go to the right instead of the
left
or whatever it is. You turn the wheel
to the right, and unknown to you,
somebody reversed the gears in the steering box
for some reason down the road.
That to me is tech debt. It's not
old stuff. It's not legacy.
Something that's totally brand new can be chock
full of tech debt.
I think there's also you,
you're you're implying sort of an unintentional
state imposed,
by virtue of not understanding the system. I
I think there's also, I think there's also
an intentional
flavor to this,
when you're, specifically when you're building software.
You know, if you have if you have
the experience to anticipate certain things but decide
not to,
if you
you you you a lot a lot of
like, when I think of tech debt, I
think of the more intentional type, like like,
physically a credit card. When you take out
a credit card and swipe it in the
terminal terminal, you're saying, I wanna buy now
and pay later. And I think the, like,
the one flavor of this I think what
you said is really important to us, but
I think another flavor of it is, making
the decision today
to do something at the expense of effort
that will be required tomorrow.
And it's not tech technical debt is not
a moral judgment.
It is, it's no more moral judgment than
the judgment to use a credit card and
pay it off at the end the month,
but I think it gets really emotionally sort
of, loaded with us when we think when
we think about it. Well and I was
thinking too as Russ was talking that when
we're talking about tech debt, that's the what
trade offs have we made. Right? We we
made a trade
to either do something quickly or imperfectly
or without the proper engineering rigor or whatever
it is.
And
now
the interest that we pay on that
tech debt
is complexity,
is slowness,
is downtime,
is,
you know, all of these
results
of a less elegant solution.
And we and we we made that trade.
What happens though, and I think the reason
we talk about tech debt so much,
is because often
we make those trades
without realizing it.
You know, we we signed the paperwork
to buy a $20,000
car, but we didn't do the math and
realized that we're actually gonna be paying $40,000
for that car over the next five years.
Right? Nobody actually did the math and understood
the trade off. And then at some some
point, you're like, I only have this, you
know, I only have $25,000
worth of stuff. Why am I spending 40,000?
And and eventually, you just don't have the
resources to do anything
because you you're paying the debt on all
these trade offs that you've made. And that's
why we talk about it so much. But
it is a much more nebulous
category.
So in software world, we say
that to get rid of tech debt, we
refactor,
which means you tear things apart.
You try to go back to the basis
of what was trying to be accomplished,
and you rebuild the software
to fit what you were trying to accomplish.
And oftentimes, you discover that there are hidden
requirements you didn't know about in the process.
If somebody's made this change to do this
or that, and nobody wrote it down,
bah, you know, six years from now or
whatever, they'll figure it out. And they do.
They figure it out. Trust me.
In the network world, I think about situations
like,
okay. I'm going to use
VXLAN to solve this problem because it's
cool, and my chipset supports it. I'm going
to use
MPLS to solve that problem.
And I'm gonna use GRE to solve this
problem.
And I'm gonna use SRV six or MPLS
SR to solve that problem.
And before you know it, you have five
different tunnel mechanisms in your network.
How many tunnels does it take to make
a network?
All of them. All of them. Exactly.
Exactly.
And refactoring would be saying, alright.
Stop it.
I don't care which one you pick.
Pick
one and make it work,
and stop piling tunnel mechanisms on top of
this network.
Right?
That's refactoring.
It's like,
I have all this stuff I'm using. I
have five different ways to allocate IP addresses.
Really?
Stop that. Right?
There's gotta be one way to do this
that makes sense. I was gonna say one
of the things I think that I see
now with age and experience that I did
not see in my youth
is that we should never underestimate
the value of a working system.
My example
is I I'm a loyal
Sonos
user, Sonos speakers. And they, in the past
year, if you're not familiar with all the
drama, they rewrote their application.
But when they released their app, it was
not,
feature rich. It didn't have all the features.
They upgraded some software on their speakers, so
they couldn't go back to the old app.
And you and and
those of us who are users lost at
least 50% of the functionality
of our app, and that's how you controlled
your speakers.
And they under so they they went through
this process to say, okay. We're gonna start
over. We're gonna rebuild our app. It's gonna
allow us to do all these new things,
but they underestimated
all of the level of effort required to
get back to feature parity.
That's the risk
in starting over,
is that if you're not really clear
on all the features, the requirements
that you were talking about, Russ, and the
capabilities that you need, it's gonna take you
a lot more resources
to get back to parity
than what you originally thought, and that can
be a huge risk.
So you just need to be really sure
what you're undertaking
when you do that because that's you know,
it it becomes a you can get underwater
really, really quickly and end up in a
bad spot.
I think that pretty well defines tech debt.
I don't know, Tom. Did you have more
to add to that?
No. No. I think that's great. Cool. Awesome.
Well, I'm kind of out of questions and
topics.
I don't have anything else to add, so
I guess we'll just go around. And
I'll start with Yvonne because Yvonne has a
longer spiel. You can find me on LinkedIn
at Yvonne Sharp. I'm on x at Sharp
Network. I'm on Blue Sky at e sharp
dot net,
and writing,
periodically on Substack. So you can search for
me there too, Yvonne Sharp.
Awesome.
And
I don't know if you're gonna ask Tom.
Oh, come on.
Go ahead. Do it. LinkedIn.
That's
it.
That's it. Alright. And I'm Russ White. You
can always find me here at the hedge.
On rule11.tech,
on x as routing geek. Not that I
ever I don't log in there very often,
but I am I am there every now
and again.
On LinkedIn
and,
I don't know, packet pushers every now. I
don't know. I'm you'll find me around. I'm
pretty easy to find.
We know that we live in an attention
driven economy, and we thank you for listening
all the way to the bitter end of
this episode of The Hedge. And thanks for
joining us, and we will catch you next.
Next