Read the show notes and download the full episode here.
Michaela Light 0:02
Welcome back to the show. We're going to be talking about modernizing your legacy ColdFusion apps through evolution and not revolution. And we'll explain what that means. Later. I'm here with goosed new, new and who's to say your name right there. He's originally from the Netherlands, but he's living in just outside Brussels in Belgium, has been doing cold fusion for many decades now. An old friend of the CF live podcast, welcome, goosed. Thank you. And he's a full stack web wizard. And he's done lots of projects in Europe, for the European Union Commission, and Adobe and all kinds of cool people. And his company has cooled through that. Through we our north is my is that right? That doesn't quite make sense. You know, maybe we are north. Oh, I see. I shouldn't have put the word through in there. No worries. Got it. So you do customization as a service, you help improve old apps. So we'll talk a bit about your experience with old ColdFusion apps and improving them instead of doing that terrible Arwood rewriting which we're not going to do people, and we'll explain why you shouldn't be doing that later in the show. So welcome boost.
Guust Nieuwenhuis 1:37
Thank you. Thank you for having me.
Michaela Light 1:39
So I think that's the big question. That's the elephant in the room here. Because everyone talks about rewriting apps, right? That's the hot thing to do. That's what the cool kids do. They're like, oh, we'll rewrite it into No, Jas or we'll rewrite it into dotnet, or whatever the latest and coolest cutting bleeding edge technology is they want to rewrite the app. Right? Why shouldn't people rewrite their legacy apps?
Guust Nieuwenhuis 2:07
Well, it's the way you describe it. It's almost like a face you need to go through as a developer. And there are a few, there probably a few phases, there's there's this phase where, where your technology is the best, above everything else. But there's also the space where, where you're, you're like totally convinced that everything should be rewritten. And of course, I went through that one as well. Everybody does. But it's a been a basically, when I started after, after college started working as a developer, immediately, immediately started working with cold fusion. But but let's be honest, even back in 2008, when I started my career in 2008, in a lot of a lot of cold fusion projects, were already considered a lot of legacy projects, especially in cold fusion, maybe not so much in in some of the newer newer technologies, but but they're everywhere. And basically, the reason why we shouldn't rewrite is, is that it's, it's not the solution. And let me explain why. Or maybe, maybe, let's let's, let's maybe dive into why people think it should we write that's that's the most interesting thing. Because what I see a lot is that that people are losing losing my my words here, what I see a lot of people think like the approach it from a feeling they think they need to rewrite. And the there's, there's, there's a really specific reason for that. And that that's the simple, simple fact that it's harder to read code than to write it. That's what a lot of us come come across and discover along along the years reading, especially some somebody else's code. It's already hard to read your own code from two years ago, but especially somebody else's code that's potentially with with a thinking in mind that hasn't crossed your mind. Yet. It's pretty hard to read it and you easily fall into the trap that you think oh, you know what, let's just rewrite this. Because, because I think I can do this better. And it's not so much because you can do it better. It's because it's so hard to recall code. And it's actually it This is a quote coming from from an article written by Joel Spolsky, we'll make sure that we add the link to
Michaela Light 5:09
sit down. Now Joel is a very famous blogger about software development. He's been blogging for 25 years now, I think he writes a lot about best practices. He founded fog bots, co founded Stack Overflow and Trello. He used to work for Microsoft on the Excel team. He's a very clever talent guy, I actually had him as a keynote speaker cfunited back in 2005. So I anytime he says something about software development, I mean, I'm not guaranteeing 100% What he says is right, but chances are 99.5% of the time, he has something intelligent to say,
Guust Nieuwenhuis 5:50
yeah, and he references you reference to it programmers as being at heart architects. And basically, the first thing we want to do whenever we get to a site is just take a bulldozer and just flatten the whole place and start building something new. And ideally, something huge. That's, that's, that's what we what we love to do. We're not so we're not so excited about into incremental revolution, all the tinkering, the improving, that's, that's not on we, as developers love to do the most. And then the result of that is that we basically, we want to throw away the code and start over. And that's yeah, like, like I referenced from his article, it's hard to read code, it's easier to just write code.
Michaela Light 6:48
It may be harder, but we're going to explain why it's better to refactor instead of running into a tell us read just read us that quote of Jolles because
Guust Nieuwenhuis 7:00
it makes it very, very blunt statement in that in that article, and he basically says, and rewriting code from scratch is the single worst strategic mistake that any software company can make. And,
Michaela Light 7:18
and the thing is highlight two things from, first of all, it's a strategic mistake, it's likely to cause serious business problems in a company, it could cause the company to go out of business, if you do it wrong, by rewriting instead of refactoring. And secondly, I just want to point out for anyone listening, who doesn't think they work for a software company, because a lot of ColdFusion developers work for a government agency, or they work for, you know, auto company or a manufacturer or whatever. And they may not be thinking in terms that they're a software company, I think every successful modern company is a software company, because if you don't have good enterprise software, making your business run efficiently and do really cool things, you're gonna be out of business in a few years is a key component of every business these days.
Guust Nieuwenhuis 8:12
Yeah, yeah. And if even if you're, if you're, if you're working in government, for example, it could very well be that your your unit is a software company, for the rest of your organization, maybe not the whole, the whole, whole government body, but you're part of your team and, and that can be as small as one or two people. You're, you're a software company, in essence. And what's what's what's key to all of this is that if we look at things from a pure technical perspective, it could very well be that we're writing and starting over from a blank screen, and just start all over from scratch, that from a technical point of view, it might very well be the perfect solution. But the reality is that it's never a technical decision, whether you do that or not, it's always a business decision. And wait
Michaela Light 9:15
a minute, I'm shocked. You have to have to take business considerations into account when writing software you do every day with people
Guust Nieuwenhuis 9:25
and I you know, like I've got a good example I worked for a company here in Belgium years ago called well I'm not gonna mention names because it doesn't matter what company it is but they had a two products and one of them was a flights, booking engine. They're not then they weren't the big players in the market that actually deal directly with with with the airlines. But what they did is that they set up for all or companies, they set up websites, which people could use to book a flight from Brussels to Rome, for example, from Brussels all the way to, to the east or the west coast of the states. But so they designed those website and they had a booking engine running in the back that had full integration with the engines behind it. Really cool products, written nickelsville. But the way, the way we've seen a lot of projects, spaghetti code, all from frameworks in this, in this case, actually no framework at all. It's been a while, but I don't even think they had an application, don't CFC, for example, none of that. And they had performance issues, they, they tend to fix performance issues by just adding additional servers, that was their philosophies. Luckily, we all know by now that that's a short term solution, and definitely not a long term solution.
Michaela Light 11:08
That's sort of like if you had a leak in your roof, instead of repairing the roof, you throw extra sheets of plastic on top of the roof. And if that doesn't work, you throw another sheet up, eventually you have 10 servers running this code still not performing good.
Guust Nieuwenhuis 11:24
And that that when all went kind of well, and then the story goes, because I must admit that I wasn't sitting in the car. The story goes at after a meeting, the CTO. And CEO had a meeting over at a client's replying complaint about performance, the only performance also their their speed of delivery. And all that they were in the car on the way back and they they blink called shooting for it. And they said it's all it's all cold fusion sold. We need to get rid of cold fusion let's let's rewrite. And story goes. I wanted to service isn't the fault
Michaela Light 12:09
of the CTO because they didn't re architect the app. It wasn't because they didn't hire the best developers? Oh, no, it's the language.
Guust Nieuwenhuis 12:17
It's It's the it's the it's always technology is it? And I must, I must be very clear, I wasn't a car. The story goes that they said, You know what, let's do it in dotnet, one of our developers, he used to do a bit of dotnet. In the past, let's rewrite in dotnet. So they did. When I joined the company as a gold fusion developer to help out they were already rewriting in dotnet. And we were with a team of four ColdFusion developers, we were adding functionality faster to the old system, then they they were able, with a team double or triple our size to catch up on rebuilding the platform. So I think at some point in time, they had spent years on the new platform with a bunch of a group of people, at least two, three, maybe even four times the size of the confusion team. They burned millions that way. And when they were finally done, they ended up in big financial troubles. And, yeah,
Michaela Light 13:36
it does seem to be I've seen this myself, many CIOs I talk to I mean, I can think of a few cases recently that they did a decision to rewrite. You know, maybe applique came because it was some, you know, they'd heard on the grapevine It was a hot language. They thought it was easier to hire developers for it. But it's very hard to make a rewrite successful, and most software projects fail, according to IBM surveys they've done. So there's a big risk in doing a rewrite, that the whole thing fails, and you lose millions of dollars, and you waste years of time, when you could have, you know what happened in that that particular case I'm talking about? They went back to their ColdFusion developers and within three months, not years, three months, they fixed all the issues when they were finally given permission to do that.
Guust Nieuwenhuis 14:32
Indeed, indeed, and that's that that's simply because it's what comes along with those with a lot of those legacy projects. Not all of them, but with a lot of them is that frameworks are outdated. Libraries are versions of libraries are used that are no longer supported. There's there are no tests. There's no documentation. It's, it's not a big surprise in that case that it's hard to maintain a project, it's hard to add new functionality. But if you don't have any tests, if you don't have any documentation, how are you then going to rewrite? Because you've got no idea on, on how to or what to rewrite. And I think if if you have, if you make sure that your project has a framework, which is up to date with current standards, that libraries are supported, and updated regularly, if you if you have, if you have tests, if you have documentation, then it suddenly becomes a lot easier to too many data projects. And then the need for for we writing because it was absolutely. Yeah, that's um,
Michaela Light 16:04
I would, I'd add there is where the documentation, it's not just like technical docs, or database diagrams. Often there's a whole bunch of business logic embedded in the code, but it's not documented as use cases outside of the code. And so when the rewrite team comes, they don't know what the business logic is. And of course, it's impossible to recreate it.
Guust Nieuwenhuis 16:27
And documentation, on the business rules and everything, it doesn't need to be this big document that describes everything in detail. If you if you just keep up with a good ticketing system. And you make sure that everything you do is locked in there. And anytime you make it, you decide to do something, put it in as a comment, and make sure that everything you do is registered registered. Every system nowadays has a good search option. And you basically whenever you need to know something, you just go and search and your your issue your ticketing system, JIRA being the most, the most used in our industry, is is a perfect form of documentation as well. It's a bit harder sometimes to go through but but it's, it's, it's an easy start, just start documenting whatever you do, and you have documentation, because it might very well be that you have some old document lying around from five years ago, when the project was initially started, that describes everything. If nobody kept document up to date, that's not even, that's not even gonna help either.
Michaela Light 17:45
So just just I mean, I don't know if you've been playing with some of these new AI tools like copilot or chat GPT. But I just have a vision that in a few years, there will be a kind of AI assistant that kind of keeps track of all those, you know, updates you put in Jura and creates a wonderful architecture document that's organized for you. And if you want that now, you just need to have a programmer assistant on the team who are a project manager or whatever, who who's that part of their job is to keep that kind of documentation up to date, based on what people have done.
Now, the other issue with legacy code, you know, is often you've got spaghetti code, tell us a bit about that you've probably dealt with a lot of spaghetti.
Guust Nieuwenhuis 18:39
Yeah, well,
Michaela Light 18:41
the problem with spaghetti is
Guust Nieuwenhuis 18:44
it's it's just it's hard to figure out what what happens in the application. It goes everywhere. It's one of the one of the projects that I'm currently using on is actually has no no framework in place. And a framework, it's not the Holy Grail and framework isn't the Holy Grail. But what we see in the project is that there are a lot of includes being made in one file and another file includes another file includes another file, and you just don't know what happens if you make a change somewhere. In one of the files, we basically we do a search or friends. Full Text Search on the codebase is our friend dates, numbers times a date and I just take a file name, put it in search to figure out where it's been used. Luckily, what we see in the project that there is some kind of structure in place which resembles a framework but it isn't but if But if nowadays, if you look at what what frameworks like coldbox, do framework one, they they do a lot with convention over configuration. And that's a way to structure and organize your code so that you actually know what's happening, it's easy to figure out what the flow is. And there's there's nothing wrong with and there's nothing wrong with with a CF include or not at all. But the, you need to make sure that it's easy to figure out and to find where, what is going on, and to be able to follow the path, the lifecycle of your request to through your code. That's, that's, that that's what what spaghetti, that's what, that's why we referenced the spaghetti being completely strangled. And having no idea
Michaela Light 21:00
would be, it would be one thing, if the spaghetti was dry in the packet before you've cooked it. And rods of spaghetti were all organized. But once you cooked it, it's all messed up in and it's hard to follow the logic of the code around the other things that I've seen in legacy code that we've improved, you know, it's often hard to change spaghetti code because you make a change, and then it breaks other stuff. And, you know, it's, it's quite hard to make maintenance changes. There's often poor, in addition to the code not being organized, often with poor naming conventions, you can't immediately tell what a function is going to do, because it's got some wacky name.
Guust Nieuwenhuis 21:41
And the biggest, the biggest danger is scoping, just right variables, variables somewhere in scoped and when you when you decide to change it somewhere else in the system, everything falls apart, because of a variable tell you.
Michaela Light 22:02
I mean, there is there are places for global variables. But generally speaking, it's better to have local variables within a function or CFC. And, you know, it's not going to get overwritten by accident. There. And the other thing related to this, I've seen quite a lot is there's a lot of hard coded special values or magic values, if I call them and you have no idea what they say, you know, What's it supposed to mean? This, this number or, you know, text in there probably has some significance, they could have just put it into a constant write your name.
Guust Nieuwenhuis 22:37
But we do know a day in law is that we use statics in in CFCs. And if we have a CFC that contains anything, if we have an integration with a with a third party system, we bundle everything around that integration into a CFC a lot of functions to do a lot of stuff. And anything which might be magic numbers we put in, we put in static variables, at the top of the CFC and anywhere else in the code, we use the static variables instead of dimension numbers.
Michaela Light 23:16
And code, the code is then self documenting, you have instead of the magic number appearing 20 times in random files that appears one place in wherever you define it application, CFC or some include.
Guust Nieuwenhuis 23:32
It's so much easier to write a two story to read a query somewhere in your code that says select star well don't do select star but select bla bla bla, from files where status equals and then a variable name that says approved instead of equals three. And you because if it says equals three, then you you look at it and you're like, No, anyway, three means. And if it's, if it's if it's really awesome, then you go to the database, and you don't even figure out what three is in the database. could very well be because nobody made the reference table either. Because there's no foreign key to another table that has like one equals open two equals declined three equals approved No, not even that. So yeah. If you run into something like that, well, good luck. Hopefully somewhere in the interface, there is a there is a drop down that has the IDs and the labels next to it.
Michaela Light 24:43
Well, one of the problems I've seen is it may be inconsistent. You know, in one place. The drop down has three values and somewhere else in the code. It has four values they use differently. Anyway, let's not dig into that too much. If so, we talked about why why Shouldn't rewrite a legacy app, we've talked a bit about why legacy apps have issues for performance for maintenance, I will throw in there, you know, also, there's often security issues, because they're using old libraries and old, you know, frameworks and what have you, and they're just not updated. So that's another reason that something needs to be done. Because don't forget, there's not two answers to this question of the spaghetti or legacy app, right? It's not rewrite, or refactor. The third one is do nothing and have even more technical debt accumulate, and pretend that you're the United States government. And you can add another trillion $1.7 trillion on to the national debt and not worry about it. Because that happens in a lot of organizations, they just quote, you know, they they're playing that three blind three monkeys, see, see no evil, hear no evil, speak no evil, and just let the technical debt accumulate and accumulate and pray that some hacker doesn't break into your system?
Guust Nieuwenhuis 26:01
Yeah, yeah. And if you want to be really pessimistic, the question is not whether you're gonna be hacked. It's the question is, When are you going to be hacked? And you just need to be ready for that. And make and that's one of the one of the key reasons why why not to go with that third option, which, which you mentioned, just do nothing? No, no, you have to do something. And, and then, we talked a lot about what not to do, why why not to rewrite from scratch? But I guess people kind of want to know the alternative then and figure out what to do. As an alternate
Michaela Light 26:50
Yeah. So let's talk about how you work with refactoring apps and what the benefit of that is and how I might go about? Yeah.
Guust Nieuwenhuis 27:01
Well, there are different approaches to this. One of them. One of the one of the projects that I always always like to talk about stuff that we did, because it makes it easy to, to still tell the story behind it. And to avoid that it becomes the theory instead of a practical example. But one of the things, one of the projects we work on is a 12 plus years old web application. And when when the company came to us, they said, you know, really cool, it works. And that's, that's the cool thing about a lot of those projects, they actually do their thing, and you're pretty stable. And nothing really goes wrong, especially not after 12 years with not too much new functionality being added and 12 years of bug fixing. That that's really cool. But what they wanted is they wanted a mobile app. And then mobile app consists out of two things, the app, but also a back end API software that integrates with existing system. And then we looked at it and we sat, what we can do is basically change the existing application to have it work and serve that API. Or what if we don't rewrite the existing system, but continue using the database that says, but just put a small application next to it, which is an API endpoint. And that's what we did. We created a separate API for the mobile app and created a mobile app to talk to them. Still, still, yeah, really straightforward. Until Until the point, of course, where some additional changes had to happen to the web application. Still, it's still that old system. But that way, and then you get to a point, which is a bit harder, because you don't want to rewrite it from scratch, like we like we just explained better. But how can you do then make a big impact on the system and add new functionality. And what we decided to do there is that anytime we will touch certain areas of the application because new functionality was necessary. We would evaluate where it might not be a better option to take that part of the application and rewrite, not the whole application at once, but specifically a part of an application. And we base the reason for that rewrite then, was the balance between technical and Business are the technical and the business decision. We wouldn't do a rewrite purely because it'll produce better code. No, we would do it because there is a need for a lot of additional functionality. And therefore, we think that it, it's the right moment that the opportunity to say, okay, but then let's, let's take this opportunity with that new functionality and rewrite that part. The important thing here is that the what the new what the users, the project owner in the users get, when you when you're done, read up rewriting that part, it then they get new functionality, rewriting, but for the sake of rewriting with no edits functionality, has no business value. And that's when that's why we were dispersed, we basically wait for a business value opportunity to take part of the application and say, Okay, let's rewrite. But then you do get a difficult, difficult situation, because in this case, with this project, we decided to rewrite the full tuition code in all tuition. But that's not always the approach you want to take, you might very well say, well, actually, no, I'm sorry, I need to correct myself, we're still using ColdFusion, that we decided to start working with front end frameworks for part of the application. And so what we did at that point, is what we need at that point is a way to integrate the two systems. And that's where that's where we're gonna get really interesting. Because we basically wrote a front end JavaScript application, and we're loading that into the existing application at the spot where we have that that functionality, the need for that functionality. Am I Am I making myself clear or is starting to become old gibberish?
Michaela Light 32:06
No, it makes it makes sense. I mean, I wouldn't use I use the, I mean, a refactor is a small rewrite. It's just a different word. And the analogy I give people, it's sort of like you have a house that you've lived in for years, you're used to it, you've done lots of tweaks and bug fixes to make it comfortable, but you know, this, maybe the roofs leaking, or the windows could do with redoing and the rewrite as you said, is the bulldozer coming in and destroying the foundations destroying the database and all the business logic and whatever and rebuilding a fresh house from scratch. And that takes a lot of delays a lot of money and a lot of risks. That might be a screw up with a refactor you're looking at okay, the kitchen doesn't work quite right let's do a remodel in the kitchen and reorganize things and fit replace the sink that leaks or whatever.
Guust Nieuwenhuis 33:02
And then I was thinking the same same direction I've got two kids in house they're six and eight nowadays. But when my daughter was six now has a totally different interest today that what what her interests will be in six years when she's 12 which is which is becoming a teenager you will have different demands different requirements. This sounds very technical and very wrong but but I'm trying to go to the point that we're talking about software she she will have she will she will prefer a different room. No no Barbie relating around No. Maybe a little less pink and maybe some watercolors and stuff like that. And and then what are you going to do and what is every dad gonna do at that point, that's gonna be renovate the room, not tear down the whole house and build a new house. No, just renovate the room. And maybe two years later, my son turned 16 And once it all into music, and wants to have more room in once you have space in his room to put his drum kit and stuff like that, well then you renovate the room, you're not gonna tear down the whole house and start over again. But that's so and that's yeah, that's what we need to keep in mind. At that point, to continue on that that path. If then suddenly, you want to you want to change from paint to wallpaper. That's that's the ideal moment. And it doesn't mean that you need to change the whole house. From from paper to paint that you can just do it in a single room. And that's what we could do with technology and writing software. As well, if you have a module, a payments module in your application, and you really want to I wouldn't understand it. But you really want to move away from bolts fusion to BHP, for example, you could very well decide to write a new back end in PHP for that module, and continue the rest, we need to, I think big, big software projects over time will eventually all become a mix of different technologies.
Michaela Light 35:36
Well, they already are, that's what a full stack is, right? Yeah, we've already got, you know, SQL Server, or Oracle, or whatever. On the database layer, you've got Cold Fusion Middleware, you've got some JavaScript framework and HTML and CSS on the front end, it already is a mess, Matt, you already know mess, the wrong word is or is a combination of technologies. And that's, that's okay. I think the key thing here is the, you know, to do that successfully, you need to encapsulate the functions. And that's what part of the refactoring can be. And you take a piece of spaghetti for the payment processing, and you stick it all into a set of functions in the CFC. So it's all in one place. It's easy to maintain. And that also comes in something else I think you've talked about before goose, which is microservices, maybe you can tell a bit about talk a bit about encapsulation, and microservices,
Guust Nieuwenhuis 36:27
you need to you need to set a boundary for what you're going to do. That's, that's actually, which, if you want to approach this, there are basically a few steps. First step is you need to decide what the case is business case. Why are we going to review, we write part of the application. And then once you've, once you've got that you need to set a boundary. And that could be for example, to decide. This, for example, say the payment interface that is one part of the application. And at that point, when talking about microservices, we asked for a good a good example for that is a project I've worked on. Think too long, it's been three, four years going up. I think, before, before Corona hit us, I worked on a project, that big Abelton company, really a really cool software company, and they their software is, is helping broadcasters in the TV industry to plan their broadcasting schedule, for example, and their router, especially for American measures. It's a rather small company, maybe to under 250 people, but their software is in use all over the world by all the big public broadcasters, public and private broadcasters. They're what's cool about this, this is that their software is written in small talk. And when I when I started started working with them, I immediately felt the connection. Because if cold fusion is probably the technology that has been declared that the most in the web space, then I'm pretty sure that Smalltalk is the technology that has been declared that the most when it comes to desktop applications, because what they basically have is a desktop application with a back end run inside the network together with a database. But it's an old client server model with with a desktop application. And they they realize it the world is changing. And we we need to look into into the cloud and web and see what we can do with that. And there. So basically, they looked for a business case, which is they looked for a new module to add to their product, a module that was suitable for web, because it's not always the case that a web interface isn't the solution for everything. I'm pretty sure that within their product, there are areas that will benefit from being a client application rather than being web application. It happens. And they clearly so they got the case, declared the boundary. And then the question is how are we basically going to integrate this in our in our system. And this is where you get where you get a little bit into that microservice architecture. That's what they basically decided to make a separate biller database back end, API front end a whole different application next to the existing one. As which is basically a separate service with within a microservice architecture, and then micro stands for the fact that you want to keep those services as a smallest as possible. So that's that's how they created a first module web based next to their product within their within the UI binder offering.
Michaela Light 40:23
So I just want to speak to a few things there. First of all, I am not convinced ColdFusion is the leader in color, you know, this language is dying type threads. I've researched this. They exist for PHP, Ruby on Rails. Basically, any language that's more than about two years old, you start to find threads that the language is dying. And I think this is something the whole development community needs to introspection on. Just because something isn't new, doesn't mean it's dying. No. And there's this shiny object syndrome, you know, they want to play with new toys. And that's fine, you know, but you don't need to beat up on the other languages as dying when they're not necessarily dying. I'm not aware of even the most extreme cases, like COBOL might be said as dying. There's billions of lines of COBOL code running apps at your bank right effing now, and they are maintained and work good. And they're not going to be rewritten in Oh, no, no, no, Jas, because all the business logic is in there. Now, I'm not saying COBOL is a particularly alive language, because we haven't had a new version of COBOL for about 15 years, I think. Whereas ColdFusion gets a new version every two years, or in the case of Lucy every three months that popping out, you know, release candidates and what have you. So that's the first point I'd make on that. And then the second thing for folks who are listening who like micro service, what's that is basically, that instead of having a monolithic app that has everything all in one app, you have several little baby apps. And they do you know, this one deals with this part of the functionality. And this one deals with this. And then if you need to scale up the app, you can have multiple copies, running in containers in Docker in the cloud. For the bits of the app, like if the reporting part of the app doesn't get used much, you might only have one container for that if you've got some other piece of the app that that really gets hit hard. You know, with your travel service, you know, maybe it's the search functionality, and the several worker containers, all providing that functionality. So instead of having to buy lots of extra servers, when you don't really need them, you're only like scaling up the containers that actually get used and then you scale them back down when they're not used. So that's what my that's my maybe you have a different explanation what microservices is.
Guust Nieuwenhuis 42:58
Notice? That's correct. And I think there one other big value that I see is that when you keep your applications smaller, because eventually every micro service is a separate application. If you keep them smaller, they're easier to maintain as well.
Michaela Light 43:19
And if you did make the strategic decision that this particular piece is better written in another way, Oh, yeah. What you can do that and you don't have to see I can't quite explain it, but it's you know, if one room in your house is painted blue, and the other is painted pink, it doesn't matter because they're separate rooms. They're encapsulated. If you have a house that's monolithic, and it's like one enormous warehouse space and all the kids are living together, you then have arguments right?
Guust Nieuwenhuis 43:53
If if we want to continue with with real estate, comparison and imagine your your heart your hobby is photography, photography, and you you like you like to work not with digital but with analog material. I love photography ghosts, and develop your film yourself. Yes. You need a dark room. Well, the dark room isn't going to be painted white. The dark room is broken in a very dark color. So it has a different requirements. And every every room like there, there are tons and tons of example in the house. You probably have some some good or some carpet in your bedroom, but you're not going to create a bathroom with bath and showers with carpet on the floor. So
Michaela Light 44:50
yes, in the shower stall you have carpet on the floor because every room has to have carpets. Yes, that would be a terrible idea.
Guust Nieuwenhuis 44:59
Yeah, But I'm bored. That's what
Michaela Light 45:00
monolithic architectures lead you to doing, you know. Whereas with a micro service, you can specialize and improve and optimize that particular little micro miniapp. Just what it needs. And particularly with with Lucy and ColdFusion. These days, you can I forget what they call it the deployment options where you can say, Look, I'm not using PDF in this instance of ColdFusion, I don't need to load that. And so you can make the footprint of the ColdFusion engine smaller by removing out the modules that you don't need for that microservice. Even though in another microservice era, you need PDF generation because the reporting app
Guust Nieuwenhuis 45:41
that we have, the funny thing is, and this is this is a totally other debate. We're not gonna help today. But in a micro service architecture, how big is your how micro is your service? That's, that's always it's always cool debate. But that depends on again, everything depends on requirements. But one of the things one of my colleagues did recently, we we, in the application have an issue for some reason that we hadn't figured it out yet. Whenever we would import a Excel document, and we read out the content of an Excel document, from time to time, it would take the whole functionality around Excel the whole Excel library down and without, I mean, it's over no excel more in the hole, no more excel in the whole application. And then and so we looked at okay, how are we going to debug this because we there's, there's there's an error message. But it's sometimes, unfortunately, with cold fusion and lucid. It's so weird, an error message deep out into Java code that you don't really, really grab what's going on. So we had a plan, we were going to spend a few days on re implementing a lot of logging to try to figure out what was happening. And then that might call a colleague set. And what if I just write a tiny, very little small node function that we could deploy as a lambda or an Azure function on AWS or Azure, that the only thing it does is receives a file, extracts the data sends the data back. And that's what we ended up doing. Eventually. That's a very tiny, very, very, very tiny, single function microservice. But it results the solution it results problem for us. And, and just just to say that sometimes ColdFusion is not the ideal language to do certain certain things. It has, especially Adobe ColdFusion has very powerful functionality around PDFs. But apparently, there are restrictions with the size, the memory size of your GVM, for example, when you started dealing with large documents and stuff like that, you want to import exports and stuff like that. So in that, in that case, you might be better off with something like note, as an example, it could very well be something else. And this, these microservices, the idea behind it, because let's be clear, you don't need to implement a mark microservice architecture, you could also just borrow borrow some of the principles and the ideas in your application. Like we did with that Excel import example, because the rest of the application is staying, you know,
Michaela Light 48:43
you don't need to read redo the whole app and encapsulate everything you can encapsulate one piece to start with. And it's sort of like, if you have the house, that's the warehouse that all the rooms are combined together, you can now make a little room that is the dark room or a little room that is your daughter's room or your son's drum practice area with the particular requirements that that needs use case for that. And but the rest of the house stays is the warehouse until you're ready to separate out other rooms. But you've still got the thing running the great advantage of this whole approach that you're talking about here to evolve your legacy apps instead of you know, rewriting them is the app keeps on running successfully throughout the world and you're delivering business value continuously during the process. Yeah, yeah,
Guust Nieuwenhuis 49:35
that's that's and then we're going back to the business side of things. But but that's that's what drives it. That's that's what drives the what should drive these changes, not not technology, the business the business should drive it drive that change. And it's funny though, because we've been talking about how to not rewrite I am actually involved in a project where we're gonna rewrite, funnily enough, but it wouldn't surprise you, I guess that the reason why we are going to revive is a business decision is not a technical decision, we were going to profit from the fact that we're going to rewrite for tech ever gonna, and we're so happy to do that, because we will be able to solve a lot of technical problem problems that we have, all at once because we're going to rewrite, the decision to rewrite is coming from a business perspective. Because they, the company actually has multiple applications with overlapping functionality. And they want to, they want to go towards a single application that replace all three, and under, they're gonna, they're gonna start with building a minimum viable product, which is, in the short term, going to replace the smallest of the three application completely, and then end target that at part of the customer base, and then start growing that application. And little by little they have, they will have clients on the older systems that can suddenly migrate to a new one, because they're required functionality in what they require from the application becomes once everything they require becomes available in the new system, they can hop over, and little by little, they're gone a bit. That's that's a business decision, a business case that drives that, that rewrite. And I'm pretty sure that we're not even going to rewrite all functionality, it could very well be that we're gonna just skip parts of it step by step that you mentioned, ality Doesn't your application, have that new thought at one point wouldn't be great, great new users users? And then after two years, you figure it out that nobody's actually using it. Very common. Yeah. And then that's, that, that becomes the code that has security vulnerability. Could be yeah, that's, that's, that's a painful moment. Because Because nobody's using it. And oh, and you still, it doesn't need to be a vulnerability, it could just be a burden. So so taking these opportunities, as well, to minimum, minimize the amount of code you have, have, by cutting some functionality that that's not necessary, any longer is a great, great step to take. Yeah,
Michaela Light 52:45
I mean, one of the common things we see doing legacy ColdFusion code, first of all, is dead wood code that's just never run at all, and can just be removed, you have to identify it and then remove it. The other related issue is a whole bunch of copy and paste code that's so common in spaghetti legacy things. Instead of it being encapsulated in a function, they just replicated the thing and maybe tweaked it a bit. Instead of using parameters with a function, again, it's a maintenance headache and best to get rid of it. The other thing I'll say with the refactoring, you know, if you're going to a microservice or encapsulation strategy, you know, you can kind of do it in a hybrid way, you can have the new app with the microservices. But it can those markers have to be can be used by the original legacy app, right by a bit of refactoring. And you can slowly migrate over the code to be better. And do it that way. Because really, doing a massive multi year project is a recipe for high risk, high cost, disaster, and that's what's best avoided. My view. The other thing that occurred to me while we were talking goosed is that part of the reluctance to refactor is the, what I would call programmer trauma. When you've, you know, there's bad code in there, you don't even want to touch it, because you know, you make bad technical decisions in there. And it's just upsetting to even deal with that piece of code. And the same thing politically, at the CTO level, you know, if you know this technical debt in there, and you know that you haven't updated your ColdFusion engine for three versions, or you didn't update your database or whatever it is. It's kind of almost upsetting to have to deal with It's almost easier to throw it all away and start fresh. But that's not the right business decision to make. Sometimes you've got to take things, decisions that are maybe emotionally harder and better for the business and better for the application.
Guust Nieuwenhuis 54:48
Exactly, exactly.
Michaela Light 54:51
So if people are interested in learning more about refactoring, where would you recommend they learn about this?
Guust Nieuwenhuis 55:01
Ha, good, good. Good question. There are definitely get to two blocks, that there are two guys that write a lot around these topics on their blogs. And those are Eric Evans, and Martin Fowler. Well, we'll uh, we'll make sure that we add the links to the, to the, to the notes. They ride, Eric Evans is the guy, for example, that wrote books on domain driven design, that's a really interesting topic to read into, especially when we're talking about okay, making a, a bounded context of what you're doing to basically create a context and a boundary to what what you're doing. Martin Fowler wrote a lot about the strangler fig pattern, for example, around on topics like anti corruption layer. Two, these are really interesting topics to read into to get a better understanding on how to architect a change like that. And, of course, I'm also going to mention vendor Dell, he, he wrote some some stuff, and I think he was even playing and writing his own library for feature flags. And feature flags are a solution to this as well, when you're rewriting your application, not only when you introduce new functionality, but also when you're replacing functionality and stuff like that. Doing that in a controlled manner with feature flags is is very, very, very useful as well. So those are sort of those are definitely some some references to look up on the web and willing to Yeah,
Michaela Light 56:57
very cool. So if we want to find you online, what are the best ways to do that?
Guust Nieuwenhuis 57:06
Normally, I would say go to my website. But no, it's still out there somewhere. But it hasn't been updated in the last six years, I think. So that's not very recent at all. I'm not really active on Twitter, anymore. That already that was even before you learn to go over. So that has nothing to do with that. No, I think the easiest if you want to reach out to me, LinkedIn, that's the easiest way. Just look me up on LinkedIn. Reach out to me, I am in I'm a member of the CFML slack as well. And I've got it, I've got it open. So if you if you ping me there, if you look for my my account and send me a direct message there. For example. Again, I do get a notification of that. It might take me a few hours to answer because it doesn't come to my attention. But I should I should at some point, get back to you and or just write me an email. Which is which is huge. And we are north.eu but we'll we'll add that to the show notes as well. Instead of me selling a lot
Michaela Light 58:21
to us and ghost I can tell you that listening. I think we are north is pretty easy spell and I think pretty everyone can spell EU. But we'll add it into the show notes along with all of other cool resources. Well, thanks so much for talking about ColdFusion code evolution versus revolution and avoiding rewrite disaster in your organization today.
Guust Nieuwenhuis 58:50
Yeah, thank you for having me. It's been a pleasure.
