Read the show notes and download the full episode here.
Michaela Light 0:01
Welcome back to the show. I'm here with Danny. And springle is his last name, you may have heard of him, he used to be a very regular speaker. And he's just back on the conference circuit for ColdFusion. We're going to be talking about refactoring versus rewriting, which is incredibly important, because I have seen a lot of coffee developers and CIOs shoot themselves in the foot in this and will reveal which of the two options is more dangerous. I guess there's a third unwritten option, which is do absolutely nothing with your legacy app, which is another dangerous option.
Michaela Light 0:35
So welcome, Danny, those who don't know him.
Michaela Light 1:18
Welcome, Danny.
Michaela Light 1:24
You know, for a lot of people listening have some legacy ColdFusion app. And they may be thinking of rewriting it, or refactoring, or maybe they're not thinking about it at all, and they're just gonna leave it alone. Right. So there are three typical options there. Why is this such an important topic? You know, this year?
Denny Springle 1:48
I think that, for me, personally, I think that the, the decision to refactor or rewrite these be considered carefully, and need to know what all the risks and rewards are for each method. And understanding the different ways of approaching those. I think that that is an important distinction to make between the two approaches to getting what you want out of your application.
Michaela Light 2:28
That no, that makes sense. I mean, people may have, you know, they may think they're supposed to do it a certain way, but they haven't thought through what are the possible risks and rewards? Then what about the unspoken stepchild of you just leave your legacy app in the corner and don't be the new improved? The right that
Denny Springle 2:47
That will ultimately lead to it being hacked nine times out of 10? Yes, unfortunate. Unfortunately, if you if you leave an app alone for too long, it will, it will develop flaws that nobody knew were there until years later. So if you don't, if you don't maintain those things, and you run that risk, surrender, yes, you run the risk of not delivering the tools that you need to whoever your end users are, whether that's internal clients, or external clients were what have you, you know, you run the risk of even losing customers by not continuing to improve your application. So there's definitely a lot of risks of leaving it alone as well.
Michaela Light 3:34
I mean, with the pace of technology and business change, doing nothing or standing still is moving backwards. Absolutely. So I, in addition, you know, I just want to dig into that security risk, because I've talked to a lot of people whose legacy apps got hacked, because, you know, they're on some old version of ColdFusion, or they had an unsecure code in there. And it's not just a technical headache, because now you've got days to clean up work, or you're trying to undo being ransomware, or whatever is a reputation, what rest of the business apps, now their customers don't trust them. So not a wise course of action.
And another factor with not doing anything on legacy apps is to be honest, when I interview ColdFusion developers, not many of them want to work on spaghetti legacy code books.
Denny Springle 4:28
That's true. That kind of leads into why a lot of developers see this spaghetti code and say, to their CIO or their manager, we need to rewrite this right.
Michaela Light 4:45
Have an allergy to spaghetti, right?
Denny Springle 4:48
And I've done it, you know, I've come into companies and been like, you know, no, let's rewrite this. So I've been down the road and made those mistakes, which is why I can I can say with some certainty that, you know, there are pitfalls. But you know, I get it, as a developer, you come in and go, you know, I could do this better, right? I understand how this could be done better. But you know, it's a very high level, I don't want to touch this old spaghetti code, just let me rewrite it, and it'll be great. But you end up missing a lot of the big picture pieces. And either, you know, you, you give a timeline that is, you know, too aggressive, because you didn't really consider all the factors involved. Or, you know, which leads to failure, or, you know, you you just absolutely miss important business intelligence pieces outright, that make whatever you produce, not what it needs to be, to be an adequate replacement to what you're trying to replace. So, there's definitely a lot a lot of risk. But I get the urge, I understand the urge when you you come into a company, or you come onto a position, where you bring on a client that that has, you know, this old legacy style code, I understand the urge to want to rewrite. That's absolutely, it.
Michaela Light 6:29
Just needs to be channeled correctly, right.
Denny Springle 6:32
And I've learned to temper that, over the years with that understanding of all the pieces involved. And understanding that, you know, a rewrite is a large endeavor, and not something to be taken lightly. Whereas we'll
Michaela Light 6:53
Dig into that in more detail later. But maybe before we do that, maybe some people listening, I'm not 100% Sure what we even mean by the term rewrite, or refactor, right, what does refactoring mean?
Denny Springle 7:06
Refactoring is a way of taking in modernizing code that already exists, and bring it up to speed with generally modern best development practices. So you know, some object orientation, data modeling type of thing, as well as you know, either using a framework or building an application framework yourself, that hits all of the major obstacles that are that a framework will do for you generally. So that you have a unified platform upon which developers can develop. And especially especially when you get into teams, refactoring is is a process that allows you to take a piecemeal approach. And you can do the same thing with rewriting as well. But the refactor gives you a chance to get into the code, it gives you a chance to understand the code, it gives you a chance to improve that code and bring it along to like I said, more modern standards, modern practices. So that the code is becomes easier to maintain, it becomes your reusability becomes a factor performance becomes a factor security becomes a factor. You know, all these things can can transpire at a much slower pace when you're refactoring. And, you know, a lot of times refactor can end up with what is essentially a rewrite at the end of the day, right? You can refactor an application to something that that is all modern is all on a, you know, an MVC MVC framework using object orientation and, you know, good data models and all that stuff. You can end up that with that with a refactor process. That's it same as you came with the rewrite process. The difference for me is refactoring allows you to take that that piecemeal approach, it allows you to implement things like feature flags, if you want to be able to implement new functionality and turn it on and make sure it works. And if it doesn't, you can turn it off and go back to the old code until you've got it to a point where you want it. So there's, there's all these steps that refactoring lets you take. In a in a small step kind of way that a rewrite generally does not rewrite generally is okay, let's sit down and for every single thing we need to do and and put down a plan and then let's rewrite it and then we launch it.
Michaela Light 10:02
It's an incremental improvement set of improvements to the code. And literally refactoring means taking a piece of code and keeping the functionality the same or, or sticking it into a object or a function. And, but then changing how internally is coded to follow those best practices, improve security and performance, usability.
Then let's just talk about what is a rewrite, because I think most people have an idea, they know what a rewrite is, but what what is what is really doing a rewrite really mean?
Denny Springle 10:42
What doing a rewrite really means? It means understanding, primarily for me nowadays, it means understanding all the business logic involved in that application, and having that well documented before you even touch code. If you don't do that, then you're gonna fail. I mean, you may not, you may, you may as probably I shouldn't say you will fail, the chances of failure become higher. If you don't take into consideration what it is the application should be doing, what business logic processes, it should be mining. And what what business intelligence does it use? And, you know, what, what problem wasn't meant to solve? And how does it do that? And, and how do you effectively capture all that into an effective rewrite cycle? You know, at one of my clients, now they're rewriting an application and to know that they've been working on it for two and a half years, and all the while, we're still maintaining their coefficient code, right? So and improving their cohesion code. And we've had to take steps, even there to do things that will help allow that, that rewrite to ultimately leverage the API's and the data that that we are using in our current application. And, you know, two and a half years into this, and they're, they're still trying to figure out what all the bits and bobs of the business are right? And what processes still need to be written. And that's why it's taking them so long. And they are, they're committed to doing it, and I believe they will eventually succeed. But again, they didn't come into this with the prior knowledge of what does this application do? What does it need to do? What what kind of business intelligence is it handling it's, and so they're finding out as they go along, right? Which requires no engineering solution, and then oh, by the an engineer, right, because I didn't understand it. So now I've got to go back and re engineer that. And it just really takes a long, long, long time, if you're not well prepared up front, with knowledge, a deep knowledge of the product that you're trying to replace. And a lot of times, that's just not there, right? You come in to a client who's, you know, had 30 developers and 20 years working on the same application, and there's nobody left. Right? So there's, there's nobody around with any kind of original OG knowledge, right? So and they bring you on and go, we want to rewrite this and, and, you know, add these additional features and things. And you have to, you know, kind of step back and say, Okay, well, do you as the client have, you know, the level of knowledge about this application and what it does and what problems it solves? All that information needs to be kind of decided at that point. And known you need unknown quantity to have an end goal. Whereas refactoring is more like you said, you can refactor a single piece of code to improve it to bring it up to speed with like said modern practices or, or whatnot. And then that piece is not generally, that's not how rewrites go rewrites go, okay. I'm gonna take the database and I'm gonna go off and write all the data models and do all that stuff that I'm going to do. And it may be in an entirely different language, right? I mean, they just can't they how many companies have gone from CF to you know, node or to dotnet or Java even And
Michaela Light 15:02
There's.
Denny Springle 15:04
Little correlation between allow the legacy CF style of coding, you know, especially if it's tag based, versus any of the modern languages that, you know, it becomes very difficult, especially for a developer of a language that is not ColdFusion, that has had no ColdFusion experience for them to go in and understand what that application was doing, and then re implement that functionality in another language.
Michaela Light 15:39
Rewriting, you're changing out some of the technology pieces, you may be changing the programming language, maybe you're not, sometimes people rewriting the same language. Maybe they're rewriting in a newer version of it, or they're using modern version, modern CF script and object orientation or whatever. Often they are changing to a new language, because it's like flavor of the month that, you know, incorporation, or whatever political reasons. They may also be changing our other components, they might be changing the database, either a version or they're changing SQL Server to MySQL. They may be changing the operating system or they're moving to the cloud. They may or may be changing. You mentioned frameworks earlier, they may be changing which framework they're using, you know, for example, a lot of legacy ColdFusion apps, if they either have a homegrown framework, or they use fuse box, and fuse box isn't supported anymore, unfortunately, you know, homegrown framework, you're never going to get third party support for that. So you may be changing it. And I think part of the thing with a rewrite is you're changing so many moving parts, it's, it's sort of like, like doing and the app isn't static. It's being used by users every day, maybe 24/7. Maybe it's business critical. It's sort of like doing repairs on an aeroplane while it's in the air.
If all you're building a new airplane next to the old airplane, and I'm walking out on the wings to kind of investigate how does the older airplane do this particular situation that's dodgy. To use an English word, a British English word? It means English. Yes. There you go. So the analogy I've used with, with customers, sometimes it's, you know, your your legacy app is a bit like a house where the lights all turned off in the rooms. It's like a black box. Yeah, the outside of it operates, okay, but you don't know what's in each of the rooms and the basement, the attic. And then you come into this legacy code, you're stumbling around, you're banging your shins on a coffee table you didn't know was there finally find the light switch, turn it on, you understand how that room works, how that piece of code works. And then either you can extract out the business logic for it if you're trying to investigate for a rewrite, or you can rearrange the furniture and modernize things, get a new coat of paint. And that's more of a refactor. So the rewrite is demolish the house, rebuild another house, possibly with totally different materials. If you're three pigs, you might choose breakover straw, for example, or whatever your pig building best practices are these days. Whereas with the refactor, you're taking the existing structure, if it's sound, you're saying, Okay, well, we just need to do you know, use some modern wiring in this house or you know, fix up the plumbing guarantees lead pipes and stick in modern plumbing.
Tell us about you mentioned briefly some of them. It seems like you have a when you were younger, you had a bias towards rewriting and now you're, you know, slightly older you must be in your late 20s By now then.
Denny Springle 19:08
They 20 times three almost.
Michaela Light 19:13
Yes. In.
Denny Springle 19:15
My early years, I was definitely the guy that.
Michaela Light 19:17
You mean time to for listeners? Yeah. Yeah.
Denny Springle 19:24
In my early years, I was definitely the rewrite guy.
Michaela Light 19:28
Rewrite kid, we should be right.
Denny Springle 19:33
That was my, my limited understanding of things at the time. led me to believe that I was smarter than the other guys in the room and could, you know, produce something that was better than whatever was there and could do it in, you know, an adequate timeframe. And I underestimated every time I've tried to do a rewrite. The amount of time it was going to take, I underestimated the amount of time it would take just to understand the the actual business logic of the application. Nevermind the actual coding pieces. In fact, I distinctly remember starting with a company, and they asked me to look at the code and they were like, you know, what do you think? And I was like, No, we should rewrite this and like, the boss was like, Yeah, you know how long they think that will take and has to be in my 20s. I was like, I'll not two weeks. And, you know, two weeks came and went, and the boss is like, alright, so you know, where's my review? Right? And I was like, I was wrong. So I learned through trial and error that, you know, the the risks of just going into rewrites for the sake of going into a rewrite is probably not the best approach.
Michaela Light 21:03
One risk is that the project goes over budget. Most software developers and CIOs have seen projects that went over budget.
Denny Springle 21:13
Budgets are definitely the first thing to go.
Michaela Light 21:18
But there is also risk of total project failure. You know, I've told you that a number of CIOs who either their predecessor decided to do a rewrite of a ColdFusion app, or they did, and,
You know, after spending millions of dollars, years of time, it just never launched, it just never was successfully completed. It wasn't just that it went over budget, it's like, they never did figure out the right business logic, the users never liked the new rewritten version of the app. various reasons, because either they miss some business logic, or because there was no focus on change management, users hate change, as do most things. And so there was no project time put into education or, you know, championing that the new system and why it was better.
I mean, this even happens in SAS apps, I was talking to someone, yesterday, they're using some SAS, but the run most of their business, and the SAS decided to do a rewrite. Well, they didn't bother to actually talk to their users, like the person I was talking to. And the new version is like sucky, and it's like, takes three times longer to do anything than it did before. Because it was done right. Right.
Denny Springle 22:40
Now, it was done in a way the user was accustomed to. And now it's not.
Michaela Light 22:46
Really that or it's a business reason they do it a certain way. That's That's true. 10 in the ideal rewrite, developer mind, that wasn't a possibility.
Denny Springle 23:00
That is true.
Michaela Light 23:02
So and also another way projects fail, you know, they just never get out of debugging. You know, I've seen that happen, where a project. I mean, ideally, when you're writing a new project, the bugs, once you've got all the features done, the number of bugs decreased. You may not get to zero bugs, but you hope to get to very few bugs. And sometimes, for various reasons, you know, the number of bugs. I do remember on one big project, many years ago, we had one developer on it, he seemed to have a negative Bug, bug entropy, he would actually he fix one bug and create 1.5. We took him off the project. You know, people write different quality of code.
Denny Springle 23:58
Absolutely. Since where I spent over two decades, mentoring other developers are trying there's, I've come come to the conclusion that there are people who are willing to learn and people who are not. And the ones that are willing to learn are the ones that I take the time to. to mentor in the ones that aren't I make suggestions and they can take them or leave them. But I'm not going to invest a lot of time.
Michaela Light 24:31
Yeah, another word. Another issue is, you know, sometimes, I'm sure this doesn't apply to anyone in the current room or listening to this. But sometimes people are so excited by the new data model and the new, you know, coding features in Node or dotnet, or whatever. They forget about the user interface, and that there are actual users you have to use them. Sometimes, while a rewrite may look bright and shiny, it may have sharp places that are Odd use are just are fun to use.
Microsoft steam especially good at producing programs, that they're technically correct in how they function, but they're kind of clunky. Yeah. And
It's quite hard to make, you know, I mean, I guess this compares that, you know, I'm not a fan of Apple products, but some people rave about them. And one of the things they rave about is the ease of use design. And the same thing applies to software, you know, you've got to take that into account, as well. And although the legacy code may be a little old looking at least people are used to it other sharp edges have been rounded off over time.
Denny Springle 25:45
Yeah, stay here lipstick on a pig as well. Yes.
Michaela Light 25:51
Well, lipstick on a bad rewrite is even worse. So yeah, what are the things you've seen in the rewrite disasters? Or risks or successes? Must have been some rewrite successes, right?
Denny Springle 26:08
I've had of the of the several I've tried. In my career, I have had one really successful rewrite.
Michaela Light 26:19
Out of how many?
Denny Springle 26:23
I'd say one out of five.
Michaela Light 26:26
That's not good odds. That's only slightly better than playing Russian roulette and
Denny Springle 26:30
Yeah, yeah. So you know, I think I stress this, I keep dressing this, I think that, that.
Knowing the business intelligence has been a primary reason for not knowing the business intelligence of these applications has been a primary reason for why I've seen me Wrightsville in my career, that I've, I've tried to approach myself personally, with or without teams. And I think that missing those pieces, and like you said, you know, making changes to user interfaces, even the slightest change, I mean, we see this with Microsoft, right, from Windows 10, to Windows 11, they took away the right click, giving you everything to right click giving you a more options options, which everyone hated and immediately sought to reverse, right. So you know, even small changes that someone somewhere thinks is a quality of life improvement can be disastrous for the actual people using the application. So, you know, as far as disasters, you know, the, the obvious one is, you know, going to a point where there is no budget left, right? So you've gone over budget to the point where there's just, there's no money left to do this. I have a client right now that that wanted to rewrite. He's, you know, running out of money for his application. And, you know, he was like, let's just scrap all this and start over. And it was like, No, don't do that. Because you know, you'll be out of money before you ever get it done. Right, you've, you've gone from having a budget of $300,000 this year to having you know, a budget of $100,000 the next year, you're not gonna pull off a rewrite and $100,000 right now, that's something that you've already spent 20 grand on. So those kinds of decisions that have to be made. And those are the kinds of risks, you know, you you get to a point where you think, Oh, we'll get this done in six months, and six months comes and goes, You're not half done, and then you go, Okay, well, we can afford to go another six months, it should be done by then. And then six months comes and goes, and you're still, you know, your two thirds on maybe. And you haven't done user acceptance testing or any of that kind of stuff yet. So there's, there's all these pitfalls. And the, the one that that I keep, I know, harping back on is just not knowing what the application does not encapsulating all the same business logic and the new application that was in the old application. Whether that's, you know, a user experience thing, or whether it's an actual new business need that is not being met. When you do the rewrite, because it's easy to miss right? You think okay, this screen does this, okay, I'm gonna go do that. But you missed all the The underlying logic of what made that screen that screen right? When calculations are happening all these things, you go off and do ad hoc things, and, you know, you dispersive, you know, go back and look at the code. And that's where refactoring is, is a handier tool, because you're in the code, you get to understand and look at and, and appreciate what the code is doing. It may be doing a poor job of it. And you may refactor it to a point where it's no longer recognizable as the original code. But you've captured all that business logic, not gone off and just written something willy nilly thinking that it's what it should do, and not knowing what it actually did do. So I think that's a big one.
Michaela Light 30:51
That I brought up, I mean, I would say only consider doing a rewrite of either the business logic is simple, or it's very well documented.
Or possibly the business, I guess another reasoning might be if the business has been merged, or you know, something's really radically changed, then it may be easier to start fresh, but
Denny Springle 31:16
That's in there happened to I've seen companies merge together where, you know, once company is using PHP and the others using ColdFusion. And ultimately, the PHP guys go, well, we can do right, all this, that journey during a cold fusion, and then they go off and try and do it. Right. But you know, none of the ColdFusion guys are left, because they got rid of all those guys, because they're gonna rewrite it in PHP, so they don't need us anymore. And, you know, couple years later, they might call us back up and go, Hey, you know, that rewrite? We're done? Yeah, but it didn't work.
Michaela Light 31:49
That's very common, unfortunately. I mean, the other thing you mentioned, you know, user acceptance testing, you know, I would add, having real users beta testers, if possible.
Early in the process. And then I think it helps to have a plan for a really long Shakedown period, after you release the new rewrites. If you're going to go the rewrite route, you know, you've got to allow months that light user feedback and rapidly fix the issues in business logic that you've missed, or the user experience the missed or you can get them on board. You can't just like be well, we're out of budget, and we're not going to fix it until next year. Right? Then people are going to not, you know, embrace the, the app. And yes, if it's an internal app, you can kind of forced them to do it. Just like some organizations are still forcing people to use Microsoft IE browser. We don't want to recode the
Denny Springle 32:53
Can we wrote this and 1992 is not doing anything with it. So here's a
Michaela Light 33:02
Yes. And, you know, if it's possible in your business, a lot of SAS owners I know, do this, they, they don't have 100% of the users on the new version, right? They use feature flags or other technology, just roll out to 10% of users and see exactly Hey, is it working? Okay, they look at the metrics on the app. griefing, about web apps, you can tell where people are getting started, you can use one of those, you know, heat map tools like hot jar or whatever, you can see where people are like, what do they call it re clicking with a mouse.
You can actually watch in time recordings of what they were doing and where they got views. Or you can sit down over someone's shoulder while they use your app. That's typically user experience, type activity. So, you know, planning for that is a good idea. But if it's anything to do with, you know, you have customers or public, if you've f up your rewrite, they're going to bail. You know, unless you have the US government where you're not allowed to have a competitor. I think we should.
Have several different governments that you could pick for the DMV license, right? Like, oh, I want to go to DMV version A today. Maybe they'd get more of nothing against people working at the DMV. Now. A little competition makes things work better
Denny Springle 34:38
Than other times. Yeah.
Michaela Light 34:41
So let's talk about your current, you've now moved away from rewriting and you've moved towards refactoring. And I think typically you're keeping the the app running during the refactor. Is that true for you? I mean, yes, absolutely. A little bit. refactoring you make sure it's work, right? You refactor one area or one module one feature, or one thing under the hood. And then you test it and roll it out. And you make sure it's still working. Okay, before you fix any issues, any bugs, any user interface issues, before you move on to the next thing, well, in an agile type environment, agile.
Denny Springle 35:28
Sprints fit very well with that.
Michaela Light 35:31
With a sprint, for people who haven't ever done one, it's, you have a period of time, maybe it's two weeks, possibly a month, you don't really want to make it much longer than gets out of control. And then you say, Look, we're going to implement so many new features in spring, two new features, or four, or whatever the number is based on the capacity of the team, and the digestibility of the old business logic. And then you focus on just those features for that. And the idea is to have them, deliver them and be done by the end of the sprint. And then you get with the business users like, well, what's your priority, because the the features picked for that sprinter not just coming out of some whiz kid read the rewrite kid's rear end right there, the business users like, well, this is what's most important for us in the next two weeks, we'd really like to get this report improved, or we need this feature changing or whatever. All you know, all technical partners API has changed, this bit stopped working, and we need it fixed up to work with a new API or whatever.
Denny Springle 36:42
So their API provider got bought by a bigger company, and they've reached out everything and I can happen.
Michaela Light 36:53
The idea being that the app is constantly in use, you're improving different parts of it. But when you finish that two weeks, that part of you so you don't get in Scituate, one of the problems with with a rewrite, as opposed to a refactor is you make a month before anything gets tested? You know, because there's no, there's not enough working pieces in the rewrite at the beginning to be even using it. That's part of the issue. All right, you may chunk it up into agile sprints, if that's what your cup of tea is, what are your tell us what else you do in your refactor process.
Denny Springle 37:40
So these days are typically the first thing I try and do is look at reusability. And that typically comes down to making sure that there's a data model, whether that's, you know, an object or an a data model, or an or M data model, or however you want to put it together. But, you know, a central set of services or CFCs, that that handle the actual logic of persisting that data and getting that data out. So that, you know, there's you don't have a query that does the same thing in 12 different places in the code, right, you're always using a single CFC service that has that query in it, and you just call it the one place of things ever change, you have to change it in that one or one place, or maybe two, if you're using DEOs, and services, maybe three if you're using you know, beans, and views and services, three places to change something, versus 12 or 24. And I've seen applications that have queries and you know, hundreds of places that have to be changed when something changes in the table. So I like to focus primarily at the outset on building a data model that encapsulates not only the data itself, but the business logic that that acts upon that data. And then
Michaela Light 39:14
Just before we move on from that reusability is, is, you know, nice for having one, you know, having one piece of code in one place and not caught. I mean, where this problem comes from. Some people, none of us in the room probably do this. But they there was some copying and pasting of code that occurred instead of taking the time to be like, Oh, this codes pretty much exactly the same, or it's 99% of the time with a different parameter. And let's write a function or stick a parameter into the SQL query or whatever you're going to achieve here. And so you're saying, hey, let's identify that let's compromise it so that when we're making changes, we can do it in one place instead of 100 places.
Denny Springle 39:58
That makes the code a lot more maintained. interval.
Michaela Light 40:01
Exactly. And that was the point I was gonna make. It's, it's, it reduces the time for future maintenance. So that's a great improvement you do in your process. And I'd add one more thing in sometimes there's not any copies of code around this actual whole chunks of code that are just never run. It's incredibly cold, I call it dead wood code that, like branches in the McCree that died.
Denny Springle 40:28
They've, they've written a new routine to replace it, but never went back and cleaned it out.
Michaela Light 40:34
I might have done that. Or maybe business case change changed, features not used anymore. Another thing, I won't name the company or the programmer here. But the program, I had a habit of like they made a copy of a whole folder of stuff. And it was like, you know, feature two, or feature three or a copy of this. And that sounds fair enough, you might be able to guess which one wasn't being used. But then they would use random CF files out of each folder to kind of mix it up. Make it more fun for anyone following them. Rare or not? Yeah, that program was terminated with extreme pressure is out of whatever that movie, what Apocalypse Now it was cold code Apocalypse Now, right? They just lost their job. And we've been able to refactor and clean up most of their messes over time. But it is very common to find whole folders or sections of code that are not used. And the same in the database. Often in a database, there are a whole tables that someone thought were a good idea, or it's just like a test copy or a backup copy or anything indexes. You know, not all indexes are equal. Unfortunately, that's true. Sometimes they will put on and no one thought to check, are they still useful? Anyway, I'll get off my Deadwood soapbox.
Denny Springle 42:04
No, no, it's it's good. That's absolutely true. And especially I found in databases, a lot of times I find things that just aren't used anymore.
Michaela Light 42:17
Oh, I will add one thing to this. This often was data to be archived, you know, the the apps been running for 20 years, it doesn't really need for reporting purposes to go back more than a year or two. And yet, it's got millions of rows of data. And it's kind of plugging it up. All this? I don't know, I'm shocked. But you know, sometimes there's bad data or it's not validated or the primary key is blocked up, or that's another potential issue that we come across or summer. You've looked into the reason reusability and you've put down to common staff got rid of the unused staff. What was the next step in your RE background.
Denny Springle 43:08
And these days, I typically try to move to an MVC framework. Either coldbox or framework one. I was a framework, one fanboy for a really long time. And didn't really like cold box. Over the past several years, I've gotten to know coal box and like coal box more. And I think that both frameworks still have a use and a purpose in the community, and there's different reasons to use different, the different ones. I think framework one is very lightweight and allows you to kind of get the MVC without a lot of the bells and whistles or it's called Box has all the bells and whistles as well as a whole ecosystem of additional products that work together.
Michaela Light 44:04
That you're talking about the box products that the guy to be clear a lot of those box are the products they work great with coldbox they can
Denny Springle 44:14
Works with your arrow standalone as well. Like wire
Michaela Light 44:17
Box, an example.
Denny Springle 44:19
Gearbox cachebox Yeah, s box.
Michaela Light 44:24
Yeah, they're all they work great. We call box but they work fine with your refactoring out Allaway. I'll just mention for people listening CF wheels as the other common framework that they all have roughly 25 30% of the market apart from the people who have a custom homegrown framework, or you know, still using fuse box.
Denny Springle 44:51
So it's boxer moto glue or Mach two. Yeah.
Michaela Light 44:57
Which they're all they were all great frame. works in this debate if but they're just not being maintained. And that's the issue here. That if you go with framework, long haul boxes, if wheels, they all have a commit, they're all open source, they will have a community of developers maintaining them and improving them. And if there's a problem you have other people to turn to.
And it's easier to hire people who might have used them or something similar. Whereas if you stick with the Homebrew one, it may be just fine. But it's going to you have to now train people on Well, here's how our work, there's no external documentation on it. It's true.
Just step back a bit, why is having a we talked earlier, we touched on this organizes your code, I believe, we should just dig a bit what better into why'd you add a framework.
Denny Springle 45:50
So it's partly because of code organization, right? So the MVC frameworks that we have now are primarily convention over configuration. So for those that don't know, like back in the fuse box and lock two days, you had to configure pretty much everything. And the idea of convention over configuration is as long as you know, your files are in this folder, then they'll be picked up by this process and used. So I think that the code organization that NBC brings is a good part of it. I think the separation of concerns that MVC brain says is an important piece as well. I think that the ability to, to separate your, you know, your views from your controller logic from your service logic is highly conducive to not only just having reusability of the code, but also in having a good organizational structure, that all developers that are in your organization can learn to follow, right? One of the key things I've learned over the years, when I'm working in teams is to try and get as many of the team members on the same page as possible in terms of, you know, code style, and, and technique. So that, you know, any developer can pick up any other developers code and have a rough idea of, of how it was being put together, and what you know, organizational rules are being used. And frameworks allow that to happen is, as you said, they may come from another company and have already used it right, they may already have experience with it. And that makes it easier to get your developers up to speed and making, you know, an increase their productivity out of the gate. So I think there's a lot of good reasons to move to a framework. There's a lot of valid reasons not to use a framework as well. But I think from a core code, organization, maintainability readability. And frankly, even just performance and functionality, a lot of times you'll get better results out of an MVC framework than you will out of not using one.
Michaela Light 48:36
I mean, another benefit of sticking all the front end code into view, parts of the MVC is that if you have people who are UX coders, they're doing CSS or whatever they can tweak with that code, they're less likely to dork up your SQL queries or call view logic. So you know, and the same with the SQL code, if you separate out the SQL into, you know, part of your model. And some of these frameworks, you know, you do separate the database stuff into separate pieces wherever you can have a DBA tweak around with that without too much fear little screw up the UX or whatever. So the other thing I'd say is MVC is not just a ColdFusion thing, this is a software industry wide thing, pretty much Well, I'm not aware of any modern programming language that does not have an MVC framework, which is popular. Me.
I know. They all have their own favorite MVC language. I'm sure there are languages out there that don't but
Denny Springle 49:44
Probably basic.
Michaela Light 49:47
Basic they all list Yeah, list just has lots of parentheses. Pretty much. But yeah, any Web Development Language Reg, there's been used in the modern way. I mean, Perl doesn't, right?
Denny Springle 50:05
Probably. Yeah, I haven't touched Perl since 90 Something.
Michaela Light 50:14
Well, probably wise. Otherwise, we'd have to disinfect, you know, no insult managed to pull programmers in the audience. But it is a little bit of a cryptic language is it's a bit like RPG, if you have a program that on mainframe days gone down anyway, for those who don't know what RPG is, just to say that the column you put the stuff in is critical. And if you get it in the wrong column, it doesn't run. Right. So a bit of a headache. And also the he was one of the call, I mean, the language, we're kind of cryptic to stay away from that. Anyway, so go use a modern, you know, move to a modern framework. And basically, that means taking the existing code and slowly over time, you're moving it into those different three bits of code. So what else do you do in and.
Denny Springle 51:11
The primary way that I do that, which is bringing things over these days, is to actually just build the REST API. It has a lot of benefits, in addition to the fact that you're refactoring. It has long term benefits for the organization. You can change front end frameworks anytime you want, right? So when the next great thing comes along that, you know, the kid you just hired out of college wants to do to improve your UX, see, he can go off and do that and not have to worry about, you know, touching any code that touches any of the back end, right? He's just working off the API. Or she and so you know, there's.
Michaela Light 52:00
I think API's are feminine bite, they're like chips. Or fees by the fall you met the programmer? Yeah. Absolutely. Many programmers are she's absolutely non binary programmers out there as well. Hexadecimal instead of binary.
Denny Springle 52:19
I think there was quite a few Twitter at one point.
Michaela Light 52:23
So I the reason for you putting a rest, for people who don't know, rest is just a standard for API's versus soap. So it's just a way of doing API's. And do not worry, because ColdFusion by default, when you do an object, you can change one parameter on the object and there'll be pumping out an API, it's not hard to do. Don't Don't worry, for those listening at home who haven't, you know, I've never done a REST API or consumed one. ColdFusion, as in many things, makes it incredibly easy to use this advanced piece of technology.
Denny Springle 52:55
And, and the, to your point, you know, rest is another pattern, right? So just as MVC is a pattern, rest is a pattern that you use to, you know, organize your application in a way that makes consumption by other applications easier, right? Or other technologies. So it replaced, that I won't say replace so because I still interface with a bunch of soap stuff these days still, and all XML stuff, but for the most part, you know, rest is is replacing that old school RPC style application calls with, you know, something that is more data centric. And, you know, worked in a in a standardized format, which is JSON. So, there's just a lot of advantages to go into a REST based API.
Michaela Light 54:00
Absolutely as the modern way to do them. And I think the word we didn't say earlier about REST API, you're encapsulating the code. With any API type architecture, it's a bit of a blackbox, you send it the parameters, it sends back the results. And so it's, it's less likely to be you know, if you have a problem in one part of the code, it can't mess up this part of the code and vice versa. So that's the benefit. One of the benefits here and
Denny Springle 54:30
Typically, you're encapsulating business logic not just the data model itself, right? So the the encapsulation takes into account all those things that
Your your business views and things like that, that that you wouldn't necessarily think about it. We're just looking at it from a data model perspective. I've seen a lot of people that build API's that It basically just, you know, glorified card interfaces to their database. Right. Right. And so you know, you
Michaela Light 55:10
Think they got that out Chronium wrong. I mean, it should have been spelled si r AP. Game agree. Yeah, but, yeah. So and you know, if you if you encapsulate this, does it let you switch out your front end? You know, for example, or
Denny Springle 55:37
I mean, absolutely. It. It. There's a lot of benefits to the API. Especially in in today's landscape. I haven't met a client today that doesn't want a mobile app. Right. And so having an API is almost essential to building a mobile app.
Michaela Light 56:02
An API? The reason is because you only want to send as few bytes as you can between the back end server and the mobile backend. Because the bandwidth may be sucky on that mobile phone. That's correct. If you're not living in Southeast Asia, where mobile speed is fast speed in the United States rate.
Denny Springle 56:23
Or you're not on a line that drops every 20 minutes. Oh, like my, my intent is to do sometimes. So yes, the the advantage, one of the advantages of building an API is that you can then branch out into other technologies such as mobile, you can change front end technologies on a whim. Almost all front end technologies are designed. Or an API, right, I mean, their, their, their way of getting data presented to the end, users expecting to use some kind of Ajax call of some sort, right. And nine times out of 10, that's going to be an API layer. And these days, nine times out of 10, that's going to be a REST API layer so and so there's that there's so if folks
Michaela Light 57:26
Ever consumed a REST API, there are many reasons you should learn how to do this, because there's all these third party API's that you could be consuming. And then you could make be making your own add additional one parameter to your CFCs. Yep.
And then, just like the MVC stuff, every other modern programming language and ecosystem, guess what they use REST API's guys. Get on the REST API bus?
Denny Springle 57:58
Absolutely. And that's another thing, right? It's all of these things are applicable outside of ColdFusion. Right. So if you can't get a ColdFusion job, but you know, MVC, you know, rest, you know, how to create data models, I mean, these things are, are patterns that are used throughout the industry in every language. So you can very easily transform over to a dotnet developer if you want to, or a Java developer, or Ruby on Rails, or whatever you want. Because all these technologies support the same core concepts, and a lot of the vast majority of new applications being written or following these concepts, these patterns. So it really opens up a sea of opportunities, even in the job market. Once you know the underlying principles. At that point, it's just a matter of syntax. Right? So you may Yes, you may need to learn.
Michaela Light 58:57
This, of course, you're a polyglot program attorney.
Denny Springle 59:00
Wow. You know, I was like, Well,
Michaela Light 59:03
I know six languages already writings on it's just a matter of different symbols and syntax. It is it is and that some people listening may only know one language minute. That's true. Learning. Yes, I find that I found the second language I learned was, you know, a little harder by the time you got to the third language. Yeah, you're absolutely correct. But the concepts are generally the same. Occasionally languages do stuff and really wacko ways. Sure. Like fourth comes to mind.
Those are a bit I mean, that fun and whatever. But yeah, so and you know, every language has its own little flavor, but I'd say all modern web programming web programming languages more or less functionally equivalent at some Turing machine level, whatever the right way to evaluate this, right. Now, you mentioned recipe API's you know, when I've been to enter the box or CF Summit, a lot of people rave about microservices using REST API's. But I think you have a bit of a different view on those.
Denny Springle 1:00:11
Yeah. So I've been down the micro service route. And the problem with microservices that I found is that they become clunky and numerous, right, so. And that that may have been a simple problem of breaking those down too small. But I've seen that, that over engineering happen a lot, where, you know, they take something and they make it tiny, and Alright, we're gonna get better performance out of this, because it's only doing this. And that's not necessarily always true. And even Amazon has backed out of the whole microservice business, and decided to go back to writing monolithic applications, because they ran into the same kind of issues, right? We've got 500,000, microservices powering this application, and nobody knows all 500,000 of them. And nobody knows how they all work together. And so it becomes, you know, a on paper, microservices sound really good. But in practice, they just become unwieldy really quickly, I think.
Michaela Light 1:01:33
Who don't know what a microservices is, basically, you've encapsulated and made a separate server that's providing this API to other little baby servers. And maybe they're in Docker containers, typically, that consume that microservice. So it's no different than having the API's all in one, one server, except that if one API is being called 1000 times a second, and the other one only three times a second theory would be that you provide more servlets. For the one that's called a lot. Yeah, that's the proposed advantage. Partly, I think, I'm sure there are other advantages I should get my fanatic on to talk about.
Denny Springle 1:02:18
Is, and there, there are some valid points, there were especially having containerized versions, where you can ramp up 1000 containers in, you know, a matter of few seconds to meet whatever demand is, is happening at that moment. So there's some advantage to that. But there's also the advantage, that advantage also exists by you know, having tall servers that you know, are running optimized code as well, right. So you can get the same performance, you can get the same ability to ramp up is just what is
Michaela Light 1:03:04
A tool server? Did I hear that correctly? Ta ll tall.
Denny Springle 1:03:09
A tall server? Yeah, lots of RAM and CPU. And basically, as much resources as you can stick in one box. They call that a tall server in the industry.
Michaela Light 1:03:23
And the other service called height challenge. So
Denny Springle 1:03:28
The one user or the shorties Yes. So it's, I don't know if they call them short servers are not to be honest with you. I just know that, that when discussing concurrency and DevOps kind of things that a lot of the the DevOps guys refer to these very large, very robust servers, just tall servers, because they have stacked as much RAM and CPU power and IO as they can into one server. And yeah, that's the the horizontal scaling piece. And then the vertical scaling is obviously having multiple of those, those horizontally scaled servers.
Michaela Light 1:04:20
I think the, I'm going to add a link to this case study that Amazon and just to be clear, people listening with Amazon Prime, not the whole. They, you know, they had something that was very microservice folks and they moved to a more you know, monolithic type architecture. And I think the other point to give here is that if you're using Adobe ColdFusion I mean, the new Adobe ColdFusion 2023 Oh, FY 2024 Coming next year, they do have like a meter base pricing. So you can have, you know, a bunch of micro bunch of surf little servers, you just pay by the hour use them, but previously, that licensing didn't exist. And then on the tool servers, the licensing that Adobe provides versus Lucy is a little nuts. So you know, it was I think it was written actually in the year 2001. Server with two CPU correlates or whatever they was on, it was unusual. And now how many how many cores the servers have on the call end of things? It's like 32, or maybe 64? Haven't? We're 64. Now so. And so the the Adobe licensing doesn't really translate too well, to that. I mean, you can do the math on it. It's just a bit not so. So often, when you have a virtual private server, you don't even know what the server underneath is.
If you're going through an ISP, that's not your headaches, the ISPs, private headache together with Adobe, and they give them.
Denny Springle 1:06:14
From what I've been hearing, sometimes that can be your problem, too. Oh, really?
Michaela Light 1:06:18
Okay. So if you're using an open source ColdFusion engine like Lucy, that whole issue is that that isn't an issue. There is no licensing cost issue. But I think that may be another factor that people need to take into account when they're looking at a microservice architecture. That's true. What's the cost and legal headache and forget the ColdFusion licensing part. If you have hundreds of Bill servers running just your AWS bill is going to be a little big. You may need to take a mortgage out to be able to afford paying Amazon.
Denny Springle 1:06:57
Well, now we've got a grab Google Cloud, too. So Google Cloud, we've got there's lots of clouds out there.
Michaela Light 1:07:08
I mean, I've even used digital ocean they have they're like 25% of the cost of AWS, they have most of the features I want for a small thing. It's a hobby site or whatever. So I probably shouldn't have said that in public.
Denny Springle 1:07:27
Yeah, I must call that host tech by name, but I decided not to Oh, wait.
Michaela Light 1:07:32
Well, you know, they've had some problems. We all you know, we all go through growing pains, lives, growing pains, or whatever the thing is, yep.
Yeah, I interviewed the folks from x byte, who you know, somewhat run chumley's Fear, host techniques now x, y. I'll put that episode in the show notes for this one, which folks will find on the Terra Tech sign? Sounds good.
I anything else you want to say about refactoring versus rewriting? Before we get to our end of show questions
Denny Springle 1:08:08
That I can think of off the top my head, I may have covered most of the major topics.
Michaela Light 1:08:14
Alright, well, I will recap it for people The answer is refactor. Unless you're 100% 110% sure that you've got the business logic wrapped up. And there's other reasons why a rewrite is, is better, but you're taking a lot higher risk. Doing a rewrite, you have enough risks in any software development activity. So you're really multiplying up risk and you can achieve the same end results. Having easy to maintain modern code by doing a refactor, probably have your business users be happier along the way.
That's the That's the message from our sponsor rewriting. Everyone can do rewrites. We refactors I mean, yeah. We do a lot of refactoring when we mobilize out. So let me ask you why, why in this year, you know, ColdFusion has been out for quite a few years.
Denny Springle 1:09:12
Only one or two. Only one or two? Only one.
Michaela Light 1:09:19
One or two decades, two digits in right. Yeah, I started looking at writing my age and hexadecimal.
Why you proud to use cold fusion, Danny.
Denny Springle 1:09:38
You know, I stumbled upon cold fusion. It was on a desk sitting in a city sitting in a shelf back in the 90s. In a company I was working for we were a Java shop writing a Java application and I I, for some reason, pick that disk up and stuck it in my computer and started reading documentation. And I was like, Oh, well, there's all these tools we need internally for this company that I can write in this. And that's how I got my start. I was actually a systems administrator back that I wasn't even officially a programmer, even though I'd been doing programming most of my adult life. So, you know, I think that today, I'm proud to use ColdFusion, because I have made a significant impact on several businesses. And using utilizing ColdFusion over other languages. And I have Yeah, I do use all languages, Java is my probably my second favorite next to cold fusion. And the reason for that is simple, because I can drop in the Java even inside of cold fusion and get things done a lot quicker. But I think that cold fusion is something that has been around and has stood up against every other language that's been thrown at it. There are features and functionalities that, you know, Lucy primarily, but Adobe followed, that they implement it into the language, there was a big focus over the last several years on actually improving the language making it more modern, giving it the same kind of capabilities as other the other modern language, things like functional functional programming. And then on top of that, ColdFusion adds these handy dandy. You, you know, kind of get out of jail free functionality, right? I mean, to make an HTTP call in Java, you got to open the connection. And you got to mean, there's 13 steps you got to make before you make the HTTP call, right. And coefficient to do it, the CFA CDP in the past have everything you need in it, because I've inside of Java, ultimately, and does all those connection things for you. So it just makes coding a lot easier, especially when you're dealing with web. I think that the capabilities of ColdFusion outweigh any of its drawbacks. There are some that exist. But I think that the rapid application development pieces of it, are really still appealing to me.
Michaela Light 1:12:40
Absolutely.
Denny Springle 1:12:43
Yeah, I mean, I can write an application in ColdFusion, probably. These days, I probably say twice as fast as I can in Java, still, and I've done Java for 20 years, too. So it's just a matter of, again, there's, there's so many convenience functions, and ColdFusion that eliminate those 13 Other steps you have to take. And I think that ColdFusion has only grown, I think the community has only gotten better over the last decade. Fortunately, that's.
Michaela Light 1:13:21
Because you did a lot of internal personal growth journey. With other people improving themselves and being more kind.
Denny Springle 1:13:30
I have, I have tried to teach others along the way. But there I stood on the shoulders of giants. I mean, I had a lot of mentors along the way, too, right. And a lot of those guys are gone now either onto other languages where we're literally gone. But, you know, I, I have tried to, to take what I've learned, not just in terms of the actual technology, but in terms of spreading that knowledge from my mentors and trying to bring that to the rest of the communities as much as possible. Because I think it's important.
Michaela Light 1:14:14
That absolutely got to, you know, pass it on, share it and, and to be honest, just from a selfish point of view you teaching other people helps you really understand what absolutely is even deeper.
Denny Springle 1:14:27
I've had, I've had people ask me to do presentations on things that I had no worldly concept of right, and I'm like, Okay, well, I guess I gotta learn this, which, as you say, has made me a better developer, a more well rounded developer as far as what my understanding is. And I, I'm one of those guys, that
Michaela Light 1:14:50
For other areas of my life, like, hey, you know, give us a presentation on a deadlift at the gym. Right? And it's like, deadlift, how do you need to do.
Denny Springle 1:14:59
Soccer? Yeah, my wife does excellent at this gym, I can't lift the bar off the ground, but she can do awesome at the gym these days. Very proud of her.
Michaela Light 1:15:13
Well, those are great reasons to be proud ColdFusion, I'll just add in one of my own, which is in the last five or 10 years, the ecosystem around ColdFusion, you know, all the tooling loaded pipelines, the box products, it's just thanks to
You know, Luis manhandle autists, and all the other artists, guys. And a lot of people contributing to those open source projects. Really, I think the ecosystem is actually better in ColdFusion, and node or, you know, certainly than PHP. I'm a bit biased, but like, you just look at what tools are available. We've got the best of breed ecosystem tools with ColdFusion. Now, because we shamelessly copy ideas from things we see in other languages, and they go.
Denny Springle 1:16:08
And that's great. And that's how, again, that's that's the ColdFusion developers themselves, expanding their knowledge, and then taking that knowledge, and bringing us tools that expand our knowledge, right. So that's another way of passing it on. And yes, MVC didn't originate in ColdFusion. Oh, didn't originate in ColdFusion. But implementing these patterns, and these techniques are tried and true methods that have been proven in just about everything which, right, so having those capabilities and ColdFusion having the the ecosystem that we have, which has been community driven, right. I mean, I laugh every time I, I go to a keynote for Adobe, and they say, Hey, we've got this great new thing that we're doing right. So what was it 2021? Well, we've made it so that, you know, you don't have to install four gigs on cold fusion in order to get cold fusion? And it's like, Yeah, listen to that, you know,
Michaela Light 1:17:14
Four years ago, five years, whatever our point, competition is great.
Denny Springle 1:17:18
Exactly. And I think that I think that the community has driven, has pushed Adobe to be better.
Michaela Light 1:17:27
And vice versa. And vice versa with Adobe pushes Lucy to be on their toes, too.
Denny Springle 1:17:33
Absolutely. I agree. You know, and I think that that competition is what's brought on and spurred the innovations that we've had over the last five to 10 years in this in this industry, as far as competition goes.
Michaela Light 1:17:53
And, you know, it's not that backstabbing, cutthroat competition. Now,
Denny Springle 1:17:58
Competition is friendly competition. Absolutely.
Michaela Light 1:18:02
And even with our languages, you know, sometimes I know the the Adobe folks, we're going to Java conferences, and I think we all trust folks that you probably do. And other languages, you know, there's many places to learn to share ideas, and also to spread the fact that cold fusion is alive and kicking. And speaking of which, what would it take to make cold fusion more alive this year?
Denny Springle 1:18:30
It would take more developers taking the time to learn some of these techniques, I think I'm, I'm still unfortunately, I still do a lot of hiring for clients. And I'm still running into a lot of developers that have been doing ColdFusion for 20 years, but still haven't picked up on NBC or Oh, or any of these, these patterns that have been there for at least a decade. Right. So I think that what would make the language more alive would be developers taking time to learn these patterns and the spread their love of cold fusion to anyone who will listen. And that's what I've been doing this past several months is spreading my love of cold fusion to anyone that will listen. I think that you know, the the whole cold fusion is dead thing. You know, if you're,
Michaela Light 1:19:32
But yeah, but a coalition is dead thing is dead.
Denny Springle 1:19:35
But if you're in the Java community, Java is dead if you're in the PHP community. That Ruby, right, Ruby, Ruby's has been dead for decades. Right? So it's,
Michaela Light 1:19:46
I think, in the next programming languages launch, they should predate it.
Denny Springle 1:19:53
So this, this notion that alive maybe.
Michaela Light 1:19:55
We can call the language dead dead. Yeah, that's that will be the name But the language is dead ml I
Denny Springle 1:20:03
Made to say any languages that is really ridiculous. Ridiculous, right? There's still,
Michaela Light 1:20:12
I'm not I mean, yes or less use languages but right Deep Mind, which is you might call somewhat dead and for maybe somewhat valid reasons like COBOL, Fortran haven't seen, they don't get, they don't get annual updates like ColdFusion. But they just billions of lines of code written in those languages that's in use. And in the case of COBOL, it runs our whole banking system is run on COBOL. Guys, it is, though maybe like making fun of it perhaps isn't too smart. And, and Fortran is used widely by scientists for scientific modeling. And
You know, I don't want to go off on a political tangent here. But there was some scientific modeling done in the last few years that turned out not to be too accurate. They were doing it in Fortran code. So right wasn't the Fortran code. That was the problem. It was. Right. It was the business logic that had the issue. Yeah. But the point I was trying to make is Fortran is still a useful language and lots of libraries out there for it, because I'm probably slightly biased, because I did learn Fortran when I had my first corporate job programming, right? We, yeah, my first full time job, I had summer jobs before that with other languages, but the pay job was using for trans have a bit of love for it. And you know, when I did a math degree, we use Fortran, for all the, you know, whatever the course was numeric analysis, I guess we call it. So, yeah, so use some of these new features. And I'm just going to give a challenge to everyone listening. What's one small baby step you could take in the next week to learn one of these languages. And, you know, maybe you can find a video on it, if you're into videos where you can Google stuff, or the latest thing is, use one chat GPT or some of these API's, and you just ask it, well, you know, give me a really simple summary of of MVC, and programming and ColdFusion. And it'll give you a lot of great information. And then you can quiz it. And if you don't understand something, and ask him to explain it to you, it's quite world changing technology. So I think you mentioned into the box and you're planning that's the next conference you're going to in 2024. Yes, sir.
Denny Springle 1:22:34
So I hope that I hope to be speaking here again, but But if not, I'm gonna go anyway. Frankly, I'm looking forward to seeing some of my old friends back in the DC metro area, because that's kind of my old stomping ground. But, you know, into the box has always been kind of an intimate setting. And everyone is always very approachable. All the speakers especially are very approachable, you know, even after they've done their presentation. So it's it's always felt like a more like a family gathering to me then then a CF Summit, you know, 400 people kind of conference. I had to be he's always been a little smaller.
Michaela Light 1:23:28
But it's around 100. Yeah. So happening in Washington, DC next year, they moved from Texas.
So they're going to experiment with doing it in downtown Washington, DC. So all East Coast ColdFusion developers, you have no excuse. Now, you might have said well flying to Texas. Well that's like going to a foreign country. And you might have been writing because the brisket barbecue in Texas. But
Now you don't have an excuse flying to Washington DC is super easy. It's right in downtown, you can take the metro from the airport.
And look should be a great event in April 2024. So if you're unable for whatever reason to attend the conference, they publish all the videos from the conference on their CF casts video channel, which is a great learning resource for ColdFusion. And you can pay to have online access to those they have other non into the box videos on there you can get separately so like a Netflix to cold fusion that's got to be careful because you can been what binge watch your way into, into trouble. Yes, but you can search for topics like MVC or rest or might have service wherever and see all the videos on it. And they have some free ones in there too. You don't have to pay money at the beginning if you want to test it out. So I was interviewing the guy who wrote that Peter I'm better at last name. Anyway, I'll
Put the link in the show notes as well. Great. Well, thanks.
For coming on the show. If people want to find you online, one of the best ways to reach out to you refactor.
Denny Springle 1:25:14
I'm not really a big social media guy. So the best way to reach out to me is on LinkedIn. You can find me at Downard sprinkle IV out there. And then GitHub. It's just the the sprinkle. You can find me there and look at my repos and the open source code that I've put out there over the years. That's pretty much the easiest way to get in touch with me these days. I don't I have a Facebook but I don't use it. I have a Twitter but I just kind of don't use that either. I've never really been.
Michaela Light 1:25:52
Again, folks off your radar, the
Denny Springle 1:25:55
Tick Tock I don't even have so yeah, you're right. Tick tock is way off my radar. No Instagram, no Instagram either. So and no only fans. I know everyone's gonna be disappointed in that. But no one was very disappointed.
Michaela Light 1:26:13
Like some very exciting refactoring video on your Yeah, would be an interesting. Great. Well, great. Well, thanks for coming on, Danny. We'll put those in the show [email protected] And I look forward to seeing you again at some future event or on the show. Sounds
Denny Springle 1:26:35
Great. Thank you for having me.
Michaela Light 1:26:42
All right, somewhere I can hit.
More related topcs:
rewrite vs refactor
coldfusion isjson
refactoring vs rewriting
javascript object notation
valid json
data interchange format
