Architectural Trade-offs: Pendulum Swings, Outsourcing Cycles and System Design

Hi, Daniel or Dan. So actually on your Dan North website, there is Daniels and usually you are Dan. So are you Daniel or Dan or both? Aha, so I spent an awful lot of time being Dan North. We have two wonderful adopted boys. We adopted them five years apart. When we adopted our first, we decided that we were going to align our surnames. So I've been Dan North for whole life. My wife's surname is Tehrost, my father's Dutch. So we both became Tehrost North for the hyphen and Dan to horse North just sounds odd. So I went with Daniel. So for me, that's a sound strange. So then Tehrost would, I mean, for me, sounds, whether Daniel or Dan, same. But you prefer Daniel these days, right? I prefer them these days. I'm to be fair. I'm like 50 something years into being called Dan. So I get it wrong. Okay, so we'll be able to make some today with Daniel and then. But cliffhanger last time you said J2E is terrible and Java is weird. And I said, this is not my opinion. So we have to discuss that just because. And I also thought about what was it? Kekaku, I think, right? Kekaku, and this is this was also a good one. And what what I think what happens is the Kaisen and Kekaku. So first Kekaku, like big shift happens and then we have incremental incremental improvements. But in software, I think through the incremental improvements, we are going to exaggerate. And then another Kekaku leads to almost the first, almost the same results as the first one. So there's like a circle, like, you know, microservices and monolith, for instance, right? So there was a monolith. They say, no, no, it doesn't work. And it didn't work because people exaggerated. We had a millions of dependency. No one knew what's going on. And they said, okay, now you know, the, the remedy is to have microservices and even Netflix. And, and Uber they exaggerated. They had millions of microservices and didn't knew what's what's what's inside. And then even they reduce it to a to a, I would say, reasonable amount of services. And now we have like a monolith, which is well organized. But I think having something organized is just a good idea. Right? So there, that you don't have to wait 20 years to find out that if we build big software, it has to be structured. So this was what I thought about the entire time, actually. So, yeah, I think what we've got is two separate things that worth teasing apart. You, what I think you're describing, I describe as a pendulum. Okay. And what happens is someone comes up with a position is usually quite extreme. And then we all go chasing after that position. And then we realize that it doesn't work. And then we say, okay, well, what can we do instead? And then we get another extreme. And that comes out effectively that comes out of salesmanship. Right? This is someone says, our microservices will solve all your problems. They tell you rather than looking at cost benefit, we just look at benefit. Okay, we don't look at and for me, it's all trade offs. Okay. So what am I trading off when I take a big lump of code and break it into pieces? I'm gaining if I break it into the right pieces with the right boundaries and the right size. I'm gaining cohesion. Right? Each of those lumps is more cohesive. Each of those lumps might be in domain driven design terms. Each of those lumps might be a bounded context. And within that bounded context, all the languages consistent, all the meaning is consistent. I guess the next boundary context, the language is different. A little familiar with maximal cohesion minimal coupling. Well, this is a thing. So we can talk about a maximal and minimal. But even then there's trade offs. And so we need to understand what we're trading off. So microservices, the monolith is a great one. Insourcing and outsourcing is another one I see a lot. And that tends to swing the pendulum swing for that tends to be a new CIO. Right? Or a new studio comes. Yeah. And they say, we're going to outsource everything. We're going to reduce cost by outsourcing everything to, you know, so near shore or offshore or whatever. And then they outsource everything. And then they discover that when you outsource, you save money and you lose all control over architectural decisions. You lose a lot of quality, but not because foreign developers or whatever offshore developers are less good or less experienced. It's just they're less invested. It's not their stuff. It's stuff they're doing for someone else. It was your stuff you're more invested. And so, you know, so all hang on, you know, we're now getting software quality problems or the change isn't happening fast enough or whatever it is. And we're going to bring it all back in house. We swing it all back in house. And this pendulum swings every three to five years, which is about 10 year of a CIO. Right? And but there's, you know, there are models for looking at exactly this and then making the right tradeoffs. So there's a fantastic model by guy called Neil Nicholison called the purpose alignment model. And it's one of these like, you know, two by two type things, a little quadrant model. And the one access you have business criticality. So how critical something is. And on the other axis is differentiating. So how much it differentiates your product in the market. So examples, non differentiating critical would be things like your payroll email. Right? So no one's going to come and work at Adam Inc. because you've got the best payroll system. But they are lucky to quit if you don't pay them. So unless your product is email, like having working email is really important, but you don't care. And so this is not entirely true. Because what I did, I had workshops on the app on Munich until pandemic, then they became online. But, and I get so many requests for what was it? They wanted a US wanted to pay by credit card. And it is somehow hard, right? So I just for them, I created meetup and event bright, you know, registrations. And just because of the registrations, I got a lot of attendees from US, India and Africa just because of invoicing. With our devoicing feature, right? So I would have less than these actually. And so, and this is why the model is so brilliant is it's not necessarily that email is not differentiating. Yeah, it's whether it's differentiating for you. And it turns out that when you're doing remote training. Yeah. And there's only one Adam. So it's not like you're doing generic training. You're not doing scrum master or whatever you're doing. Adam being like custom brilliant, all of the stuff. Yeah, there's only one if you're doing it. So, so what, so now having stripe or whatever having some in some way opens in you market to you. It is differentiating. Right? Yeah. And so that is something that you then say, you know what I need to find a really good version of that. Yeah. So, so the the the Nikolaisen model, the bonus alignment, it says if it's non differentiating, you don't need to be better than anyone else. You just need parity. Yeah. Right? It just needs to be as good. Right? You know, at least me as good. But that doesn't matter. Yeah. But then if it's your product, like I'm a trade, I do training. If my training material, you know, I don't want to outsource that, like generating my building my material because my class is my product. Right? But I might use a designer to do some of the slideware. I'm not very good at design, but having good catchy slides is going to be differentiating. Yeah. And so, so what it does, it gives you a model for deciding what you should build in house, what you should become really good at. What you should try and just outsource and get someone else to do who's really good at it. And then the bottom left corner, which is always the rubbish corner, right? So the bottom left is non differentiating and non critical. He says, just try and get rid of it. Why are you even doing this? If you're doing an Excel sheet or a bash script or that, we'll just just get rid of it. Yeah. But what I think, if the non differentiating is also appealing, magic happens. So if take a look at Apple, right? So I was, I was an Apple store had some issues with, with my hardware. And I was a bit disappointed about the entire process. I say Apple should handle that better. Not that, you know, that they tried. But the process didn't, for instance, I wanted to order something to the store. It was not possible because they say in Germany's impossible. How come I mean, this is so simple, just do it, right? So why it is not possible. And this was not differentiating. There's not like, you know, you would think first about Apple, but I thought you know, come on. So what's going on? So what's a bit of disappointed because I assumed, you know, because they build great hardware, they will also able, you know, to have more flexible processes. So I think if you, whatever is consumer facing and even not differentiating, but it's great, it, it magic happens then, you know, you become a way better than your competition, I think. Well, and you know, you're absolutely right. And this is the thing is that it is actually genuinely differentiating. There's some great stats about the fact that people are much more likely to say positive things about a brand than negative. Like I just had the most amazing customer experience. Exactly. Because we're surprised. We should be surprised. We are surprised. You know, I went into the, you know, the so and so store. And the thing is, I just I just changed my home broadband. There's a company that's doing it working in London called Community Fire, but I think they're only in London. And I went from paying £50 a month for 150 megabits, so £25 a month getting over a gig of it. Wow. And it just worked. And you know what, the engineer that came was really polite did a fantastic job of cabling, like invisible cabling. You couldn't even see it. And cleared up after himself, motorised, and it was just the most brilliant experience. And I have a loyalty link and I've given it to three people so far and I'm mentioning it on your show. Yeah. Do you know what I mean? Now that, what do I need? I need an engineer. What does he need to do? He actually need to do. He needs to drill a hole in the wall and run some cable through. That's the job. No, no, no, no, no, actually, no, the job is to leave the customer telling people how brilliant the experience was. Yeah, but in the other finish, this would be non-defeatured differentiating. Well, no, this is the point is that the task itself is neither is or isn't. The differentiation piece comes from your business strategy. Exactly. So if you're a business strategy, if you say, as Community Fire, but I want to compete with BT or Sky or whoever does fiber in you. That sort of very narrow view of your product would mean, you're absolutely right, it's done differentiating. But if you say no, my product is customer loyalty. My product anyone can do broad bend, right? We're going to be cheap. That's fine. We can compete on price. What we're going to what we're going to retain people on is they have a brilliant experience with us. And so they've decided that customer experience is part of their product. And therefore anything that's customer facing is differentiating. So they want to own that process. They could outsource it to a bunch of, I know, I bet there are white label, fiber installing companies. I'm sure that thing exists. Yeah. So they're not going to go to them. So business strategy has a direct impact on architecture. And yes. And this is the brilliant insight from the Nikolaisen model is as your business strategy changes. Different things either become or stop being differentiating. Right. So true example. This is UPS, the Mini Brown. They were very much the third by a long way courier in the US. You have FedEx and DHL owned the market and then UPS with these start up. And what you know, and they were competing and they were doing okay. And then what they realized is because they talked to their customers is people are much less worried about when something's going to arrive when they send it as a parcel. Especially, you know, US landmail takes days weeks, right? It's not necessarily a slow process. They're less worried about when the thing arrives. They want to know where it is. There's like a sense of, obviously they don't have any control over that. There's a sense of like, and if I know where it is, I can kind of make plans. And what they did is they took their internal logistic system and they turned it around and put a wide page on it. And then you had a customer portal, which is why all these all these UPS numbers and these incredibly long numbers. Because there are only of us supposed to be used internally, right? But now I can go to the UPS website and I punch in my very long tracking number and it tells me it's stuck in a bonded warehouse somewhere. I don't know what a bonded warehouse even is. But I know where my parcel is. And I know that it's five days away or something, right? And because of that decision, they said, right, we're going to our product isn't moving stuff around. Our product is letting people know where their thing is while we're moving it around. But UPS is more than that. Would I remember a years ago, I met someone who was a huge UPS fan and what he knew is all the tracks. I remember they said they are special brands with special doors and whatever. He knew everything about UPS. And I was, I was this incredible one. Why you bother UPS? But he knew about it and this changed a little bit. So UPS became more less generic. You know what I mean? So now it is no, they don't have at least in Germany, a special tracks. They it is for me actually I prefer DHL over UPS because the the tracking is better, for instance, and then UPS. Yeah, now right now. And but they were far more than the competition, I would say 10 years ago, because of the differentiation, you know, special tracks, special branding, they had a special appealing, not for me, but there are lots of fanboys where really no drawn into the entire UPS brand. Right. And who is a fan of a career? I mean, you say something like a career and a game of Adam. It's exactly the point. So UPS realized that knowing where stuff was was the product. And so they made that available. And then DHL and FedEx then became fast followers and did the same thing. And so now this thing that was differentiating, now just becomes parity. Right. You wouldn't use a career now that couldn't tell you where your stuff is. Yeah. And this is what happens is that one, you know, there'll be a leader, then there'll be fast followers for a some new thing. Every single smartphone in the world looks like an iPhone. Yeah. Right. And has done since 2007. Yeah. And when that first came out, the idea of a full touch screen, you know, without buttons was completely unheard of. Yeah. And it was differentiating full sometime. You know, BlackBerry desperately tried to keep people on buttons on people. Yeah. But eventually they lost. And now every single phone looks the same. And so now we associate smartphone equals rectangular slab. Right. Yes. Yeah. I suspect there'll be a new thing soon. I know Apple's got a folding phone coming out. I know Samsung tried a folding phone. Now they've I think they're ditching it. So I don't know what's going on there. But you know, there will be the next format. And as soon as the next format happens, people will look at the slab phone and go, wow, I can't believe we suffered that for 20 years. Yeah. And this is a thing. So the next thing comes out, it's differentiating. You get fast followers. It becomes parity. And while we're during those cycles, that's when you decide what are they going to build this thing in house because it's our differentiator. Or we're going to now pass it out to a commodity partner who just does that. Apple famously gets all their screens from from Samsung. But maybe not pass to commodity partner, rather than if possible, do something as a service. You know, just not build it. Just use it. Yeah. If you can house us, it to someone for which that is the differentiator. Yeah. Yeah. Exactly. Apple gets all their OLED screens from Samsung because it turns out it's much cheaper to pay Samsung in bulk for screens. And it is to set up your own screen fab plan. Yeah. But but here's another fun twist for decades. Apple computers ran Intel chips. Right. And then Apple a few years ago famously decided they want to go back to the risk kind of system on a chip type architecture. Completely in secret, launched Apple Silicon, the M1s. And you know, I'm still I'm speaking to you now on my M1 max that I bought in 2021. It is still running like a boss. It's my fear old computer. And I have no plans to upgrade it anytime soon. And I can't remember the last time I held on to an Intel machine for more than a couple of years. Same here. So far ahead of the game. Yeah. Yeah. So so but back back to original plot, the car, the car, the car is in is so we have these two things going on. One is the pendulum swing where someone says, let's do X because X is great. Rather than saying let's do X X has all of these great aspects and you're trading off Y. And now we can make an educated assessment of that. We just go chasing after the X and we don't notice the Y. Right. And then the next person comes in and says, oh, microservices are incredibly complicated to observability, to monitor at scale, to manage. Let's go back to structured monoliths and all the monoliths here. We're going to mainframes are incredibly expensive. Let's not have mainframes and terminals. Let's have lots of PCs on everyone's desks. And then now we go to cloud, which is basically mainframes and using AWS using GCP. And you're using this super powered laptop on your desk is basically a dumb terminal. But even in the mainframe era was the same. So I still know some developers, mainframe developers, they do a peel one and I know the largest installation of S 400 and they are extremely happy because maintainable. So and I was curious why and the main feature of that is, you know it, is that the transaction system and the database were in the same memory. So actually, if you try to implement the same with J2E, let's say in my world or Quarkuza, whatever, it would be really hard to do that. And they can handle almost half of the world on one machine, which is incredible. And I And I look at that and I ask me, you know, could we migrate it away? I want to say, but why? If it works and everything, everyone is happy with it. And we talk about patterns, you know, before image after image. What I remember, group sorting lots, so I learned a lot for no sequel, even though from what they did is actually I could apply some of their patterns to to that I'm going to be. And there would actually I'm a surprise that or I'm surprised that there's not not more happens on mainframe because some some architectures could be the right fit, you know, back to mainframe, everything you want memory. So this would be actually the exact opposite of microservices. So, so yes and yes and I feel that you're conflating to things. You're conflating the the OS 400 model with mainframes. You could take the OS 400 architecture of integrating, you know, the brilliant thing it does, one of the brilliant things it does is you don't as you say you don't have the distinction between memory and drive memory and this. You have storage and the OS figures out which of that storage should be durable. Yeah. So you put stuff into the store and the store is durable, right? And the one you scale that is have more OS 400, OS 400 machines, mini computers. Now that system architecture was directly in what's it called in conflicts with the von Neumann model we have memory, store and CPU. Now what we're seeing is and I think it's brilliant actually is we're seeing more alternatives to that. So the whole SOS model system on a chip model where you have memory, you know, compute and store on the same silicon. Yeah. And one. And you have lots and lots and lots of those and that's where that's how the Apple Silicon Model works. That's how risk used to work. But now if you look at say AWS an awful lot of AWS compute happens on SOS nodes and that's becoming a much much more prevalent model. And again, I don't know what the next generation is. I don't know if it's much more of that or if it's if that's a stepping stone on the way to something. But I feel like I'm going to massively agree with your PL1 buddies. I think having having to not consider whether data, the durability of data, right? Having that not to be a concern when I'm solving, computing problems is brilliant, right? And we have to decide. And of course, then what happens with distributed computing, which is, you know, the Java is kind of, I guess, happy place. That's why it's best known is you are then made aware of made responsible for more of those layers of indirection. So you've got memory, you've got hard drive, you've got the network, someone else is memory, someone else is a hard drive. And then you got the coordination between nodes. And I love Martin Thompson. I was quoting him recently, he came up with the term mechanical sympathy. He built the, well, he built the El Max trading exchange in DeFali and their team in Java. Then he would running on a single call. They can be had an overhead of something like 300,000 trades per second. Right. So trade is actually a match. And it's quite complicated algorithm. So it was doing buffer right? How do you get 300,000 matches per second on a call? And he does this whole series of brilliant talks. He basically says, a three gigahertz chip, three gigahertz means three billion goes a second. You've got to be really, really not paying attention to not be able to do stuff with three billion goes. But in terms of that, we're not paying attention. Going to the cash, going to L1 cash is like three goes. Going to memory is 30 goes. And he talks about goes instead of my sort of nanoseconds. And then suddenly it all makes sense. Going to the network is several million goes. Right. And you're like, oh, wow, it's really easy to completely waste away the all my guys. And so the whole point of mechanical sympathy is just good, clean architecture, really simple data structures. And so it's the pack well into a raise, understanding how your L1 L2 cash works, understanding the cost of a cash miss, really simple, understanding your computer architecture all the way down. Right. And understanding your network architecture. And once that's in your head as a developer. And again, Java does this brilliantly. And the JVM does this brilliantly if you lean on it as an architecture. I was writing, I mentioned this before in back in the 2010s. I was writing high frequency trading system. And in Java, and they were like, you know, the C++ folks are going, oh, you'll never make it perform in Java. And we're like, have you seen the JVM? And we had Java based training systems that were outperforming custom C++ training systems or certainly on a part, and we're very, very similar. Because we could do things like pinning the fast algorithm loop to a single core. So we had control of the CPU all the way down. We were writing bytes directly onto the network card memory because we could. Because Java has the APIs for M-MAP for various unsafe functions. And so then we were doing like zero copy trade writing effectively onto the network. And stuff that would have been thought impossible in a VM language. There's garbage collected that's all of those reasons that people used to kick the Java puppy. And it turns out you can get mind boggling performance just by understanding how your system architecture works, how your programming language works, how the VM works. And the fact that it is a spectacular piece of software engineering. This is the problem why I still do Java because the hope was I remember a scholar were around I say, okay, maybe there would be a project where Java is just not scalable enough or whatever and I would have to do reactive programming or scholar or whatever. And never happened actually even the biggest project just JVM and even simple code was enough. This was the stunning part. So we just brought simple business code and it was fast enough. This is the amazing part of Java. And then I started to know to build a simple and simple and simple code, almost trivial code and was still fast enough. And fast enough is the point we could of course optimize what a question is why. So if it's fast enough and understandable, maybe the understandability or maintainability is better than 5% better performance. And in my consulting gigs, if it stopped working was often because of optimization, wrong optimization, no caching pooling was a big one. I remember countless projects where we removed caching and it broke better than without. So we then with caching for instance or object pooling which destroyed garbage collection. So but I have to share a very short story with you. Yeah. I was on a Java gig in a UK bank in the mid 2000s and we picked up some legacy Java code and we were trying to clean it up and it had been written by an army of contractors that had swarmed it and then disappeared. And it was a single, it was a service tier across three kind of legacy stove pipe systems. And the idea was you had a single API or everything and you could figure out where the messages went. And we were trying to simplify this because it was really clunky and we had in this one code base, we found six different implementations of caching, database caching, right? It gets better. It gets better. So I was looking with a guy and I'm going to name check him because he's lovely Alex Harin is his name is and he became known as Alex the deleter. Alex the deleter. I always like him. Cash to cash to cash. Deleting the cash and replacing it with like two lines of EH cash, hibernate, like configuration. And then the pinnacle of this was about 6,000 lines of code of one cash was 6,000 lines of code and we were able to prove that it had never run because it couldn't. It would fail as soon as you ran it. And so we deleted this 6,000 line. We called it the crap cash of all the cash. This is the crap cash. We removed the crap cash and again replaced it with like two lines of EH cash configuration. Maybe this was that project because in one, they had never cash it because the key was wrong. For instance, so this was actually it was verse with caching because we consume memory. And we never had the cash management and none of that you're caching. So it was maybe more like, you know, a history cash. So whatever happened in the project was in the cash, but we never were able to read from the cash. So this was actually. Yeah, yeah. Yeah, we are in the same project. I see already. So and this one, six, maybe not, but two caches or logging. I was in project with multiple logging frameworks. Yeah, yeah. It was logging. Yeah, yeah. Logging configuration and caching because if you hired consultants and they not all consultants were interested in the business logic, so in every project they started with configuration caching and logging. This was the simplest possible thing to do in Java. Yeah. But maybe I don't. think we can cover BDD but we can cover J2E, J2E criticism and you like Java so there will be no discussion but J2E. So just briefly because I started with Java before J2E and the problem I had back then is there were so many competing implementations and servers so I couldn't understand the world so there were like 15 to 20 different application servers back then, persistence power tier, tight stone, gemstone, lots of stones interesting back then. Objects to, yeah and echelon was a thing. Stones were common, weren't they? Yeah, stones were very common. Then the Tenga which became web logic and there was this from eBay, the application server and for me I say this is impossible for me to be to be consultant because they are so different. I cannot just learn 20 products. Then J2E came out and I say that's actually cool because I learned it once and then I know it and this is what happened. The first I ignored EGBs at the beginning because we had serverless and Java being solutions so there in lots of projects so there was pointless in migration, migrating to EGBs but I played with it or played. I had to play with it because I delivered some courses for some micr systems about EGBs which a funny story because my name is Adam Bean and I couldn't believe that I teach Java Bean and Enterprise Java Bean courses. There's no way your name is Bean as I get it is but this is spelled differently but this is not only is that my middle name is Enterprise. Yeah exactly so I should rename myself but lots of fun back then and the first EGB specification was the configuration was like DSL with Java and it was serialized and then in year 2000 there was an evil book from O'Reilly Java and XML and this book changed everything because I remember two months after release of the book in some of my projects they try already to store XML in the relational databases which led to explosion of our storage and then son and all the deployment as cryptos happened which I hated with the EGB jar XML and web XML and J2 XML and I always tried to generate them with X-Doclet which worked somehow it was slow but it worked and then the X-Doclet, Doclets, Java Doclets were more or less one to one translated to annotations with Java 5 and beginning with Java 5 it was 2005 for me it was perfect because the code we wrote back then was a little so in order to have let's say a and this is 2005 this is 21 years for 20 years it is lean before 2005 it was problematic with the XML I really hated and this is why I never got the spring thing before 2005 the spring framework because I'll briefly look at a spring framework back then and it was very usual to have a spring applications with more XML than Java so the XML configuration was longer than Java and I say you are crazy so I don't and what I never got is why they name interface and impulse you know you have to like order order impulse customer service customer service impulse like the naming what do you do if you go to second implementation you will call it impulse two or wimple three or what's the idea right and and I ignored spring and stick with Java and to this day actually this was the best decision ever for me at least because all my projects look like this and if you have let's say a jax arrest and point jax arrest what you have a class with path let's say we had UPS so let's say orders and the orders one method with get and you see your orders of tracking you know your parcels maybe not orders parcels parcels results with path parcels get you have one class one method you are done and then you just say add inject another class and you have two classes and you are done this is basic j2e project right now and this is stable for 20 years so I did some fun talks even I think a j focus by the way I saw you briefly a j focus but because of agenda changes because the victor had to talk before me or whatever I had no time to say hello to you so there was some you know some some agenda changes which affect me so I saw you briefly but I had no time to say hello and I only saw that your talk is very popular and and with that so what I did at j focus I I think I also mentioned at 2014 Java user group meeting where I pulled some code and showed how easy it would be to migrate so the point is it never changed and now it comes the cool story ever the coolest story what I do right now is because the thing didn't change for 20 years and there are so many blogs resources and books llms know it really well so what I can do right now in my projects with three words prompt of three words I can generate almost perfect applications which are very token efficient inference cheap so I would say it is a huge success actually the problem back then was what you said is you know too many consultants who got into j2e they really love it and they used countless patterns and introduced blood without the reason this is was a different problem and another problem was one application server was the web sphere classic which booted for hours you know this is what I didn't understand what what they do maybe they had already an early Bitcoin mining in place or whatever happened during the boot but it was way too slow and I remember in one project we had just to update you know the eGB container with web sphere and this was like one gig they said it is launch is not enough I couldn't even understand one gig of bytecode imagine this is this is incredible and I know glassfish was 60 kilobyte the entire eGB container so so for me j2e great success and I do j2e more or less right now and we save money with it because Quarkus is the fastest and use Quarkus serverless with j2e API and because it is so well known to llms we we have a minimal skill we can you know it is maintainable it is well documented it runs great so this is why I wanted you know this was the cliffhanger from last time and and for me the j2e is like Linux it is boring it is solved so the dependency injection is solved if I need persistent itself if I need you know jax arrest endpoint is solved and I pick a runtime micro node or Quarkus because they are the fastest and we can focus on the different she think bits like you know what my clients would like to have and we forget about the infrastructure there is no discussion we just pick whatever as well documented is solve problem and we are multi-vendor so this is this is my take on yeah well I mean you know clearly we're talking about two different periods of time here so my my beef with j2e is the roughly decade probably less than that seven eight years that I again I was a j2e one person I was late late 90s and I think I mean okay so the the the the bottom line if you like just the the what's it the the tweetable bit or no we're not on touch anymore the the blue skyable blue skyable yeah exactly well I'm on the mass analysis days it is it was and you know and even the folks involved in it well well acknowledge it was vastly overengineered so a bunch of the assumptions in it were that different people different roles yeah okay yeah so you had you know half a dozen of these eight not just they were XML files yeah half a dozen XML files to do one thing yeah I agree within had some you know made a there was this deployer assembler component development yeah yeah yeah yeah and if you were doing all those jobs you basically just had a ton of admin yeah there wasn't a tooling support you know yes yes yeah yeah yeah frenic you know with that yeah so exactly so many many years later the tooling has has matured now at the point where it is now effectively a legacy you know there's yes there are some people writing J2E code but there are many many more people not writing J2E code I think we are writing J2E code without noticing because if you take a look at corkus the entire thing is J2E but no one talks about that as J2 you know well except that is not you know J2E is the standards right the fact that you the faint of it. I'm talking about. about J2E was at the point where you would build your own car. The fact that we now have car, you know, automated car assemblies doesn't make the car any less complicated. It means you don't have to worry about it anymore. I was using J2E U and I were using J2E at the point where you had to worry about every element of that car. - Okay. - And the massive mistake that's sun made, and they made some mistakes. I'm a huge career sun fan boy. My first proper Unix machine out of university was a sun for these little boxes like this, with a vast monitor on top of it. And I couldn't believe that this little box was the server 'cause it was just so powerful. Right, and then they did the pizza box here, and then it did Salaris and all of that. One of the few qualifications I have is I'm a Salaris 2.2 system. - Oh, I'm not dead. So, it would be sad. So, but I was also a huge of Salaris and sun fan. - Uh-huh. But what they did when they published J2E, which was a collaboration between Sun, Oracle, IBM, some other folks, but primarily those three. - Novel. - Was it a novel? - Novel. - Yeah, novel. - It was that they laid out what they called blueprints. And the blueprints kind of were like a market stall of all the things you could do in J2E. And you had your remoteing and your J&I and you had your EJBs and your session beans and entity beans above. and rather than saying here are some popular patterns, use cases they said here is the market stall. The blueprints. And then exactly what you describe, a bunch of folks, while meaning folks believed that the way you were to build three tier software was to have every single one of these things. - Got started, got started. - And I spent years of my life writing, Getset, - Yes. - So, - Periscival D. - Oh, coming back, set, Getset, Getset, Getset, Getset, Getset, Getset, get into this bit. - And there's dozer, you know, dozer, remember dozer, yeah. - Well, so I, when Java 1.3 came out, which had - Dynamic proxy. - Dynamic proxy. Two things happened, one is a Ryan application server happened. Which was, you know, the first application server that said we don't need to do code gen, but it's doVJBC. And I was on the EFnet Java channel, the IRC channel with the, with the, with the our own folks, the. - The IRC, right? - Yeah, yeah, yeah, so Magnus and Carl, and they were just lovely, lovely guys. So they basically a couple of students, but as a college project. - Yeah. - And the hilarious thing is, so the entire download was six megabytes. - Exactly. - And I need a megabyte download. - And the 4J2E stack in it. - Yes. - With user interface. - Yeah, with, with data, with J, with EJBs, with serverless, with, yeah, all that six megs. And it would start in milliseconds. - Yes. - And, and I was writing so my first open source contribution was a thing called XJB. And XJB was a, because web sphere took so long to start. And because we were trying to do TDD with effectively entity beans. What I did was I started with an entity bean, and I tried to compile it and run it, and I got a stack trace. And I basically just started writing code until I no longer had stack traces. And that meant that I could nail, but this thing still exists, XJB. And I'm only running as Java, and EJB 1.2, I think. But, so you could, you could basically, you could write your entity beans, you know, write your descriptors. And then XJB would run it, so you could do TDD on your entity. But once you're happy with it working, you could then plug it into web sphere, and it would probably work. - It's almost like LLM spec then, you know, Eval loops. So until this, you know, - Yeah, no, no, no, no, no. - So 20 years ago. - Yeah, exactly. And this was like, so now I could do, TDD, I could do REPL, effectively development of EJBs. And it sped our team up like enormously, and we were able to do stuff. But then I was on, before I joined ThoughtWorks, this is in the late 90s, I was on a team of contractors. I was a contractor on a team of contractors working for a, it was a vehicle leasing system. And there was something like 30 engineers on this program. And all of us at good contractor rates, all of us could get double time if you came in on a Saturday or Sunday. So what would happen? They'd goof around and then they'd come in on a Saturday. (laughing) Like this. And the whole thing was writing, "Get set, get set, get set." So I sat there one Monday morning. I remember this vividly. And I was like, I bet I could do all of this with, you know, I didn't know about Orion then. I said, I bet I could do all of this with dynamic proxies. So I wrote a basic dynamic proxy. I wrote effectively a skeleton of, right. That would take, you know, just the XML that we had, parse it, there was good stuff for parsing it, XML and Java, pull out what was needed, and do the internal glue. And then it would go straight to the database, didn't need a DTO, get the data, position it into the, the servlet, and then put it on the screen. And I wrote this thing and it was going to save about two days work per, you know, thing. - Yeah. - And it would take two days work down to about 20 minutes work. - Yeah. - And I proposed this to the guys running the program. I said, look, this will make things so much faster. And I went, yeah, we're not gonna use it, right? - Well, we're busy buying our houses. - Yeah, exactly. - I'm busy coding myself in you, Minivan. And then they refused to use this much, much, much. And this to me, this is what flipped a bit. It was so much of J2E, the part of J2E that I have a beef with, so much of it was admin code. It was pointless, zero added value, admin code. - But it was self-made problems, right? It's just like, it was, what you did. - I also did. I never understood the data setter. And to this day, I still see in code reviews, pointless copying, and I say, why are you doing this? Because of decoupling, say, look. - 'Cause it's a best practice. - Best decoupling. - Yeah, but, what I never understood is, okay. But if you have two classes, which are identical, in two packages, and they were always identical, there's no decoupling, right? So if you're copying this always, and you always, you know, keep in sync, or together in the service. - There's more than two. - Yeah, so if you've been, you have the entity being, you have a session being, you have the DTI. - Yeah. - And you have the database schema. - Yeah, you have the query. - Yeah. - And I say, if something changes in the database, and you all in all layers are affected, if all layers are affected, design is wrong, period. So, but if you change the database, in only one class is affected. This is a good place. - So we have decoupling. Ah, super cool. So this is a Java open source programming. Uh-huh. - And this is my signed copy. - Uh-huh. - And one of the authors, Joe Walnes, his buddy. - Huh? - And this, this was the book that introduced, X, doclet, J-unit, web work, hibernate. This was the first time all of these things were kind of brought together. - I also have this book on my shelf. - It's an absolute classic. What year was it? Oh, how about that? One of the authors is my Ken and Brooks. (laughing) This was before. - But regarding entity beings and EGBs, without dynamic proxy, it would really hard to do something different. Because before dynamic proxy, do you know the interfaces at the home and remote and the class, they were implemented that way because of deployment time, code generation happened. - Yes. - And with dynamic proxy, we could skip altogether. We could just have a simple interface and have, you know, adjust proxy patterns, stock, gangle for proxy pattern, implement everything in the proxy, like what I remitted it. So I would say, for that, in 1997, the design was not as bad because it was no other way with stock Java to do something. - Well, I don't know. And this is the thing I stood up. I've never gone back and given myself those constraints to see what I would have come up with. - I've just been interested in this slide. - And just being interesting to me, strikes me as a series of premature levels of interaction, premature seams designed by committee to cover all possible cases, rather than something that you would say, okay, let's take a bunch of use cases, a bunch of genuine use cases, and figure out what the simplest thing would be that would give you exactly what Adam wanted back in the '90s, right? I don't want to have 15 different data stores, yeah. I get that. So the one part of the whole J2E world that made sense to me and that still makes sense to me is JDBC. JDBC was brilliant, continues to be brilliant. - It was part of Java, actually. - Well, I know you're right. You're right, it predates. - J2E, JDBC, J2E, it was part of Java to server edition. - No, just JDK. I think it was in Java. - Yeah. - JDK 11, just Java to see, just Java, just stock Java. - Yeah, yeah, we'll choose J2E, right? So it's the other way called J2E. So yeah, so you're right, JDBC was called Java, which means there is nothing in J2E. That I think was good. - But wait, maybe the definition, what for me, J2E means, or J2E, there is no more J2E. So it was renamed to Java, now it's Jakarta, and Micro profile and Core profile, but I don't care, let's call it J2E [BLANK_AUDIO] And I mean whatever whatever we associate with it What for me is if you go to microprofile I owe there is a core spec if you click on it You will you will find a specs like Dependency injections called CDI Then jux arrest and JPA so with that you can build 80% of enterprise of the already Jason Web token is also there and so what what what what what remains from back then is not the no the deployment Rolls-day were killed in 2005 XML was killed in 2005 so that there's I think no even no mention in the specs anymore Entity beans don't exist anymore. So we have JPA Jax arrest CDI and and bin validation stuff in some some supporting utilities, I would say And now the cool store that the cool part happened is a few years ago Python people wanted to run Java in production For reasons so they have specific reasons and they ask me what they should do and I propose it to take a look at Quarkos and they were confused because if you take a look at Quarkos or micro node They are if you if you read the tutorial That will show you like 20 possibilities, you know, you can be reactive non-reactive You can be you can have you know the the the annotated way or build away or whatever And I say look this is way to complicated and I say why I never read the tutorial And ask me what you are reading and I pointed them to this pack and the beauty of this pack is there's only one way and it's actually readable It's is way more because they don't for all the choices the all the Jakarta microprofit whatever we call them specs they have written really well. This is boring but exact precise You know you can read that and you see the path what to do and if you are done basically so it will work So this is the first Thing which I really appreciate about Jakarta and microprofit as you know the quality of this packs and There is a din d.i.n norm or isonorm. No, no, sorry rfc rfc and this rfc Defines what shell mask node mask ends of fourth. What is the meaning of it? And all these packs were written in normative way and now the cool stories because they were always opened All elements were trained on the specs So and this is what I do is now I'm grounding the LLMs to these packs You say you are only allowed to generate jacks or escort and The the LLMs generate with a very short prompt, you know Beautiful code because they were trained on the patterns and so forth and they don't know by the way The your your your time with the with the deployment roles and XML. This is maybe two It disappeared from the internet god bless. So we have only the newer stuff and the newer stuff is is actually The problem with me I was always freelancer and as you I had to fight against you know huge consulting Companies and try to explain that I don't understand why we map everything 20 times and Ruby on the rise Just you know realize on a table and they say convention of a configuration and this is the truth within the in the database And they are happy with it and why we have to copy 20 times and and this was my Agmentation by I sometimes lost because you know I was a freelancer and have to fight against a huge not thought works but thought works similar companies, I would say right yeah, yeah and And and now Because it was written in normative way and LLMs were trained on it We can be very token efficient and the inference is cheap and this is huge success So so really what we're agreeing on is that the the enterprise Java specification is great if you're a machine But yes calls people to have to act like machines in order to generate all of the craft that goes with Basically getting worked on yeah Push that craft far enough down the stack the things like corkers, which is brilliant Yeah, and and actually this bringing this full circle. This is another one of those pendulum conversations Yes, you started at the end late 90s with this big smorgasbord mess of remoteing options of date of durability of data store options of and then Some very heavy weight Organizations with a lot of vested interests came out with the most over-engineered way you could possibly do it But it was the one true massively over-engineered way and then that you know that the the pendulum swings that way and then spring came out The original spring was how simple could we make this? And then that grew you know fangs and teeth and whatever else, but you know the original core spring What was very tiny? You know where those I was at thought works when they were doing you know when Paul Hammond and Joe Wands and that's like Helicine whatever we're doing there in the original Pico containers and nano containers and a version of control and And some of the ideas that then ended up being the annotation piece of spring and And so That there was a desire to rein this thing back in and then it goes fine But the other way became too simplistic, you know You're trying to find the simple essence in the middle, but it swings by being whilst the over-engineered or too simplistic to get work done Then everyone has to reinvent and then you get them Yeah, because of the methods right there is some some and you know The Hollywood principal and inversion of control and everything has to be a Hollywood principal Inversion of control and then you go too far too extreme and I think in software engineering if something is extremely suspicious You know is this always it is it is always a How to call it a compromise, you know because well and it comes back I don't think it's even a compromise, but it is a trade-off. Yeah, straight-off And that's that's the thing is to and if you understand what it is you're losing in order to gain the thing Then you can make intelligent choices you can make informed choices and I think a huge amount is exactly the same with all the llm hype and grifter whatever I'm right now. I'm using Claude code, you know other lm's are available. I'm using Claude Very effectively to help me do a bunch of things, right? I'm not using it in nearly the way that the hype circus would have me use it. It's not running my life I don't believe it will replace any junior developers. I'm very happy out there renting about this. Yeah, you are junior year still here, right sir Right And we need more of them So so I think You know again and unfortunately there's a trillion dollars worth of marketing Budget telling you that you have to use these things But when when the dust settles and it'll be ice my prediction if we if you're allowed to make predictions It was within the next year or so. There will be a huge resettling You know reset of expectations and we'll realize that these tools are useful in a bunch of situations Terrible in a bunch of other situations um a reasonable compromise in yet other situations, you know and and as of all these things The best products are the ones that help people work better rather than attempt to replace them and the the parts where LLM's AI Gen AI will help people work better those are the products that are going to win. Yes And regarding pendulum I have to admit Similar story to spring because back then it was so much XML so I ignore it Similar story to python is a java started Python was not well not very popular among Java developers And I had no chance to use it actually so I I understand a little bit python but I never wrote I think a Align of python code I and Recently or it happened several times. So there was a some python code and we had to run in production And I say before with my half knowledge. I will extend it to run it Let's migrate to java 25 And the last thing is actually last week and I posted on my LinkedIn Did the screenshots of it and to my surprise The java 25 migration of the thing Was To this day always shorter and now it comes shorter could be but I could just use java 25 without external dependencies and all the python Examples needed external dependencies. So I was surprised by that. I thought with python Will be simpler than java maybe java's more robust and types or whatever But the python would be simpler to understand and shorter. It was never the case So the last case is which is a con launcher for for inference and the java was I think I remember 30% shorter No external dependencies Python was longer with external dependencies and I think okay, what's going on? And I try you know I've read lots of java 25 scripts because you can a share bank with java. I can just run it And I understand java wells. I'm fast with it. So actually for me is no issue to read a file transform a file is like one liner And all you know whatever I ported migrated is shorter So there's also interesting part and I even have a repository with maybe 20 30 scripts already For instance recently what I did I created a command line utility which searches for java doc Class I can say shrink it searches for the string in java doc on my local disk Opens the browser and copies to clipboard the link. So with I say if you know minutes or seconds every time and and in java it is maybe 10 lines of code or or or or 30 lines of code with usage notes and so forth. And it's also stunning that that is possible. I even I believe that Python is way simpler than Java because everything is simple and Java is bloated and it is not the case. Right. So this is also interesting. And I send you maybe a link you can you can you can look at this and my scripts even exaggerated because they are in color and I have you know input validations. But if you live it off, live it off is like a five to ten with Java streams or whatever it is it is actually for a Java developer very easy to read. And last time. So I have to invite you back because actually today I wanted to talk about BDD. This was this was my idea you know with you because you are the BDD master but it didn't happen but we clarified the J2E stuff and also as a cliffhanger what I wanted to mention but I didn't want it to interrupt you that the outsourcing the problem of outsourcing and specifying what you would like to do to an external team is very similar to working with LLMs because you need these specifications in the hope that LLM would generate this specification and back then we had the same problem because we had to know to create a specification in order that the remote team will implement that. Yeah. And similar challenges this is one I may be next time. So here's the thing that's not how I use LLMs. No, not a problem. My usage of LLM is much more iterative. Yes. Because I don't know where I'm going yet and that's the same way I work with developers. This is also what I do. And if I work with an outsourcing partner it's not one shot. It's not here's a specification. And this is what company is trying to do and this is now what everyone is talking about. It's not like we should do this. It's more like we have the same problem because back then I was hired by a TV station and what I wanted to do is they asked me how to specify how to write a specification so that can be implemented by external team and what we find out is that the effort to create such a specification is maybe the same as implementing this in-house. So this was the outcome of that. And having a no-strict specification spec driven is maybe the same. But we don't have to talk about it but we have to talk about BDD. I feel like that's a conversation for another day. Perfect. Thank you a lot. Where people can find you? Hi are you? And yeah. Easiest place to find me, goldwoods.co is my consulting website. So goldwoods as in towards a goal dot c o. I'm on LinkedIn as Tastopod, Daniel Tehrhausnorth. I'm very easy to find. Yes, I am. I'm actually wide open at the moment. So I'm very happy to talk to folks about consulting work. I run some my own training classes. If you look gold was like how you slash training you'll find it there. What training classes are about what? So three-ish themes. One is general software development. So how do we write software better? I guess the way I describe it is my classes aren't for beginners. For folks who've been around the block and they're like they must be more to it than this. They tend to be mid career sort of senior type folks who have opinions, who want to have them challenged. I don't want to be in my classes on transmit. That's boring for me. I want to have Adam in my class so we can riff a bit and argue and both learn from each other. That's how my classes work. I then have a testing class which kind of grew out of that as a specific subset if you like. Which is not again, it's not for testers. It's for software teams about testing. So it looks at testability. It looks at a design for testability. What makes good automated tests. Obviously there's a BDD segment because people expect to be in the segment and it's the thing I like to talk about. Next up I will tell you why I hated BDD. So maybe this is the good DDD. Oh, I'm not a class singer. I would hate what. Do you know what it may well be for the same reason? I hate how a lot of people do BDD. Okay, this could be. This is actually taking my name. It's being quite aligned on this but I'm going to write my answer in an envelope for next time. Exactly. So you have software engineering testing. This is your training. Yeah, and then more of a kind of leadership type management. So I spent a lot of my time these days working at organization level. So yes, you know, we can look at the code. We can look at how the teams are writing the code. But then how do we structure teams of teams? Like some problems are what I call wide problems. You know, this is the wide problem, an 80 person wide problem. Business strategy. This is where you know what about the business strategy, right? So decisions. Yeah, exactly. So a lot of things that look like 80 person problems are really 10 person problems but they've blown out of proportion. Some problems are genuinely wide, right? You genuinely want teams of teams. How given those problems? How do you structure those folks? How do you get them? So they're not tripping over each other. So you're not in low to circular dependencies and say people can have fun. People can work well and enjoy what they're doing and see the results of their work. So I do a lot of working with C suite with local L1L2 kind of the folks that report into your CXOs. And then looking at programs of work. How do we structure programs? How do we structure portfolios of work? And to me, it's all the same, right? It's all it's optimizing. How do I make the organization go faster? How do I make the code go faster? How do I help the teams work better? Is all just kind of the same thing at different different scales? Are they in person or online? So all of my training so far is in person. I've always been too much of a coward to do online training. I'm looking at that right now, fun enough. But I find the types of training I do work better when everyone's in a room and we can really kind of get into some little discussion. And where is it in London? So I'm in London. I travel basically anywhere in Europe, non-US at the moment. I'm a little bit worried about flying that way. But yeah, so I do, I've done a lot in Germany, in Scandinavia, in Northern Europe, Western Europe. I've been out to, I was working with a client in the Baltics earlier last year. So I'm pan-Europe or UK and I'm in Paris. I'm in Paris that the whole thing happened. The thing is I'm in my 50s. I've spent my whole life being European. I've identified as European before I identified British. And then 10 years ago they ripped that away from underneath me. I'm cross-addom. I'm cross. Super cool. Hopefully a lot of people will sign up to your courses. Next fantastic. Yeah, hit me up. Yeah. And what was the URL of your courses? Do you have a dedicated one test-aport, you say? So go to the goldwoods.co website, the training is on there. Generally what I do is I bring it in-house. I'm doing, I don't do much public training. So it's generally it's in-house. It's 20, 25, 30 people, that sort of stuff. Yeah, cool. Couple of days. And yeah, we get into some really many stuff. Super cool. And see you next time with BDD. Hopefully. That's exactly what I want to do today. So thank you a lot. And thank you. Thanks Adam.