Making Design Pay with Billy Hollis - podcast episode cover

Making Design Pay with Billy Hollis

Sep 12, 20241 hr 6 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

How does good design pay off in software? Carl and Richard talk to Billy Hollis about his work designing software, both from a user interaction perspective and application architecture. Billy talks about saving time and money by working hard on design to get a clearer picture of what stakeholders want—because code rework is always more expensive! The conversation also digs into the institutional knowledge walking out of many companies through employees retiring—and how much work that is going to generate over the next few years to modernize!

Transcript

Speaker 1

How'd you like to listen to dot NetRocks 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 will get you that and a special dot NetRocks patron mug. Sign up now at Patreon dot dot NetRocks dot com. Hey, Carl and Richard here with your twenty twenty four NDC schedule.

Speaker 2

Will be at as many NDC conferences as possible this year, and you should consider attending no matter what. The Copenhagen Developers Festival happens August twenty sixth through the thirtieth. Tickets at Cphdevfest dot com.

Speaker 1

NDC Porto is happening October fourteenth through the eighteenth. The early bird discount ends June fourteenth. Tickets at Ndcporto dot com.

Speaker 3

And we'll see you there, we hope.

Speaker 1

Hey, guess what it's dot net rox. I'm Carl Franklin, and I'm Richard Campbell, and Billy Hollis is here. Billy, you can chime in anytime, because I think you can.

Speaker 2

Pass the threshold.

Speaker 4

I appreciate that I do, and I might, but you know, I know you guys have early show things you need to do, so I'll want you to go ahead and do that.

Speaker 2

No your first rodeo.

Speaker 1

Yeah, well, Billy, I don't know. I kind of think you're really gonna love my better no framework. And there's two of them for today, so by all means, feel free to jump in. After we roll the crazy music, let's go.

Speaker 4

What do you got?

Speaker 1

All right? So I have a link to a Reddit rant and it's all about somebody who's ranting about zamal or WPF. Right, so here you go WPF zamal frustrations. Bill, You're gonna love this. I love that this is good and this is from three years ago. I am attempting to broaden my c sharpabilities by making different UI projects. I've had two experience with examal, once at making a simple phone app, another just now while trying to make

a personal project. Both have been incredibly infuriating. The first time I would just assume I was being dumb, but now I feel as though examal is just a steaming pile of dog shit nice. Anytime I edit a file, dot zamal er dot c S Visual Studio loses its fucking mind and throws the most ridiculous errors that I have nothing to do with the problem. And I think that's more about visual Studio and no about examble. But half the time some magicalxamal dot g dot cs file

breaks for no good reason in parentheses. No, it's not the common problem name spaces being wrong. Cleaning in or rebuilding the solution does not remove those errors. I have to let it happen, clear the file, and save it over again again. Nothing else in the change is just saving over these filed generated files fixes it. Then when I go to launch the project, it will not bring up the main view seventy five percent of the time without changing my code. Just some seemingly random combination of

cleaning and rebuilding allows it to start again. I'm way better with back end stuff, so maybe I'm doing something horribly wrong. I read the documentation, searched for solutions to my particular errors, and check every detail, but still feel like examble is an uphill battle. End of rant. And then he goes on and people try to talk him off the ledge. But Billy, I thought.

Speaker 4

You, well, Zambo is an uphill battle.

Speaker 1

I thought you'd get a kick out of that.

Speaker 4

Learning how to use it effectively is hard. It's the C plus plus of enterdetechn of versation.

Speaker 2

Just waiting with a zero pointer to move everything.

Speaker 4

But you can do things with it that are difficult, impractical, or in a few cases impossible to do with other common technologies. And once you do learn how to do it, and you learn to switch your mind and how to think about it, then you can create experiences for the users that have enormous value. It's worth it, but I'm not. I've never been one to say that you should just jump and dizamble and start using it. And no, it's

it's it's a real uphill struggle. I mean, look, I made a lot of money training people and examble for many years because I constructed an approach to help people switch from the way they think about programming in regular code see sharp or whatever, which is an imperative way of.

Speaker 1

And as I said, I think this guy's problem was clearly one hundred percent visual studio.

Speaker 2

It wasn't you know. I read a little further down the line there he was using MVVM cross, So I wonder if he wasn't using it well, because you know, you have to approach those libraries with their intent. So I suspect he may have been just fighting with MVVM. And let's face it, when you mess with something related to the library, it's gonna spew terrible messages like you were gonna have it.

Speaker 1

All right, So I have something else that I want to bring up in better no framework. I actually have two things. So Zamal for Blazer came out last year. Now, Zamal for Blazer is the brain child of Giovanni Albani, who's the guy behind open Silver, and it's also based on open Silver. So this is basically unleash the power example in your Blazer applications. Yeah, so it and open Silver was sort of an open source version of silver Light that Giovanni started. In fact, we interviewed him twice.

Speaker 2

Yep, yeah we he interviewed him twenty delivered.

Speaker 1

It exactly in twenty twenty and in twenty twenty one when he delivered it, and so so this is this is interesting stuff. So if you're you know, you want to get on the web and silver Light was the end, I'll be all for you. And you liked Xamal in the browser, uh, Zambal for Blazer, Zamal Dash four Dash Blazer dot com checking out.

Speaker 4

That's been on my list to check out for a while.

Speaker 2

Yeah, it sounds like a show in the making, isn't it.

Speaker 4

I've done most of my stuff in that space with the Uno platform, yeah, and that has worked out pretty well in general. They was a real road there over the last five or six years to get that complete and stable, especially for the web. Some of the early stuff they.

Speaker 2

Did, yeah, you know, did a lot of twist and turns. They came into the game as a UWP platform and realized they needed to transform and did yeah, like quite an accomplishment really.

Speaker 4

So they're an interesting alternative to Zammering now for multiplatform stuff, and so I've been spending time with that. But yes, I'd like to take a look at Zambal for Blazer because I really do hope that the responsiveness of the Blazer engine will be the way to get a lot of the experiences I want to see and just normal websites.

Speaker 1

And you know, I'm I'm not gonna stop on the whole visual studio challenge thing. I often had problems like that even with MAUI in visual studio, with xamble, you know, overriding and generating files and then being out of sync and stuff. It's better now. But one of the things that's cool about the web platform is the whole rendering process.

Speaker 3

Right.

Speaker 1

You don't typically have those problems because but the end product you're looking at is just pure markup right in code or whatever. So anyway, that's a that's my rant. Who's talking to us?

Speaker 2

Richard grabbed a calm on top of Billy's last show when we did back in December twenty two, episode eighteen twenty two. Coincidental numbers. By the way, I believe this is your twenty fourth episode, Billy, oh man, I wow, do believe we owe you like a sack of submarine though this point. You were a guest on episode three three, Yeah, you know, and here you are now on what is this episode nineteen fifteen?

Speaker 4

So I can't believe people aren't just tired to listen it to me.

Speaker 2

Well, I'm not, you know. I call you routinely because I see the work you're doing. I'm like, oh, dude, I want to talk about that, right, Like that's the reality.

Speaker 4

Always doing something new. I'm too easily bored to keep doing the same self.

Speaker 1

So exactly true.

Speaker 2

Still, so that last episode was Thinking High Level Design, which I thought was really enjoyable. We had a great conversation there, and the audience seemed to agree because lots of messages and this one's from Ismo who said this sounded like a fun episode of discourse with Billy, Carl and Richard. It really got some wheels turning into discussion.

One particular part of the episode that stood out for me is when Billy mentioned the idea that companies quote have designers, but they don't know how to implement design thinking and produce great high level design. Similarly, I find we could apply the same logic to most enterprise architects.

They know how to organize and dive deep into code and maybe how to output some pretty nice cloud diagrams, but we seem to fail spectacularly in putting all the pieces together to make a very well put together pieces of software. High level design thinking can fit this, if only we could get out of our own way.

Speaker 4

I can't argue with any of that.

Speaker 2

Well, my immediate thought is, you know where do most architects come from? This is my only promotion path as a developer, So you're sort of driven into the architectural role, whether it's a natural fit for you or not, and you rarely get additional training. And so this idea of being that architectural leadership, of really being you know, responsible for the shape of your project, I just don't know that anybody takes that on intentionally. You have to eventually

realize it needs to be done or you don't. And it's a weak spot in the whole thing.

Speaker 4

There isn't really an education path for it, right, Yeah, So somebody has kind of have some natural talent and try things out, maybe they have a mentor if they're lucky. But the supply of enterprise architects who are actually good at what they do is so limited that it's it's hard to find a mentor and do things. You have to solve real problems to do it, and we really don't have anything a lot. We have less than ten percent of the expertise in our product atensure that we need in this profession.

Speaker 1

Well, and going back to design aptitude, I have a story from my own family. My daughter Emmy in as a junior in high school. Turns out she had ridiculous artistic talent, right she was doing three D models, and she met with one of her mentors who said, you should go to in for industrial design. So she went to Rhode Island School Design, which is Risney's prestigious design school in these coasts, and Risney and got a degree

in industrial design. And I said to her, hey, you know, can you help me with like some some web stuff. She's like, I don't want to do web stuff. Hey can you help me with some graphics? And that I don't want to do graphics, you know, she's like, she was like, I want to do industrial design. Guess what she's doing.

Speaker 4

Now, what's that?

Speaker 1

Web design?

Speaker 4

Web design?

Speaker 1

Yeah? All right, well she's doing it on the side, but yeah, she.

Speaker 4

Has That's just that's the easy way to get into design. And it is a look. I go to a lot of meetings of meetups for designers, for visual designers, and I talked to a lot of people at conferences and things like that, and we've reached a point now where those people, for a lot of the decision makers in business, those web designers, that's what design is. Yeah, as far

as executives are concerned, that's not really healthy. Because that's why I started to talk more about design thinking instead of just design because the term design is so overloaded.

Speaker 2

Yeah, so sure so is well, thank you so much for your comment, and the copy music co Buy is on its way to you. And if you'd like a copy of music go buy right a comment on the website at dot at rocks dot com or on the facebooks. We publish every show there and if you comment there and to read on the show, we'll send you a copy of music go buy.

Speaker 1

And yeah, music to code buy is still going strong. Yeah, people are still loving it helps you stay and focus while you code or do anything deep work. It's the term I heard today. I like that talking about work. All right, So let me formally introduce Billy Hollis in case you've been sleeping under a rock for the last twenty years. Billy is a software designer and developer with a contrarian streak that often challenges conventional wisdom in the industry. Is that true, Richard.

Speaker 3

No mo.

Speaker 2

If you need to to testers for every developer, you must suck as.

Speaker 3

A developer.

Speaker 1

End quote. He has a consulting practice in Nashville, Tennessee, USA. He and his team focus on user experience design, which is ux advanced user interface development. Rules based architectures and healthcare systems. He teaches classes for design thinking and UX design and technical classes on zamal for win UI and Zamle for WPF. Okay, there you go, your official bio for today. Billy, you go.

Speaker 4

Yeah, And what the bio never says, because there's no good way to put it in there, is that what I really am is a generalist. And I decided that all the way back in high school that that's what I was going to be. In an economy where everybody tells you to specialize, I already decided I was going to be a generalist.

Speaker 2

When I first met you, and at least twenty years ago now you were much more an app architect personality. I watched you evolve into someone who cared deeply about design.

Speaker 4

Well, you watched me expose it. Yeah, perhaps, says but I cared about it before that. It's just that nobody else in the industry did, so I didn't talk about it then.

Speaker 2

Well, and the tech also changed, Like you were there first when zamble emerged, and you were long before Microsoft knew what the heck to do with that, you were already gone in a way.

Speaker 4

Well, that was the reason I embraced it so much. Is that sensibility about doing design? Remember my first book in nineteen ninety nine has the title Design, Specification and Objects, which kind of helps you understand that I was moving in that direction even earlier. But yeah, nobody cared about it until some of the technologies came out to be able to do some of these interesting things.

Speaker 1

Nineteen ninety nine when the word objects was novel was novel.

Speaker 4

Yeah, and the iPhone was one of the break points to put people into a new way of thinking to.

Speaker 2

Learn the words.

Speaker 4

So that's why I began talking about it more. I cared about it before that, and I've certainly learned a huge amount of the last fifteen years. But yeah, I always cared more about it that I think than most people in the industry.

Speaker 1

So you're thinking these days about how to make design pay? What do you mean by that?

Speaker 4

Yeah, well, see, that's that's because the entire area is confused. I talked about this. You go to a typical person running a software development team and he somebody tells him, man, you need a designer, and he goes to HR what's what's what are they going to get? They're probably going to get a web designer, because that's just what the

industry kind of thinks. Well, the term design thinking is to help break loose from that, because from my perspective, that kind of visual oriented design is the lowest step above not doing design at all.

Speaker 1

Hamburger menu or no Hamburger menu.

Speaker 4

Yeah, I don't mean to say it doesn't any value, because it does. Nobody wants an ugly application or website, and proper layout and good cosmetics do in fact increase the quality and value of websites and of apps. But when you start getting into interaction now, the potential for design to do things goes up. And there's a spectrum that goes all the way up to business process re engineering, designing entirely new ways for a business to operate. Design

thinking embraces that entire spectrum. And I want people in the industry to kind of understand what level are you at, because what level you're at now determines what kind of people do you need to get to help you Billy.

Speaker 1

Sometimes you know this the simplest decision, the simplest decision should it go here or here, can make the difference between some process that takes an hour and a process that takes ten to fifteen minutes, the simplest decision.

Speaker 4

There's a famous article that's that's still relevant called the six million dollar Button. Yeah, you've probably seen that article one time or another. Thad if you google that, anybody who's listening can google that and get the article on how moving a button save six million dollars?

Speaker 1

Are banks the worst? Bank websites the worst? In your opinion? I mean in my opinion. Richard's nodding in, So I have a local bank, and I wouldn't trade them for the world. They're the best because they're local. Even when I go to like the virtual ATM, like the people that come on screen, Oh hey, Carl, how's it going. How's the band right? Like? I feel connected to this bank.

And yet the process for doing ach payments, which is, you know, direct deposit payments, requires you to go to a screen see a list of the last payments that you did, that all the way down to Texas, you know, And to start a new one you have to scroll all the way to the bottom and hit new nice. And then after you do a new one, it goes to the bottom again, and so you have to sort by date and then sort by date again to get to what you just put in so you can edit it.

And this is the dumbest fucking thing I've ever seen. And it's a bank.

Speaker 4

Well, yeah, banks are some of the worst offenders, and there really isn't much excuse for that. My eighty eight year old mom does online banking and they keep changing the site. Now. Look, she's smart and she did eventually learn to do her online banking. In fact, she prefers it now. Her mobility is more limited than it used to be, so not having to trot down the bank is a big help for her. But I mean when she calls me once every year or two, they've changed the page and I don't understand what.

Speaker 1

Yeah, oh, they made it easier, mom, They and they didn't.

Speaker 4

Make it easier, that's the problem. In many cases, they just changed it for the sake of change. Now the banks are learning and they are getting better. My bank US Bank actually does a pretty good job with their website and just an excellent job with the app that they put on the phone, So they're kind of learning this. But yeah, I hear complaints about banking sites and apps all the time.

Speaker 1

I guess if it works, that's enough for them. Right, because people are going to be able to do and it doesn't matter how frustrating it is for them, they'll do it.

Speaker 4

That was a quote that I coined way back in probably twenty eleven, was that for most of the time in this industry, just making something possible was enough that people consider themselves successful. But it really shouldn't be it. Also, you also should consider making it easy as part of their success.

Speaker 1

And enjoyable even shall we even go that far?

Speaker 2

Yeah, delightful, but yeah, okay, we talked about the six million dollar button. The real question always is you're delaying writing code, messing around with the design stuff. Let's just get to work.

Speaker 4

Yeah, And my perspective on that is, and having been involved in a ton of projects both with and without design up front, all the way back to see stuff in the eighties and the late seventies, I have never seen a project where designed doing design up front wasted time or took more time until you finally got delivery. And the reason is it eliminates a lot of blond alleys, right.

I mean, if you don't do design, you're going to end up doing things that you take to people and they go, now, this isn't what I needed, or this isn't good now, or I hate this and then have to do rework on it. So the idea that you need to start coding first, I mean back end stuff. I guess maybe even there though, I think the back end is sometimes more affected by what goes on with the user than a lot of developers tend to think.

Speaker 1

But developers, and they do, dare I say, test their apps in you know, in development, they have to test them. So the idiot that designed that page had to fill the screen with dummy data and scroll all the way to the bottom. You would think he said, hey, I got an idea, let's put these buttons at the top of the page. He would probably.

Speaker 2

Had three records, like he never considered that somebody would have more.

Speaker 1

Probably right.

Speaker 4

Yeah, but you've got that psychology, Carl, And I've got it too that I see these flaws and that irritate me. I have an emotional response to these flaws. But I can tell you that a lot of developers don't.

Speaker 1

My wife that my wife uses an app and she can't figure out She's like, some damn programmers screw this up.

Speaker 4

And I think that's that's good. Yeah, especially for developers they ought to be offended by poor design on behalf of the users. But the fact of the matter is, I'll run into a lot of developers that just oh, scroll, okay, fine, I mean, they're paying me by the hour, does it matter to me how much I scroll.

Speaker 1

Kelly's mother is a Southern bell from Lake, Missouri, right, so anytime anything screws up, she will always say, some man probably designed this.

Speaker 4

I will say that in general, while the difference isn't great, the women in this industry do pretty well at design, and maybe somewhat better than the men. Now, there are men who do a great job, but there are more men who just aren't any good at it at all. So the women win on average.

Speaker 2

I think, And I wonder if it's just a lack of awareness, like you're not noticing that this UX could be better well.

Speaker 4

And that's why some of the very first stuff I ever started talking about in seminars and such for UX was about the principles of how the brain works now the visual system works, because that sensitizes you to things that if you know why something doesn't work, well, why don't people like to scroll? Well? That does not work in concert with the visual and cognitive systems. You're constantly having to refresh and absorb new material, which which causes

cognitive effort as well as wasted time. So when you start to learn some of these principles about how the brain and the eyes work, now you tend to notice things more that don't work in concert with them, and thereby slow people down and frustrate them.

Speaker 1

Do you do a lot of reworking of legacy apps?

Speaker 4

Billy Well, I personally don't do a lot. I do some, and that's probably fifteen to twenty percent of my work. But in terms of people want being interested in it, that's a very high, highly ranked topic because, let's face it, lots of teams have these legacy apps that are there are many millions of dollars invested in and they have yet to experience the pressure to replace that moved new technologies.

Typically a platform change, a dramatic business change causes new people to move to new platforms, and that's when they typically involved me. But most people aren't in that situation. So I've been doing a session lately on ux designed for legacy apps. That's been pretty popular. I've done it at several conferences.

Speaker 1

That's good. I have a customer and I looked at this legacy app that I was upgrading. I said, how old is this? And they said, oh, since about episode eight hundred.

Speaker 2

Twenty thirteen is something like that stuff like that. So I've still got your list of shows up there. So yeah, yeah, it would have been about twenty thirteen, twenty twelve.

Speaker 4

I basically remember that because episode six hundred was the one that introduced using the joke you talked about their Richard where I was going on about some of the people whose heads in the cloud, about how you do development and all the extra testing and all the stuff that goes with it, and we did that on stage in San Diego, yep and twenty ten, I think, and I remember Richard falling off the chair when I too punched the line of that jair.

Speaker 1

You couldn't revive me. So tell us about so tell us about this talk on legacy apps designed for legacy apps.

Speaker 4

On legacy apps. Yeah, it came about because of something interesting that I hadn't planned it because since I don't normally do that work, a lot of my talks are based on the work that I've actually done. In this case, though I do sessions for people for free to sort of introduce them to the whole idea of design. And that's partially because we don't have sales when we don't

do traditional marketing, so that introduces me to people. I mean, the primary way that I find new people to work with is the conferences and going to and doing sessions and talking to people in depth there. But I hit upon another way a few years back, when the virtual stuff became very easy to do, is well, if people want to lunch and learn, well, let's put me on the screen man, I'll I'll talk for forty five minutes

about some topic. And I had a list of them, and I had somebody that asked me to do it looked at my list and nothing really lit them up, and they said, well, we're stuck with this legacy app. What advice would you give us about applying design? So I wrote a whole new session on that and it was it was very successful, and I started doing it at conferences too, and it gets it gets bigger audiences typically than my sessions on how you redesign an app from.

Speaker 1

Scratch step one, burn it down.

Speaker 4

That's a problem inte. And so I started thinking about it and thinking well, what if you are stuck in kind of a legacy world. First of all, I understand why, because trying to change out an entire application that runs a business is an enormously risky proposition. Yeah, and its expensive too, But I think, honestly, I don't think it's the expense that drives people away from it. Mostly I think it's the risk, because it's an existential threat if

you get it wrong. So improving the legacy app, well, okay, would you want to improve legacy apps? So I made a list of the areas that I had seen that I thought worked well. Search was very high on the list. A lot of legacy apps have very poorly designed search because it was designed twenty years ago or whatever. And our database technologies are better now we could do full text indexing and all that kind of stuff, where twenty

years ago we couldn't. And it surprises me how many corporate apps still require you to search by entering information in different fields. If I want to search for address, I have to enter something in a field for address, Whereas the world has gone beyond that, haven't, I mean, everybody.

Speaker 1

Just time and have these programmers ever heard of link?

Speaker 4

Yeah? So or re search is an obvious candidate, and it's not so much just that you change so that you enter into a Google sell bar. It's more about how you expose the results. Because right now developers just dumping in a data grid and that's okay actually for so for some interaction cases, especially if people are going to kind of sort and massage the data a lot, then data grid's okay to do that. But we've got card views and all the stuff and graphics that we can put in there.

Speaker 1

I'm working on an app right now, Billy, where we leave it up to the user to decide whether they want to see stuff in the grid or in cards.

Speaker 4

Oh, that's I'll be interested in the results of that simple And part of it is how well designed are the cards, of course, But in general, if the cards are well designed, I find that people tend to prefer that. Because this gets back to some of the neurological things. The part of our brains that works with graphics and shapes and color is much older in evolutionary terms than the part that reads and it interprets numbers, and.

Speaker 1

Certainly that reads spreadsheets. Yeah, that's kind of new.

Speaker 4

So in essence, there's an ease of absorbing the material when you're leaning on graphics and such. For example, if you've got, oh, you've got five categories of returned results, and you've got a graphic for each one, the eyes will be able to use that graphic to zero in on the one they want very quickly. And it actually feels good because anything that helps your brain offload cognitive

effort feels good. It's at a subconscious level, but people tend to be attracted to and become attached to those kind of views if they leverage graphics, well, now, if they do allows e job and the graphics are just as hard to figure out as the text, then you don't get any benefits.

Speaker 1

I like the card idea because you know, when you put a border around something, it's a thing. You know, it has a boundary, it's a thing. Whereas it can just be some space around it and it's still a group, it's still a thing. The line in a grid is much more difficult for the brain to understand, much more, much more.

Speaker 2

But aren't you getting to a point here where you're trying to punt on the design and saying let the user define how they want to see things.

Speaker 1

Well, that's yeah, well in this case. In this case, there were users that wanted a table and there were users that wanted cards. So we were we had this you know, design meeting. They were yelling back and forth and stuff, and I'm like, hey, we can do it. We just do in a JSON file.

Speaker 2

Yeah, it'll be okay.

Speaker 4

Say, I use that approach quite a lot because you do get into confrontations typically because the range of users is such that they are advanced users and there are simpler users. And I really don't like the idea of hamstringing everybody because some power users need some things.

Speaker 2

Yeah, and definitely you get that split between the novice users that are going to use that out once a week and the person that's in there four out of eight hours of even working day, and they just they want all the shortcuts. They want to be as efficient as possible because they're in an out of there so often.

Speaker 4

So that's real. That's very smart to do that, Carl. And because it does short circuit a lot of the resistance, you get to change because there is there is status quo bias among people that people tend to like what they're comfortable with, what they're used to, and overcoming that well, first of all, you have to do some good work and come up with a good design. Just trying to make minor changes typically doesn't really work very well to get those people off the button for the old stuff.

But if you come for something really new, then they're more likely to see that and realize that that's better. But yeah, in general, you are going to have in many cases two groups and you just can't reconcile between the two.

Speaker 2

And they're both valuable and important, you know, I would say occasionally, I've certainly seen apps where nobody spends enough time in it to be good at it, right, where the leadership leading you all the time models what everybody ends up using. Because it's like I go to this thing once a week, I go into this thing, you know once a month. Nobody's ever going to be.

Speaker 3

Good at it.

Speaker 4

Yeah, And unfortunately, because there are parts of the app that are used quite a lot, that's where you tend to put your investment because that's where your payback is. So those parts of the app very often or not as well designed because you just don't have time to do it.

Speaker 2

You can't tune everything up, tune up the thing's going to give you the biggest return.

Speaker 1

Do you remember, Billy, And we got to take a break, so I'll make this quick, but do you remember I wrote this tool for Windows Forms that was sort of like UI Beginner, Intermediate, and Expert mode levels and you could tie those to the different you know, visible properties of controls, and so the user could say, I want to be in beginner mode because they're just learning the app, and so it kind of guides them through the easy stuff,

going to intermediate shows, a few more features, expert shows, humor reaches. I really like that, and I've used that metaphor ever since for.

Speaker 4

It's a It's a great metaphor, and it works even better with modern technologies where you've got dynamic layout. Yeah, that responsive layout. The problem in more static environment slighted Windowsforms was okay, now I'm leaving holes in the screen, and some don't like that, but yeah, I think that's

an excellent approach. You just don't want to clutter a screen with stuff that somebody is not going to use, and so that's one really good architectural way to sort of give it enough flexibility that you're accommodating a wider range.

Speaker 1

And the one thing that you have to be careful with with that kids, is that you have to make the option to go to the next level discoverable enough so that people don't get stuck inside where is all this stuff?

Speaker 4

Yeah? In general, I mean that's that's a great example of configuration. We put a lot of configurability in our apps, and configurability is one of the ways that you do try to bypass a lot of these blockages, these these where people are button heads about the way. In fact, I've seen cases where people where a team would thrash for six months over something fundamentally fairly simple y to them both likely, Yeah, stop stop arguing about it.

Speaker 1

Yeah, just Raightbode, it's a radio button.

Speaker 4

So we do a lot of configurability. In fact, I think a good architecture for applications ought to have some poplines for configurability built into it. That it ought to be really easy to implement configurability in the UI instead of having to close up some code to do it. I mean, you're in your your little your thing to sort of tag the stuff at what level is an example of that kind of configurability.

Speaker 1

All right, And with that, we're going to take this very brief pause for these very important messages. And I'd like to remind you that if you don't want to hear these messages, you can become a five dollars a month patron at Patreon dot dot netroocks dot com and you can get a feed that is ad free. All right, now here comes the annoying part. We'll be right back. Did you know you can lift and shift your dot

net framework apps to virtual machines in the cloud. Use the elastic beanstalk service to easily migrate to Amazon e C two with little or no changes. Find out more at aws dot Amazon dot com, slash elastic beanstock. And we're back. It's dot net rock some Carl Franklin's my

friend Richard Campbell. Hey, and we're talking about our friend Billy Hollis, the right Reverend Billy Hollis, And uh he's got some good ideas about design, about the designed for legacy systems, and uh yeah, and and all those little things.

Speaker 4

Some of the some of the other areas besides search, data visualization. I mean, we got all this wonderful ability to do data visualization with our modern UI technologies, but how much data visualization do you see in the typical corporate app. I mean they might they might get a charting package and do a few pot charts in bar

charts and that's about it. Whereas a custom designed data visualization can sometimes not only speed people up and keep them from making mistakes, but it can also communicate to the user, Hey, I understand where you live and work, and I've developed this software for you. They tend to have an unconscious favorable understanding of what you do if you accommodate them in those kinds of boys. So data visualization is very underused. I mean I see dashboards and

they've just got the most common looking stuff. It's just a whole bunch of line charts.

Speaker 1

From the fact we were done with pie charts. Apparently pie charts haven't died yet.

Speaker 2

Yeah, well pi charts were always bad.

Speaker 4

Yeah, but somebody wants a dashboard. Somebody, some decision maker wants more. Okay, we do a dashboard. Now what do we put on it? Well, they don't think about that, and that's really too bad because dashboards, by their nature, ought to be very dynamic. You ought to be able to do new wiges for a dashboarding time you want. And and when I've seen that when companies adopted that

at acute. Now you get some really really useful dashboards, things that contain Oh okay, here's the top five things that you need to worry about right now, you know.

Speaker 2

Hell, And that's where visualization is like the sort of up into the right graph because okay, if but it's going up to right, good things around them, it's going down to the right, it's bad thing happening.

Speaker 4

But certainly data visualization is one of those design things that you have to take into account. Sort of a typical you have to do some sketching. Really, if you're going to do a good data visualization, you start with pencil and paper.

Speaker 2

Do you like tools like Pigma? Like where do you sketch up your your app?

Speaker 4

I'm fine with almost any wireframing tool, and Figma is very popular right now. My partner Gary Bailey, who's does quite a lot of that work. In our case, locks of Balthsenic and I think they're like that just for Balsenic over Pigma. Psychologically, Balthsenic looks like a sketch and Figma does not. And when I takes people, I want them to critique them. What if they look like a sketch? Psychologically they go, oh, yeah, I guess it's just an idea. Figma looks more like a finishing.

Speaker 1

For pollsamic with a queue.

Speaker 4

So I'm not as fond of Pigma as a lot of people are. But what Pigma does do, and I think the reason why a lot of web designed kind of people take to it is you do get something that's very representative of what's actually going to be put on the page, whereas balsamic does not do that. And since those people are more concerned with the esthetics and the visual stuff, Figma tends to be the tool that they go to. But the basic idea for all of these is don't start with them. Don't walk up to

an electronic tool to design your screens. Get a pencil on paper, man. Go out there and think about how that thing's going to be laid out, and try two or three or four different ideas for how you do it so you can compare them.

Speaker 2

Sorry, pencil, paper, pencil.

Speaker 4

Yeah, that technology has been around for two thousand years now.

Speaker 1

Random access. I like the resolution, great battery life ever run, and the storage capacity that's always believer in the whiteboard too.

Speaker 4

That yeah. Basically, when when I teach classes on how to do design for to mostly to developer teams. I emphasize use any media you want as long as it's blank. Don't do lined paper that flips and switches in your head.

Speaker 1

And when you're done with your design on the whiteboard, take a picture.

Speaker 4

Take a picture.

Speaker 1

Just guess what the cleaning crew is coming in and it's going to be tomorrow.

Speaker 4

Yeah. So, especially collaborative de nown with two or three people, whiteboards work work really well. But you know, one of the options that that has been particularly popular among the people that that I've worked with in recent years is butcher paper. Butcher paper amount, I think, well, it comes in rolls. So you think about the tables that are in the typical conference room, unroll about six or eight feet a butcher paper.

Speaker 2

Everybody got a corner.

Speaker 4

Everybody's got a piece of it, and and everybody kind of so that that gets past the thing of see, some people are like to kind of sit back and let other people do all work, all the sketching. So now, okay, you got your piece, don't tell me what you want me to sketch. Go ahead and sketch it yourself. And then when you when you want to store the finished drawings, you roll them up, put a rubber band around.

Speaker 1

Now, are you talking about the light green butcher paper or the barbecue but wrapping stuff? Because I figured that's what you would pick, is the pink paper.

Speaker 4

It's the pink pat No, no, no, you want white paper. Yeah, you don't want any psychological whatever predisposing people in any direction. Why is the best color that we can We can put a link for the show in the product I use on Amazon if you like an Amazon link that reclinds to the roll of butcher paper. It's about one hundred and fifty feet and I think about fourteen inches wide. That's great, And so yeah, that that's a really good,

really good option and for teams. But yeah, I like a lot of whiteboards, especially in the early stages where you're trying to figure out a little bit more about the flow. But yeah, there are lots of ways to do it as long as you use blank media and pencils. Colored pencils are nice, yeah, and colored markers are nice. They you emphasize some things.

Speaker 2

But blank paper very good.

Speaker 1

And again take pictures of it and end up in the garbage someday.

Speaker 2

Well, like I said, it rolls back up again so you can you can keep it compact.

Speaker 4

Yeah, that's the not that's one of the reasons I love butchet paper easy to pack up and take home and and unroll when I need it. So yeah, that has worked really well, and I I don't think I've ever had a team that used it before I came in, but they all like it after it.

Speaker 1

I tried pizza boxes once but the pencils didn't work in the three spots and.

Speaker 4

They so, yeah, you have to do a lot of sketching for data visualization. And then the other area that that for legacy apps. I tend to suggest to people is to do some work on workflow because you think about these apps that have been developed twenty fifteen, twenty years ago, they tended to have that model of basically, the app replicates what's in the database, the menu replicates what's in the database. There's a lot of crud screens. Getting data in and out is the primary thing that

the app is doing. So you think about workflow with an app like that, you've got five steps in a workflow, you probably have to go to five different places in the app to do it. And understand that that we're talking about those principles, those cognitive etc. Principles. One of the basic standard principles is that short term memory is limited and cognitive effort is limited. You stress people out if you make them think too much. So think about

now workflow and a legacy app. If you've got to bounce around to five different places to do steps, you're having to store in your short term memory where you are and what you have to do next, and expend the cognitive effort to kind of remember where all these things are. Well, leave that in place, don't take away any of those things, but you can develop an ad on that steps people through the steps and link straight to the thing that they need to do and tracks where they are.

Speaker 1

You do stand up comedy too right? I do because I feel a routine coming on. You know, you could mimic Jeff Foxworthy. You might have bad design if if if you find yourself pulling up notepad between screen A and screen B, you might have bad design.

Speaker 4

And I actually did say I was doing user observation and saw a woman she would work with a record and write down the non digit ID on her pad so that she could come back to it later what she was doing on the fly. Was constructing a recently U used list on paper, right, and what man, let's let the computer keep up with that. Why are we making her do it?

Speaker 1

At least let them use the clipboard for crying out.

Speaker 4

So, yeah, workflow is a great way to add a lot of value. Think about this. If you help people with workflow, not only do you reduce training for people coming in because they can walk through all the steps, but you also prevent errors because most old applications don't have guardrails to keep you from doing things.

Speaker 3

Out of order.

Speaker 2

Yeah, and you could they just fail, Yeah.

Speaker 4

They just mess up. And so if you build a separate thing for workflow, you can build those guardrails in so that don't do step three before you've done step two.

Speaker 2

I've been a big there's been a few piece of software now I've found that as they build a breadcrumb trail at the top of the screen below the menu of you went here, and then you went here, and you went here, and you here, And I found myself occasionally seeing that bricko trails jump back four steps. Yeah, yeah, make a change, yeah, you know, be able to get back down again.

Speaker 4

And then what does that what kind of ripple effect does that have so you can design extra pieces to take that into account, and people love that stuff.

Speaker 1

Yeah. Yeah.

Speaker 2

The other one that I've always delighted is don't lose my work. Like I typed a bunch of stuff in, then something failed and so forth, and then you get back there. It's like after this over and you get back there and so oh it's still there.

Speaker 4

I am going to give the Windows team a thumbs up on something in that area, because number one, I don't lock the idea that they update and reboot so much. Yep, Okay, they promised us a long time ago they wouldn't do that, can't do it, and now they can't figure it out. But what they did figure out is that pretty much any app that they controlled, they've got ways to save the state. Even notepad no nopad used to just man, if you reboot it after an update, whatever was in that notepad was gone.

Speaker 2

Well lock the update, block the reboot, right, So yeah, so so.

Speaker 1

They when there's eleven they added the memory tabs.

Speaker 4

But yeah, well then it works on THEE when just ten updates as well. That if it now nowadays, I guess they backport it or something. But now if they if they update, do a forced update because of a force reboot because of an update, then when I come back, all my notepads are back, they're fine, And thank you Microsoft.

Speaker 2

A good feature, and it's a great thing to think about in your software too. Like you talk about, yeah, design that pays, it's like how much work saved that way? How much frustration saved that way? They're not that much code.

Speaker 1

Yeah, And if if you're doing let's say a Blazer server application, you can use protected browser storage anytimes somebody mutates the state, just save that to protect your browser storage and bring it back when you load up if it's there. That's one of the or give the give them the hey, last time you were working on this, do you want to resume where you left off. You can even bring them to the page they were on and the data that was on that page.

Speaker 4

Like yeah, well, Carl, I think you and I tend to be tuned into that because we started out in desktop native, where having a lot of state is pretty easy, and so you get accustomed to leverage again. Whereas people that begin doing stateless web applications, which kind of the browser requires a certain amount of state listness, they don't tend to leaver reage state as much. They just don't tend to think that way, and so yeah, they should.

We've got ways of doing the state now, and they need to kind of twist their mentality because that is such a useful thing for the user.

Speaker 1

Sure is. Yeah, And the application state talks that I do and Blazer are still the most popular ones because you know, people coming from different web technologies, that's a thing that they're not used to. Yeah, in memory state.

Speaker 4

And another thing about all sort of connected to all the stuff we're doing. We're talking about with legacy apps and getting a workflow right and such is something that I noticed a couple of years ago, and now that I'm attuned to it, You know how it is, You notice something once and then you start seeing it in other places. And I've seen, oh at least six or eight examples now of this. I struggled to explain it

really concisely, but I'll try. I call it generational turnover because you think about and it's unique to this point in time because we've all been in the industry long enough that we know we went through that period when a lot of businesses were automating. They were switching from basically paper into computers for the first time, typically very

data related apps. I did my first one in probably nineteen seventy nine, and of course it really picked up steam in the mid eighties, and by the mid nineties you pretty much had to be automated or you weren't competitive as a business anymore. But you think about how those apps were done. I mean, we didn't have the computing power, or the expertise or the money to build what we would now call it an enterprise app. And

most of these companies are pretty small anyway. So what got built, well, a piece of the app that you built a piece of the business, an app for that, and then maybe another piece for another app for another piece of the business. And so the systems that came out of that in the nineties and early two thousands tended to be pretty granular, data oriented pieces. Everything was

done kind of piecemeal. How did the business function? Somebody in that business, typically a small number of people, knew how to take all of those things and implement the real workflow in the businesses. And we talked about four They were holding the workflow in their head. They knew when to move from app to app, and they knew all the domain knowledge to know when to bypass the app or get around limitations in the app. They knew all of that stuff. Most small to medium businesses had

that cadre of people. If they were successful, that probably meant that they treated those people pretty well and they hung around for a long long time. Let's do some math. If a business automated in nineteen ninety that way, and they've got people that know how to make all this current stuff work, but that means that there's a whole lot of information in their head that's required to make it work. If they were thirty, let's say thirty years

old in nineteen ninety, how old are they today? There are sixty four I've seen in half a dozen plus businesses a small group of people who are key to the operation of the business that are all approaching retirement at the same time.

Speaker 1

Wow.

Speaker 2

Yeah, there's a lot of skill about to walk out there.

Speaker 4

There's a lot of people walk yeah. I mean these people are going to go to a retirement party one day and then that expertise walks out the door that night and doesn't come back.

Speaker 1

And this the millennials will take over and write it on the lampstade.

Speaker 4

Yeah, well manh sorry, it's good. Even the best motivated millennial is going to come in. It would take them years to build up all that domain knowledge to do this, and the business is going to take some pretty serious hits if you don't prepare for this. So a couple of our clients, that's actually the project we were doing was taking this string of things that were all built separately in that the people helped knew how to how to put together, and replacing that with what you would

call an enterprise system. Even though I mean, I mean the people at SAP truck tell you that they can do this, and for some businesses, I think they probably can if the business is data and accounting driven enough. But if you've got proprietary business processes, then now you've got a whole lot of work to do it. You can either hammer SAP into doing it, which is very expensive, or you can go get somebody to write the replacement system, which is is better if you do it right, but

carries a lot of risk. But businesses need to be sens does this. I was doing that session on design for legacy apps at a conference and talk a little bit about that because see The idea is you stretch the legacy app too far. There's a whole lot of risk involved there with them, and there are various risks with the legacy apps being stretched too far, but one of them is generational turnover. And I kind of went through with him about the same thing I just with

it with you. I had a guy come up to me after the session and he said, the insights you just gave me is worth more than I paid to come to this conference. He's going to go back and start doing checking things out. Who are these people that the business depends on that maybe the top executives don't even know who they are, and how close are they getting to retirement? And what's our plan for dealing with it?

Are we going to create a new app? Are we going to try to transplant that expertise into other heads? It's it's solved in a lot of different ways, but a lot of small even up to pretty large businesses. Because one of the businesses we did this for there is a multi billion dollar business with five factories. So people ought to just do a checklist thing in your business? Are you in that boat? Because a lot of businesses are I talk to an executive for a large bank.

That is, they've got all these technologies and all the people who know how to make them work. They've got to either change out the technologies or get somebody new to keep them running, right, because those people are just about to retire.

Speaker 1

I mean, we're all older people here, so and I'm not there's no secret, right, we've been around a while. Have you ever encountered somebody who says, you know, we're going to abandon the whole application idea in favor of a series of TikTok videos.

Speaker 4

I don't think I've ever heard anything.

Speaker 1

That ridiculous it's coming.

Speaker 4

But way it probably is.

Speaker 2

I mean there's another aspect of this, which is that the folks that have been doing this, operating that software for a while are used to the foibles, used to the problems, yeah, the bad ux of it. Yeah, and that new folks coming in are going to have a demand to This doesn't have to suck right like that, This could be better.

Speaker 4

Yeah. You think about, say, a twenty four year old coming in for their first job looking at one of these twenty five year old corporate apps, and they sit down the first day in front of that thing. What does that do to their connection to the company they just started working for. I mean they don't even they don't even own a laptop or a desktop. All they know is tablets or whatever. Yeah, the emotional impact of that is not to be discounted.

Speaker 1

Nope, sure thing.

Speaker 2

Yeah, that's an interesting point in evolution, and it's the demand is going to get huge as we lose this knowledge base walking to the door.

Speaker 4

Yeah, and there is the problem is there's just no clean way to do it. To solve this problem. I mean, we went into a multi billion dollar company and architected everything in their production process, from forecasting they needed through the entire supply chain to scheduling workers in the factories. And I don't want to sound arrogant and entitle here, but the number of teams that can go in and do that there just aren't that many. They're just are not.

So the risk is very, very high when you pick a team to do that. And so I don't like being in these decision makers shoes because it's very career affecting if they get it wrong. And both in I mean, we've talked various times on donet Rocks about the limitation of design talent. We don't have enough. We have that visual design talent, but the interaction design talent and the

other types of design talent are pretty short. But as I mentioned and earlier, the limitation on enterprise architecture is really high to if you're going to do enterprise level workflow the architecture for that. I've done it, and I know what the architecture involves, and I'm going to be honest. The average person, even a large company with architect in their title, even enterprise architect in their title, are not up to doing it. I don't mean to sound arrogant

about it, but they're just not. I've talked to these people.

Speaker 1

So basically what you're saying is most architects are full of.

Speaker 4

One of the large banks, a different I've talked about before has over two thousand people in their technical area with the word architect in their top on their business card. How many of those people are actually architects?

Speaker 1

You suppose? Well, how many can actually do the work?

Speaker 4

How many can actually do the work.

Speaker 2

Yeah, it's a different thing, but you know, again, the titles are one thing, works another.

Speaker 1

Yeah, so yeah, sure, I would like to apologize to all the architects that listen to dot net rocks. That wasn't talking about you. We're all cool here, right, yeah.

Speaker 4

Well, of course the best architects, of course they listen.

Speaker 1

To do well, you're absolutely right self selection, right.

Speaker 4

Yeah, so there, you know, we've got a filter there, but the number who are really good at it, it's I'll see this, for example, in the proliferation of micro services. Our services are a good solution for some places, but in a lot of cases they're using this excuse for not doing architecture. It's just oh, we won't do we won't do achitecture, We'll just do you the little things all over the place.

Speaker 1

Billy, you just blew my mind. I mean, we've been struggling with this whole micro services versus the you know, the monolith, the modular monolith thing for what a couple of years now, because people who went down the micro services road got disillusioned with it. And you just nailed it on the head people that some people that do microservice is an excuse to not do proper architecture up front.

Speaker 4

Yeah. Well, it's one of my one of my most popular slides these days is uh, you know the distracted boyfriend me.

Speaker 1

Oh yeah, yeah, yeah, okay, right, So boyd.

Speaker 4

He's got his girlfriend there, but he's looking over his shoulder up and he's walking with But I did one of those, and the girl walking away is labeled with writing code and his girlfriend is labeled with architecture ux design talking to users because developers blow that stuff off.

Speaker 1

And she's looking at him like, I'm going to give you such a smack.

Speaker 4

I'm gonna So that kind of captures the psychology. We should probably put a link up for that.

Speaker 1

That's really good, yes, and that to.

Speaker 4

Us that slide too, it's popular, very good.

Speaker 1

So what's next for you, Billy? What do you want to.

Speaker 4

Well, I have a project that I'm starting on to do kind of a big chunk of an application, but it isn't replacing an entire one entire one in some in the engineering space, and I'm looking forward to that. That's that's some interesting new stuff. I really like the people that I'm that I'm starting to work with too, and and so that is kind of a modest sized project. It isn't as big as the ones that I normally do. And then I am in general moving toward smaller projects.

And I mean, I don't know how many people really realize how old I am. But I'm reaching the point where I won't be doing the large projects that much longer. And what I found out. You know, I've talked to people at conferences sometimes will repeats over the years, and they go, yeah, we'd like to bring you in, but you know, we haven't gotten our ducks in a row or whatever. Folks, you're running out.

Speaker 5

Of time that front porch and that picture, and it's the dead line. It's it's the deadlines that I'm ready

to kind of move past. So I expect to be doing still some of the large projects the next year or two, and then after that I'm going to move to smaller projects for another year or two, and then I mean I will never stop working, but getting on the planes and going out and seeing people and taking control taking command of a redesigned project, which again, the supply of people who can do that is just critically short.

I mean, look, you guys have been in one of the most prestigious communities in the Microsoft space for almost as long as I have the Regional director community. How many of those guys, and most of those guys have that special capability to get in front of a group that includes CEOs or whoever high level people.

Speaker 4

And facilitate the way through to a solution. I mean, you talk about some of the contentious issues there, Carl, some of the things that come up trying to arrive at a solution that everybody's going to be happy. A big chunk of my work over the last five years has been serving in that role with companies that got stuck in one way or nothing, that are thrashing or whatever, because as an outsider, you can come in and you can kind of it doesn't bother you as much to make people mad because.

Speaker 1

Right, and plus you have no you have no skin in the game, right, right, you're getting paid a rate, so for your authentic I.

Speaker 4

Expect to keep doing that for a while, mostly because most of my clients who use me, they'll call me in every couple of years to get them through some project, to facilitate. They'll get all the important people in the room and we'll spend three or four days just kind

of getting they hammered out. Right, And Richard, I know you've done stuff like that with groups, and the number of people who could do that is so limited that my clients are probably going to be still be begging me to do that in five or six years.

Speaker 1

I tell you what, I love my small business customers. I love working for small businesses because there's just so fewer layers and politics. I mean, Richard's kind of a pulled creature, but I don't like that at all. Kind of well, yeah you are, yeah, you're right. Not kind of absolutely thrives in a political environment, but not me.

Speaker 4

So if I were you, if I were bossing some of the people here about they talk because you talked about people becoming architects because that's the promotion path way. No, they should be building a talent stack and learning how to facilitate is a potential layer in that talent stack.

Speaker 2

No, No, And it's the thing is people who want to move in that space, We've got to do a better job of letting them be good at it, letting them be able to learn. Again, I feel the same way watching folks bounce between PM and direct dev where it's like I love someone who wants to do both jobs. Like sometimes you want to write in the code, sometimes you want to help other people write the Yeah, yeah,

Like both are rewarding gigs. It's just do we give room for folks to be able to change and to you have to get up to speed and give them appropriate projects. You can't be linear. It's not a linear process.

Speaker 4

But yeah, we don't. As you said, we don't invest as much in helping people move in that direction as we should. And if I were to suggest the very first starting point, it would be learning how to listen better, because in general, human beings are bad at listening. Developers are human beings.

Speaker 1

So most sorry you say something, goodness, wife, I got a dope slap.

Speaker 4

So there are various resources for that. That might be another link if I can remember, put it on there to get some some listening resources for people. There's a book called The Charisma Myth that has an entire chapter on listening with some exercises. Wow, that I think is worthwhile. So, yeah, we need to help people move in that direction. Now I'm going to be kind of again candid about it, just as I was with some of the architectural stuff.

Some people don't have the call it presence. I guess to be in that group and keep control of it. It's it's kind of an born thing. And so you want to if you're going to move in that direction, you ought to you have to have that that inner confidence that you can talk to people on their level, even if no matter where they are, that you can talk to them as equals, listen to them, but also tell them when you think they're wrong, and work through

disagreements and such. Some people just worry too much about other people's feelings and so they it's very hard for them to step into that facilitation role. But if you can do that, and I don't mean that you have to be a jerk. I don't feel like I'm a jerk, for example, but you do have to be able to challenge people this. That's a phrase, just a free tip for people who are in this that when they say something you disagree with, don't say I disagree with that,

Say I challenge that. Notice the different psychology there.

Speaker 1

If I'm not saying I'm.

Speaker 4

Not wrong, you're saying I'm not sure that you're right about that. So let's let's invot some more discussion of it.

Speaker 1

And it helps to have a sense of humor, Right, Billy.

Speaker 4

I'd like to think so yeah, I think so too.

Speaker 1

All right, well, we've wasted another hour and four minutes of your precious life. I have always a waste it was great listening to this lousy show. No I'm kidding, So thank you, Billy. It's been great as always.

Speaker 4

You're welcome. I got to talk about a lot of stuff. I was interested in it, and I hope people find some value.

Speaker 1

I look forward to our next in person meeting as well as our next dot net rocks meeting. So thanks again and we'll talk to you, dear listener next time on dot net rocks. Dot net Rocks is brought to 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.

Speaker 4

You got Ja met Van

Speaker 1

And

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android