ConsumerFi Podcast: The Tech Option Holy Wars with Greg Hindson


November 26, 2020

Episode 4

Summary

Nortridge CEO, Greg Hindson, stops by to talk about what technology is really for, why Nortridge chose to use C++ as its base coding language and taking a stance in the API ‘Holy War’.

ConsumerFi is presented by Nortridge Software: Loan Software That Accelerates Change

And special thanks to The National Automotive Finance Association: The only trade association exclusively serving the nonprime auto finance industry.


Transcript

I’m really excited, honored, and humbled to have Nortridge CEO, Greg Hindson on the podcast with us today, as someone who’s been a consumer of software for many years in an executive, who’s had to make decisions and live with the consequences. I thought it’d be great to get Greg on, to provide some clarity to various.

Decisions that you’re confronted with such as protocols and formats that are out there. I recall being in a CO position and feeling like I needed a lesson in technology before I even met with certain solution providers. There are a lot of technical terms out there, like APIs APIs that are thrown around quite a lot, but a lot of the time I find myself really questioning how many people really know what that means and how it works.

So in today’s podcast, Let’s take advantage of Greg’s experience in software development management to help educate yourself on what all this stuff means and identify what matters and what does not. Before I get down to the topic first off, welcome Greg Hindson, CEO of Nortridge. Welcome to the podcast.

Joel, I’m excited about this conversation. This is close to my heart. Awesome. You know, Greg, you’ve been with for some time. I think your background is of interest. Can you tell our listeners a little bit about your experience with Northbridge? Yeah. So I’ve been with Ben with Northridge for, for 30 years.

And, you know, I, I love my job. And because of that, I, it seems like it’s, it’s only been five or six years, but it’s been 30 years, which is just amazing to me. So I came to Nortridge back in the early nineties and I worked for a company that did escrow services for real estate, construction, loan control, and the like.

As I came into Nortridge, Nortridge had this product called the commercial loan system. They had a bunch of other products they were into Community Banks. So they wrote a lot of applications in straight basic at the community bank level. And so we saw this product and we ended up rewriting it and thought, this is, this is something that would be very useful to many people, this commercial loan product.

And we decided to write it in a manner that would be super generic for anybody that’s doing lending. So you’d be able to configure it directly in the application. And so we’ve been working on for 30 years, same code base.

That’s phenomenal. You mentioned basic. That’s one of those languages that I recall actually coding back when my dad was a, an Atari guy back in the… it’s a different podcast maybe, but, uh, Hey, what are the cool things that I learned about you very early on?

Is that you are an ultra runner and you’re a trail runner. You and I both spoke about David Goggins and how that philosophy can be very pervasive and, and help us when we’re trying to, uh, manage our way through the pain cave. Are there, are there things that you’ve learned or through business or, or vice versa through the trail running that you feel, um, are consistent and inform one another in your management style or how you run Nortridge?

For example? Yeah. So, um, it’s funny. As I, as I grew older, I started becoming slower at road running, uh, running on roads and five Ks, 10 Ks, things like that. And I had a friend say, Hey, you ever run trails before? Let’s go for a trail run. One time I was hooked. I couldn’t get away from it. After that.

Um, my wife’s still is telling me there’s a 12-step program out there to solve my addiction. I went directly from 10 K to 50 K trail race, and now I run 50 milers. Um, and I think that it’s just like anything else. You have to work at it over time. It’s a long time progression too.

Get into the sports. And I think it’s, it’s just like business. It’s weird that I would compare it to what businesses like, but it’s, it’s just something that you start working at and you just keep hammering at it, hammering at it, hammering at it to get to some goal at the other side. Yeah, I definitely connect with that.

And I think most that are most of our listeners connect with that as well. Just constantly pushing yourself, needing some goal to chase after I think it’s phenomenal. Well, all right. Well, okay. Enough fun stuff. One of the first questions that I want to get down to is very general. So Greg, in your mind, what is the goal of technology as you see it?

So first I want to point out that I’m not a fan of technology for the sake of technology. So I’m always looking to make sure that whatever technology is being used solves a business problem. Our job is to figure out how to solve somebody’s business problem. You start there and then figure out the technology that you need to use to, to, to solve that problem.

Outstanding. So Nortridge is coded in C++. Why C++ versus other language options that are out there. Greg?

That’s a great question. Um, and I get asked that quite often we chose C++ and years ago, back in the nineties as the core language for building all the base classes and processing code in Nortridge.

So if you look at our codebase, we have different interfaces on the front end, but C++ is our core code. That’s where all the computations being done, that’s where all the heavy lifting is being done. And so we chose that because it’s portable. It’s a very expressive, robust language that compiles all the way down to machine code and we can call it from anywhere.

We can call it from Java, C, C#. Um, you can call it from PHP, wherever you need to get those resources into an application to a front end.

Yeah. It’s very stable. I mean, when you look at the world around us and the things that are written in C++, I mean, if you think about enterprise applications, You could basically throw a dart at any enterprise application. And it’s probably 80% chance it’s written in C++, I mean, for example, Microsoft windows, uh, Microsoft, the windows server, all the windows server operating systems, uh, Microsoft sequel server.

Oracle database is written in C plus, plus even though they tend to have Java on the front end from all over the place, the back ends all use C+, plus Microsoft office, the Chrome browser, Firefox browser. Um, All of these systems, the enterprise systems, they’re all written C++ under the covers, all the heavy lifting part.

Um, one extreme example is Facebook Facebook’s app on iOS, and Android is written in C++ really they built it that way so that they would have the maximum horsepower. For the equipment that they were on and they have a single code base that is compiled to both platforms. Outstanding browser-based apps are ubiquitous today.

We all use them on our laptops. Why do we still use desktop apps? Question two. I think that when you look at applications to solve a specific business problem. I’m going to use Outlook because I think everybody can relate to Microsoft outlook because it is the predominant email platform. Sure. And when you look at Outlook, they have a desktop application.

They have a browser application. They have, uh, of iPhone and Android application. So they have all these different light, different versions of Microsoft outlook by far, the number one is the desktop app. And when you ask people, would you prefer to use the web app or the desktop app? Well, Microsoft has both, but 90% of the people use the desktop app over the browser app because it’s more powerful.

It’s easier to use. And if you’re going to be in it all day, it’s just, it’s easier to be in an app in some instances than being in a browser interface. Now, when you look at outlook, I use all of them. I use predominantly. The desktop app day to day. That’s where I’m doing all my emailing scheduling. And what have you?

I use the iOS phone app on my iPhone, the Microsoft outlook phone app second. And then I use the D the browser app. When I’m on someone else’s computer, I need to sign in real quickly, do something and then sign out and be done. Cause I don’t want to put my credentials into their desktop app. Sure. So they all have a place.

I’m a fan of all of them. In the right use case, right? Yeah. It’s a perfect example. All right here, we’re going to, we’re going to have some fun here. We’re we’re gonna, I mentioned that acronym API. Um, it’s an everyday term. We hear it all the time, but what about the protocols and formats? I know there’s, there’s quite a lot underneath and I’m going to put you on the spot and, and challenge you to tell us which one you think is best.

Well, this turns into a Holy war, by the way. Um, so there’s, there’s a lot of people they’re going to be very sensitive about the particular API technology they use. So first API APIs are incredibly important. I think today you have to be API forward period. You have to be able to play in the sandbox. So every other app be able to do things and connect with other applications.

And that’s generally through. API APIs. And as API has come in a couple of flavors, um, interestingly we support both, uh, soap and rest. There’s some other, um, less familiar, uh, web service, uh, mechanisms, but I’ll just talk about soap and rest, uh, soap-based web services. Um, Tend to be a little more complex, a little harder to implement them.

Rest. Rest is purely. Stateless can not be stateful like a soap can. Uh, my favorite is rest. I’m a fan of rest web services, pure stateless, easy to load bounce, easy to connect to an endpoint, uh, easy to get your job done, but they both have their place. Okay. So I’m going to, I’m going to ask you about the word stateless right there.

Cause that’s one that many of our listeners may not know what that term really means. Yeah. So, so the concept of a stateless web services, I make a request for a piece of data. The web service processes. It does whatever I’ve asked it to do returns to me that it did. It’s okay. Job. And it’s over the very next call I make has no understanding of that first call.

Each call is stateless. It happens. It’s a single atomic unit. It’s over when it’s done. There’s no understanding of relation or there’s no understanding or knowledge of the previous requests to the secondary request. Um, soap’s a little different. So, so while can be re uh, stateless, generally stateful, where I make a call and I still have a connection.

And then I make a second call and a third call and a fourth call, and they all have maybe knowledge of each other. That would be stateful. So that’s the significant difference between state lessons? Are there, are there different options where state a stateless or, or a non, uh, the opposite are more relevant?

Does it have to do with volumes? I mean, yeah. I think when you look at, um, large silt implementations, you’re going to see those in financial services. So if you’re communicating directly with. Banks or wall street or something like that through web services, that’s going to be generally soap based because it’s a larger framework, uh, built in error correction.

And what have you. So it it’s meant for a little bit different tasks. Okay. Re-ask came from the social, social media worlds where we’re making singular requests and we’re done. Um, they can still be used for financial transactions. There’s no problem. They’re doing that, but where you’re going to see, uh, sofas in the large financial frameworks.

Okay. That’s helpful. They sound both very, it’s kind of like a right tool for the job type thing. They’ll both do the job. They’re both perfectly acceptable and almost every context. It just depends on where you started, how long they’ve existed and, um, what you need in the way of the protocol. But rest is really taking over.

I that’s that’s the predominant web service going forward in my mind. So this is one that, uh, uh, have a little more familiarity with having worked in, in database and presentation layer and reporting. So we got Microsoft SQL server versus a no SQL option, um, which is kind of an open source versus Microsoft type of decision.

So aside from wanting greater control at obviously a greater cost, why would somebody choose to build it all themselves? When what they all already need is resident within the Microsoft stack. Well, I think the way to look at the differences between, um, Microsoft SQL server and SQL is Microsoft sequel.

Server is a commercial platform while they’re both semi-commercial SQL servers, commercial platform, that’s well-suited for financial transactions and for, uh, database operations, where. Data integrity is super important. Um, and that’s an extreme example to split the two and say, one’s good for financial and one’s not, um, North Korea will work.

So it will work for those kinds of trends, uh, for financial transactions. But yeah, where no nice feel really excels is in distributed database platforms. Thank Facebook, LinkedIn, things like that. You make a post. It doesn’t necessarily need to be available to everybody right now. So, um, it’ll eventually get there into the dataset where SQL servers, absolutes.

Um, and I know I’m going to get some blow back from people that like know SQL and they’re going to say, well, it will do, uh, atomic time transactions and so on. Right. But it really wasn’t designed for that. It was designed more for unstructured data and it’s trying to move into the more structured data that you would see in a relational database.

Um, my, my, my personal viewpoint on it is yeah. When it comes to the back end data, you do not want to worry about the data. You do not want to worry about the process. You want to know that it’s going to work and it’s going to work flawlessly. And you’re going to see that in Microsoft SQL server and Oracle and the primary databases on the market, um, notice Kiehl’s a great option for many use cases, but I personally do not like it for financial transactions.

Well, this has been a fantastic conversation, Greg. I really wish that, uh, You. And I had had this conversation before I went down the path with a number of software providers that I had to select during my career as an operator. So, Greg, I gotta thank you for the time. This has been fantastic.

Oh, thanks, Joel.

This is fun. The consumer five podcast has been brought to you by Nortridge. Loan software that accelerates change. We’d also like to thank the national automotive finance association, the only trade association, exclusively serving the non-prime auto financing industry.

This website stores cookies on your computer. These cookies are used to collect information about how you interact with our website and allow us to remember you. We use this information in order to improve and customize your browsing experience and for analytics and metrics about our visitors both on this website and other media. To find out more about the cookies we use, see our Privacy Policy.