How'd you like to listen to dot net rocks with no ads?
Easy?
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. 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.
Show number three. Yeah.
Three's kind of been around since the beginning of dot net.
Yeah, a one digit, two digit, three digit, four digit kind of guy.
Well, you know, just real quick, how's everything up in Canadia?
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.
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.
Yeah, but we release them. You know, there is a guy in Quebec called the beaver Whisperer.
I don't this completely fits yes in my mental model.
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. 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.
Yeah, that's a good feature. Okay, let's roll into better know a framework. So crazy music, queue it up, punch it.
What do you go now?
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.
Uh.
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 buttons with the X you know, with the tags, and then with the X next to them, so you can.
And what are the tag values for?
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.
Use this.
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.
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.
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.
I like that.
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.
But it's cool. I like it. Yeah, no, that spark, I like, yeah, good.
All right, So who's talking to us today, Richard?
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 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 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 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
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 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 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
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 because let's face it, we're getting too old for that stuff.
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.
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 we'll read it on the show, we'll send you a copy of music.
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 called the Cuban missile crisis.
Little thing, just a little thing closest I think we ever came to nuclear.
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 basically came face to face with their ships and you know, cooler heads.
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.
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.
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 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, 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.
Right, and after studying Venus, everybody said, ouch, I'm not going there.
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 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.
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.
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.
And then we discovered that it rains up instead of down, right right, So go ahead.
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 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 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, 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 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.
It was Doug Crockford's say at the end of his talks, don't write bugs.
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 also nineteen sixty two.
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
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 is when UI still a thing, there's that an old bio, it is still a thing. Well, welcome Billy, welcome back.
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.
But then I thought about it.
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.
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.
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 be interesting.
Yeah.
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.
And the legacy apps thing came about from a request actually from someone because I do these lunch and learn type things for companies.
Virtually.
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.
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 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.
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.
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.
And it's working, right, It's not like it's not a pejorative. This is making money for us, Yeah.
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 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.
Yes.
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.
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 might be impossible to patch because of its dependency tree.
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 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.
Because well they should. Yeah, high risks or reward.
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?
Sure?
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 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 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.
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 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 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 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, 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 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.
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 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, isn't it.
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 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 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.
That's not really agile, yeah right.
That, yeah, that's that's that is I think of that anyway as an example of the no true Scotsman logical fallacy.
You guys know that one.
It's like, you know, no true Scotts, no Scotsman puts sugar in his porridge.
Right, No true Scotsman dips his Scotch eggs and Marl.
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.
Maybe they're right.
I don't know, I'm not.
It's an excuse to ignore the facts in front of you.
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 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.
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 you know, really flows?
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.
Be, because it costs money, and.
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. Do you guys have words like proliferation is one of them? And another one for me is interoperability, I have to.
Correct. That's why we always say interopt.
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 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. 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.
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.
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
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 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 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, 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,
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 you can prevent errors by keeping people from doing things out of order and stuff like that.
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 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 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.
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
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.
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.
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 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 couple of tangible examples from real projects.
If that would help. Let's do the break.
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.
Do you have a.
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 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.
Well it's that Southern accent that I get a little bit excited talking about stuff.
No no, no, dough. It was put your hands on the screen and repeede after me. I am an addicted a code addict.
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.
All absolute, but I will clude it in the show notes. Okay, good, Yeah.
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, they should be able to just hit a couple of keys and go there. Anyway, So back to your uh.
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, 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.
Nothing wrong with that.
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 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 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 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 turns out to be really common lawyers call up the water billing to get final numbers for a property sale clothes.
So there's a lawyer's button. Yeah.
So there's basically a button just to go to go exactly to the place to get.
Use murder button at McDonald's, right.
Yeah.
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 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 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.
Now is it?
Is it obvious?
Why?
No, How long is a mobile device gonna last cattle feed like condition.
It's just it's been tried and it's there any bandwidth.
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 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
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.
So one of the ring events. Yeah, that's one of the.
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 could come in and take care of it.
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.
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 code addiction. If you're addicted to code, you don't want to take time off to go figure that business do.
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.
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 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. And you might even find out you like it well.
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.
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, 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 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. 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 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.
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, 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?
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.
Yeah.
Yeah, and the future proofing is kind of part of that whole.
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 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 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 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 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.
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.
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.
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 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 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 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.
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.
To take into account way is that the whole yagny line, like you're going to need.
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 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, because you can't do effective architecture without considerable abstraction exactly.
Yeah.
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.
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 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 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. 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.
Yeah.
Well, it takes judgment, and judgment comes with experience, and.
Experience comes from massive failures.
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.
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.
We have the source code, but it's written in whatever you know, visual Basic six.
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.
We don't have all the dependencies for whatever it is.
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.
What do you think about that?
I think it'd be great, but i'd have to see it work for I believe it could do that.
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. I just haven't found it yet. It doesn't mean it doesn't exist. I keep looking.
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
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 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.
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,
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.
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 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.
You.
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.
That's true in terms of certainly in terms of performance.
Well, and yeah, you just don't know.
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.
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 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 you've seen more, you've seen more examples, and you have a bigger pool of things drawn.
So I you saw the gorilla playing basketball, Yeah, so you know he's there.
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. 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.
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 still in early days. But these tools are interesting.
They are interesting. Yeah, just don't get so freaked out about it. Anything gonna happen.
And I'm not going to deny there's a hype cycle going on, because there is.
And because of that HiPE cycle I have made fun of, like Vibe coding, for example.
Well, it's infinitely funnable.
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.
You know you should get you ot GPT to help you write that.
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.
Yeah, you could see that it's it's not going to go well and going wrong. And then and then I.
Thought I would deep frying seems like when we had a little turmeric and see what happens.
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.
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.
I said, it's in the mid twenties summer.
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.
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 the idea you have.
Indeed, yeah, you predate the inception certainly before the word podcast.
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.
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.
Actually, we said embrace of zam that I think sort of because nobody else was doing it. They're such a contrarian.
Everybody that picked up Zamble was just like spoofing whatever they'd done.
Before, and you know, whatever before.
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.
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.
Yeah, well fantastic. I hope this is not the last we've heard of you, mister Hollis.
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 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.
And likewise, if you've got a new rant, you call us.
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.
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 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 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