Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads?
Speaker 2: Easy?
Speaker 1: Become a patron for just five dollars a month. You
Speaker 1: get access to a private RSS feed where all the
Speaker 1: shows have no ads. Twenty dollars a month. We'll get
Speaker 1: you that and a special dot net Rocks patron mug.
Speaker 1: Sign up now at Patreon dot dot NetRocks dot com.
Speaker 1: Hey guess what it's dot net rocks. I'm Carl Franklin,
Speaker 1: an amateurd Kembell. We're here with Reverend Billy. He'll be
Speaker 1: joining us shortly.
Speaker 2: Show number three. Yeah.
Speaker 1: Three's kind of been around since the beginning of dot net.
Speaker 2: Yeah, a one digit, two digit, three digit, four digit
Speaker 2: kind of guy.
Speaker 1: Well, you know, just real quick, how's everything up in Canadia?
Speaker 2: You know, we're doing just fine. That's good. Still summertimes warm,
Speaker 2: it's nice. I will I think when this shows comes out.
Speaker 2: I've just gotten back from a cruise to Alaska for
Speaker 2: our friend's fiftieth.
Speaker 1: Awesome and Canadians are still polite no matter what anybody says.
Speaker 1: We are, you know, still very smart. And you know
Speaker 1: they still trap beavers yeah make maple yep.
Speaker 2: Yeah, but we release them. You know, there is a
Speaker 2: guy in Quebec called the beaver Whisperer.
Speaker 1: I don't this completely fits yes in my mental model.
Speaker 2: No, you know, he's figured out how to manipulate beavers
Speaker 2: to get them to build the dams where you wanted
Speaker 2: to build them. So it's actually beneficial. Oh that's awesome. Yeah,
Speaker 2: we just had a problem with aa a beaver up
Speaker 2: the road here, and they literally changed the water structure
Speaker 2: so that it doesn't make water flowing noises because that's
Speaker 2: what beavers don't like. It's called a laminar flow inlet.
Speaker 2: So because does make any sound, the beaver's leave it
Speaker 2: alone happens to be good for you too. Well, yeah,
Speaker 2: because it doesn't flow thea anymore, which I think is
Speaker 2: a feature.
Speaker 1: Yeah, that's a good feature. Okay, let's roll into better
Speaker 1: know a framework. So crazy music, queue it up, punch it.
Speaker 2: What do you go now?
Speaker 1: I gotta preface this by saying I have not used it,
Speaker 1: but somebody mentioned on Reddit a GitHub repo called blazer
Speaker 1: dot input chips and it's got some good traction.
Speaker 2: Uh.
Speaker 1: And so it's an input control for editing a collection
Speaker 1: of chips or otherwise known as tag values. Okay, and
Speaker 1: since this is nineteen sixty two, we'll go to nineteen
Speaker 1: sixty two dot pop, dot me, and then we'll go
Speaker 1: right to this Blazer dot input chips and you can
Speaker 1: see kind of a demo of where you add a
Speaker 1: tag with a textbox and then you get the little
Speaker 1: buttons with the X you know, with the tags, and
Speaker 1: then with the X next to them, so you can.
Speaker 2: And what are the tag values for?
Speaker 1: Well, if you're tagging, let's say, an entry into you know,
Speaker 1: or review or putting up some media content and you
Speaker 1: want to tag it, you know, like dot net rocks.
Speaker 1: We have tags in dot net rocks, right, sure, So
Speaker 1: I actually thought we might.
Speaker 2: Use this.
Speaker 1: As a as a as a way to add tags.
Speaker 1: I mean, we already do it because we have a
Speaker 1: list of tags and we can do it.
Speaker 2: Fine, but that's convenient. Aren't the tags also used for
Speaker 2: things like accessibility and stuff or this identifies it for
Speaker 2: rather input sources that kind of thing.
Speaker 1: Yeah, it's metadata, right, It's just data that you associate
Speaker 1: with some other data. So making it easier to put
Speaker 1: the right mentadata on Blazer.
Speaker 2: I like that.
Speaker 1: Yeah, And it looks like just you know, it's a
Speaker 1: simple little thing. It doesn't it's not complicated, and it
Speaker 1: just looks like somebody's you know, first Blazer project is
Speaker 1: what it looks like.
Speaker 2: But it's cool. I like it. Yeah, no, that spark,
Speaker 2: I like, yeah, good.
Speaker 1: All right, So who's talking to us today, Richard?
Speaker 2: I grabbed a comment off of Billy's last show and
Speaker 2: that was nineteen fifteen, which we did back in Stember
Speaker 2: of twenty twenty four called it making design pay and
Speaker 2: one of our regulars and long time. Actually somebody I
Speaker 2: think I owe an email. Tony Vergouli wrote this a
Speaker 2: little bit long comment, but it's worth reading, and I
Speaker 2: think it was a reference to something Billy said at
Speaker 2: the end of the show, which was I can't believe
Speaker 2: you guys still listen to me, and so there's no
Speaker 2: way I can get tired to listen to you, Billy.
Speaker 2: I routinely direct developers to your talks for them to
Speaker 2: get to think about design, because when I think about design,
Speaker 2: a lot of the times I think about user experience
Speaker 2: and usability. This is probably because it's my first job.
Speaker 2: I was put in front of clients and I would
Speaker 2: hear the pain points similar to what Carl brought up
Speaker 2: about buttons and where items are placed. Then, as I
Speaker 2: heard your talks and the images that you would share
Speaker 2: about not well thought out designs, I grew to understand
Speaker 2: design was not just about the screen, but also included
Speaker 2: user experience, and I appreciate you think about the overall
Speaker 2: design and experience. Visual designers purely about designing the screen
Speaker 2: and not being able to help with any of the
Speaker 2: UI code, CSS now or whatever, and I have butted
Speaker 2: heads over the years. I'm working with one now who
Speaker 2: created a design for a web based training light app.
Speaker 2: His design was pixel perfect and specific to the device,
Speaker 2: which happened to be a surface studio too at one
Speaker 2: hundred percent scaling, and had a lot of empty space
Speaker 2: around the video player, and the buttons had moving accents
Speaker 2: crying look at me. When I questioned and pushed for
Speaker 2: this to be a responsive app, he told me not
Speaker 2: to spend time addressing something for the future, and the
Speaker 2: clients said they were running it on these devices in
Speaker 2: the lapp. After delivering the app to the client, Oh
Speaker 2: that's the best lie ever, isn't it. After delivering the
Speaker 2: app to the client, the client commented that the about
Speaker 2: the massive amount of empty space that was their term
Speaker 2: needing to zoom the browser to fifty percent because the
Speaker 2: default scale in the Surface Studio two is two hundred percent,
Speaker 2: and that the app was not responsive to run on
Speaker 2: the employee's devices remotely. Obviously, there was a failure to
Speaker 2: understand their needs. However, there's also failure of the visual
Speaker 2: designer to create a design specific to the device. This
Speaker 2: may have been because the previous apps he designed were
Speaker 2: for a specific Kioscar trade show device. To me, this
Speaker 2: type of design feels like static designs use on boxes
Speaker 2: or billboards versus business web apps. Designer in question only
Speaker 2: knows how to use Figma and Zeppelin, and that designer
Speaker 2: is all about visual, which is unfortunate. They do not
Speaker 2: want to hear feedback from the team. The design tool
Speaker 2: does not matter to me, but I liked having sketchy
Speaker 2: tools best at client meetings. So they are not critiquing
Speaker 2: the color and more focus on the flow and the experience. Yep,
Speaker 2: any design tool is fine as long as their collaboration.
Speaker 2: I appreciate your thinking and sharing. I hope to see
Speaker 2: you in Philly again and have a relaxed with a
Speaker 2: glass of sweet tea. I'm also hoping that Carl and
Speaker 2: Richard will visit Philly again. Probably not a road show
Speaker 2: because let's face it, we're getting too old for that stuff.
Speaker 1: I it's on my bucket list because I want to
Speaker 1: go down. I love Philly just as a place to
Speaker 1: hang out. And also my friend Jeff Fritz lives down there,
Speaker 1: so Jeff's down there.
Speaker 2: Yeah, it's on my list. Let's figure that out and
Speaker 2: I'll fly out as well, and we'll see how much
Speaker 2: trouble we can get into. That would be fun. Yeah, Tony,
Speaker 2: we owe you what you've done great things for us
Speaker 2: over the years, so you should call in that favor
Speaker 2: and we'll figure that out. And thanks so much for
Speaker 2: your comment. And a copy of music Cooba is on
Speaker 2: its way to you. And if you'd like a copy
Speaker 2: of music, go buy I rite a comment on the
Speaker 2: website at donnetrons dot com or on the facebooks. We
Speaker 2: publish every show there, and if you comment there and
Speaker 2: we'll read it on the show, we'll send you a
Speaker 2: copy of music.
Speaker 1: To Kobar and he's talking about music to code by
Speaker 1: this is a library of music, twenty five minute tracks
Speaker 1: that I wrote many many years ago and I still
Speaker 1: can contribute to. There's twenty two tracks right now. And
Speaker 1: you can get the entire collection at music toocode by
Speaker 1: dot net in MP three flakand wave format. What happened
Speaker 1: in nineteen sixty two, Oh nothing, just this little thing
Speaker 1: called the Cuban missile crisis.
Speaker 2: Little thing, just a little thing closest I think we
Speaker 2: ever came to nuclear.
Speaker 1: Closest we ever came to nuclear war with the you know,
Speaker 1: possible exception of now, no, no, not no, This was
Speaker 1: way more dangerous. This was way more dangerous, yes, Khrush
Speaker 1: chef and we basically had brought a blockade around Cuba.
Speaker 1: We saw some missiles and silos there. We said remove them.
Speaker 1: They said no, and you know, hilarity ensued, and we
Speaker 1: basically came face to face with their ships and you know,
Speaker 1: cooler heads.
Speaker 2: There was a moment where a missile armed submarine of
Speaker 2: the Soviet Union was headed towards Cuba. It was about
Speaker 2: to interceed on the blockade, and then they blinked and
Speaker 2: turned around. Yeah, thank god. It was an air thing,
Speaker 2: without a doubt. Terrible.
Speaker 1: Well, other things happened too, Okay, So that started a
Speaker 1: USM bargo against Cuba, and so John Glenn, Yeah, February twentieth,
Speaker 1: first American to orbit the Earth aboard Friendship seven.
Speaker 2: Later that year, Carpenter also, yeah, well that started it off.
Speaker 2: I guess that was the first American in orbit. Yeah.
Speaker 2: Marily Monroe died in August fifth. If you don't know
Speaker 2: who she is, just google her. I might want to
Speaker 2: put it in safe mode though. Sixty two feet a
Speaker 2: World Cup held in Chili. Brazil won the tournament, solidifying
Speaker 2: its status and international futbol. You got some more stuff there,
Speaker 2: a little more space. This was the beginning of the
Speaker 2: Mariner series of the space of florers. The two of
Speaker 2: them flew in nineteen sixty two, the very first one
Speaker 2: Mariner one who which promptly exploded and fell into the ocean,
Speaker 2: and the second one that was in July. In August,
Speaker 2: they flew Mariner two, same kind of satellite, same rocket,
Speaker 2: but this one made it into orbit and by December
Speaker 2: made the first fly by a Venus, the first time
Speaker 2: humans had ever sent a piece of their machinery to
Speaker 2: another planet.
Speaker 1: Right, and after studying Venus, everybody said, ouch, I'm not
Speaker 1: going there.
Speaker 2: No, not a hostile. It's a little nasty. Don't at nasty.
Speaker 2: Although there's an interesting idea about building cloud cities around Venus.
Speaker 2: There's a point in altitude's about seventy five kilometers up
Speaker 2: where it's one atmosphere of pressure, although not breatheable, lots
Speaker 2: of solar at about one G. You know, it'd be
Speaker 2: the most comfortable environment you could live in. And because
Speaker 2: the atmosphere is so dense, you could literally fill a
Speaker 2: big balloon with air and it would float on it. Wow,
Speaker 2: and you could breathe it. And if you tore a
Speaker 2: hole in it, it would it wouldn't blow out, it
Speaker 2: would just slowly leak anyway.
Speaker 1: So one G means the same amount of gravity. We
Speaker 1: enjoy the same amount of gravity. Yeah, so it wouldn't
Speaker 1: mess with us. No, we'd be pretty comfortable except for
Speaker 1: the except if that atmosphere leaked up in there, that
Speaker 1: would be.
Speaker 2: The whole floating, you know, on top of a pile
Speaker 2: of sulfur cacid is you know, Yeah, I'm not sure
Speaker 2: I like that anyway. Let me give you a little
Speaker 2: computer history.
Speaker 1: And then we discovered that it rains up instead of down,
Speaker 1: right right, So go ahead.
Speaker 2: Computer history. There is a computer called the link computer
Speaker 2: l I n C stating for a laboratory instrument computer,
Speaker 2: which is arguably the first PC ever made. It was
Speaker 2: designed at MIT and built by Deck. There was only
Speaker 2: fifty of them made. It had twelve bit words and
Speaker 2: the original model had oneenty twenty four words. Later was
Speaker 2: upgraded to twenty and forty eight of fully words and
Speaker 2: it was made for transistors, so that's why it was
Speaker 2: relatively compact. It was two units that were three foot
Speaker 2: tall and twenty inches wide. You could stack them one
Speaker 2: on top of your other if you want a six
Speaker 2: foot tall computer, or you know, go wider about for
Speaker 2: three and a half feet wide. The units typically had
Speaker 2: two tape drives, a display, control console, and a keyboard.
Speaker 2: There were about forty thousand US dollars in nineteen sixty two.
Speaker 2: Wow Jeez. Famously a lady by the name of Mary
Speaker 2: Allen Wilkes who was one of the very early programmers
Speaker 2: in the fifties working at it, initially on IBM computers,
Speaker 2: but she helped the original designer of link Fellow by
Speaker 2: the name of Leslie Clark on this design. She wrote
Speaker 2: the operating manuals and later wrote an operating system for it,
Speaker 2: and has the best quotes ever. The first quote was
Speaker 2: because she took one of these things home Wow. So
Speaker 2: she was able to say before anybody else, I'll bet
Speaker 2: you don't have a computer in your living room. And
Speaker 2: my favorite quote of them all in thinking back about programming,
Speaker 2: she said, we had this quaint notion at the time
Speaker 2: that software should be completely, absolutely free of bugs. Unfortunately,
Speaker 2: it's a notion that never really quite caught on.
Speaker 1: It was Doug Crockford's say at the end of his talks,
Speaker 1: don't write bugs.
Speaker 2: This advice, Thanks Doug. One other mit deck collaboration from
Speaker 2: nineteen sixty two. The previous year, in sixty one, Deck
Speaker 2: sent a PDP one to MIT and in nineteen sixty
Speaker 2: two a group of developers wrote a video game on
Speaker 2: it called Space War Space War. Yeah. Yeah, so that's
Speaker 2: also nineteen sixty two.
Speaker 1: Wow. All right, Well, I guess it's time then to
Speaker 1: welcome Reverend Billy back to dot net rocks for the
Speaker 1: umpteenth fifty million times, fifty eleventh time, or how do
Speaker 1: you say that in this sound fifty eleventh for eleventh time.
Speaker 1: Billy hollis, if you don't know, as a software designer
Speaker 1: and developer with a contrarian streak that often challenges conventional
Speaker 1: wisdom in the industry. He has a consulting practice in Nashville, Tennessee,
Speaker 1: and he and his team focus on User experience design UX,
Speaker 1: Advanced user interface development, rules based architectures, and healthcare systems.
Speaker 1: He teaches classes for design thinking in UX design and
Speaker 1: technical classes on ZAMO for when UI xamble for WPF
Speaker 1: is when UI still a thing, there's that an old bio,
Speaker 1: it is still a thing. Well, welcome Billy, welcome back.
Speaker 3: Well, it's always always a pleasure, guys. And you know,
Speaker 3: as as I said in the last and that comment
Speaker 3: from Conny, which I genuinely appreciate, he's he and I
Speaker 3: have talked many times over the years. I do kind
Speaker 3: of wonder why people continue to want to listen.
Speaker 2: But then I thought about it.
Speaker 3: I went, I went back, and I'll listened to the
Speaker 3: last podcast, and actually there was a lot of interesting
Speaker 3: new stuff in it, and I think that we continue.
Speaker 3: It's about a year between codcasts basically, and with that
Speaker 3: amount of time, there's always something new happening. I'm I'm
Speaker 3: poking my fingers into something new so well.
Speaker 2: And I also find like I pay attention to what
Speaker 2: sessions you're writing too, and your current thing is often
Speaker 2: reflected in that like, you take feedback of your experiences
Speaker 2: and you try and teach the new ways you're thinking
Speaker 2: that you're that you find emerging from the work you're doing.
Speaker 3: Yeah, since we do projects, real projects, and not only
Speaker 3: real projects, but you also get a sense of thinking
Speaker 3: and what's important and what people are grappling with when
Speaker 3: you talk to people at conferences, and I do. I
Speaker 3: talked to quite a lot of them, and that gives
Speaker 3: you kind of a statistical sample that you can draw
Speaker 3: some conclusions on about what the general community finds to
Speaker 3: be interesting.
Speaker 2: Yeah.
Speaker 1: Well, our listeners have used to fact that a dot
Speaker 1: net Rocks episode goes way beyond the title in terms
Speaker 1: of topics. We use that as jumping off point and
Speaker 1: then talk about the other things that brings to mind.
Speaker 1: We've always done that, so it's always good talking to you, sir.
Speaker 3: And the legacy apps thing came about from a request
Speaker 3: actually from someone because I do these lunch and learn
Speaker 3: type things for companies.
Speaker 2: Virtually.
Speaker 3: That's a fairly new thing because only in the last
Speaker 3: few years have people had the infrastructure available typically to
Speaker 3: do that. And so I have a list of topics
Speaker 3: that I do for people. They just call me up
Speaker 3: and I do it. That's kind of our substitute for
Speaker 3: sales because we don't do sales for consulting. So that's
Speaker 3: a way of letting people get familiar with what we do, right.
Speaker 3: And one company said, you know, we'd like to have
Speaker 3: you do that, but you talk a lot about all
Speaker 3: these new systems that that you design and create, and
Speaker 3: we're not going to be able to do that for
Speaker 3: a long time. We've got this legacy app, we got
Speaker 3: millions of dollars in it. Can you help us understand
Speaker 3: a little bit about what we might do, how we
Speaker 3: might apply some of the stuff you know for the
Speaker 3: legacy world. And I drew up a session based on
Speaker 3: that and started doing any conferences and it has been
Speaker 3: popular because, let's face it, a lot of people have
Speaker 3: those legacy apps. They have a huge amount of investment
Speaker 3: in them. Plus the fact that legacy apps are risky
Speaker 3: to replace if you're talking about a complete replacement.
Speaker 1: Well, I want to cure your definition of a legacy app.
Speaker 1: I have my own, but it's probably the same as yours,
Speaker 1: but let's hear yours.
Speaker 3: A legacy app to me is something that has that
Speaker 3: has been built with less than the modern leading edge
Speaker 3: technologies and has typically been around for ten years or more,
Speaker 3: sometimes up to twenty five or thirty years, and it's working.
Speaker 1: And it's working, right, It's not like it's not a pejorative.
Speaker 1: This is making money for us, Yeah.
Speaker 3: It is not. The business depends upon this application. In
Speaker 3: almost all cases, that application, if it were gone or
Speaker 3: you tried to replace it and you failed, that would
Speaker 3: have an existential consequence for the business. So all these
Speaker 3: are very very important, a lot of money in them
Speaker 3: and a lot of risk. And I know plenty of
Speaker 3: examples of companies that have tried to replace legacy apps
Speaker 3: and have have hit that failure point. I mean, even
Speaker 3: Windows eight, as far as I'm concerned, is in that category.
Speaker 2: Yes.
Speaker 3: Absolutely, they tried to completely rethink a legacy application, well
Speaker 3: a legacy operating system in this case, and completely failed
Speaker 3: at producing something new and lost billions of dollars. Well,
Speaker 3: most companies can't afford to lose that kind of money.
Speaker 1: Right, So the trick is that you need people on
Speaker 1: staff that can see the problems, whether they're security issues,
Speaker 1: because let's face it, security issues are like the number
Speaker 1: one thing, right. There's an exploit in some DLL that
Speaker 1: somebody was using and you have to patch it, and
Speaker 1: patching it might mean a lot of pain, and it
Speaker 1: might be impossible to patch because of its dependency tree.
Speaker 3: Well as legacy apps are that there's a very nice
Speaker 3: tension there because it is very high risk in order
Speaker 3: to replace them. If your if your platform becomes obsolete enough,
Speaker 3: or you've run into some of those security holes and
Speaker 3: some of the other things that can go wrong, you
Speaker 3: may eventure, or the business may change in various ways.
Speaker 3: You may eventually get to the point where it's actually
Speaker 3: a mess risk to go ahead and start over that.
Speaker 3: But that's a that's a very tough thing, and most
Speaker 3: businesses will put that off as long as they can.
Speaker 2: Because well they should. Yeah, high risks or reward.
Speaker 3: Yeah, And that's that to me is one of the
Speaker 3: key things about looking at UX design for legacy apps
Speaker 3: versus looking at UX design to do a completely replacement,
Speaker 3: which we do a lot of. Of course, there are
Speaker 3: people doing it, and if you're going to completely replace,
Speaker 3: why wouldn't you redesign to really make it leading edge?
Speaker 2: Sure?
Speaker 1: You know what's really annoying, Billy is when a perfectly
Speaker 1: find a perfectly good working application on the Internet that
Speaker 1: you're using, like, oh, I don't know, Riverside completely changes
Speaker 1: the way that you flow through your you know, do
Speaker 1: do your thing right. They put more layers in front
Speaker 1: of you that you have to navigate through. Whereas before
Speaker 1: it was one button click you knew exactly where the
Speaker 1: button was. Now there's more layers and for what you know,
Speaker 1: just makes me me angry. Here's another one. The bank
Speaker 1: that we currently use that we have to pay people
Speaker 1: with ACCH you know, direct deposit for those who don't
Speaker 1: know what that is. We have we have to scroll
Speaker 1: through all of this stuff and they did a complete revamp.
Speaker 1: But what they didn't do is fix the problems that
Speaker 1: were already there. They added more problems. Just infuriating.
Speaker 3: I think that I've I've kind of come to and
Speaker 3: understanding that one of the reasons that that sort of
Speaker 3: thing tends to happen is that software development teams in
Speaker 3: the modern era are focused a lot more on granular
Speaker 3: features than they are on big picture and workflow and
Speaker 3: things like that. And Okay, this is probably going to
Speaker 3: get into ranting territory here, which is go so if
Speaker 3: I should. But one of the reasons why there is
Speaker 3: that focus on granular features. It comes from the widespread
Speaker 3: use of Agile methodologies because they tend to focus on
Speaker 3: features in a very gradual, in a very granular sort
Speaker 3: of way. The typical backlog has a lot of features
Speaker 3: on it, and if somebody on the team goes to
Speaker 3: get something off the backlog and work on they are
Speaker 3: charged with working on that feature and getting that to work.
Speaker 3: And then they just kind of put it on a
Speaker 3: menu or something, or put it on a button somewhere, however,
Speaker 3: and they don't really think about how it fits into
Speaker 3: a bigger context. And you know, I have to give
Speaker 3: the usual disclaimers when I'm suggesting that Agile is less
Speaker 3: than perfect, because there are people out there who will
Speaker 3: who will get upset about that because it's it's it's
Speaker 3: something that they're kind of emotionally attached to. I find
Speaker 3: that's a that's a small minority actually of the people
Speaker 3: who use Agile, but they are a very vocal minority,
Speaker 3: and so I tend to hear from them, and I
Speaker 3: like to emphasize no, for the code centric parts of
Speaker 3: your of your application development, you've got to have something
Speaker 3: to manage it. And we work with lots of clients
Speaker 3: and about two thirds of them use some variation of Agile,
Speaker 3: so I've seen quite a number of them, and certainly
Speaker 3: in terms of getting the feedback, keeping people going, keeping
Speaker 3: from getting blocked, there's some value there for most of
Speaker 3: the people who use it. But that doesn't mean it's perfect.
Speaker 3: And I think one of the big defects is not
Speaker 3: looking at things from the big picture and not drawing back, and.
Speaker 1: The big picture can change, and it most likely does,
Speaker 1: doesn't it. Like you know, you start off with a
Speaker 1: good UI that where you have everything organized and it's
Speaker 1: perfect the way that you've designed it, and then new
Speaker 1: features coming along and you're not quite sure how to
Speaker 1: get there and how to put them there, and then
Speaker 1: it turns into this much. And I think, without telling
Speaker 1: who it is, one of my customers I recommended you
Speaker 1: because they were looking to do some UX redesign you
Speaker 1: I redesign, and they said they're very happy with the
Speaker 1: stuff that you've done for them so far. But I
Speaker 1: think that might be a good example of that something
Speaker 1: that started out working really really well and then just
Speaker 1: grew and grew and grew, and now they have to
Speaker 1: think about redesigning it. But it's definitely a big picture change,
Speaker 1: isn't it.
Speaker 3: It is, And you really have to draw back to
Speaker 3: look at things from the big picture to do it.
Speaker 3: And so if you're in the grind of just going
Speaker 3: forward two week sprints, get stuff off the backlogs, try
Speaker 3: to whittle let backlog down. If that's the only thing
Speaker 3: you're thinking about, then you're going to get into that
Speaker 3: kind of a mess. Now, theoretically speaking, there's some project
Speaker 3: manager role that a product manager role that that that
Speaker 3: is supposed to be looking at that and supposed to
Speaker 3: be doing big picture. In my experience, in general, big
Speaker 3: picture thinking ought to be a part of everybody on
Speaker 3: the team because that that person can't know and think
Speaker 3: of everything. So so I hope that that they'll give
Speaker 3: me a little bit of of of looseness on the
Speaker 3: Agile side, that they won't think that I'm trying to
Speaker 3: tell them that that they shouldn't do that, just that
Speaker 3: they need to spend some time thinking about the big picture.
Speaker 3: Because because I run into this whenever I say, look,
Speaker 3: Agile doesn't do this well, one of the common things
Speaker 3: I get in response is well.
Speaker 2: That's not really agile, yeah right.
Speaker 3: That, yeah, that's that's that is I think of that
Speaker 3: anyway as an example of the no true Scotsman logical fallacy.
Speaker 2: You guys know that one.
Speaker 3: It's like, you know, no true Scotts, no Scotsman puts
Speaker 3: sugar in his porridge.
Speaker 1: Right, No true Scotsman dips his Scotch eggs and Marl.
Speaker 3: My cousin Angus likes sugar in his porridge. Yes, but
Speaker 3: no true Scotsman so must not be a true Scotsman
Speaker 3: that that kind of that kind of thinking does not
Speaker 3: get into the the the reality of the fact.
Speaker 2: Maybe they're right.
Speaker 3: I don't know, I'm not.
Speaker 1: It's an excuse to ignore the facts in front of you.
Speaker 3: Yeah, I'm not on the Council of High holy people
Speaker 3: who define what agile is. I'm not in that. Apparently
Speaker 3: a lot of people are, but I am not on that,
Speaker 3: And I don't know. I just know what I see,
Speaker 3: and I see that if I see teams doing things
Speaker 3: the same way a lot of different teams, then I
Speaker 3: have to presume that that's kind of part of what
Speaker 3: agile is. Is that enough for the rant? I guess
Speaker 3: we should get back to when we get back to
Speaker 3: real stuff.
Speaker 2: Slash soapbox. When you're where you're tackling the problem of
Speaker 2: a legacy rewrite like this. I mean, obviously you're jumping
Speaker 2: a bunch of versions or jumping into a different stock entirely.
Speaker 2: Is this all about initially rendering a ux just sitting
Speaker 2: with the people who use the app and say, how
Speaker 2: you know, how much of your workflow is based on
Speaker 2: how this software works versus how much of your workflow
Speaker 2: you know, really flows?
Speaker 3: Yeah, it's it varies all the way. From man, we're
Speaker 3: throwing out everything we've got, including the back end. But
Speaker 3: more commonly, what I find in general is that companies
Speaker 3: have done a pretty good job in the dot neet
Speaker 3: era of getting their back end to the point where
Speaker 3: it needs to.
Speaker 2: Be, because it costs money, and.
Speaker 3: It costs a lot of money if you don't get
Speaker 3: that right, and it creates problems that are really hard
Speaker 3: to work around. So I find that the majority of
Speaker 3: the people we go into have done a pretty good
Speaker 3: job of getting their back into place. So now they're
Speaker 3: replacing the front end, and that makes sense. You think
Speaker 3: about all the proliferation by that word always stumbles me up.
Speaker 3: Do you guys have words like proliferation is one of them?
Speaker 3: And another one for me is interoperability, I have to.
Speaker 2: Correct. That's why we always say interopt.
Speaker 3: But the proliferation of different devices and form factors in
Speaker 3: many cases pushes people towards new platforms for pushing the
Speaker 3: app out because they have to there are people that
Speaker 3: they have to have to reach. So that will cause
Speaker 3: a really dramatically route of the front end, maybe multiple
Speaker 3: front ends. But then there's another layer of Okay, we
Speaker 3: got a business app, and you know it's running the
Speaker 3: business and it's doing fine, and we know we could
Speaker 3: take advantage off some of the modern UI technologies and
Speaker 3: we could do better. We could improve this app, but
Speaker 3: they are not at the point where they're ready to
Speaker 3: take on the risk of a complete front end replacement.
Speaker 3: And that's what that's session that we talked about is about.
Speaker 3: When you're stuck with this business I shouldn't say stuck
Speaker 3: with If you have decided that it's meeting your business
Speaker 3: needs in general, that doesn't mean you can't still try
Speaker 3: to try to improve it because there's a lot of
Speaker 3: a lot of latitude to do that.
Speaker 2: I mean, I got to think of this. If your
Speaker 2: app is that critical to the workflow, every minute you
Speaker 2: can cut off achieving a task represents significant savings over
Speaker 2: and over and over again. Every time you can avoid
Speaker 2: causing a mistake that happens routinely, they all have big benefits.
Speaker 2: Little incremental improvement should have huge benefit.
Speaker 3: And that is the two usual metrics you're looking at
Speaker 3: as a justification for doing it. Is that you're speeding
Speaker 3: people up and you're keeping them from making as many mistakes.
Speaker 3: And there is a normous room for improvement, partially because
Speaker 3: of the way we came at building applications in the
Speaker 3: first place. Our first round of automation back in the
Speaker 3: eighties and nineties was almost just pure database apps, file
Speaker 3: maintenance apps. Sure that you are basically using the computer
Speaker 3: screen as a replacement for paper and folders and such.
Speaker 3: And you know, we still see we still see the
Speaker 3: effects of that today. What I tell people in that session,
Speaker 3: one of the things I tell people in that session
Speaker 3: is if you look at a business app and you
Speaker 3: look at the menu, and you can map the menu
Speaker 3: of the business app to the database schema, then you
Speaker 3: have an enormous room for improving how that app helps
Speaker 3: users do their jobs. Because if that's the way it is,
Speaker 3: the user has got Let's say the user's got like
Speaker 3: five five steps in some work task that they've got
Speaker 3: to do. If you've got that database style thing, that
Speaker 3: probably means they go to four or five different places
Speaker 3: in the app to do it. They have to bounce
Speaker 3: around in the menus and they have to do this
Speaker 3: part of it and then go over to someplace completely
Speaker 3: different to do the next thing. Well, from a design perspective,
Speaker 3: one of the things we try to do is limit
Speaker 3: the use of short term memory and limit the use
Speaker 3: of attention, because both of those are limited. That's just
Speaker 3: built into our heads that we've only got so much.
Speaker 3: So if you're having to split your attention between navigating
Speaker 3: menus and the actual work task that you're trying to accomplish,
Speaker 3: that now you're using up your attention. And if you
Speaker 3: have to track where I am, Oh, did I finish
Speaker 3: step three and ready to go over to a different
Speaker 3: menu for step four, if you are having to do that,
Speaker 3: you are straining your short term memory. And so the
Speaker 3: options that the possibilities for doing better are quite dramatic.
Speaker 3: And you can speed people up, as Richard said, and
Speaker 3: you can prevent errors by keeping people from doing things
Speaker 3: out of order and stuff like that.
Speaker 1: You know, one of my customers is dealing with this
Speaker 1: now and it's the Microsoft Office problem, right. You think
Speaker 1: about Microsoft Office. First everything was in menus, then they
Speaker 1: had a menu bar, then they had the ribbon, and
Speaker 1: you know, we when we started out with this customer,
Speaker 1: they were adamant that they wanted to standardize the menus,
Speaker 1: like every page has an action menu, where in a
Speaker 1: view menu where you can go to different pages and
Speaker 1: action menu, we can do the things. But some of
Speaker 1: the actions are so critical and some of the navigations
Speaker 1: are so critical they pull them out of those menus
Speaker 1: and put them well not pull them out, but they
Speaker 1: add buttons to the top of the page that do
Speaker 1: those things because they're so critical that they don't want
Speaker 1: the user to have to go search for them in
Speaker 1: a menu. Well, that brings up the question why have
Speaker 1: anything in the menu if because you have to search
Speaker 1: for it? I mean, yeah, just because it's not critical,
Speaker 1: they're still going to have to search for it. So
Speaker 1: just it's it's a good tension.
Speaker 3: That's a great example of the the Yeah, the philosophy,
Speaker 3: the physical philosophical approach from my perspective, is especially in
Speaker 3: legacy apps, you don't necessarily want to take away the
Speaker 3: way things are done now that would have a lot
Speaker 3: of ramifications that you don't want to deal with. But sure,
Speaker 3: there's nothing wrong with finding different ways to get to
Speaker 3: those steps in a workflow, or creating completely separate views
Speaker 3: that say, Okay, I've got the five steps. Why don't
Speaker 3: we create another view that has those buttons to get
Speaker 3: to those five steps and maybe some kind of tracking
Speaker 3: that says, yes, I've done this and that one. You know,
Speaker 3: change the visuals a little bit.
Speaker 2: Now. People off share, especially when you start thinking about
Speaker 2: different devices, right, Like, you've been doing this all this
Speaker 2: time on a PC, but now they really want to
Speaker 2: be able to use a tablet or a phone, and
Speaker 2: the ux menaphores are different. The Hamburger menu makes sense
Speaker 2: in that scenario, and it doesn't make sense on a PC.
Speaker 3: So that that's kind of what I encourage people to
Speaker 3: do when I talk about the legacy app thing is
Speaker 3: look for the common workflows, the one that a lot
Speaker 3: as you you said earlier, the ones that a lot
Speaker 3: of people do a lot of the time, and really
Speaker 3: make it transparently easy for people to go through that.
Speaker 3: And notice that you don't just speak people up and
Speaker 3: prevent errors. Although those are really two big considerations. You
Speaker 3: also lower people's stress and fatigue because they're not using
Speaker 3: up their short constrated hard and you make it easy
Speaker 3: for somebody new to walk up to one of these
Speaker 3: things and carry carry out some process because they don't
Speaker 3: have to know as much about how to bounch around
Speaker 3: the menu. It would help for I can do a
Speaker 3: couple of tangible examples from real projects.
Speaker 2: If that would help. Let's do the break.
Speaker 1: Yeah, let's do the break first, so we'll be right
Speaker 1: back with Billy's suggestions after we get through this break.
Speaker 1: So stick around. We'll be right back after these very
Speaker 1: important mesters.
Speaker 2: Do you have a.
Speaker 1: Complex dot net monolith you'd like to refactor to a
Speaker 1: micro services architecture? The micro Service Extractor for dot Net
Speaker 1: tool visualizes your app and helps progressively extract code into
Speaker 1: micro services. Learn more at aws dot Amazon dot com,
Speaker 1: slash modernize, and we're back it starting at rocks some
Speaker 1: Carl Franklin, it's Richard Campbell. Hey, that's Reverend Billy Hollis,
Speaker 1: and he's going to give us some examples for the record,
Speaker 1: not a reverend, not for the record, Yes, not a reverend. No,
Speaker 1: that's a that's a nickname I gave him after a
Speaker 1: hilarious talk that he did at a.
Speaker 3: Well it's that Southern accent that I get a little
Speaker 3: bit excited talking about stuff.
Speaker 1: No no, no, dough. It was put your hands on
Speaker 1: the screen and repeede after me. I am an addicted
Speaker 1: a code addict.
Speaker 3: Do you guys know that video where I started the
Speaker 3: whole thing about code addiction was twenty years ago? I know,
Speaker 3: isn't that crazy this year because it was at tech
Speaker 3: ed two thousand and five. Yeah, and that video, by
Speaker 3: the way, is still out there on YouTube. Smarty wants
Speaker 3: to go look at the technology is.
Speaker 2: All absolute, but I will clude it in the show notes. Okay, good, Yeah.
Speaker 1: Before you get to your suggestions, I just want to
Speaker 1: get back to desktop apps for a bit, because we
Speaker 1: also forget about keyboard shortcuts with desktop apps, even in
Speaker 1: browser apps, keyboard shortcuts, because those are things that you know,
Speaker 1: people sitting at their desks don't want to navigate through
Speaker 1: hierarchical menus. Once they know where they need to go,
Speaker 1: they should be able to just hit a couple of
Speaker 1: keys and go there. Anyway, So back to your uh.
Speaker 3: Yeah, and just to come and finish off that my
Speaker 3: philosophy is that having multiple ways to get to things
Speaker 3: for different classes of users is perfectly fine, and there's
Speaker 3: a tendency not to do that. Again, going back to
Speaker 3: the very beginning of our of our industry, where you
Speaker 3: have these extremely limited screens, these character based screens that
Speaker 3: you know there was one function key to get to this,
Speaker 3: and the tech support would tell you, oh, if you
Speaker 3: want to do this, press F two and then F
Speaker 3: five or whatever. But now with modern UI, you should
Speaker 3: make you can make multiple ways to get into things,
Speaker 3: and that's there's nothing really wrong with it.
Speaker 2: Nothing wrong with that.
Speaker 3: Yeah, one thing that one example that comes to mind
Speaker 3: is a situation that's not kind of the linear work
Speaker 3: for we're talking about. I got another one of those
Speaker 3: I'll talk about too, But I was working with a
Speaker 3: company actually not too far from you, Carl, up in Connecticut,
Speaker 3: and they were doing a utility building package. Now, think
Speaker 3: about somebody answering the phone in a utility building place.
Speaker 3: What do they need to be able to do in
Speaker 3: the app to respond to the people that are on
Speaker 3: the phone. Well, it turned out, as we discovered there
Speaker 3: there were about seven things that form the clear large
Speaker 3: majority of all the things that they have to ever
Speaker 3: answer phone calls about and so in order to do
Speaker 3: that work, they had to be able to go to
Speaker 3: seven different places in the app because they were all
Speaker 3: completely disconnected things. So that meant that, you know, Marge
Speaker 3: who's been there twenty five years, she knows exactly what
Speaker 3: to do all that, how to do all that, but
Speaker 3: then Brittany comes in to fill in for lunch or something.
Speaker 3: Now she's kind of helpless. So instead, what we designed
Speaker 3: there was a screen that said, okay, let's take those
Speaker 3: seven things and ex put seven buttons basically that go
Speaker 3: straight to the thing that you're talking to that particular
Speaker 3: person about. So one of them, for example, was this
Speaker 3: turns out to be really common lawyers call up the
Speaker 3: water billing to get final numbers for a property sale clothes.
Speaker 2: So there's a lawyer's button. Yeah.
Speaker 3: So there's basically a button just to go to go
Speaker 3: exactly to the place to get.
Speaker 2: Use murder button at McDonald's, right.
Speaker 1: Yeah.
Speaker 3: So that's an example of what you think of as
Speaker 3: hub based workflow. You've got this this central place that
Speaker 3: promotes the ability to go to lots of different places,
Speaker 3: but there's a reason why you're at the hub. That
Speaker 3: those things are connected in some fashion. In this case,
Speaker 3: they're connected by the fact that that's what people call
Speaker 3: up on the phone to do. So, So that's example.
Speaker 3: And then another another one that came up again from
Speaker 3: a legacy app that did this just horribly badly, was
Speaker 3: if you are on a cattle feed lot and you've
Speaker 3: got cows moving around, and you've got they've got to
Speaker 3: be fed, and they got to go to the vet
Speaker 3: and all this stuff, well it turns out that the
Speaker 3: people managing the cattle don't use mobile devices.
Speaker 2: Now is it?
Speaker 3: Is it obvious?
Speaker 2: Why?
Speaker 3: No, How long is a mobile device gonna last cattle
Speaker 3: feed like condition.
Speaker 2: It's just it's been tried and it's there any bandwidth.
Speaker 3: Yeah, well that's a problem. Yeah, the connectivity could be
Speaker 3: a problem too. But so basically they still they still
Speaker 3: fill out paper forms. Right, so now at the beginning
Speaker 3: of the day, somebody has to take all those paper
Speaker 3: forms and get all the data into the system. And
Speaker 3: there's we got to move the cattle from one one
Speaker 3: pen to another. We got to take into account all
Speaker 3: the food that was fed the cattle, because that's got
Speaker 3: to be charged to the owners of the cattle, and
Speaker 3: we got to import what happened on the ve veteran
Speaker 3: a side. Maybe some cattle died and things like that.
Speaker 3: So there's several things that you have to do, and
Speaker 3: you have to do it every day. Coming on Monday,
Speaker 3: you do it for the whole weekend. Right, here's the
Speaker 3: real problem. If you leave a step out and you
Speaker 3: do the final step that kind of puts all the
Speaker 3: pieces together. You got on one on the database. Yeah,
Speaker 3: I mean that's really bad. So that was what one
Speaker 3: of their big customer support burdens was sort of refixing
Speaker 3: things up for people who did it out of order.
Speaker 2: So one of the ring events. Yeah, that's one of the.
Speaker 3: Main design things was Okay, here's all those things you
Speaker 3: got to do, check off. Yes you've done that, No,
Speaker 3: you have it. Some warnings and things like that. Their
Speaker 3: error right dropped dramatically and it didn't have to think
Speaker 3: nearly as stressfully about all the different things that they
Speaker 3: had to do, and somebody that wasn't really very sophisticated
Speaker 3: could come in and take care of it.
Speaker 2: That was a line we used to use on the
Speaker 2: assistedmin's side when we were doing you know, root cause
Speaker 2: analysis is be more careful next time. Is not a strategy.
Speaker 2: Build this into your software, right, build a name as
Speaker 2: best you can. Yeah, so I think you don't have
Speaker 2: to be that sensitive.
Speaker 3: So most legacy apps have places where you could go
Speaker 3: in and do that. That you could, but understand that
Speaker 3: that now is charging you with the responsibility of understanding
Speaker 3: the big picture the jobs people carry out the details
Speaker 3: of those tasks. That's honestly, I think that's the reason
Speaker 3: a lot of developers don't do it. We talked about
Speaker 3: code addiction. If you're addicted to code, you don't want
Speaker 3: to take time off to go figure that business do.
Speaker 2: It's also tires to Tony's comment too, which was there
Speaker 2: was a designer who wanted nothing to do with what
Speaker 2: the customer actually needed, just wanted to design a screen.
Speaker 3: I think everybody, no matter what their task, they have
Speaker 3: the thing they like to do, and they have the
Speaker 3: other stuff that they don't necessarily like to do. But
Speaker 3: I am blessed. Okay, I'm a generalist. I like solving problems.
Speaker 3: None of that stuff bothers me. I love doing it
Speaker 3: at all. But I'm a freak, and I understand that
Speaker 3: most people in the industry aren't like me. But you
Speaker 3: need for your own personal growth and you're success in
Speaker 3: your career. You need to be able to branch out
Speaker 3: to do those things. If you have a stack of
Speaker 3: talents that you do as a developer and one of
Speaker 3: them is figuring out what the business needs for this
Speaker 3: software to do, you're going to do better in your career.
Speaker 3: And you might even find out you like it well.
Speaker 2: And yeah, it's super valuable. Right. The fact that fose
Speaker 2: people struggle with it and aren't key on it, it's
Speaker 2: just another case for why you might want to focus
Speaker 2: on that. You get a lot of return for them.
Speaker 3: Yeah, So just look at all those different things you
Speaker 3: could do. You can you can learn the principles of
Speaker 3: ux design and becoming to be a design You can
Speaker 3: learn the principles of facilitation of a group to kind
Speaker 3: of help them work through the solution of a problem.
Speaker 3: And I know all this is not all for everybody,
Speaker 3: but growing outside just the code and process world, I think, well,
Speaker 3: there's also a psychological component to it. How shall I
Speaker 3: put this. I know people that I've worked with over
Speaker 3: the years who were extremely talented and very bright, and
Speaker 3: their careers just never really took off. And what I
Speaker 3: noticed is kind of the common characteristic among those people
Speaker 3: is that they lack more for lack of a better
Speaker 3: term of its, like kindness. They don't project concern for
Speaker 3: the people that they're doing the work for. They may
Speaker 3: be perfectly professional, but the people that are doing the
Speaker 3: work for don't get the idea that they care. And
Speaker 3: you're part of a you're part of a society matrix here.
Speaker 3: The other people who see what you do need to
Speaker 3: need to feel like you care about them. That's just
Speaker 3: human that's just the way things are. And if they
Speaker 3: give up, yeah, that's all all life. Yeah, that's life.
Speaker 3: And so if you focus so much on code that
Speaker 3: the people that are involved in the in the other
Speaker 3: aspects of what you do don't get the idea that
Speaker 3: you care, then they won't present you with opportunities to
Speaker 3: do new things and move up and succeed. All my
Speaker 3: best opportunities in this world have come about because somebody
Speaker 3: heard some situation or some problem and said, oh, you
Speaker 3: need to talk to Billy about that. That's my best
Speaker 3: opportunities ever.
Speaker 1: I'm going to bring up switch gears here and bring
Speaker 1: go back to the whole legacy systems and how do we,
Speaker 1: you know, handle them without breaking them, how do we
Speaker 1: update them? All that I might say something, I might
Speaker 1: ask a question that's a little controversy. Maybe so, uh,
Speaker 1: if our legacy systems were built with a micro services architecture,
Speaker 1: would we necessarily have an easier time replacing just those
Speaker 1: pieces that need replacing? And if so, is that the
Speaker 1: only benefit to a microservice?
Speaker 3: Well, we might, I guess, but micro services fall into
Speaker 3: that category of to me of things people do so
Speaker 3: that they don't have to look at the big picture.
Speaker 2: Yeah.
Speaker 1: Yeah, and the future proofing is kind of part of
Speaker 1: that whole.
Speaker 3: Well wow, but look, everything in this industry depends upon circumstances.
Speaker 3: Some of the places I've gone and done vario sophisticated architecture.
Speaker 3: That architecture provided the ability to change things very quickly,
Speaker 3: so that, for example, that one of the case studies
Speaker 3: often talk about is a workflow system throughout an entire
Speaker 3: organization of a couple hundred people that was taking drug
Speaker 3: orders on facts or Internet at one end and shipping
Speaker 3: FedEx boxes out the other. Now drugs have some drugs
Speaker 3: have to be mixed, some just are picked off, some
Speaker 3: require special approval. There's all kinds of potential steps. So
Speaker 3: now we don't have just a linear workflow. Every order
Speaker 3: that comes in could zoom through the organization in a
Speaker 3: different way. So the generalized architecture said, well, let's generalize
Speaker 3: this down, this workflow down to there are work items,
Speaker 3: things that need to be worked on. There are cues
Speaker 3: the computer analog of stacks of items, and there are
Speaker 3: rules that route items from one queue to another or
Speaker 3: tell you when you've got valid data and you're done,
Speaker 3: et cetera. So the architecture put capabilities for all those
Speaker 3: things in place, and every existing part of the workflow
Speaker 3: was implemented in that architecture. But now they come along
Speaker 3: next month and say, you know, we need a new workstation.
Speaker 3: There's a new condurruct coming out. We got to do
Speaker 3: something different with it. It's ours to make that happen
Speaker 3: with that architecture instead of going back and having to
Speaker 3: write a custom module code somewhere that fits in. So
Speaker 3: architecture itself can facilitate that kind of of.
Speaker 1: So we ought to be thinking generation when we build
Speaker 1: new systems today, about what happens when they become legacy systems.
Speaker 1: How easy will it need to update them? And I
Speaker 1: don't agree that micro services is the answer because we've
Speaker 1: already been down that road, Richard. Lately, there's been a
Speaker 1: big back against microservice architecture for the modular monolith, right, But.
Speaker 2: Well, I think there's there's a universality here. Like it,
Speaker 2: there's no universal solution, right. The best argument I've ever
Speaker 2: heard of microservices is you have a large team and
Speaker 2: you need to granularize the workload so that everybody's productive.
Speaker 2: But if you don't have a large team, it's a
Speaker 2: lot of ceremony. It's a really good point, Richard.
Speaker 1: So let's go back to dot Net framework on Windows,
Speaker 1: which have the ability to update assemblies in place. Once
Speaker 1: we got to dot Net Core, we don't have that
Speaker 1: ability because that's a Windows feature, right, So a sp
Speaker 1: net Core you can't, like you could do with sp
Speaker 1: Net on dot Net framework, take a DLL, copy it
Speaker 1: to the working directory and just have it come up
Speaker 1: like there's no none of that shadowing and all of
Speaker 1: that stuff that Windows has. However, I have a Blazer
Speaker 1: architecture that I've figured out where if you use Razor
Speaker 1: class libraries as the boundaries of your Blaser application, whether
Speaker 1: they're pages or sets of pages or components or whatever,
Speaker 1: those Razor class libraries can be swapped out at runtime
Speaker 1: with a tool that is part of my architecture, and
Speaker 1: that is a really good way to think about it.
Speaker 1: Into future proof is a really kind of a terrible word,
Speaker 1: isn't that. I mean, there's no such thing. But it
Speaker 1: can mitigate the problems when you need to update, you know,
Speaker 1: one piece of your application and you don't want the
Speaker 1: whole thing to go down and you don't want all
Speaker 1: of your users to be interrupted.
Speaker 3: Yeah, call it. Call it future friendly. Yeah, future friendly,
Speaker 3: because yeah, you can't. It is not economically or even
Speaker 3: necessarily cognitively possible to future proof.
Speaker 2: To take into account way is that the whole yagny line,
Speaker 2: like you're going to need.
Speaker 3: It so that you certainly can't get into that. On
Speaker 3: the other hand, at the other end, what people don't
Speaker 3: seem to be able to do is do any significant
Speaker 3: level of abstraction if everything is just a piece in
Speaker 3: and of itself and they don't see the commonality between
Speaker 3: the pieces. So you have to do that abstraction to
Speaker 3: do effective architecture. Yes, and I will tell you that
Speaker 3: number one we that's caught partially because of the agile thing.
Speaker 3: We don't promote people doing abstraction. They're working on individual pieces,
Speaker 3: and we don't really push them young early in their
Speaker 3: career to develop some of those abstraction skills to think
Speaker 3: about things. And we should, yeah, we should, We absolutely should,
Speaker 3: because you can't do effective architecture without considerable abstraction exactly.
Speaker 2: Yeah.
Speaker 1: And if that just means interfaces, yeah, then that's what
Speaker 1: it means. But multiple layers of abstraction have their benefits,
Speaker 1: but they can also make things more complex.
Speaker 3: They can. It's that's I think that's the problem is
Speaker 3: that architecture is a craft, a discipline that takes years
Speaker 3: to develop. It isn't don't give somebody just stick architect
Speaker 3: in their title and expect them to go do some
Speaker 3: architecture now. It's it takes time to form that skill
Speaker 3: set and to be disciplined about it because a lot
Speaker 3: of what you're doing is balancing. Architecture is always a
Speaker 3: balancing act. I mean, for example, one of pre eminent
Speaker 3: people in the industry on architectures is uvall Oi good
Speaker 3: good friend, and I think he's got a terrific uh
Speaker 3: way of looking at architecture at the enterprise level that
Speaker 3: he works at. And of course, if you add all
Speaker 3: guys want to hear yourself get chewed out. Just go
Speaker 3: listen to you volved. Sometimes he'll do it, but will
Speaker 3: But what I see is that, Yeah, but what I
Speaker 3: see is that if you go down the chain far enough,
Speaker 3: then some of the ways that you've all would like
Speaker 3: to do things don't apply at that bottom end, because
Speaker 3: he's really optimized for the enterprise way of doing things.
Speaker 3: And so you have to have that s It's ability,
Speaker 3: that balance to take circumstances in size and scale and
Speaker 3: do account in order to do it. And we just
Speaker 3: don't have enough people that ever learned to do that.
Speaker 2: Yeah.
Speaker 1: Well, it takes judgment, and judgment comes with experience, and.
Speaker 2: Experience comes from massive failures.
Speaker 1: Yeah, but that brings us, that brings us to our
Speaker 1: favorite topic, Richard, which is large language models. And how
Speaker 1: I say that totally tongue in cheek because we're so
Speaker 1: tired of talking about him. However, when you have a legacy,
Speaker 1: you know, part of the problem with legacy applications they
Speaker 1: were written by people who are long gone or maybe
Speaker 1: long gone or on their way out.
Speaker 2: I think that's another one of the another one of
Speaker 2: the aspects of what makes a legacy app. It's like
Speaker 2: the team that built this isn't there anymore exactly.
Speaker 1: We have the source code, but it's written in whatever
Speaker 1: you know, visual Basic six.
Speaker 2: Yeah, and I've also I've run in these situations where
Speaker 2: and it's not compilable, Like we don't have a compilable
Speaker 2: environment the moment.
Speaker 3: We don't have all the dependencies for whatever it is.
Speaker 1: Yeah, so that could be a place where a large
Speaker 1: language model could be agents or whatever could help people
Speaker 1: who have at least the closest knowledge set to what
Speaker 1: these people were doing, go ahead and improve it, upgrade it,
Speaker 1: at least get it compiled, maybe upgraded that kind of thing.
Speaker 2: What do you think about that?
Speaker 3: I think it'd be great, but i'd have to see
Speaker 3: it work for I believe it could do that.
Speaker 2: Okay, Yeah, I think it's fair, and it's yeah, it's
Speaker 2: totally fair. Certainly. Something we're pursuing on the show is
Speaker 2: find people having success with these tools. I want real
Speaker 2: projects fixed. I'm finding some folks having great success in
Speaker 2: the green field space. I would love to find someone
Speaker 2: who's really knocked it out of the park on an
Speaker 2: existing application, a brown field refit using these kinds of tools.
Speaker 2: I just haven't found it yet. It doesn't mean it
Speaker 2: doesn't exist. I keep looking.
Speaker 1: Yeah, well, the GitHub copilot agent seems to do a
Speaker 1: good job of small tasks. And by the way, if
Speaker 1: anybody saw my Blazer train on that, I have since
Speaker 1: changed my philosophy from write one huge prompt that does
Speaker 1: a lot of things to you know, take it in
Speaker 1: smaller bites. Just it's a lot easier to fix when
Speaker 1: things go wrong. But anyway, I think that that tool
Speaker 1: works really well. You know, if you give it a
Speaker 1: small task and it goes off and does it and
Speaker 1: comes back with a with a commit, and you can
Speaker 1: check it out and try it and test it and
Speaker 1: if it works good, it's really good for you know,
Speaker 1: upgrading things and doing things differently. But your results may vary.
Speaker 1: And since it's nondeterministic, you know what, the results I
Speaker 1: get might not be the results you get here. Results
Speaker 1: may very prompt to prompt. Yeah, that's absolutely true. How
Speaker 1: about your results will vary definitely.
Speaker 3: That's the non deterministic part is the scariest part for sure. Yeah,
Speaker 3: Because look, I learned to write code in nineteen seventy three,
Speaker 3: and the first time from money in nineteen seventy eight
Speaker 3: And for the entirety of that time, up until very recently,
Speaker 3: coding was a deterministic thing. Yeah, and compiling was deterministic,
Speaker 3: and running was deterministic. And so my entire brain is
Speaker 3: trying to expect a certain amount of determinism and it
Speaker 3: rebels at the idea that, well might not be the
Speaker 3: same this time, and you just have to be relaxed
Speaker 3: about that. Well, I haven't learned to be relaxed about
Speaker 3: it yet.
Speaker 1: So I think the first generation was you're a surgeon, Right,
Speaker 1: you're a DOS programmer or whatever. Before Windows, you set
Speaker 1: a breakpoint. You have control of that entire machine at
Speaker 1: that breakpoint. Right, you're a surgeon. You go in and
Speaker 1: tell it exactly what you want. It does exactly what
Speaker 1: you tell it to do. And Bob's your uncle. Windows
Speaker 1: comes along, and now you have asynchronous, right, And that's
Speaker 1: the second generation. Yeah, asynchronous is like, no, you're more
Speaker 1: like a psychologist. You have a conversation. Yeah, you know,
Speaker 1: you make a suggestion, you observe the behavior.
Speaker 3: You.
Speaker 2: Tweak a few things, but it'll be clear. Like we've
Speaker 2: been living with non and Himany's behavior and computing for
Speaker 2: a long time. Have you ever been on the Internet.
Speaker 2: Oh well, yeah, but then every packet could travel through
Speaker 2: a different route between a certain word client and the workstation.
Speaker 1: That's true in terms of certainly in terms of performance.
Speaker 2: Well, and yeah, you just don't know.
Speaker 1: Then comes along llms with nondeterminism on top of asynchrony
Speaker 1: and the Internet and all of that stuff, and geez, wow,
Speaker 1: it's a little different.
Speaker 3: I'm in the enviable position of not having to worry
Speaker 3: very much about that because I don't expect ever to
Speaker 3: personally hands on do a large production system. Again, I've
Speaker 3: done many over the years. Semi retired at this point.
Speaker 3: And the part that the thing about it is coding
Speaker 3: requires a certain set of capabilities a lot of people
Speaker 3: don't have. And I had it one time, and I
Speaker 3: guess I still have. I just don't have them for
Speaker 3: as long as I used to. I can't focus and
Speaker 3: and and do that at the intensity that I once did.
Speaker 3: On the other hand, design oriented tasks in software, you
Speaker 3: actually get better at that as you get over because
Speaker 3: you've seen more, you've seen more examples, and you have
Speaker 3: a bigger pool of things drawn.
Speaker 1: So I you saw the gorilla playing basketball, Yeah, so
Speaker 1: you know he's there.
Speaker 3: But yeah, so I've got all those examples and concepts
Speaker 3: to work with. So so now I've focused my time
Speaker 3: more on that than I do. I still write prototypes
Speaker 3: and things like that, but I don't I don't write rutch.
Speaker 3: I don't really write production code much anymore. I might
Speaker 3: write a little proof of concept for some some complex
Speaker 3: thing that somebody else doesn't really understand how to do.
Speaker 3: I might, I might, I might do that. But that's
Speaker 3: about the limit of my coding at this point. So
Speaker 3: I get to be fairly relaxed about about these changes
Speaker 3: pretty good.
Speaker 2: I got to tell you on the over on the inside,
Speaker 2: them run as radio. Like the feedback I'm getting from
Speaker 2: some folks where we're talking about using tools like copile
Speaker 2: to help you right PowerShell and starting to manage it
Speaker 2: that way, and they're criticizing it. I'm like, you know,
Speaker 2: when you say that, you should shake your fist at
Speaker 2: the sky. It fits together very nicely. But yeah, we're
Speaker 2: still in early days. But these tools are interesting.
Speaker 1: They are interesting. Yeah, just don't get so freaked out
Speaker 1: about it. Anything gonna happen.
Speaker 2: And I'm not going to deny there's a hype cycle
Speaker 2: going on, because there is.
Speaker 3: And because of that HiPE cycle I have made fun of,
Speaker 3: like Vibe coding, for example.
Speaker 2: Well, it's infinitely funnable.
Speaker 3: It is. It is mockable. It is extremely mockable. I
Speaker 3: had an idea this week. I was thinking about see
Speaker 3: what you guys think about I was thinking about writing
Speaker 3: a humor article about a transcript of a show on
Speaker 3: Vibe cooking.
Speaker 1: You know you should get you ot GPT to help
Speaker 1: you write that.
Speaker 2: I mean a every comedy thing you want, right, Billy,
Speaker 2: is something I want to read it. But no, I
Speaker 2: like your Vibe coking idea because I think it ends
Speaker 2: in a fireball, which I be awesome.
Speaker 3: Yeah, you could see that it's it's not going to
Speaker 3: go well and going wrong. And then and then I.
Speaker 1: Thought I would deep frying seems like when we had
Speaker 1: a little turmeric and see what happens.
Speaker 3: And then I thought, at the very end it would
Speaker 3: be stay tuned for the next. The next on this
Speaker 3: channel an episode of Vibe Child Rearing.
Speaker 1: Subscribe to my channel for more helpful hands. Oh, Billy,
Speaker 1: it's been an absolute delight having you on the show again.
Speaker 1: And do we know how many times you've been on Richard?
Speaker 1: Do you have account like.
Speaker 3: I said, it's in the mid twenties summer.
Speaker 2: I think somewhere in the twenties. He's, you know, at
Speaker 2: the near the top, if not the top. But I
Speaker 2: think the bigger one is a single digit show, a
Speaker 2: couple of visual digit shows, a whole bunch of three
Speaker 2: digit shows, and a ridiculous number of four digits.
Speaker 3: And I'm really proud Carl the fact that the inspiration
Speaker 3: to get started on this was you listening to me
Speaker 3: and Rocky and I talk about something and speakers and
Speaker 3: the speakers he thought, you know, these people have stuff
Speaker 3: to say that other people are to hear. And absolutely
Speaker 3: I really like having kind of so in that sense,
Speaker 3: I've been on dot net rocks since the inception of
Speaker 3: the idea you have.
Speaker 1: Indeed, yeah, you predate the inception certainly before the word podcast.
Speaker 2: Yeah, you know. I think the other one that I
Speaker 2: like about your story on dot net Rocks, Billy, is
Speaker 2: your transformations there too. Yeah I remember design taking you over.
Speaker 3: Yeah. Well, partially it is because I've always kind of
Speaker 3: had some affinity but nobody cared, and now they started
Speaker 3: to care and like the twenty ten times, and I
Speaker 3: do enjoy it. And also partially because in the Microsoft space.
Speaker 3: You go back to like twenty ten, there's nobody, nobody
Speaker 3: who's focusing on you.
Speaker 2: Actually, we said embrace of zam that I think sort
Speaker 2: of because nobody else was doing it. They're such a contrarian.
Speaker 3: Everybody that picked up Zamble was just like spoofing whatever
Speaker 3: they'd done.
Speaker 2: Before, and you know, whatever before.
Speaker 3: And I'm pretty proud of the fact that that that
Speaker 3: me and the team that we worked with on early
Speaker 3: Examal projects, we were determined we were going to make
Speaker 3: Examble do things that people had never seen before.
Speaker 2: I remember talking to one of the pms of Zamal
Speaker 2: talking about his problem with finding concrete examples, like do
Speaker 2: you not know who Billy Hollis is? Are you crazy? Like,
Speaker 2: let me connect you to It'll be a long conversation.
Speaker 2: I get clear your calendar.
Speaker 1: Yeah, well fantastic. I hope this is not the last
Speaker 1: we've heard of you, mister Hollis.
Speaker 3: Oh, I've still got I've still got some time. I
Speaker 3: just not as much of it. I think I'm mentioning
Speaker 3: this on the last show, so I will I will
Speaker 3: remind people are still listening. You know, the people on
Speaker 3: your show do stuff. I mean they can call us
Speaker 3: and get us to do Yeah, but your window of
Speaker 3: opportunity for me in particular is starting to close. So
Speaker 3: if you got something you want me to be involved
Speaker 3: in at your company, I'm happy to talk to you,
Speaker 3: but two years from now I might not be well.
Speaker 1: And likewise, if you've got a new rant, you call us.
Speaker 2: Okay, okay, So it's one single digit, two double digits
Speaker 2: including panels, ten triples and ten fours. Well now eleven, wow, yeah, wow, jeez, excellent.
Speaker 1: All right, sir, we'll see you, thanks again, Thank you, gentlemen.
Speaker 1: All right, and we'll talk to you next time on
Speaker 1: dot net rocks. Dot net Rocks is brought to you
Speaker 1: by Franklin's Net and produced by Pop Studios, a full
Speaker 1: service audio, video and post production facility located physically in
Speaker 1: New London, Connecticut, and of course in the cloud online
Speaker 1: at pwop dot com. Visit our website at d O
Speaker 1: T N E t R O c k S dot
Speaker 1: com for RSS feeds, downloads, mobile apps, comments, and access
Speaker 1: to the full archives going back to show number one,
Speaker 1: recorded in September two thousand and two. And make sure
Speaker 1: you check out our sponsors. They keep us in business
Speaker 1: now go write some code. See you next time you
Speaker 1: got Jack middle vans acc