Improving Legacy Applications with Billy Hollis

Can you improve a legacy application? What's the right way to go about it? Carl and Richard talk with Billy Hollis about his work updating legacy applications, starting with the most essential question: should you? Billy begins by defining what it means to be a legacy application and how, invariably, these applications are critical to the organization, so you have to tread lightly. Typically, the focus is on modernizing the client-side of the app, which brings us to the crux of the matter: Are the workflows of the company today well reflected in the older application? Lots of great thoughts from one of the longest-serving guests of .NET Rocks!

Episode Transcript

Speaker 1 (00:01):
How'd you like to listen to dot net rocks with
no ads?

Speaker 2 (00:04):
Easy?

Speaker 1 (00:05):
Become a patron for just five dollars a month. You
get access to a private RSS feed where all the
shows have no ads. Twenty dollars a month. We'll get
you that and a special dot net Rocks patron mug.
Sign up now at Patreon dot dot NetRocks dot com.

(00:34):
Hey guess what it's dot net rocks. I'm Carl Franklin,
an amateurd Kembell. We're here with Reverend Billy. He'll be
joining us shortly.

Speaker 2 (00:41):
Show number three. Yeah.

Speaker 1 (00:44):
Three's kind of been around since the beginning of dot net.

Speaker 2 (00:48):
Yeah, a one digit, two digit, three digit, four digit
kind of guy.

Speaker 1 (00:58):
Well, you know, just real quick, how's everything up in Canadia?

Speaker 2 (01:02):
You know, we're doing just fine. That's good. Still summertimes warm,
it's nice. I will I think when this shows comes out.
I've just gotten back from a cruise to Alaska for
our friend's fiftieth.

Speaker 1 (01:12):
Awesome and Canadians are still polite no matter what anybody says.
We are, you know, still very smart. And you know
they still trap beavers yeah make maple yep.

Speaker 2 (01:24):
Yeah, but we release them. You know, there is a
guy in Quebec called the beaver Whisperer.

Speaker 1 (01:29):
I don't this completely fits yes in my mental model.

Speaker 2 (01:34):
No, you know, he's figured out how to manipulate beavers
to get them to build the dams where you wanted
to build them. So it's actually beneficial. Oh that's awesome. Yeah,
we just had a problem with aa a beaver up
the road here, and they literally changed the water structure
so that it doesn't make water flowing noises because that's
what beavers don't like. It's called a laminar flow inlet.

(01:55):
So because does make any sound, the beaver's leave it
alone happens to be good for you too. Well, yeah,
because it doesn't flow thea anymore, which I think is
a feature.

Speaker 1 (02:01):
Yeah, that's a good feature. Okay, let's roll into better
know a framework. So crazy music, queue it up, punch it.

Speaker 2 (02:17):
What do you go now?

Speaker 1 (02:17):
I gotta preface this by saying I have not used it,
but somebody mentioned on Reddit a GitHub repo called blazer
dot input chips and it's got some good traction.

Speaker 2 (02:34):
Uh.

Speaker 1 (02:34):
And so it's an input control for editing a collection
of chips or otherwise known as tag values. Okay, and
since this is nineteen sixty two, we'll go to nineteen
sixty two dot pop, dot me, and then we'll go
right to this Blazer dot input chips and you can
see kind of a demo of where you add a
tag with a textbox and then you get the little

(02:56):
buttons with the X you know, with the tags, and
then with the X next to them, so you can.

Speaker 2 (03:01):
And what are the tag values for?

Speaker 1 (03:03):
Well, if you're tagging, let's say, an entry into you know,
or review or putting up some media content and you
want to tag it, you know, like dot net rocks.
We have tags in dot net rocks, right, sure, So
I actually thought we might.

Speaker 2 (03:18):
Use this.

Speaker 1 (03:21):
As a as a as a way to add tags.
I mean, we already do it because we have a
list of tags and we can do it.

Speaker 2 (03:26):
Fine, but that's convenient. Aren't the tags also used for
things like accessibility and stuff or this identifies it for
rather input sources that kind of thing.

Speaker 1 (03:35):
Yeah, it's metadata, right, It's just data that you associate
with some other data. So making it easier to put
the right mentadata on Blazer.

Speaker 2 (03:41):
I like that.

Speaker 1 (03:42):
Yeah, And it looks like just you know, it's a
simple little thing. It doesn't it's not complicated, and it
just looks like somebody's you know, first Blazer project is
what it looks like.

Speaker 2 (03:53):
But it's cool. I like it. Yeah, no, that spark,
I like, yeah, good.

Speaker 1 (03:57):
All right, So who's talking to us today, Richard?

Speaker 2 (04:00):
I grabbed a comment off of Billy's last show and
that was nineteen fifteen, which we did back in Stember
of twenty twenty four called it making design pay and
one of our regulars and long time. Actually somebody I
think I owe an email. Tony Vergouli wrote this a
little bit long comment, but it's worth reading, and I

(04:22):
think it was a reference to something Billy said at
the end of the show, which was I can't believe
you guys still listen to me, and so there's no
way I can get tired to listen to you, Billy.
I routinely direct developers to your talks for them to
get to think about design, because when I think about design,
a lot of the times I think about user experience
and usability. This is probably because it's my first job.
I was put in front of clients and I would

(04:42):
hear the pain points similar to what Carl brought up
about buttons and where items are placed. Then, as I
heard your talks and the images that you would share
about not well thought out designs, I grew to understand
design was not just about the screen, but also included
user experience, and I appreciate you think about the overall
design and experience. Visual designers purely about designing the screen

(05:03):
and not being able to help with any of the
UI code, CSS now or whatever, and I have butted
heads over the years. I'm working with one now who
created a design for a web based training light app.
His design was pixel perfect and specific to the device,
which happened to be a surface studio too at one
hundred percent scaling, and had a lot of empty space
around the video player, and the buttons had moving accents

(05:24):
crying look at me. When I questioned and pushed for
this to be a responsive app, he told me not
to spend time addressing something for the future, and the
clients said they were running it on these devices in
the lapp. After delivering the app to the client, Oh
that's the best lie ever, isn't it. After delivering the
app to the client, the client commented that the about
the massive amount of empty space that was their term

(05:45):
needing to zoom the browser to fifty percent because the
default scale in the Surface Studio two is two hundred percent,
and that the app was not responsive to run on
the employee's devices remotely. Obviously, there was a failure to
understand their needs. However, there's also failure of the visual
designer to create a design specific to the device. This
may have been because the previous apps he designed were

(06:06):
for a specific Kioscar trade show device. To me, this
type of design feels like static designs use on boxes
or billboards versus business web apps. Designer in question only
knows how to use Figma and Zeppelin, and that designer
is all about visual, which is unfortunate. They do not
want to hear feedback from the team. The design tool
does not matter to me, but I liked having sketchy

(06:27):
tools best at client meetings. So they are not critiquing
the color and more focus on the flow and the experience. Yep,
any design tool is fine as long as their collaboration.
I appreciate your thinking and sharing. I hope to see
you in Philly again and have a relaxed with a
glass of sweet tea. I'm also hoping that Carl and
Richard will visit Philly again. Probably not a road show

(06:48):
because let's face it, we're getting too old for that stuff.

Speaker 1 (06:50):
I it's on my bucket list because I want to
go down. I love Philly just as a place to
hang out. And also my friend Jeff Fritz lives down there,
so Jeff's down there.

Speaker 2 (06:59):
Yeah, it's on my list. Let's figure that out and
I'll fly out as well, and we'll see how much
trouble we can get into. That would be fun. Yeah, Tony,
we owe you what you've done great things for us
over the years, so you should call in that favor
and we'll figure that out. And thanks so much for
your comment. And a copy of music Cooba is on
its way to you. And if you'd like a copy
of music, go buy I rite a comment on the
website at donnetrons dot com or on the facebooks. We
publish every show there, and if you comment there and

(07:20):
we'll read it on the show, we'll send you a
copy of music.

Speaker 1 (07:22):
To Kobar and he's talking about music to code by
this is a library of music, twenty five minute tracks
that I wrote many many years ago and I still
can contribute to. There's twenty two tracks right now. And
you can get the entire collection at music toocode by
dot net in MP three flakand wave format. What happened
in nineteen sixty two, Oh nothing, just this little thing

(07:43):
called the Cuban missile crisis.

Speaker 2 (07:46):
Little thing, just a little thing closest I think we
ever came to nuclear.

Speaker 1 (07:49):
Closest we ever came to nuclear war with the you know,
possible exception of now, no, no, not no, This was
way more dangerous. This was way more dangerous, yes, Khrush
chef and we basically had brought a blockade around Cuba.
We saw some missiles and silos there. We said remove them.
They said no, and you know, hilarity ensued, and we

(08:12):
basically came face to face with their ships and you know,
cooler heads.

Speaker 2 (08:17):
There was a moment where a missile armed submarine of
the Soviet Union was headed towards Cuba. It was about
to interceed on the blockade, and then they blinked and
turned around. Yeah, thank god. It was an air thing,
without a doubt. Terrible.

Speaker 1 (08:31):
Well, other things happened too, Okay, So that started a
USM bargo against Cuba, and so John Glenn, Yeah, February twentieth,
first American to orbit the Earth aboard Friendship seven.

Speaker 2 (08:42):
Later that year, Carpenter also, yeah, well that started it off.
I guess that was the first American in orbit. Yeah.
Marily Monroe died in August fifth. If you don't know
who she is, just google her. I might want to
put it in safe mode though. Sixty two feet a
World Cup held in Chili. Brazil won the tournament, solidifying

(09:03):
its status and international futbol. You got some more stuff there,
a little more space. This was the beginning of the
Mariner series of the space of florers. The two of
them flew in nineteen sixty two, the very first one
Mariner one who which promptly exploded and fell into the ocean,
and the second one that was in July. In August,
they flew Mariner two, same kind of satellite, same rocket,

(09:28):
but this one made it into orbit and by December
made the first fly by a Venus, the first time
humans had ever sent a piece of their machinery to
another planet.

Speaker 1 (09:36):
Right, and after studying Venus, everybody said, ouch, I'm not
going there.

Speaker 2 (09:41):
No, not a hostile. It's a little nasty. Don't at nasty.
Although there's an interesting idea about building cloud cities around Venus.
There's a point in altitude's about seventy five kilometers up
where it's one atmosphere of pressure, although not breatheable, lots
of solar at about one G. You know, it'd be
the most comfortable environment you could live in. And because

(10:04):
the atmosphere is so dense, you could literally fill a
big balloon with air and it would float on it. Wow,
and you could breathe it. And if you tore a
hole in it, it would it wouldn't blow out, it
would just slowly leak anyway.

Speaker 1 (10:14):
So one G means the same amount of gravity. We
enjoy the same amount of gravity. Yeah, so it wouldn't
mess with us. No, we'd be pretty comfortable except for
the except if that atmosphere leaked up in there, that
would be.

Speaker 2 (10:23):
The whole floating, you know, on top of a pile
of sulfur cacid is you know, Yeah, I'm not sure
I like that anyway. Let me give you a little
computer history.

Speaker 1 (10:31):
And then we discovered that it rains up instead of down,
right right, So go ahead.

Speaker 2 (10:36):
Computer history. There is a computer called the link computer
l I n C stating for a laboratory instrument computer,
which is arguably the first PC ever made. It was
designed at MIT and built by Deck. There was only
fifty of them made. It had twelve bit words and
the original model had oneenty twenty four words. Later was

(10:57):
upgraded to twenty and forty eight of fully words and
it was made for transistors, so that's why it was
relatively compact. It was two units that were three foot
tall and twenty inches wide. You could stack them one
on top of your other if you want a six
foot tall computer, or you know, go wider about for

(11:18):
three and a half feet wide. The units typically had
two tape drives, a display, control console, and a keyboard.
There were about forty thousand US dollars in nineteen sixty two.
Wow Jeez. Famously a lady by the name of Mary
Allen Wilkes who was one of the very early programmers
in the fifties working at it, initially on IBM computers,

(11:39):
but she helped the original designer of link Fellow by
the name of Leslie Clark on this design. She wrote
the operating manuals and later wrote an operating system for it,
and has the best quotes ever. The first quote was
because she took one of these things home Wow. So
she was able to say before anybody else, I'll bet
you don't have a computer in your living room. And

(12:00):
my favorite quote of them all in thinking back about programming,
she said, we had this quaint notion at the time
that software should be completely, absolutely free of bugs. Unfortunately,
it's a notion that never really quite caught on.

Speaker 1 (12:14):
It was Doug Crockford's say at the end of his talks,
don't write bugs.

Speaker 2 (12:19):
This advice, Thanks Doug. One other mit deck collaboration from
nineteen sixty two. The previous year, in sixty one, Deck
sent a PDP one to MIT and in nineteen sixty
two a group of developers wrote a video game on
it called Space War Space War. Yeah. Yeah, so that's

(12:40):
also nineteen sixty two.

Speaker 1 (12:42):
Wow. All right, Well, I guess it's time then to
welcome Reverend Billy back to dot net rocks for the
umpteenth fifty million times, fifty eleventh time, or how do
you say that in this sound fifty eleventh for eleventh time.
Billy hollis, if you don't know, as a software designer
and developer with a contrarian streak that often challenges conventional

(13:03):
wisdom in the industry. He has a consulting practice in Nashville, Tennessee,
and he and his team focus on User experience design UX,
Advanced user interface development, rules based architectures, and healthcare systems.
He teaches classes for design thinking in UX design and
technical classes on ZAMO for when UI xamble for WPF

(13:24):
is when UI still a thing, there's that an old bio,
it is still a thing. Well, welcome Billy, welcome back.

Speaker 3 (13:31):
Well, it's always always a pleasure, guys. And you know,
as as I said in the last and that comment
from Conny, which I genuinely appreciate, he's he and I
have talked many times over the years. I do kind
of wonder why people continue to want to listen.

Speaker 2 (13:49):
But then I thought about it.

Speaker 3 (13:50):
I went, I went back, and I'll listened to the
last podcast, and actually there was a lot of interesting
new stuff in it, and I think that we continue.
It's about a year between codcasts basically, and with that
amount of time, there's always something new happening. I'm I'm
poking my fingers into something new so well.

Speaker 2 (14:12):
And I also find like I pay attention to what
sessions you're writing too, and your current thing is often
reflected in that like, you take feedback of your experiences
and you try and teach the new ways you're thinking
that you're that you find emerging from the work you're doing.

Speaker 3 (14:25):
Yeah, since we do projects, real projects, and not only
real projects, but you also get a sense of thinking
and what's important and what people are grappling with when
you talk to people at conferences, and I do. I
talked to quite a lot of them, and that gives
you kind of a statistical sample that you can draw
some conclusions on about what the general community finds to

(14:49):
be interesting.

Speaker 2 (14:50):
Yeah.

Speaker 1 (14:50):
Well, our listeners have used to fact that a dot
net Rocks episode goes way beyond the title in terms
of topics. We use that as jumping off point and
then talk about the other things that brings to mind.
We've always done that, so it's always good talking to you, sir.

Speaker 3 (15:07):
And the legacy apps thing came about from a request
actually from someone because I do these lunch and learn
type things for companies.

Speaker 2 (15:17):
Virtually.

Speaker 3 (15:18):
That's a fairly new thing because only in the last
few years have people had the infrastructure available typically to
do that. And so I have a list of topics
that I do for people. They just call me up
and I do it. That's kind of our substitute for
sales because we don't do sales for consulting. So that's
a way of letting people get familiar with what we do, right.

(15:40):
And one company said, you know, we'd like to have
you do that, but you talk a lot about all
these new systems that that you design and create, and
we're not going to be able to do that for
a long time. We've got this legacy app, we got
millions of dollars in it. Can you help us understand
a little bit about what we might do, how we

(16:00):
might apply some of the stuff you know for the
legacy world. And I drew up a session based on
that and started doing any conferences and it has been
popular because, let's face it, a lot of people have
those legacy apps. They have a huge amount of investment
in them. Plus the fact that legacy apps are risky
to replace if you're talking about a complete replacement.

Speaker 1 (16:21):
Well, I want to cure your definition of a legacy app.
I have my own, but it's probably the same as yours,
but let's hear yours.

Speaker 3 (16:27):
A legacy app to me is something that has that
has been built with less than the modern leading edge
technologies and has typically been around for ten years or more,
sometimes up to twenty five or thirty years, and it's working.

Speaker 1 (16:42):
And it's working, right, It's not like it's not a pejorative.
This is making money for us, Yeah.

Speaker 3 (16:47):
It is not. The business depends upon this application. In
almost all cases, that application, if it were gone or
you tried to replace it and you failed, that would
have an existential consequence for the business. So all these
are very very important, a lot of money in them
and a lot of risk. And I know plenty of

(17:10):
examples of companies that have tried to replace legacy apps
and have have hit that failure point. I mean, even
Windows eight, as far as I'm concerned, is in that category.

Speaker 2 (17:21):
Yes.

Speaker 3 (17:21):
Absolutely, they tried to completely rethink a legacy application, well
a legacy operating system in this case, and completely failed
at producing something new and lost billions of dollars. Well,
most companies can't afford to lose that kind of money.

Speaker 1 (17:34):
Right, So the trick is that you need people on
staff that can see the problems, whether they're security issues,
because let's face it, security issues are like the number
one thing, right. There's an exploit in some DLL that
somebody was using and you have to patch it, and
patching it might mean a lot of pain, and it

(17:54):
might be impossible to patch because of its dependency tree.

Speaker 3 (17:57):
Well as legacy apps are that there's a very nice
tension there because it is very high risk in order
to replace them. If your if your platform becomes obsolete enough,
or you've run into some of those security holes and
some of the other things that can go wrong, you
may eventure, or the business may change in various ways.
You may eventually get to the point where it's actually

(18:19):
a mess risk to go ahead and start over that.
But that's a that's a very tough thing, and most
businesses will put that off as long as they can.

Speaker 2 (18:28):
Because well they should. Yeah, high risks or reward.

Speaker 3 (18:32):
Yeah, And that's that to me is one of the
key things about looking at UX design for legacy apps
versus looking at UX design to do a completely replacement,
which we do a lot of. Of course, there are
people doing it, and if you're going to completely replace,
why wouldn't you redesign to really make it leading edge?

Speaker 2 (18:52):
Sure?

Speaker 1 (18:52):
You know what's really annoying, Billy is when a perfectly
find a perfectly good working application on the Internet that
you're using, like, oh, I don't know, Riverside completely changes
the way that you flow through your you know, do
do your thing right. They put more layers in front

(19:12):
of you that you have to navigate through. Whereas before
it was one button click you knew exactly where the
button was. Now there's more layers and for what you know,
just makes me me angry. Here's another one. The bank
that we currently use that we have to pay people
with ACCH you know, direct deposit for those who don't
know what that is. We have we have to scroll

(19:34):
through all of this stuff and they did a complete revamp.
But what they didn't do is fix the problems that
were already there. They added more problems. Just infuriating.

Speaker 3 (19:46):
I think that I've I've kind of come to and
understanding that one of the reasons that that sort of
thing tends to happen is that software development teams in
the modern era are focused a lot more on granular
features than they are on big picture and workflow and

(20:07):
things like that. And Okay, this is probably going to
get into ranting territory here, which is go so if
I should. But one of the reasons why there is
that focus on granular features. It comes from the widespread
use of Agile methodologies because they tend to focus on

(20:31):
features in a very gradual, in a very granular sort
of way. The typical backlog has a lot of features
on it, and if somebody on the team goes to
get something off the backlog and work on they are
charged with working on that feature and getting that to work.
And then they just kind of put it on a
menu or something, or put it on a button somewhere, however,
and they don't really think about how it fits into

(20:53):
a bigger context. And you know, I have to give
the usual disclaimers when I'm suggesting that Agile is less
than perfect, because there are people out there who will
who will get upset about that because it's it's it's
something that they're kind of emotionally attached to. I find
that's a that's a small minority actually of the people
who use Agile, but they are a very vocal minority,

(21:17):
and so I tend to hear from them, and I
like to emphasize no, for the code centric parts of
your of your application development, you've got to have something
to manage it. And we work with lots of clients
and about two thirds of them use some variation of Agile,
so I've seen quite a number of them, and certainly
in terms of getting the feedback, keeping people going, keeping

(21:40):
from getting blocked, there's some value there for most of
the people who use it. But that doesn't mean it's perfect.
And I think one of the big defects is not
looking at things from the big picture and not drawing back, and.

Speaker 1 (21:55):
The big picture can change, and it most likely does,
doesn't it. Like you know, you start off with a
good UI that where you have everything organized and it's
perfect the way that you've designed it, and then new
features coming along and you're not quite sure how to
get there and how to put them there, and then
it turns into this much. And I think, without telling
who it is, one of my customers I recommended you

(22:17):
because they were looking to do some UX redesign you
I redesign, and they said they're very happy with the
stuff that you've done for them so far. But I
think that might be a good example of that something
that started out working really really well and then just
grew and grew and grew, and now they have to
think about redesigning it. But it's definitely a big picture change,

(22:37):
isn't it.

Speaker 3 (22:38):
It is, And you really have to draw back to
look at things from the big picture to do it.
And so if you're in the grind of just going
forward two week sprints, get stuff off the backlogs, try
to whittle let backlog down. If that's the only thing
you're thinking about, then you're going to get into that
kind of a mess. Now, theoretically speaking, there's some project

(23:00):
manager role that a product manager role that that that
is supposed to be looking at that and supposed to
be doing big picture. In my experience, in general, big
picture thinking ought to be a part of everybody on
the team because that that person can't know and think
of everything. So so I hope that that they'll give

(23:22):
me a little bit of of of looseness on the
Agile side, that they won't think that I'm trying to
tell them that that they shouldn't do that, just that
they need to spend some time thinking about the big picture.
Because because I run into this whenever I say, look,
Agile doesn't do this well, one of the common things
I get in response is well.

Speaker 2 (23:43):
That's not really agile, yeah right.

Speaker 3 (23:48):
That, yeah, that's that's that is I think of that
anyway as an example of the no true Scotsman logical fallacy.

Speaker 2 (23:57):
You guys know that one.

Speaker 3 (24:00):
It's like, you know, no true Scotts, no Scotsman puts
sugar in his porridge.

Speaker 1 (24:05):
Right, No true Scotsman dips his Scotch eggs and Marl.

Speaker 3 (24:09):
My cousin Angus likes sugar in his porridge. Yes, but
no true Scotsman so must not be a true Scotsman
that that kind of that kind of thinking does not
get into the the the reality of the fact.

Speaker 2 (24:27):
Maybe they're right.

Speaker 3 (24:28):
I don't know, I'm not.

Speaker 1 (24:30):
It's an excuse to ignore the facts in front of you.

Speaker 3 (24:33):
Yeah, I'm not on the Council of High holy people
who define what agile is. I'm not in that. Apparently
a lot of people are, but I am not on that,
And I don't know. I just know what I see,
and I see that if I see teams doing things

(24:53):
the same way a lot of different teams, then I
have to presume that that's kind of part of what
agile is. Is that enough for the rant? I guess
we should get back to when we get back to
real stuff.

Speaker 2 (25:02):
Slash soapbox. When you're where you're tackling the problem of
a legacy rewrite like this. I mean, obviously you're jumping
a bunch of versions or jumping into a different stock entirely.
Is this all about initially rendering a ux just sitting
with the people who use the app and say, how
you know, how much of your workflow is based on
how this software works versus how much of your workflow

(25:23):
you know, really flows?

Speaker 3 (25:25):
Yeah, it's it varies all the way. From man, we're
throwing out everything we've got, including the back end. But
more commonly, what I find in general is that companies
have done a pretty good job in the dot neet
era of getting their back end to the point where
it needs to.

Speaker 2 (25:42):
Be, because it costs money, and.

Speaker 3 (25:44):
It costs a lot of money if you don't get
that right, and it creates problems that are really hard
to work around. So I find that the majority of
the people we go into have done a pretty good
job of getting their back into place. So now they're
replacing the front end, and that makes sense. You think
about all the proliferation by that word always stumbles me up.

(26:08):
Do you guys have words like proliferation is one of them?
And another one for me is interoperability, I have to.

Speaker 2 (26:18):
Correct. That's why we always say interopt.

Speaker 3 (26:20):
But the proliferation of different devices and form factors in
many cases pushes people towards new platforms for pushing the
app out because they have to there are people that
they have to have to reach. So that will cause
a really dramatically route of the front end, maybe multiple
front ends. But then there's another layer of Okay, we

(26:40):
got a business app, and you know it's running the
business and it's doing fine, and we know we could
take advantage off some of the modern UI technologies and
we could do better. We could improve this app, but
they are not at the point where they're ready to
take on the risk of a complete front end replacement.
And that's what that's session that we talked about is about.

(27:02):
When you're stuck with this business I shouldn't say stuck
with If you have decided that it's meeting your business
needs in general, that doesn't mean you can't still try
to try to improve it because there's a lot of
a lot of latitude to do that.

Speaker 2 (27:16):
I mean, I got to think of this. If your
app is that critical to the workflow, every minute you
can cut off achieving a task represents significant savings over
and over and over again. Every time you can avoid
causing a mistake that happens routinely, they all have big benefits.
Little incremental improvement should have huge benefit.

Speaker 3 (27:37):
And that is the two usual metrics you're looking at
as a justification for doing it. Is that you're speeding
people up and you're keeping them from making as many mistakes.
And there is a normous room for improvement, partially because
of the way we came at building applications in the
first place. Our first round of automation back in the
eighties and nineties was almost just pure database apps, file

(28:01):
maintenance apps. Sure that you are basically using the computer
screen as a replacement for paper and folders and such.
And you know, we still see we still see the
effects of that today. What I tell people in that session,
one of the things I tell people in that session
is if you look at a business app and you
look at the menu, and you can map the menu

(28:23):
of the business app to the database schema, then you
have an enormous room for improving how that app helps
users do their jobs. Because if that's the way it is,
the user has got Let's say the user's got like
five five steps in some work task that they've got

(28:45):
to do. If you've got that database style thing, that
probably means they go to four or five different places
in the app to do it. They have to bounce
around in the menus and they have to do this
part of it and then go over to someplace completely
different to do the next thing. Well, from a design perspective,

(29:07):
one of the things we try to do is limit
the use of short term memory and limit the use
of attention, because both of those are limited. That's just
built into our heads that we've only got so much.
So if you're having to split your attention between navigating
menus and the actual work task that you're trying to accomplish,

(29:31):
that now you're using up your attention. And if you
have to track where I am, Oh, did I finish
step three and ready to go over to a different
menu for step four, if you are having to do that,
you are straining your short term memory. And so the
options that the possibilities for doing better are quite dramatic.
And you can speed people up, as Richard said, and

(29:52):
you can prevent errors by keeping people from doing things
out of order and stuff like that.

Speaker 1 (29:56):
You know, one of my customers is dealing with this
now and it's the Microsoft Office problem, right. You think
about Microsoft Office. First everything was in menus, then they
had a menu bar, then they had the ribbon, and
you know, we when we started out with this customer,
they were adamant that they wanted to standardize the menus,
like every page has an action menu, where in a

(30:17):
view menu where you can go to different pages and
action menu, we can do the things. But some of
the actions are so critical and some of the navigations
are so critical they pull them out of those menus
and put them well not pull them out, but they
add buttons to the top of the page that do
those things because they're so critical that they don't want

(30:38):
the user to have to go search for them in
a menu. Well, that brings up the question why have
anything in the menu if because you have to search
for it? I mean, yeah, just because it's not critical,
they're still going to have to search for it. So
just it's it's a good tension.

Speaker 3 (30:54):
That's a great example of the the Yeah, the philosophy,
the physical philosophical approach from my perspective, is especially in
legacy apps, you don't necessarily want to take away the
way things are done now that would have a lot
of ramifications that you don't want to deal with. But sure,
there's nothing wrong with finding different ways to get to
those steps in a workflow, or creating completely separate views

(31:19):
that say, Okay, I've got the five steps. Why don't
we create another view that has those buttons to get
to those five steps and maybe some kind of tracking
that says, yes, I've done this and that one. You know,
change the visuals a little bit.

Speaker 2 (31:34):
Now. People off share, especially when you start thinking about
different devices, right, Like, you've been doing this all this
time on a PC, but now they really want to
be able to use a tablet or a phone, and
the ux menaphores are different. The Hamburger menu makes sense
in that scenario, and it doesn't make sense on a PC.

Speaker 3 (31:49):
So that that's kind of what I encourage people to
do when I talk about the legacy app thing is
look for the common workflows, the one that a lot
as you you said earlier, the ones that a lot
of people do a lot of the time, and really
make it transparently easy for people to go through that.
And notice that you don't just speak people up and
prevent errors. Although those are really two big considerations. You

(32:12):
also lower people's stress and fatigue because they're not using
up their short constrated hard and you make it easy
for somebody new to walk up to one of these
things and carry carry out some process because they don't
have to know as much about how to bounch around
the menu. It would help for I can do a

(32:33):
couple of tangible examples from real projects.

Speaker 2 (32:36):
If that would help. Let's do the break.

Speaker 1 (32:37):
Yeah, let's do the break first, so we'll be right
back with Billy's suggestions after we get through this break.
So stick around. We'll be right back after these very
important mesters.

Speaker 2 (32:48):
Do you have a.

Speaker 1 (32:49):
Complex dot net monolith you'd like to refactor to a
micro services architecture? The micro Service Extractor for dot Net
tool visualizes your app and helps progressively extract code into
micro services. Learn more at aws dot Amazon dot com,
slash modernize, and we're back it starting at rocks some

(33:12):
Carl Franklin, it's Richard Campbell. Hey, that's Reverend Billy Hollis,
and he's going to give us some examples for the record,
not a reverend, not for the record, Yes, not a reverend. No,
that's a that's a nickname I gave him after a
hilarious talk that he did at a.

Speaker 3 (33:27):
Well it's that Southern accent that I get a little
bit excited talking about stuff.

Speaker 1 (33:32):
No no, no, dough. It was put your hands on
the screen and repeede after me. I am an addicted
a code addict.

Speaker 3 (33:40):
Do you guys know that video where I started the
whole thing about code addiction was twenty years ago? I know,
isn't that crazy this year because it was at tech
ed two thousand and five. Yeah, and that video, by
the way, is still out there on YouTube. Smarty wants
to go look at the technology is.

Speaker 2 (33:56):
All absolute, but I will clude it in the show notes. Okay, good, Yeah.

Speaker 1 (34:00):
Before you get to your suggestions, I just want to
get back to desktop apps for a bit, because we
also forget about keyboard shortcuts with desktop apps, even in
browser apps, keyboard shortcuts, because those are things that you know,
people sitting at their desks don't want to navigate through
hierarchical menus. Once they know where they need to go,

(34:21):
they should be able to just hit a couple of
keys and go there. Anyway, So back to your uh.

Speaker 3 (34:26):
Yeah, and just to come and finish off that my
philosophy is that having multiple ways to get to things
for different classes of users is perfectly fine, and there's
a tendency not to do that. Again, going back to
the very beginning of our of our industry, where you
have these extremely limited screens, these character based screens that
you know there was one function key to get to this,

(34:47):
and the tech support would tell you, oh, if you
want to do this, press F two and then F
five or whatever. But now with modern UI, you should
make you can make multiple ways to get into things,
and that's there's nothing really wrong with it.

Speaker 2 (35:00):
Nothing wrong with that.

Speaker 3 (35:00):
Yeah, one thing that one example that comes to mind
is a situation that's not kind of the linear work
for we're talking about. I got another one of those
I'll talk about too, But I was working with a
company actually not too far from you, Carl, up in Connecticut,
and they were doing a utility building package. Now, think

(35:21):
about somebody answering the phone in a utility building place.
What do they need to be able to do in
the app to respond to the people that are on
the phone. Well, it turned out, as we discovered there
there were about seven things that form the clear large

(35:44):
majority of all the things that they have to ever
answer phone calls about and so in order to do
that work, they had to be able to go to
seven different places in the app because they were all
completely disconnected things. So that meant that, you know, Marge
who's been there twenty five years, she knows exactly what
to do all that, how to do all that, but

(36:05):
then Brittany comes in to fill in for lunch or something.
Now she's kind of helpless. So instead, what we designed
there was a screen that said, okay, let's take those
seven things and ex put seven buttons basically that go
straight to the thing that you're talking to that particular
person about. So one of them, for example, was this

(36:27):
turns out to be really common lawyers call up the
water billing to get final numbers for a property sale clothes.

Speaker 2 (36:35):
So there's a lawyer's button. Yeah.

Speaker 3 (36:37):
So there's basically a button just to go to go
exactly to the place to get.

Speaker 2 (36:41):
Use murder button at McDonald's, right.

Speaker 1 (36:43):
Yeah.

Speaker 3 (36:45):
So that's an example of what you think of as
hub based workflow. You've got this this central place that
promotes the ability to go to lots of different places,
but there's a reason why you're at the hub. That
those things are connected in some fashion. In this case,
they're connected by the fact that that's what people call

(37:06):
up on the phone to do. So, So that's example.
And then another another one that came up again from
a legacy app that did this just horribly badly, was
if you are on a cattle feed lot and you've
got cows moving around, and you've got they've got to

(37:26):
be fed, and they got to go to the vet
and all this stuff, well it turns out that the
people managing the cattle don't use mobile devices.

Speaker 2 (37:37):
Now is it?

Speaker 3 (37:38):
Is it obvious?

Speaker 2 (37:39):
Why?

Speaker 3 (37:40):
No, How long is a mobile device gonna last cattle
feed like condition.

Speaker 2 (37:46):
It's just it's been tried and it's there any bandwidth.

Speaker 3 (37:51):
Yeah, well that's a problem. Yeah, the connectivity could be
a problem too. But so basically they still they still
fill out paper forms. Right, so now at the beginning
of the day, somebody has to take all those paper
forms and get all the data into the system. And
there's we got to move the cattle from one one
pen to another. We got to take into account all

(38:12):
the food that was fed the cattle, because that's got
to be charged to the owners of the cattle, and
we got to import what happened on the ve veteran
a side. Maybe some cattle died and things like that.
So there's several things that you have to do, and
you have to do it every day. Coming on Monday,
you do it for the whole weekend. Right, here's the
real problem. If you leave a step out and you
do the final step that kind of puts all the

(38:33):
pieces together. You got on one on the database. Yeah,
I mean that's really bad. So that was what one
of their big customer support burdens was sort of refixing
things up for people who did it out of order.

Speaker 2 (38:48):
So one of the ring events. Yeah, that's one of the.

Speaker 3 (38:52):
Main design things was Okay, here's all those things you
got to do, check off. Yes you've done that, No,
you have it. Some warnings and things like that. Their
error right dropped dramatically and it didn't have to think
nearly as stressfully about all the different things that they
had to do, and somebody that wasn't really very sophisticated

(39:12):
could come in and take care of it.

Speaker 2 (39:14):
That was a line we used to use on the
assistedmin's side when we were doing you know, root cause
analysis is be more careful next time. Is not a strategy.
Build this into your software, right, build a name as
best you can. Yeah, so I think you don't have
to be that sensitive.

Speaker 3 (39:29):
So most legacy apps have places where you could go
in and do that. That you could, but understand that
that now is charging you with the responsibility of understanding
the big picture the jobs people carry out the details
of those tasks. That's honestly, I think that's the reason
a lot of developers don't do it. We talked about

(39:51):
code addiction. If you're addicted to code, you don't want
to take time off to go figure that business do.

Speaker 2 (39:57):
It's also tires to Tony's comment too, which was there
was a designer who wanted nothing to do with what
the customer actually needed, just wanted to design a screen.

Speaker 3 (40:08):
I think everybody, no matter what their task, they have
the thing they like to do, and they have the
other stuff that they don't necessarily like to do. But
I am blessed. Okay, I'm a generalist. I like solving problems.
None of that stuff bothers me. I love doing it
at all. But I'm a freak, and I understand that
most people in the industry aren't like me. But you

(40:30):
need for your own personal growth and you're success in
your career. You need to be able to branch out
to do those things. If you have a stack of
talents that you do as a developer and one of
them is figuring out what the business needs for this
software to do, you're going to do better in your career.

(40:53):
And you might even find out you like it well.

Speaker 2 (40:55):
And yeah, it's super valuable. Right. The fact that fose
people struggle with it and aren't key on it, it's
just another case for why you might want to focus
on that. You get a lot of return for them.

Speaker 3 (41:05):
Yeah, So just look at all those different things you
could do. You can you can learn the principles of
ux design and becoming to be a design You can
learn the principles of facilitation of a group to kind
of help them work through the solution of a problem.
And I know all this is not all for everybody,
but growing outside just the code and process world, I think, well,

(41:29):
there's also a psychological component to it. How shall I
put this. I know people that I've worked with over
the years who were extremely talented and very bright, and
their careers just never really took off. And what I
noticed is kind of the common characteristic among those people

(41:53):
is that they lack more for lack of a better
term of its, like kindness. They don't project concern for
the people that they're doing the work for. They may
be perfectly professional, but the people that are doing the
work for don't get the idea that they care. And
you're part of a you're part of a society matrix here.

(42:16):
The other people who see what you do need to
need to feel like you care about them. That's just
human that's just the way things are. And if they
give up, yeah, that's all all life. Yeah, that's life.
And so if you focus so much on code that
the people that are involved in the in the other
aspects of what you do don't get the idea that

(42:37):
you care, then they won't present you with opportunities to
do new things and move up and succeed. All my
best opportunities in this world have come about because somebody
heard some situation or some problem and said, oh, you
need to talk to Billy about that. That's my best
opportunities ever.

Speaker 1 (42:56):
I'm going to bring up switch gears here and bring
go back to the whole legacy systems and how do we,
you know, handle them without breaking them, how do we
update them? All that I might say something, I might
ask a question that's a little controversy. Maybe so, uh,
if our legacy systems were built with a micro services architecture,

(43:21):
would we necessarily have an easier time replacing just those
pieces that need replacing? And if so, is that the
only benefit to a microservice?

Speaker 3 (43:37):
Well, we might, I guess, but micro services fall into
that category of to me of things people do so
that they don't have to look at the big picture.

Speaker 2 (43:47):
Yeah.

Speaker 1 (43:48):
Yeah, and the future proofing is kind of part of
that whole.

Speaker 3 (43:53):
Well wow, but look, everything in this industry depends upon circumstances.
Some of the places I've gone and done vario sophisticated architecture.
That architecture provided the ability to change things very quickly,
so that, for example, that one of the case studies

(44:14):
often talk about is a workflow system throughout an entire
organization of a couple hundred people that was taking drug
orders on facts or Internet at one end and shipping
FedEx boxes out the other. Now drugs have some drugs
have to be mixed, some just are picked off, some
require special approval. There's all kinds of potential steps. So

(44:38):
now we don't have just a linear workflow. Every order
that comes in could zoom through the organization in a
different way. So the generalized architecture said, well, let's generalize
this down, this workflow down to there are work items,
things that need to be worked on. There are cues
the computer analog of stacks of items, and there are

(45:02):
rules that route items from one queue to another or
tell you when you've got valid data and you're done,
et cetera. So the architecture put capabilities for all those
things in place, and every existing part of the workflow
was implemented in that architecture. But now they come along

(45:22):
next month and say, you know, we need a new workstation.
There's a new condurruct coming out. We got to do
something different with it. It's ours to make that happen
with that architecture instead of going back and having to
write a custom module code somewhere that fits in. So
architecture itself can facilitate that kind of of.

Speaker 1 (45:44):
So we ought to be thinking generation when we build
new systems today, about what happens when they become legacy systems.
How easy will it need to update them? And I
don't agree that micro services is the answer because we've
already been down that road, Richard. Lately, there's been a
big back against microservice architecture for the modular monolith, right, But.

Speaker 2 (46:06):
Well, I think there's there's a universality here. Like it,
there's no universal solution, right. The best argument I've ever
heard of microservices is you have a large team and
you need to granularize the workload so that everybody's productive.
But if you don't have a large team, it's a
lot of ceremony. It's a really good point, Richard.

Speaker 1 (46:24):
So let's go back to dot Net framework on Windows,
which have the ability to update assemblies in place. Once
we got to dot Net Core, we don't have that
ability because that's a Windows feature, right, So a sp
net Core you can't, like you could do with sp
Net on dot Net framework, take a DLL, copy it

(46:44):
to the working directory and just have it come up
like there's no none of that shadowing and all of
that stuff that Windows has. However, I have a Blazer
architecture that I've figured out where if you use Razor
class libraries as the boundaries of your Blaser application, whether

(47:05):
they're pages or sets of pages or components or whatever,
those Razor class libraries can be swapped out at runtime
with a tool that is part of my architecture, and
that is a really good way to think about it.
Into future proof is a really kind of a terrible word,
isn't that. I mean, there's no such thing. But it

(47:28):
can mitigate the problems when you need to update, you know,
one piece of your application and you don't want the
whole thing to go down and you don't want all
of your users to be interrupted.

Speaker 3 (47:39):
Yeah, call it. Call it future friendly. Yeah, future friendly,
because yeah, you can't. It is not economically or even
necessarily cognitively possible to future proof.

Speaker 2 (47:51):
To take into account way is that the whole yagny line,
like you're going to need.

Speaker 3 (47:56):
It so that you certainly can't get into that. On
the other hand, at the other end, what people don't
seem to be able to do is do any significant
level of abstraction if everything is just a piece in
and of itself and they don't see the commonality between
the pieces. So you have to do that abstraction to
do effective architecture. Yes, and I will tell you that

(48:17):
number one we that's caught partially because of the agile thing.
We don't promote people doing abstraction. They're working on individual pieces,
and we don't really push them young early in their
career to develop some of those abstraction skills to think
about things. And we should, yeah, we should, We absolutely should,

(48:38):
because you can't do effective architecture without considerable abstraction exactly.

Speaker 2 (48:42):
Yeah.

Speaker 1 (48:42):
And if that just means interfaces, yeah, then that's what
it means. But multiple layers of abstraction have their benefits,
but they can also make things more complex.

Speaker 3 (48:52):
They can. It's that's I think that's the problem is
that architecture is a craft, a discipline that takes years
to develop. It isn't don't give somebody just stick architect
in their title and expect them to go do some
architecture now. It's it takes time to form that skill
set and to be disciplined about it because a lot

(49:13):
of what you're doing is balancing. Architecture is always a
balancing act. I mean, for example, one of pre eminent
people in the industry on architectures is uvall Oi good
good friend, and I think he's got a terrific uh
way of looking at architecture at the enterprise level that
he works at. And of course, if you add all

(49:36):
guys want to hear yourself get chewed out. Just go
listen to you volved. Sometimes he'll do it, but will
But what I see is that, Yeah, but what I
see is that if you go down the chain far enough,
then some of the ways that you've all would like
to do things don't apply at that bottom end, because
he's really optimized for the enterprise way of doing things.

(49:57):
And so you have to have that s It's ability,
that balance to take circumstances in size and scale and
do account in order to do it. And we just
don't have enough people that ever learned to do that.

Speaker 2 (50:10):
Yeah.

Speaker 1 (50:11):
Well, it takes judgment, and judgment comes with experience, and.

Speaker 2 (50:15):
Experience comes from massive failures.

Speaker 1 (50:17):
Yeah, but that brings us, that brings us to our
favorite topic, Richard, which is large language models. And how
I say that totally tongue in cheek because we're so
tired of talking about him. However, when you have a legacy,
you know, part of the problem with legacy applications they
were written by people who are long gone or maybe
long gone or on their way out.

Speaker 2 (50:39):
I think that's another one of the another one of
the aspects of what makes a legacy app. It's like
the team that built this isn't there anymore exactly.

Speaker 1 (50:45):
We have the source code, but it's written in whatever
you know, visual Basic six.

Speaker 2 (50:50):
Yeah, and I've also I've run in these situations where
and it's not compilable, Like we don't have a compilable
environment the moment.

Speaker 3 (50:57):
We don't have all the dependencies for whatever it is.

Speaker 1 (51:00):
Yeah, so that could be a place where a large
language model could be agents or whatever could help people
who have at least the closest knowledge set to what
these people were doing, go ahead and improve it, upgrade it,
at least get it compiled, maybe upgraded that kind of thing.

Speaker 2 (51:19):
What do you think about that?

Speaker 3 (51:21):
I think it'd be great, but i'd have to see
it work for I believe it could do that.

Speaker 2 (51:24):
Okay, Yeah, I think it's fair, and it's yeah, it's
totally fair. Certainly. Something we're pursuing on the show is
find people having success with these tools. I want real
projects fixed. I'm finding some folks having great success in
the green field space. I would love to find someone
who's really knocked it out of the park on an
existing application, a brown field refit using these kinds of tools.

(51:49):
I just haven't found it yet. It doesn't mean it
doesn't exist. I keep looking.

Speaker 1 (51:52):
Yeah, well, the GitHub copilot agent seems to do a
good job of small tasks. And by the way, if
anybody saw my Blazer train on that, I have since
changed my philosophy from write one huge prompt that does
a lot of things to you know, take it in
smaller bites. Just it's a lot easier to fix when
things go wrong. But anyway, I think that that tool

(52:14):
works really well. You know, if you give it a
small task and it goes off and does it and
comes back with a with a commit, and you can
check it out and try it and test it and
if it works good, it's really good for you know,
upgrading things and doing things differently. But your results may vary.
And since it's nondeterministic, you know what, the results I

(52:36):
get might not be the results you get here. Results
may very prompt to prompt. Yeah, that's absolutely true. How
about your results will vary definitely.

Speaker 3 (52:49):
That's the non deterministic part is the scariest part for sure. Yeah,
Because look, I learned to write code in nineteen seventy three,
and the first time from money in nineteen seventy eight
And for the entirety of that time, up until very recently,
coding was a deterministic thing. Yeah, and compiling was deterministic,

(53:10):
and running was deterministic. And so my entire brain is
trying to expect a certain amount of determinism and it
rebels at the idea that, well might not be the
same this time, and you just have to be relaxed
about that. Well, I haven't learned to be relaxed about
it yet.

Speaker 1 (53:26):
So I think the first generation was you're a surgeon, Right,
you're a DOS programmer or whatever. Before Windows, you set
a breakpoint. You have control of that entire machine at
that breakpoint. Right, you're a surgeon. You go in and
tell it exactly what you want. It does exactly what
you tell it to do. And Bob's your uncle. Windows
comes along, and now you have asynchronous, right, And that's

(53:46):
the second generation. Yeah, asynchronous is like, no, you're more
like a psychologist. You have a conversation. Yeah, you know,
you make a suggestion, you observe the behavior.

Speaker 3 (53:57):
You.

Speaker 2 (53:59):
Tweak a few things, but it'll be clear. Like we've
been living with non and Himany's behavior and computing for
a long time. Have you ever been on the Internet.
Oh well, yeah, but then every packet could travel through
a different route between a certain word client and the workstation.

Speaker 1 (54:12):
That's true in terms of certainly in terms of performance.

Speaker 2 (54:16):
Well, and yeah, you just don't know.

Speaker 1 (54:17):
Then comes along llms with nondeterminism on top of asynchrony
and the Internet and all of that stuff, and geez, wow,
it's a little different.

Speaker 3 (54:32):
I'm in the enviable position of not having to worry
very much about that because I don't expect ever to
personally hands on do a large production system. Again, I've
done many over the years. Semi retired at this point.
And the part that the thing about it is coding

(54:54):
requires a certain set of capabilities a lot of people
don't have. And I had it one time, and I
guess I still have. I just don't have them for
as long as I used to. I can't focus and
and and do that at the intensity that I once did.
On the other hand, design oriented tasks in software, you
actually get better at that as you get over because

(55:15):
you've seen more, you've seen more examples, and you have
a bigger pool of things drawn.

Speaker 1 (55:20):
So I you saw the gorilla playing basketball, Yeah, so
you know he's there.

Speaker 3 (55:27):
But yeah, so I've got all those examples and concepts
to work with. So so now I've focused my time
more on that than I do. I still write prototypes
and things like that, but I don't I don't write rutch.
I don't really write production code much anymore. I might
write a little proof of concept for some some complex
thing that somebody else doesn't really understand how to do.

(55:49):
I might, I might, I might do that. But that's
about the limit of my coding at this point. So
I get to be fairly relaxed about about these changes
pretty good.

Speaker 2 (55:58):
I got to tell you on the over on the inside,
them run as radio. Like the feedback I'm getting from
some folks where we're talking about using tools like copile
to help you right PowerShell and starting to manage it
that way, and they're criticizing it. I'm like, you know,
when you say that, you should shake your fist at
the sky. It fits together very nicely. But yeah, we're

(56:20):
still in early days. But these tools are interesting.

Speaker 1 (56:24):
They are interesting. Yeah, just don't get so freaked out
about it. Anything gonna happen.

Speaker 2 (56:29):
And I'm not going to deny there's a hype cycle
going on, because there is.

Speaker 3 (56:33):
And because of that HiPE cycle I have made fun of,
like Vibe coding, for example.

Speaker 2 (56:38):
Well, it's infinitely funnable.

Speaker 3 (56:40):
It is. It is mockable. It is extremely mockable. I
had an idea this week. I was thinking about see
what you guys think about I was thinking about writing
a humor article about a transcript of a show on
Vibe cooking.

Speaker 1 (56:53):
You know you should get you ot GPT to help
you write that.

Speaker 2 (56:57):
I mean a every comedy thing you want, right, Billy,
is something I want to read it. But no, I
like your Vibe coking idea because I think it ends
in a fireball, which I be awesome.

Speaker 3 (57:08):
Yeah, you could see that it's it's not going to
go well and going wrong. And then and then I.

Speaker 1 (57:13):
Thought I would deep frying seems like when we had
a little turmeric and see what happens.

Speaker 3 (57:18):
And then I thought, at the very end it would
be stay tuned for the next. The next on this
channel an episode of Vibe Child Rearing.

Speaker 1 (57:28):
Subscribe to my channel for more helpful hands. Oh, Billy,
it's been an absolute delight having you on the show again.
And do we know how many times you've been on Richard?
Do you have account like.

Speaker 3 (57:43):
I said, it's in the mid twenties summer.

Speaker 2 (57:45):
I think somewhere in the twenties. He's, you know, at
the near the top, if not the top. But I
think the bigger one is a single digit show, a
couple of visual digit shows, a whole bunch of three
digit shows, and a ridiculous number of four digits.

Speaker 3 (57:58):
And I'm really proud Carl the fact that the inspiration
to get started on this was you listening to me
and Rocky and I talk about something and speakers and
the speakers he thought, you know, these people have stuff
to say that other people are to hear. And absolutely
I really like having kind of so in that sense,
I've been on dot net rocks since the inception of

(58:19):
the idea you have.

Speaker 1 (58:21):
Indeed, yeah, you predate the inception certainly before the word podcast.

Speaker 2 (58:27):
Yeah, you know. I think the other one that I
like about your story on dot net Rocks, Billy, is
your transformations there too. Yeah I remember design taking you over.

Speaker 3 (58:38):
Yeah. Well, partially it is because I've always kind of
had some affinity but nobody cared, and now they started
to care and like the twenty ten times, and I
do enjoy it. And also partially because in the Microsoft space.
You go back to like twenty ten, there's nobody, nobody
who's focusing on you.

Speaker 2 (58:58):
Actually, we said embrace of zam that I think sort
of because nobody else was doing it. They're such a contrarian.

Speaker 3 (59:04):
Everybody that picked up Zamble was just like spoofing whatever
they'd done.

Speaker 2 (59:09):
Before, and you know, whatever before.

Speaker 3 (59:11):
And I'm pretty proud of the fact that that that
me and the team that we worked with on early
Examal projects, we were determined we were going to make
Examble do things that people had never seen before.

Speaker 2 (59:22):
I remember talking to one of the pms of Zamal
talking about his problem with finding concrete examples, like do
you not know who Billy Hollis is? Are you crazy? Like,
let me connect you to It'll be a long conversation.
I get clear your calendar.

Speaker 1 (59:39):
Yeah, well fantastic. I hope this is not the last
we've heard of you, mister Hollis.

Speaker 3 (59:44):
Oh, I've still got I've still got some time. I
just not as much of it. I think I'm mentioning
this on the last show, so I will I will
remind people are still listening. You know, the people on
your show do stuff. I mean they can call us
and get us to do Yeah, but your window of
opportunity for me in particular is starting to close. So

(01:00:06):
if you got something you want me to be involved
in at your company, I'm happy to talk to you,
but two years from now I might not be well.

Speaker 1 (01:00:12):
And likewise, if you've got a new rant, you call us.

Speaker 2 (01:00:14):
Okay, okay, So it's one single digit, two double digits
including panels, ten triples and ten fours. Well now eleven, wow, yeah, wow, jeez, excellent.

Speaker 1 (01:00:26):
All right, sir, we'll see you, thanks again, Thank you, gentlemen.
All right, and we'll talk to you next time on
dot net rocks. Dot net Rocks is brought to you

(01:00:56):
by Franklin's Net and produced by Pop Studios, a full
service audio, video and post production facility located physically in
New London, Connecticut, and of course in the cloud online
at pwop dot com. Visit our website at d O
T N E t R O c k S dot
com for RSS feeds, downloads, mobile apps, comments, and access

(01:01:20):
to the full archives going back to show number one,
recorded in September two thousand and two. And make sure
you check out our sponsors. They keep us in business
now go write some code. See you next time you
got Jack middle vans acc