333. Why Boring Technology Wins

Why are companies so far behind the times? New developers often want to learn the cutting edge technologies, but when they get their first job, they're shocked to see just how far behind the times their new company is. They might be using .NET Framework or they might be using a long outdated system. So why is this? Why do companies gravitate towards boring and outdated technology? Why does it seem like the best practices never apply in the corporate environment? That's what we're going to discuss in today's episode of Dev Questions. Software development is more than just writing code. So, let's talk about the rest of it. Specifically, let's talk about why boring tech wins in business environments. Now, there's more than one answer to this question, but I want to focus on the boring tech part. To do that, I first want to answer the other half, which is why companies don't upgrade the technology they use. And I think there's probably three major reasons. One, it's expensive. You're spending a lot of money to basically stay in place. So, when you pitch an upgrade to your boss, you say, "Hey, we're on net 8. We should move at .NET 10." Your boss says, "Well, that's an awful lot of money. How long it's going to take?" Well, it's going to take two months worth of work and testing. Well, okay. If you start doing the math on

that, that's just thousands and thousands of dollars. Is it worth it? And unless you have a good reason, the boss often will say, "Well, no. I don't want to spend the money if there's not a great reason to do so." And just saying the version number gets bigger isn't enough of a reason. So part of this is on developers to have a really good reason. For example, I would say things like immediate performance improvements. You'll get that with an upgraded.net. You also get the ability to be again shielded under the security blanket of updated security changes which security is more and more of an issue etc. So but number one is the expense because it is expensive and the end user doesn't see any new features. they just see the same thing. So why is it that their work didn't get done? Their new features didn't get added, new bugs didn't get fixed for two months while you upgrade. Is that worth it? It doesn't feel that way. So that's one reason. Now again, I don't agree with that, but again, it comes down to how you talk about it.

Number two is a lack of understanding. This kind of goes with number one, which is they don't understand why would you upgrade? It's working now. Why would we change it? So, think about anything else you use in your life. Let's talk your house. I've been dealing with some house issues recently, but I have an air conditioning unit. Why would I ever change that out if it's still working, right? I I would keep it going as it is. There's no reason in my mind to say, "Well, yes, but it's it's been two years. It's time to get a new new unit." Well, no. It's it's working now. This is the same mindset that management brings into upgrades. It's working now. Why would we spend the money? Again, expense number one. But why would we do that when it's working? There's no reason to change just because of change sake. In fact, change is scary. Change causes problems. So, it's a lack of understanding about what this change means and why it's actually more dangerous not to change. That's number two. Number three is that users are often focused on features, not fixes.

So, yes, they want bugs fixed, but they're really focused in on that new feature they want. Hey, I want the software to do this. And if you talk to a user and say, "Dream with me. What do you want to see in the software?" They don't say things like, "I would like to see new versions of .NET imple implemented. I would like to see those uh node packages upgraded. I would like to see the Nougat packages brought to the latest version. They don't say those things because they have no clue what those things even are. What they say is, I would love it if the software would do X or Y. And that's what they see as progress. So if you don't start implementing new features, then they see the application is stagnant. They don't know what's going on behind the scenes. They don't know how many lines of code you took out or how many things are more efficient now. they may see performance improvements and that's something you want to talk about a lot but be beyond that they don't really see much change.

So they're often focused on features not on version numbers. So that's that's the one side of things about why companies don't upgrade their technology which leads to them having old technology. But there's another side of this and that is that companies don't tend to have the flashiest of products. Um they t you know especially in enterprise um the the software just gets the job done. It's not entertaining. It's not flashy. It just does the work. Um so and let's look beyond the the big players to the actual software that runs most companies. So, I'm not talking about like, you know, Microsoft or Teams, which is, you know, we all have opinions on Teams, but let's talk about like the the actual software that runs companies. Um, it's boring. Battleship gray screens with standard fonts are really common. Um, I used to be a consultant. I spent years going from company to company to company, working on their software, building some of these things, and then improving a lot of them. And it's pretty common that nothing looks good. It just works. Um, they even have textbased data entry screens sometimes. Uh, there's a store in Dallas called Nebraska Furniture Mart and it's a chain. Obviously, it's not from Dallas. Um, but Nebraska Furniture Mart is massive. I mean, it's a massive store. It's an event just to go there.

It's it's actually got really great prices and a great selection. But their sales staff, they'll use tablets to help you check out right where you're at. So, you say, "I want this couch." They'll say, "Cool." They'll look it up. Here's the price. They'll put it on your order and when you're ready, you give them a credit card and they can go ahead and take care of that that right there and then send your order onto the warehouse. And they use a tablet for that, which is very modern. But those tablets are running a web-based version of a textbased data entry screen. So, it's the same data entry screen that I used to work on and and modify back in the 90s when I was working on on machine applications. Why? Why don't they have a flashy web app with images and Amazon like shopping carts and more? Well, in my years of experience working with dozens of companies, it comes down to one of three things. Number one, it works. So, don't change it. Like, if you have something that works, again, it comes back to that air conditioning example. It works. So if this is the way we've done things for 30 years and it has worked all that time, why would we change it? Now there are reasons. But that's one of the the arguments is it works so don't change it. Number two, it's heavily integrated systems that are outdated that really can't change. And this is a really common one where maybe that textbased system alls it is is just

a web wrapper around the actual text entry screen. and it's even doing some really clunky stuff behind the scenes to make it work. I've built those things. Um, but the reason why is because the the systems and and processes that it connects to, those actual machines or other things, they don't have new new upgraded software. I've worked a lot with manufacturing plants and when you buy or install a machine in a a in a plant, you typically don't get a new version in five years. you typically don't say, "Hey, that that big very expensive uh thing, let's rip it out and put a new one in because it's a new model." That doesn't happen. So, a software that runs those things, it is what it is. And you often have updates for a very long time, but at some point those updates go away and a machine is still in use. So, what do you do then? Well, you keep running the machine and just have to have software that integrates with that. And that can be true for conveyor systems or it can be true for any number of other things that might go into supporting an enterprise business.

So if they're heavily integrated in systems that are outdated, you're not going to get a whole lot of change. And then third, and this is one that I see way too often, is there were upgrades that were proposed, but those upgrades are proposed or even they try to implement those things and they were very expensive and they were less efficient. This is one that's very common. Um, people see an old system and they say, "Ah, I could do so much better than that." They see the Nebraska furniture market, they say, "You know what? Textbased data entry, it's not where it's at. we've got a modern web, we've got a modern way of doing things, we can build a site that is so much better, so much faster, um, and so much more efficient. And then you actually start doing it and you're like, oo, I didn't realize all these edge cases existed. And you have workarounds and systems and other things that you have to try and figure out how to make work. And before you know it, you have this clunky system that is really complicated and really fragile and it's really expensive and it doesn't do it as efficiently as the boring system that just worked. And that's where companies after a while they get jaded to this and say, you know what, we're not spending millions on consultants to come in and, you know, give us a flashy new product that won't work. And so they kind of stay where they're at. So it works so don't change it. It's heavily integrated as systems that are outdated and every

proposed upgrade was actually less efficient. So where does this leave us? I think there are things to learn from all these things. I think that the my challenge to you is to make boring software. And that may feel boring. It may feel like I don't want to do that. But I think it's really important as software developers when you're thinking about how to make a mark on on what I do. How do I how to make sure that I am invaluable as a developer? How do I make sure that if I build a product that people actually use it? And I think one of the big things you can do is make boring software. And what what do I mean by boring? Make software that is incredibly efficient. So when you're building software, too often people start with a user interface and they start with, you know, how to make this thing look pretty and how to make it, you know, look modern and they're focused in on colors and fonts and styles and that that kind of thing.

That's not where your your application should shine. Now, to be clear, I do think your application should look good. I do think your application should be more than just battleship gray, but I think it's more important that you focus on making it incredibly efficient. Talk to the people who are actually going to use your application and figure out every possible place that you can take time out of the process. So it could be as simple as don't touch your mouse. So if you're building a desktop application or a web application or a mobile application, especially desktop and mobile because or desktop and web because mobile doesn't have a mouse necessarily, but try to figure out how do I stop the user for having to move to another device like a mouse to move a cursor down and click next. Maybe it's a it's you know keystrokes and trying to figure out hot keys and things like that. Try to figure out how do I help this user move quickly through the system. The point isn't to spend time in your application. The point is to help them get the job done. If you can change that paradigm in your mind to go from the point is to use my application to the point is to use my application as little as possible to do the job. You're going to write a whole lot better software. Number two, focus on making

your customers successful before you make it pretty. The goal of your application is not to be the next Mona Lisa of designs. Your goal is not to win awards for how pretty it looks. Your goal is to make your customer successful. Now, your customer might be internal. Your customer might be your boss. Whoever the case may be, your goal is to make them successful in what you build. Spend almost all of your time there. Yes, make it look good, but that's a secondary goal compared to your primary goal of making your customer successful. Number three, make your apps rock solid. Okay, this is something that microservices really hurt this this case here. Um the whole idea behind microservices was hey we can make things more resilient and that can be a very good thing especially if you're at the Amazon level but most people aren't at the Amazon level they're at the 100 people use this at a time level and the problem is the more dependencies now I don't just mean like nougat packages but I mean things like if you have a front-end app that's that's a a web UI and it depends on API but that API depends on a database. Okay, so there's

three links in the chain there. Your front end, you have your API, and you have your database. If one of those goes down, then your app is down. And I say, well, okay, so I'm going to put a a message bus in the middle so that I have more resiliency, like the friend can still work if the the middle is is down or something like that. Yes, but now you have even more dependencies and interconnectedness where if something were to happen to one of those servers, you've got a problem. And so what happens is we built more and more complex applications that yeah, it works in the web, it works on mobile, it works all all over the place, but is it rock solid or is it a bit messy? It's a bit muddled. Sometimes the best thing you can do is write a desktop application. A thing that installs locally, has local storage for data, and it just works. It doesn't crash. You think about it. Every time your application crashes, every time it's slow, every time one of the dependencies is down and causes a slowdown in the system, you are hurting your user. Your user is waiting on the application.

that makes your application less reliable. And this is where you want to be a boring system that just works. You want to be a thing that no one has to think about. No one has to wonder, is it going to be okay today? You want to make sure that your app is rock solid. Every possible case you want to work out so it's as efficient as possible and it's as performant as possible. And part of that is making sure that you don't depend too many things more than you have to especially so that you can make sure that your application [clears throat] always works. And finally, define your success on performance, not features. Kind of goes back to the previous ones, but define your success on performance, not features. [snorts] you've if you've listened to me at all, you've you've probably heard me not rant, but kind of rant around Microsoft's tooling. Um, let's take an example that probably everyone knows about Microsoft Word. So, what's the point of Microsoft Word? Well, it's to be a a a an editor for documents. Cool.

Okay. How many features does Microsoft Word have? Could you put that into the 10, 20, 30, 50, 100? Could you even get close? Or would you not even realize just how many features are inside a word? And then do you know how to use 50% of them, 30% of them? What happens is as software matures and grows, there's one more feature, one more feature, one more feature that keeps getting requested until your app is this bloated mess that no one knows how to use. It's slower because every little feature takes a little bit more uh effort out of it. If you've used Visual Studio, you've seen this in action because we've had Visual Studio for decades now. And we keep getting more and more cool features. But because of that, it keeps getting slower and slower. And the team has done a great job at trying to improve that, trying to bring back performance, etc.

But it's a constant struggle because of all the stuff that's in Visual Studio. Now, VS Code came out and all of a sudden, this is a snappy code editor that is just so fast, but it doesn't have all the features. And so, they start putting the features into VS Code and all of a sudden it starts to slow down a bit. Right? This is what happens. It's the cycle of software. Be very careful about that. Be careful you define your success on performance, not features. Because it does not matter if you have 100 great features. if none of those features are very performant because people just aren't going to want to use it or can't use it. It's just too slow or it crashes or it's not reliable. But instead, if you do the one thing that you're designed to do really, really, really well, then you're just that reliable thing they always rely on. They always come back to because it's all about the fact that you get out of the way. Your application is not the star. They are. You are saying I want to get you in, out, and on your way as soon as possible. Define your success on performance, not features. Again, that does not mean you can't have more features. It just means that your success is defined by the performance of your application, not on how many features you have. Okay? So boring

applications are really valuable tools. And unfortunately today we're getting farther and farther away from those boring tools. We're getting to the point where we're focusing more on things like, hey, does it deploy everywhere? Does it, you know, have all the features? Is it, you know, quick to build? And yet that's not the right set of metrics. This is why when you open up Microsoft Word now, it's a web-based app, which quite frankly isn't as good as a desktop app. It's not as performant. It's got quirks to it. Outlook drives me nuts because of the fact it's a web app and it doesn't have some of the features that Outlook used to have that I relied on because, well, it's web- based now, so you can deploy it to more places. Yes. So you have a lesser product deployed to more places. I want you to focus on making better products even if they are more tightly targeted. Okay? This is what's going to create great software. This is the thing that people keep coming back to. Instead of saying I'm going to hold my nose and use this tool, they say this is the tool you have to use. All right? That's what I want you to build for your software, even if it does feel a little boring.

All right, thanks for listening and as always I am Tim Corey. [music]