Application modernization: an interview with Ben Wilson

Why this interview?

Companies invest a lot of money in custom software. Not only it costs significant amounts to build such software but it costs even more to maintain it and evolve it during the years. Successful software stay with the company across the decades and soon enough the technical platform used for the original solution become inadequate to face the changed landscape.

So what company should do when they find themselves owning software built with legacy technologies? Start over? This is probably not a good idea, because of all the knowledge they have poured in the system, all the improvements they have done and how well it now serve the users. There is an alternative to starting over: performing application modernization.

Application modernization is a topic not frequently discussed. Many CTOs or Software Architects overlook this possibility and this is a pity because rejuvanate a code base means saving the investment performed and keep extracting value out of it. Because of the importance of this topic we wanted to have a conversation with a well known expert. We were lucky enough to have Ben Wilson from Vaadin accept our invitation. We learned a lot from Ben and we hope you will do the same.

Here there are some quotes I found particularly interesting:

Federico: Hey Ben, thank you very much for taking the time for this call. It’s very nice to meet you. How are you today?

Ben Wilson: I’m fine, and thank you, it’s my pleasure.

Federico: Good. So I think that today we will discuss a very interesting topic, we are talking about application modernization. This is something for which I don’t think there are many resources, so I’m very glad that we can have an expert to give us it’s vision on this topic, and maybe encourage some people to learn more about this. Can you start telling us something about you?

Ben Wilson: Sure. My name is Ben Wilson, and I work at a company called Vaadin, and my role here is migration practice lead. I joined Vaadin about three and a half years ago, and I’ve been working with their different teams here to move some migration and modernization initiatives forward, but before I joined Vaadin I was working for another company called Anubex, that was a company that’s really specialized in application modernization. In total I’ve been working in this domain for over 23 years now, which seems like a long time.

I kinda grew into the application modernization space in phases, and it kinda grew on me the more I learned about it. I guess I started becoming really fascinated by the domain when we had a case for an insurance company. It was back in a time when I was at Anubex. There was an insurance company that had a number of applications running on mainframe system. They had been trying for some time to migrate these applications from the mainframe to a Unix system, and they couldn’t get the proof of concept to work. Their applications had been so optimized for the mainframe architecture, that they were not able to get the performance on Unix to be comparable to what was on the mainframe. They couldn’t find a transformation, so a way of describing in a consistent manner the way that they would be transforming all of their applications in a way that they could still have a number of critical processes to work. It was a real problem for them, and they issued a contest to a number of companies, who can make the workload of the mainframe work as quickly on Unix. There were a number of different companies participating, also Anubex at the time, and we won that contest.

Federico: Congratulations.

Ben Wilson: Thank you. We won the contest, but then we were awarded the contract for actually doing the full migration of the mainframe workload. Our team was able to see everything, from the start to the finish, of collecting the sources, understanding all the different interfaces, how the applications were linked to external users and external companies, and how all of the changes… what we could keep the same and what things we could change, what we had to change in order to make the transformation possible. I was able to see all that. That kinda grew on me, and I’ve been continuing to be active in this space since then. It’s been a focus, really, and I keep seeing companies struggling with the questions. Very often they start initiatives, but it’s not really clear to them how to finish them. I have the sense there’s a lot of work still to be done in this domain, so I kinda sense it as a calling now.

Federico: Definitely, I think it’s a very important topic, because some people don’t realize about the huge value they have in this old codebases, something that they built over decades in some cases, and is crucial for their entire organization, and basically sometimes is trapped in some old technology. If you don’t manage to port it to some technology that is more fitting – the new context, for example – something that you can access from the web, or can run on modern hardware, basically you lose that value, and it’s something that I think most organization can not afford.

Ben Wilson: Yeah, absolutely.

Federico: Good. I wanted to ask what are the reasons to perform framework migration. We already started to touch the subject, but can you list a few of the reasons why you would perform a framework migration?

Ben Wilson: This is the key question in so many cases, it’s how companies justify the investment for undertaking something, because in many situations you start from a situation where there is already an application and this application is already running, so it was already providing value, so the business case to invest even more work to have something that’s basically the same thing, it gets kind of difficult.

There’s a number of reasons, a number of good reasons, actually, for doing a application migration, and I think the problem is that many of these reasons, many of these drivers can be existing at the same time, but these drivers have different business cases. Sometimes these business cases will be in conflict with one another, and I think the easy way of seeing or understanding how these different business cases can be categorized is looking at the degree to which you can quantify them. How easy is to put an actual number on the business case for replacing an existing system that might be working?

On one extreme, there are business cases that are very clear and very easy to quantify, and on the other extreme they can be very… It’s very abstract. I’ll give a few examples. On the extreme where it’s easy to quantify, you have, I think, the technical risk. Technical risk is one of the areas that’s the easiest to quantify, because if an application is running your business, and this application fails for whatever reason, or you can’t use it anymore, then effectively this can end your business. It’s a mission critical system. That’s pretty easy to quantify. You have the cost of what that would mean if the operation would be unable to continue, and then you have a probability for what if something would go wrong.

I think very often what happens is you have a scenario where a vendor will announce, “Okay, sorry, we’re bust. We don’t exist anymore. You can’t get any support from us anymore.” The companies that’s built applications using this technology, they really need to make a risk assessment. Will they continue work, because it actually has been working okay for a long time maybe… and maybe it’s acceptable to take on the risk? But it’s a consideration that they’re going to make. But I think something like this is very easy to quantify, and if you want to take action on it, then the action is going to be really defined in terms of rescuing value from a fire.

I guess if we move away from the really easily quantifiable drivers, then I think TCO would be the next one, on top of technical risk. The total cost of ownership. That’s something that’s quantifiable, definitely, but it’s a bit harder to quantify because the cost is going to be affecting various departments, and the way that you’re going to measure the cost is also going to be varying depending on what department you’re looking at. You can add these things together, but it means you need to talk to more people and you’re not necessarily going to be comparing apples to apples there.

Then it starts getting a bit harder, even harder to quantify, and then you get to things like increasing business agility, so that’s something that’s actually mentioned quite a lot, that businesses want to be able to be competitive, to be able to change, to adapt to changing technological things that are happening. Doing this, measuring agility, I think is pretty hard. Definitely harder than total cost of ownership, but still it happens. Increasing agility, you can see this in a number of ways. There’s the availability of skills: you might find it harder to get skills, that’s one thing that you can try to quantify. It might become more expensive to have interoperability with the systems interoperating with your customers. That’s also a bit harder to quantify than just the costs. And you might have the technical quality of the code itself, that it might be harder to change. You might be spending more time testing than you are actually developing new functionality and stuff. Also definitely business cases can be made around this, but you can see it’s not quite the same… You can’t really compare with the two previous ones.

Then you’ve got, I think, the extreme all the way to hardest to quantify, and that would be trying to cater to users and giving users a modern look and feel, giving them an impression that is modern. I think companies that are selling software, especially ISBs, they would be the most sensitive to this. I don’t know how to quantify that at all. How do you quantify the subjective impression of the user that the interface is modern?

So you can see, a number of things can be taking place at the same time, but what you’re gonna do and the action that you’re going to take, that way that you’re going to try to achieve this modernization, it’s really gonna depend on where you want to see the focus. I think companies struggle with that quite a bit, about making compromises and prioritizing which business cases need to come first.

Federico: Yeah, I think in particular it’s difficult to quantify business agility, also because when you achieve that maybe you start doing things that you were not expecting to do before. Like if you have now the possibility to introduce changes more quickly, you start getting more ideas, you try to experiment more, and maybe you find more opportunities, while before you were not even considering some experiments because, I don’t know, a change was taking one month instead of one day. I think this can change your mentality and have consequences that are very difficult to forecast.

Ben Wilson: It’s hard to tell the future.

Federico: One question that came to my mind while you were talking is, do you feel that sometimes there is resistance from developers to these migrations? Because maybe, you know, I’m working at some company, I spent the last 10 years learning all the details on some framework, so now I have a competitive advantage with respect with my younger colleagues, because I know I’m valuable, because I know all the dirty secrets of this framework, so if you take it away from me I lose some power somehow.

Ben Wilson: I’m sure that’s taken place in some people’s heads, but I think there’s a more positive way of looking at this. It’s that people, if you’re responsible and, you know, if you have a certain competence and you’re responsible, then you’re also comfortable with the risk. You know what risk you’re taking, and you feel more comfortable taking responsibility because you’ve got a clear view on what would be the impact if you change a certain thing or you try something new. Your familiarity is going to let you solve the problem more quickly, and you lose that ability when you’re going to something new. On the competence scale you’re going from what it’s called the unconscious competence to unconscious incompetence. You’re switching all the way from one extreme to the other, and that’s always very difficult to judge, and you lose a lot that way. I totally understand the trepidation of developers there.

Federico: Also because I think that from the point of view of a company, something to consider is that maybe I have a lot of developers that know very well a certain framework, so if I move to something else, at the very least I will have to do some training, I guess, but I could also be forced to maybe hire new persons to take over.

Ben Wilson: Yeah, there were studies around that, around the time of the Y2K problems. Gartner had done a number of studies looking specifically into how long does it take a Cobol programmer, a professional Cobol programmer, to become proficient with Java, and to have the same level of competence, and they came up with figures that it was between three quarters of a year and a full year. Those were the ranges that we were looking at, so it’s quite an investment, and being able to put these people on the bench so that they can acquire these new skills and obtain a professional level of expertise, that’s expensive.

Federico: True. Can we talk about some typical framework migrations that you see? If there is anything typical, but just to make some more concrete for our listeners to understand what can be achieved.

Ben Wilson: Sure, so I’m working in Vaadin for the most. Vaadin is a company that makes a web framework, it’s a framework for developing web applications and PWAs, where you’ve got Java on the back end and you’ve got web components and standards in the browsers, and the Vaadin framework is doing synchronization between the server back end and the client front end, and this is easy for developers. It’s a natural way for developers to develop. It’s very intuitive for Java or JVM developers.

A lot of what we’re seeing is obviously customers migrating to Vaadin. Right now, most of that is being pushed from desktop, where the development paradigm is very close to the development paradigm inside Vaadin. So desktop applications, Swing of course is one of the key examples, and we’re also seeing some interest from companies that have applications that were developed using multi-page web frameworks, so things like JSP and perhaps also JSF. There’s another JSF library, for instance, that is deprecated, and some of these customers are finding their way to us.

But that’s specifically for Vaadin: Vaadin’s not doing mainframe migrations, that’s just a different thing. There’s a lot of that happening still, and actually there are many boutique vendors, or let’s say specialty vendors that are specializing on the very specific 4GL or perhaps even 3GL that might have existed on earlier versions of Windows, so there’s a whole lot happening. Not even to speak of the data migration: of data migration, there’s a lot happening there.

Federico: Maybe more specifically about migrating application from Swing to Vaadin, how much of this process can be automatized, and how much requires manual intervention? What kind of effort we could typically look for?

Ben Wilson: It is normally possible to automate quite a bit. I have to say that our tooling right now is in a prototype stage, so we don’t have a lot of cases where we’ve been able to collect a lot of data for how far can we go, but certainly the specifications that we’ve made so far and the proofs of concept that we’ve been working on, they’ve all been extremely positive. Swing applications are typically composed of a number of layers. You’ve got the MVP or the MVC patterns, applications patterns that people would be using. It’s possible to retain these basic patterns inside Vaadin, so that’s just a really good fit. And of course, being able to have the Java as is, that’s also very useful. You have the same types, you have the same flow, you have the same exception handling, the same APIs.

Federico: If I’m not wrong, you wrote some tutorials on migrating from Swing to Vaadin?

Ben Wilson: Those were colleagues of mine that wrote that, but yes, there are some resources online.

Federico: Okay, so maybe later we could link them in the interview so readers can take a look and get a better feeling.

Here there is the article Migrate a Swing app to the web: use your Java experience to build web apps

Okay, so we talked about framework migration, but you also named the possibility of migrating from one language to another, right? Maybe, in this case, are the reasons to perform these migration different from the one for migrating from one framework to another?

Ben Wilson: I would say a number of these would be the same. So certainly skills availability would be a factor that really counts there. Something else that I think plays a big role is not being open source. So much of development right now is open source, it’s hard for us to actually imagine that there was a time where you had to pay to develop software. These things are still out there, and I think there’s quite a lot of interest to move away from proprietary languages or languages where you have to have a license to use them. Couple that with, let’s say, a mission to migrate an in-house, or say an on premise application that’s running on a server, and you want to move this to a cloud, but you don’t have the licenses to run this on a particular cloud platform, then it makes sense to get rid of the frame, to move away from the proprietary language then. Sometimes the compilers just don’t exist, so it just makes sense.

Federico: For me it was surprising to find out that there are companies that are still migrating from Cobol or RPG to modern languages. I mean, a few years ago I didn’t expect this. Now I’m aware that this is a thing going on.
Okay, now a more specific question is, when you do this language migration, do you typically generate code in the target language, or do you consider other techniques like writing an interpreter?

Ben Wilson: There’s a whole lot of confusion around that topic. It’s very interesting because there are a number of solutions: for instance you mentioned Cobol. There are some tools that are basically source to source translation tools that take Cobol and turn it into C, and C is easy to compile on most platforms, where Cobol is less easy to get a hold of a Cobol compiler on those platforms than it is to get a hold of a C compiler. These sorts of things exist, but when you go and you use a source to source translation tool to help you in a migration, you go from a situation where you have one source that the developer’s maintaining and that you’re also using to compile, to a situation where you now have two sources, and you can choose, there are options. You can either have the developer say, “Okay, I want to continue working in my old language, and let’s convert this every time I want to compile, we’ll do the source to source translation,” or you can say, “Well actually, we don’t have a license to be using this language anymore, or we don’t have the skills to do this language anymore, we need to move across and start maintaining what has been translated through a machine.” That always makes people nervous. The idea that we’ll translate a program from one language to another and then we’re going to ask developers to start maintaining, continuing the maintenance of the translated source code. There’s some people who are really, really against just even the notion of that, but there are some companies that actually do that, and they’re having some success with it. I’d say it’s very easy to imagine a case where something would make a lot of sense: if you’re paying a lot for a compiler today, and you have a huge amount of code, but his code base has become very stable, in other words, you’re not changing it very much, and you’re running into the skills availability problem.

This is a situation where it’s a no-brainer that using a source to source translation tool to achieve a consistent transformation of all of the lines of the existing source code, and having this consistently translated sources being maintained by people who understand the new language, that’s actually a very easy case to make, and there’s quite a number of companies that are having some success with that. I have to say it’s not for everyone. Some people will just say, “No, no we don’t want to ever accept that.” Because if you have a machine translating Cobol into Java, what you’re going to get isn’t really going to be Cobol, and it also isn’t really going to be Java either, so neither a Cobol nor a Java person is going to be totally happy with that. But it’s technically Java, and if you can compile to JVM then you have an application. Then it’s probably easier for you to start… If maintainability is important for you, then you can start gradually removing those parts of the application that are important, and that do change, so that you can focus your modernization efforts there where it makes sense. That’s a mouthful. I know you were asking to do these things… There are cases of both for these things.

As for your question about interpretation, I tend to stay away from interpretation because, that’s a personal preference of mine, most of the interpreters that I’ve seen, they tend to lock you in. They can lock you into the capabilities of the original source,but they also lock you into the capabilities of the source that the interpreter’s implementing, and you don’t have direct access in most cases to the underlying platform, so your modernization abilities are quite limited there. I’m sure there’s someone out there in the world who has found a nice way of making an interpreter where you can achieve this, but I haven’t seen those. Most of what I’ve seen has been this pretty restrictive, so that’s my reflex there.

Federico: Okay. In this translation, typically do you think it’s more difficult to do the transpiler, so the code that transpiles from the original language to the target language, or the runtime supporting this? Because it seems to me sometimes people underestimate the complexity of building the runtime. Maybe on the original platform I have some special form of database that I also need to support in the target platform, and so I need to build a new runtime that is bigger than anticipated.

Ben Wilson: Yeah, that’s a good point. Typically when you’re developing these things, then both of these things are coming into being at the same time. I would say it would really depend on the runtime. Some runtimes are absolutely ridiculously huge, really, really huge, and implementing them, you just never finish. I don’t know how some of these 4GL proprietary frameworks have been implemented, but they’re just really, really rich. There are huge manuals. There are all sorts of flags that you can put when you’re building. There are all sorts of options that you can set, and this could be a really huge work to implement all of this. In some cases I’d say the runtime is more complicated, yeah.

Federico: Okay, so we’ve talked a little bit about modernization projects, and… are there typical migration also in this case? There are typical languages that people are moving away from or moving to?

Ben Wilson: Yeah, in the Java space I’ve been seeing quite a bit of interesting in migrating from Java to Kotlin.

Federico: Our next topic.

Ben Wilson: But aside from that I haven’t seen a lot of movement. Mostly I’m dealing with Java at the moment, and I think most companies with Java skills understand the power, the strength of Java, and definitely the power of the Java Virtual Machine, and also at the same time the new paradigms that are coming out, so some of the new languages and how the Java language doesn’t really fit into some of these different paradigms. I have the impression that certainly from a Java, or existing Java programs are staying put, aside from moving to Kotlin.

Federico: Also by moving from Java to Kotlin we could possibly target the browser and now also the native platform, I mean, given if Kotlin can compile also to these targets, so maybe…could be a side advantage of this.

Ben Wilson: Yeah.

Federico: Let’s talk a little bit about the tools that you are using. Are there any open source tools or other tools that you use as part of your job?

Ben Wilson: Yeah, my budget is zero, so everything is open source, that I’m using at the moment, and there’s actually a number of people that are doing some stuff on the side. I know a colleague of mine is actually using the JavaParser project. I have to deal with some very hairy source code that I have no control over what’s been happening with the source code, and sometimes some very strange things happen in the source code that our customers give me.

For me, I’m using the JDT library inside Eclipse, and that’s helped me because it just lets me sleep well at night, because I know that what the tool is giving me is gonna be the same thing as what the compiler’s gonna give me. The Java language specification is actually a little complicated now. It started as something simple, but now the Java language specification’s 700 pages, something like that. It’s become quite complicated. Even the compiler builders, they don’t always interpret the specification in the same way, and you can still find differences in behavior. I found a number of these back in the Java 6 days, and I had a number of heated conversations on StackOverflow to many people from Eclipse, and the reference compiler builders in javac, so that’s what I’m doing there.

Federico: I thought that I knew Java well, then I started contributing to JavaParser and building the symbol solving stuff. Now I realize that no, there are so many corner cases and things, and part of the language that are still technically supported even if no one is using them that make things even more complex. Probably JDT is more reliable for a lot of things than JavaParser at this stage.

Ben Wilson: It might be. It’s unfortunate because I actually like JavaParser because it’s simple. It doesn’t come with a huge overhead, and it’s not linked to a bunch of libraries. It’s actually pretty simple and the interface is pretty intuitive. I’d say the interface is more intuitive than that of JDT. I hope the people watching this know what JDT is. I just said JDT.

Federico: Yeah, it’s the Java Development Tools. I think it’s basically a compiler framework, part of the Eclipse platform, right?

Ben Wilson: Yes.

Federico: So maybe we will also add some links in the transcript, in case they’re interested. Now I would like to ask you, how did you learn about application modernization? There are any resources or things that people should use to learn?

Ben Wilson: Yeah, I fell into it by accident, actually. My first work in the modernization space was limited to user interfaces, so I was giving some user… some static initializers of screens, applications on different technologies, and I was writing some very simple tools. I wasn’t even using a parser generator. I was just programming in Visual Basic. Going through the lines, understanding what the different lines were, you know, some basic notion of a state machine was sort of in there, and doing some transformations. It’s mostly syntax changing that was happening in there. But I fell into it sort of by accident, and as I sort of grew in the space, I became more interested in some of the more fundamental things, and I think the exercise that taught me the most was probably developing a Java parser of my own using ANTLR, so I created one myself. I found it really fun, but I also realized what were the limits of my understanding of Java. I learned a lot about Java that way, and I also learned that I don’t want to be writing parsers, actually. If there’s a parser available, I want to use the parser that’s available. I don’t want to be inventing the wheel myself on these sorts of things, so I’m very eager now to find the work of other people and integrating that into my own development. That is what I learned. The most interesting experience for me was writing my own parser and just getting hands dirty there.

Federico: Let’s talk about the lesson learned doing application modernization. Do you find that there are typical barriers that make it difficult for organization to use these techniques or maybe make those project fail?

Ben Wilson: Yeah, the barriers to even getting started, that’s going to be the status quo being acceptable. The current applications just work. I think you’ve got the boiling frog syndrome, where you understand that there’s some risk, but as time goes on, the risk increases, but you’ve already developed a tolerance for a little bit of risk. There’ve been some companies that I’ve talked to where they were using specific hardware, and they didn’t have the spare parts for it anymore, so their remaining users of this particular technology, it was a mini computer technology. They had created this union where they would all keep each other updated on the spare parts that they still had, so if some… if a bank, somewhere, had a memory chip that blew out, they would be able to get a replacement by talking to other users. This acceptance of risk is something that’s really real, and that really delays modernizations efforts.

And then we’ve got the fact that these things are generally unprecedented, that companies don’t have experience with that. This is the risk that I think most people are afraid. They’re afraid of trying something really big and really new, so… These are the things that keep current applications in place, I think.

Federico: And also because I think they are not so many advertising this migration projects. I mean, maybe some company internally is using, I don’t know, Cobol, they managed to move to Java, it’s not like they’re publishing blog posts explaining how they did that, so it’s difficult to have the perception that these things are happening, so maybe you feel like you’re the only one doing that.

Ben Wilson: That’s very true.

Federico: You get scared. I know that it’s a bit of a broad question, but do you have any advice to a person doing application modernization? Something that they should pay attention to?

Ben Wilson: Sure, absolutely. I’m seeing quite a few initiatives. I would say most of the time it’s going to be your first time. There are many companies out there that actually do specialize in this and that have seen similar migrations in the past. I think people have the tendency to think that they’re… When they on board developers, they typically have to spend a long time explaining the architecture and the coding conventions and things like that, and there’s a perception that the application is really unique and very different from other applications, and therefore the migration or the modernization of it, even if it’s just a technical exercise, that’s something that’s very difficult to outsource. But actually the opposite is in most cases true.

Companies that specialize in this domain, they can really help quite a lot, especially by saying what sort of technical mappings have happened in the past. What has been successful, what sort of performance problems you might be looking out for, and how to troubleshoot those, especially. These things are really useful. I’d certainly say get an ally. Find a company to help you out there, get some experience on board.

And scope is really important. You have to be very clear about what the scope is. Especially for companies that are migrating core business systems, you’ve got a whole team of people that are involved with keeping these systems running and also developing them. You’ve got the developers, but you’ve also got the backup and restore people, you’ve got the disaster recovery people, you’ve got the networking people and the security people, you’ve got DBAs, DBAs, DBAs. You’ve got a very wide range of specializations, and when a project starts, you’re going to find things that are going to affect different groups of these at the same time, and then there are always these meetings that take place where people try to find out what is going to be the solution. Having a clear scope that’s clear to everyone in the project is super super important because you can never predict who’s going to be in the meeting whenever a problem is going to be resolved.
Something that I’ve found has been very effective has been using mottos. Just very short little sentences that everyone in the team can remember. This is important also because very large application transformation projects, they typically take a long time. They might take a year or two years, especially when a lot of testing needs to happen, so over this long period of time people are going to be joining the project. Maybe people will be joining and people will be leaving the project, but you’ve only done the kickoff once. You’ve only done the kickoff in the beginning, so the kickoff wears off after time, and when you get new people with new ideas coming in, it’s very easy for the original ideas to get lost, so having a motto can be really powerful and can help to keep a project on track even when the team composition is changing. For instance, a motto might be, “If you can do it one to one, do it one to one.” That would be just a simple sort of motto like that, and that’s something that everybody can remember, and it doesn’t really matter if you’re a project manager or a developer or a tester or whatever, you can apply something simple like that to your thinking and you don’t need to wait for a decision or something, you can just apply this motto and move ahead on that basis.

Federico: Making so stuff get more coherent. But you named testing, probably it would be good to have an entire interview on testing this application modernization effort, because sometimes it’s an issue that someone doesn’t have any tests and wants to do these migrations… It’s kind of risky.

Ben Wilson: Absolutely. It’s important when you’re doing a big bang, that you can test cheaply. Being able to test cheaply and test everything cheaply, that’s important for big bangs. We don’t really talk much about big bangs, but big bangs can be useful. There’s some successful big bangs. There’s quite a few.

Federico: Yeah, it seems big users, insurance and banks, big users of mainframe be interested in migrating those days. I would like to talk about this topic for another hour, but we are running out of time, so let’s wrap things up, and I would like to ask you if there’s any interesting thread or any interesting things you’re seeing happening in the future in this field. Anything that you want to share?

Ben Wilson: Here at Vaadin we’re working on a few things, actually. Outside of Vaadin, what I find interesting is the language server protocol. I think there’s interesting possibilities around that. I haven’t actually been able to apply any of these yet, but I’m interested in that. And of course migration to cloud. These are things happening outside of Vaadin.

Within Vaadin we’re doing a number of things that are also kind of interesting. One of the things is the presentation transparency. I kinda made up that word, I’m not sure if that word actually exist. Basically it’s achieving transparency at the presentation layer. One of the tools that we’ve created has been something that we call the MPR. It’s the multi platform runtime, which essentially allows you run two client engines inside a web browser at the same time. If you’re migrating from one, let’s say, client engine to Vaadin, for example, to the latest version of Vaadin, then you can have both engines running at the same time so you can gradually do the switchover, and for the user it’s not visible which engine is being activated at a certain moment in time. That’s been fun to watch and to see that being put into practice.

Of course, doing things like not starting with the source code, but many people have the tendency to start directly with the source code and processing the source code, but we’re also looking at some methods that extract visual trees from running applications, and then trying to build some stuff around the trees that we’ve extracted. That’s also fun to be working on.

Federico: Especially because I guess that a lot of stuff that is built dynamically, I mean if you… It’s sometimes difficult to rebuild from looking at the code, right?

Ben Wilson: Yeah.

Federico: Okay. Finally do you have anything else that you want to add that maybe I should have asked or you want to tell our listener?

Ben Wilson: Yeah, I think the core thing is tested, working code is valuable. See what you can do with it. Don’t write it off. There’s plenty that can be done with it if you’re using a bit of creativity. I guess that’s the main message.

Federico: Good. I’d like to thank you very much for your time, it was super interesting for me, so thank you. Thank you so much.

Ben Wilson: It was my pleasure.

Federico: Okay. Bye.

Ben Wilson: Bye bye.