The Modern .NET Show

S08E19 - Simplicity First: Why Complexity Is Not Sophistication with Chris Woodruff

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S08E19 - Simplicity First: Why Complexity Is Not Sophistication with Chris Woodruff
The Modern .NET Show

S08E19 - Simplicity First: Why Complexity Is Not Sophistication with Chris Woodruff

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In this episode, Chris Woodruff joins Jamie to discuss his upcoming book on simplicity-first software architecture — a philosophy distilled from over 30 years of professional development experience.

Chris argues that complexity is too often mistaken for sophistication, and that the industry has drifted into “resume-driven development”: choosing patterns like microservices for career reasons rather than technical ones. He introduces three practical filters that any team can apply:

Along the way, Jamie and Chris dig into the economics and sustainability of simpler architectures, why Amazon Prime Video moved back to a monolith and cut costs by 90%, how AI tools amplify complexity by defaulting to React with hundreds of dependencies, and why ASP.NET Razor Pages with HTMX can serve the vast majority of web applications without the SPA tax.

Whether you’re an architect, a senior engineer, or someone wondering why your cloud bill keeps growing, this conversation is a reminder that complexity is a budget — and once you spend it, you don’t get it back.

Episode Transcription

A lot of people go to conferences and they do conference-driven development. They come back with all these great ideas. And you know what? I’m guilty. I speak at conferences and I give lots of ideas. But they’re ideas and you don’t have to take every idea and apply it when you get back to the office.

- Chris Woodruff

Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I’m your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.

Today, we’re joined by Chris Woodruff to talk simplicity, which is his overarching philosophy when it comes to working with code; whether that’s developing, architecting, or interacting with decision makers: simplicity matters.

Simplicity also reflects in cost. Because I’ve found all these studies that say that most companies that start putting solutions out on the cloud pay a lot more than they should.

- Chris Woodruff

Along the way, we talked about how simplicity goes further than the code we write and into how we choose to host our applications, either in the cloud or on prem. Arguably, most of the time, an application which has a simpler architecture will be cheaper to host.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : Chris, welcome to the show. It’s going to be a fantastic episode. Well, there are always fantastic episodes, but I’m going to have a whole bunch of fun talking with you today because it’s something that I’m really, really passionate about. It’s right up there with secure by default for me, and we can shift into that as well later on if you want. Welcome to the show.

Chris : Thank you. Thank you, Jamie. I’ve listened to your show for many years, before the name change, and I’ve always enjoyed you and the guests that you have on.

Jamie : Oh, thank you very much, Chris. So I guess before we get to what we’re going to talk about — folks will have seen the episode title and they’ll be guessing, but I try to make it a bit clickbaity, so who knows — before we get to all of that, would you mind giving the folks listening in a little taste of who Chris is and that kind of stuff?

Chris : Yeah, so most people may know me as Woody. I grew up in the seventies and eighties and there were lots of Chrises because of Winnie the Pooh. I think we had about twelve Chrises in our little friend group, so one person got to be Chris and the other ones got nicknames. So everyone just calls me Woody.

I think I’m one of the old men of the community. I’ve got lots of grey hair. Well, I have no hair now, but I have grey in my beard, so it must mean I’m old. I’ve been doing software development professionally for over 30 years now, and for fun for almost forty-five years. So it goes way back.

I’ve done a little bit of everything in my career: developer, architect, databases, developer advocacy, training, content creation, sales. I’ve been on the dark side with sales. But yeah, that’s a little bit about me.

Jamie : Wow, okay. So you’ve literally done it all. You’ve seen all of the effects and side effects of the work that we do.

Chris : Yes, I have worked at every type of company that you can think of, also consulting to small to very large. Yes.

Jamie : Wow. So I work as a — I guess consultant or contractor is the thing that I do. I always get confused as to which one of the two it is, because depending on where you are in the world it’s a slightly different word. Most of my clients, and most of my employers back when I was an employee of other companies, were really big companies. So I’ve never really seen the really small companies until very recently, when I started doing some work for a very, very scrappy startup.

Folks, you’ll need to get lots of experience of different sized companies. I have to say you’re right there, Chris. Everyone needs all of that experience.

Chris : Yes, yes, they do. They need to have that, especially just to know how to adapt to different situations, different teams, and different environments. It’s a long and winding road, as Paul McCartney would say. Indeed, indeed.

Jamie : I totally get your point about lots of different experience with different teams, because in the part of software development that I’m in, where I’m jumping between projects and teams every year or two, I feel like I have grown so much just by looking at how other teams do stuff.

Because I’m the expert in my own experience, I don’t know whether this maps to everyone else’s experience. But we as an industry assume that we have a whole bunch of rules and best practices, and we assume that everybody just implements them the exact same way. Let me tell you, folks, nobody does, right?

Chris : No. They shouldn’t be best practices. They should probably be better practices — I call them better practices, because your best practices for you might be horrible practices for someone else. Now, I would probably say that, Jamie, your best practices probably should be everyone’s best practices, because you have a lot of good experience.

Jamie : That’s very kind.

Chris : But yeah, experiences are just that — experiences — and we have to try to take a look at other people’s perspectives in the work that we do.

Jamie : We absolutely do. It is vital that we look at other people’s experience. I suppose it fits really well with what we’re about to talk about. I keep teasing it, but what we’re about to talk about —

Chris : Yeah.

Jamie : You can’t adopt a better, as you said, practice without keeping it simple. I think that’s the key thing there, right?

Chris : I was thinking about this and thinking about my career, and usually everyone tracks this way. In the beginning of our careers we try to do things simply, because we’re trying to understand everything. As we understand things more and more, or think we understand things more and more, our solutions get more complex, our thinking gets more complex, and we cause a lot of complexity in our work.

Then, as we transition to being seasoned, as I say, or very experienced developers, we see the error of our ways. We come back to trying to make things simple. I’m at this point in my career where I’ve been looking back on 30 years and I just said, I made a lot of mistakes.

For the past couple of years, I’ve been really thinking about this, and I said, I’m going to document some of this. I just got done publishing a book with some friends on developer relations patterns, and I talked to the book editor and said, I’ve got this idea about a book and it’s about simplicity first. They were like, okay, let’s do it. I was like, okay, I guess it resonated with the editors. So we’re going to have a book out probably in the late summer, early autumn.

Jamie : Right. So is that separate to the dev advocacy, dev relations stuff? That’s a separate book?

Chris : It’s a separate book.

Jamie : Right, okay.

Chris : Yeah, the book that just came out is around developer relations and the patterns in that, which is a whole different story. But this new book is all around — I call it a software architecture philosophy book. There is some code in it, but most of it is philosophy and trying to get people to think about solutions in simplistic ways.

Some people think simple means not valuable, but I try to challenge people to say simplicity just means you try to have — I have three filters that I try to apply to solutions, and we can talk about those as we go on, Jamie — but I just try to make solutions that people can understand. If you can explain a solution in ten to fifteen minutes and someone else can understand it, I think it’s simple enough to implement. If it takes a week to explain a solution or a project, you’re in a bad spot, especially if you’re at the starting point or in the beginning of it.

Jamie : I agree a thousand percent. There are two quotes I’m going to hit you with — we’ll hit the listener with. One of them I think is attributed to Einstein. It was: make the explanation as simple as possible and no simpler. Or something along those lines, right?

Chris : Yep, I love that quote. I use that quote a lot. What was the other quote? I’m sorry, you said you had two.

Jamie : No, no, it’s not a problem. The other one comes from a Terry Pratchett novel, one of the many Discworld novels, in his description of one of the characters, Carrot Ironfoundersson. He’s a human but grew up with dwarfs, and so his name is descriptive — he looks like a carrot, he’s tall and wide at the top and thin at the bottom. The description of him is: people often found Carrot to be simple, but they also often confused simple with stupid.

I think personally a lot of people confuse making something simple with making something stupid. That is completely the opposite, like you’re saying, right? If you can explain it on the back of a napkin in an elevator ride, or in less time than it takes to drink a coffee — what was the character’s name? Charlie in Always Sunny. If you need a pegboard with a thousand photographs, you’ve probably overcomplicated it.

Especially since I feel like 90% of the applications we build — yes, we might add the complications of things like microservices and sharded databases, but 90% of the applications we build are forms over data. Get some data out of a database, show it to the user or to the consumer of the API, let the user or consumer of the API tell you what needs to be updated, and then put the data back in the database. That’s it, right?

Chris : Yep. Now, there might be AI thrown in there a little bit here and there, but I totally agree. I saw so many times where people would get in meetings and have these demonstrations or discussions, and they would talk in big words and make things very complicated. Sometimes it actually was a benefit for them, sadly. They would get in these rooms and make everything sound so great and grand, and the people who were paying for it — either senior leadership in their company, or clients, or stakeholders — would be like, wow. They would just be overjoyed by the big picture and complexity, and so many things that they couldn’t understand. That is the worst thing.

Complexity is not sophistication. What we have to realise — and you hit it on the head — is simple does not mean it’s dumb or stupid or not worth our time. It just means that it’s a simple way of dealing with something. I always said that the best tool, and the most simple tool, sometimes is just a pencil and a piece of paper. You don’t need a mobile phone and an app sometimes. All that you need sometimes is a piece of paper. If you’re writing down notes, why do your notes have to go into a computer? I write my notes on paper and then I’ll go back, read them, and put them into something like Notion or some other tool.

We have this idea that we have to start everything in a complex manner. I’m going to say many things that will probably make your listeners mad. But here’s the first thing — you hit on a keyword that triggers me: microservices. Microservices are not a default starting point. They are a destination point. They’re not where you start. You start with something simpler.

I always say if you’re really thinking about microservices, take a look at domain-driven development and look at the modular monolithic architecture idea, because that will give you 80% of what you’re trying to do with your microservices, without the complexity of microservices. I don’t mean just by code — I mean by deployment, testing, maintainability. So when I say simplicity first, it’s not code, it’s the entire process of software development.

That’s the first thing that I’ve probably really upset your listeners with, the ones who think that microservices are the be-all and end-all. Even the person who coined the term microservices — I cannot remember his name — but he came up with the idea in about 2006, and by 2012 he was telling people that they didn’t have to use microservices, that those were special cases only, and it wasn’t a blanket for everything.

Jamie : Yeah, wasn’t it Martin Fowler?

Chris : No, it wasn’t Martin Fowler. Martin Fowler did a lot of essays around microservices, but it was another gentleman, a friend of his, who came up with the original idea. Martin had lots of — I think Martin changed his views over the years on microservices, just like everyone. It’s a tool. It should be applied when needed. When it isn’t needed, leave it alone and don’t do anything with it.

Jamie : Absolutely. You’ve hit the nail on the head with a whole bunch of stuff there, because then I feel like I’m stepping over a whole bunch of stuff that we’re going to discuss. But there’s that wonderful phrase of resume-driven development.

I feel like, whilst microservices is a great pattern to look to move towards, when it started to become the design pattern du jour, a lot of people saw one or two conversations at conferences and talks by people like Netflix, and it looked easy because Netflix did it and Netflix is really successful. But what they didn’t take from the talk was the bit where Netflix had said, yes, it does work for us, but it has required the equivalent of two hundred engineering years, or two thousand engineering years, or something like that. I can’t remember the actual number, but they were pretty public about: it has taken us a long time to come up with this kind of solution and to figure out how to glue all of these microservices together such that they are stable, and such that we can throw Chaos Monkey at it and get it to work.

It’s still a relatively simple design compared to what it could be, but it is still very, very complex. My own personal opinion is, I feel like they probably had a lot of help from AWS setting everything up and getting it up and running. For folks who don’t know, Netflix is the killer app of AWS, right? As far as I’m aware, the video hosting side of it isn’t on AWS, but all of the microservices and the back ends for front ends and the app that is Netflix all runs on AWS. It is the poster child for microservices on AWS.

Chris : Oh yeah.

Jamie : My personal opinion is they got loads of help from AWS to get it working, because AWS knew that if this takes off, our web hosting service is going to make us loads of money, right?

Chris : Yeah, yeah. What is it — Netflix used to be, I think it’s dropped a little bit, but it used to be like 9% of all traffic on the internet was Netflix. It’s amazing. Netflix is a great organisation and they have lots of great engineers. But I saw a number — to implement their microservices strategy, they had more than two thousand software engineers. Now that was across everything: DevOps, implementation, infrastructure. They had over 2,000 people.

So when one person comes in and talks about what Netflix did at a conference, what they don’t explain is all the manpower, like you said, behind the scenes. For a small company and a small team, I think microservices has turned into a career decision instead of a technical decision.

You hit it earlier when you were talking — a lot of people go to conferences and they do conference-driven development. They come back with all these great ideas. You know what? I’m guilty. I speak at conferences and I give lots of ideas. But they are ideas, and you don’t have to take every idea and apply it when you get back to the office. Think about stuff. Just like if you were reading the Gang of Four pattern book, you don’t need to try to get every pattern into your software solution. It’s not a competition.

I feel that over the last ten, fifteen years, a lot of people made technical decisions that weren’t the best for their teams or their organisations. They were chosen and implemented for their career development, which — I’m all for people making the most of themselves and creating a good career for themselves. But when you put yourself in front of your team and the organisation that you represent by developing solutions that are far more complex and complicated than they need to be, just because you wanted to have something on your resume, I think that is a huge, huge issue in our industry.

Jamie : A thousand percent. I wonder — and I was just thinking of this whilst we were talking — there’ll be multiple parts to it, but the two parts that stick out to me are: perhaps the company that I work for, or the department that I’m in, have paid for me to attend this conference, or have given me paid leave to attend this conference, or maybe they’ve helped out with travel expenses. Therefore I have an obligation to bring the learning to the company, and perhaps I subconsciously or consciously need to be rather excited about the things that I’ve learned there and try to convince everyone. Look, the value of me going to this conference was: I learned about this pattern, this library, this whatever. If I can get you all excited about it, then that will show to whoever the decision maker is that they made the right decision in sending me here, because it will add to the value.

But then I’m also going to counter that same argument with — one of the things that I know about American pop culture is that in the TV shows, someone who is approaching retirement age tends to pick up a hobby outside of work that is not directly related to what they’re doing, right? So maybe they take up woodwork and start fabricating things and building things, and they buy a special set of equipment. They don’t buy the equipment specifically because it’s the only equipment they could use to do the thing. When they buy the equipment, they don’t just use that piece of equipment for what they’re building.

Let’s say someone’s building a boat in their workshop, the space that they can do their activity in. You can buy a belt sander, or you can buy a hand-operated plane, and you can slowly sand and plane the wood down to give it the finish that you’ll feel — you’ll have the right feel to it. You can use the belt sander or you can use the plane to plane it down. Now, you don’t buy one and exclusively use that forever. You buy the one and use it in the situation in which it makes the most sense.

It’s one of the reasons why the tagline for this show is “the tools in your toolbox”, not “do it this way and only ever do it this way”, because that’s just silly. It would be a terrible idea for me — not for others, but for me — to tell people specifically: you should only ever write software in this particular way, with these particular languages, with these particular frameworks and these particular tools, because none of those apply to every single problem, right?

Chris : They don’t. When I say that you should make your solutions as simple as possible, that’s very arbitrary. Simple to Netflix might be very complex to a four-person startup that is trying to get an MVP out the door. So simplicity is very relative to where you are. That’s why it comes down to a philosophy. It’s not a hard-driven “you have to do these rules”. Philosophy is more of this nebulous type of thinking.

When I say simple, a lot of people think, oh, you’re just trying to make things simple. I go, well, no, I’m trying to make things affordable, I’m trying to make things sustainable, I’m trying to make things testable, I’m trying to make things maintainable.

I’m releasing over six weeks right now: the economics of software architecture. Simplicity also reflects in cost, because I’ve found all these studies that say that most companies that start putting solutions out on the cloud pay a lot more than they should, either because teams add a lot of complexity to the solutions which causes the resources and the features to be more expensive on Azure or AWS or Google Cloud, or engineers and DevOps teams set up too big of resources for their solutions.

One of these filters that I speak about — there’s three of them — one’s called the half rule. I come in and I say, you know, if we could get rid of half of the resources — for this, let’s say it’s cloud — could we get rid of half of the cloud resources and still have a functional solution? I challenge teams to do that. Just like I challenge teams — and I’ll tell you what the two other filters are in a second — but sometimes I’ll say, hey, can we get rid of half the code and still have a working solution that meets the customer’s needs? So one of the filters is called the half rule.

The other important one, probably the most important one, is what I call the 2 a.m. test. If you could have someone wake up at 2 a.m. when your solution or your system goes down, and they can — half asleep and groggy-eyed — fix that solution quickly and not have to call 20 different people across 20 different teams to get a solution, that’s what you strive for. So that’s the other filter I try to apply. Could a tired, stressed engineer debug this problem at 2 a.m. without help? I’m not saying they could or they couldn’t — I’m just saying that’s what you’re striving for.

Then the last filter, and you’ll laugh because every engineer does this, I call it the primary path first. I say develop your primary path of your solution. Don’t worry about edge cases. You know when engineers get into a room and they start talking about designs, it’s all about edge cases. No — worry about the 90%. Worry about the 90% that’s your primary path. If there’s a feature and less than 5% of your users will use it, that’s an edge case. Don’t even think about edge cases until you get the primary path done. Then you can bring edge cases into it.

If you build all these edge cases, you’re using up the complexity tax of your teams. That complexity tax, or that energy that a team has to build the solution, should be for meeting the needs of the majority of the users. We all get caught up — and I’ve done this in my career — you sit there and go, well, what about if we go for this integration? No one sits there and goes, how many of our users need to integrate to that X third-party tool? Well, I don’t know. If someone says I don’t know, you slap them and tell them to be quiet and let’s keep on the primary path.

My philosophy, this simplicity-first philosophy, is not hard. It’s common sense. It’s just reminding yourself to ask questions. It’s reminding yourself to say: is this really worth the time to do it? Are we putting too many resources into this solution? Are we making this solution too complex for our engineers and our DevOps people to fix if something breaks? It all comes down to common sense and respect for each other and the users.

Jamie : Yep. I feel like I’m going to be agreeing with you so much today, but I agree a hundred percent. There’s something in The Pragmatic Programmer, 20th Anniversary Edition. I keep bringing up Netflix, but their example is Netflix. They said: if you want Netflix scale, go get a million customers. Then you’ll need Netflix scale. Don’t build Netflix scale when you have two customers.

Chris :

I have that in my book too. The other case study is with Amazon Prime Video. I think they took a look at Netflix and in the beginning they thought they had to do Netflix architecture. So they built this whole microservice platform out, and they let it go and people started using it. I think a tenth of their planned user usage caused the system to bog down. There were some technical issues and stuff.

After a few years of them trying to get this microservice platform architecture running, I think they just decided we’re going to go back to a monolithic architecture, and they built it. Now they built it in a way where they used all the knowledge that they learned from the microservices — how not to do it. I don’t think they were really implementing microservices well, but they had a lot of that knowledge, and they built their monolithic solution. It is still used today and it supports their tens of millions of users. I don’t think they have the same user base as Amazon — they could, because there’s tons of people that have Amazon Prime — but they went back to a simple solution and got better, easier, more maintainable, more testable, and it was a better solution for them.

I think they were trying to just say, oh well, if Netflix does it, we should do it. I think they learned that everyone has to develop their own solution for themselves and their users.

Jamie : We have to remember that there is a constant trade-off between complexity and simplicity. I guess this is what you’re saying, right? Please correct me if I’m wrong, but my own personal thoughts are: we should aim for simplicity wherever we can. If we start with simple, we can only go up, right? We can only go up to complex when we need it. But if we start with complex, we can’t come back down — not without having to rebuild or re-architect. There’s loads of rework involved in making something less complicated.

Imagine you’re building a house, right? You decide that two hundred years ago there was a flood in your area, and the water levels rose to, I don’t know, twenty-five feet. It’s only happened once in the last two hundred years, so you build your house on stilts, like they do in some parts of Australia, where your house is twenty feet in the air. That’s fantastic. But then you realise, maybe ten years into owning that house, I didn’t need those stilts. Well, guess what? You’ve got loads of complexity required in lowering your house back down to the ground.

Chris : Yeah. You can’t cut the house down. Exactly. The other thing that Amazon Prime Video discovered was their costs went down ninety percent with a monolithic architecture. They didn’t need all the people and they didn’t need all the AWS resources. It went down 90%.

Imagine you going to your boss and saying, hey, I want to redo this system; it’s going to save us 90% of what we pay for the current system. Unless it takes 10 years to implement, your boss is going to listen to you. This is the economics of simplicity. Instead of sixty-five thousand dollars a year for a microservices solution and architecture, what if it was ten thousand dollars a year for the same capabilities, the same number of users, the same uptime, the same everything? If you could say, instead of a $65,000 solution, we’re going to have a $10,000 solution, I would guess that the people that are paying for it, or having to sign off on the cost, would probably be happier.

Jamie : A hundred percent, yes. If I said to you, hey Chris, here are our two products. From your perspective they are functionally exactly the same, but one costs $250,000 more. Which one are you going to choose?

Chris : I know what I’m going to choose. I’m going to choose the cheaper one. So let’s pivot this again. Usually a cheaper solution uses less — I’d say it uses less CPU cycles, or uses less resources and less memory and less storage potentially. Well, that goes back to a sustainability idea.

In my book, I also have a couple of chapters on environmental concerns. I’m not a tree hugger or anything, but I do want to think about solutions that use less energy, because we’ve all seen it in the past couple of years: energy prices have gone up. We have more demand for energy, mostly from these AI data centres, which I don’t know if they really take a look at sustainability or not. But I have changed my ideas and changed my views. If I can make a solution that is more sustainable, uses less energy, that will be a simpler solution and usually a cheaper solution, because I’m not using as much energy compared to a complex solution that uses a lot more features and energy and stuff.

So there’s this whole idea of sustainability and using less energy and making a positive impact on the environment. We should be stewards of our world. I want to leave this world in a better place for my kids and my grandkids. I don’t think other people have that philosophy, but I do. So when I sit down and look at solutions, I try to look at it from a sustainability aspect also.

Jamie : Oh yeah, absolutely. Even if the person you are talking to doesn’t really care about the environmental sustainability perspective, like you said, it’s cheaper to run something that is simpler, because you require less complicated hardware, or you require less of the complicated hardware, or you just require less hardware, right?

I’m going to pick an easy low-hanging fruit here. We do need abstraction in order to do our jobs, but we don’t need as much abstraction, I think, as we use, right? If the power cost of creating one level of abstraction is, say, ten milliwatts an hour, and you have 400 levels of abstraction, the numbers add up really quickly, right? Maybe that’s per request, and maybe you’re getting four million requests a minute. Your power consumption goes through the roof.

One of the things that we don’t realise as devs is that every time you create a new class, or every time you go back to a class that previously existed, or every time you move through a function call stack, you’re literally moving through a stack. The CPU and the whole system has to remember where it came from. So it has to hit pause, put some stuff onto the real stack, increase the program counter, flush a whole bunch of memory, pull all of your instructions back in from level one or level two cache, rehydrate everything, and then continue. First off, that’s super inefficient anyway. But secondly, it might be picowatts, I don’t know, but that’s power that’s being used that you don’t need.

Then combine that with — there was a blog article, I’ll see if I can find it for the show notes. I read it yesterday and it was about 49 megabytes of data required to load a single HTML page. This person is talking about the design of the page and all of the ads and all of the extra cruft — the 49 megabytes of JavaScript and images and stuff that are required to show 250 kilobytes, if that, of a news article, right? That’s a huge waste too, because that’s super complex.

In that instance, what’s happening is it’s loading a whole bunch of JavaScript, and then the JavaScript figures out which of the ad networks is “the best one” in quotes to go to to get an ad. But it has to load them all, and there’s this whole complex bidding process and tracking and stuff. All of that itself is an argument for another day. But it adds to the complexity of loading that page, because if I’m running a relatively low-powered cell phone, or maybe I don’t have a well-optimised laptop, I load a website and the fan is going to kick in and the battery’s going to get hot. That shouldn’t be happening.

Chris : Yeah, exactly. That’s where most energy — when we’re talking about the cloud, I don’t know the percentage, but a majority of the energy used by cloud platform data centres is cooling. It has nothing to do with the energy it takes to run the computers; they’re all pretty efficient. It’s just that the heat put off by all these computer parts takes a lot of refrigeration and cooling to cool off. That’s where most of the energy is.

I have four computers in this office that I’m sitting in. If I close the door, especially in the summertime, and I come back and they’re all running, this office is pretty toasty. I don’t really need heat in this office — these computers give off enough heat.

When I was in school, and early in my career, no one ever talked about saving energy, like building solutions to use less energy. They would talk about building solutions to be cheaper, to run on cheaper hardware, or on smaller resources in the cloud. But I think it’s this new idea of the last maybe five to eight years that we’ve really taken a look at the energy consumption that these cloud platforms, these cloud providers, are using. Now, with all the AI data centres, there might not be enough energy to go around, no matter how much oil we get out of the ground.

I know we’re beating a dead horse right now, but there are lots of ways to think about simplicity. You hit on abstraction, but there are also dependencies. So let’s bring in the big elephant in the room — we’ve already said AI a couple of times. Here’s the other thing: AI is a complexity amplifier. The perfect example is, if you ask Claude or Copilot or Codex, ChatGPT, to create you a web app that does XYZ — if that’s all you asked each one of those agents — what do they create right off the bat?

Jamie : Oh, like a web app. It’s going to be React, right? It does npx create-react-app.

Chris : Exactly. Has anyone ever taken a look at how many dependencies a bare-bones React application has in today’s world? It’s like 600 dependencies, if you take a look at the dependency tree of just a boilerplate React application. AI spits out complexity. It doesn’t understand simplicity, unless you tell it simplicity.

I’ll tell you what — 80% of most applications that anyone builds, and here’s another one where I’m going to make people mad out there — 80% of web applications can be created either using static sites or 100% server-rendered frameworks like ASP.NET Razor Pages. Even Blazor — I know Blazor’s the hot thing in the .NET community. You don’t need Blazor for most of your application. Blazor is a me-too framework that is trying to do what React and Angular and Vue and Svelte and all the other SPA frameworks do.

There was a time and a place for needing to get all of that JavaScript into a browser, but in today’s world, we have huge data pipes going from servers out to either our browsers or out to our mobile phones. We don’t need client-side. We don’t need to push everything into the client anymore. You can email me, you can find me on social media and tell me I’m the biggest dunce in the world, the stupidest person in the world, but it’s a hill that I am worth dying on: 80% of people do not need SPA applications. They don’t. They can do everything, and it’s actually cheaper, easier to maintain, costs less, and easier to test.

I do it every day. I use ASP.NET Razor Pages with HTMX. It allows me to have an application that looks like a SPA application, but it’s 100% server-side. I don’t have to mess around with JWTs. I don’t have to mess around with having a front end and back end. I have one code base, and I’m such a simple person. I love it. Really, I’m a simple person. I’m not smart enough to come up with these huge complex ideas. I’m just a simple person that thinks in terms of: simple is good enough. Okay, I’ll get off my soapbox now, Jamie.

Jamie : But you raise a really interesting point. Again, right, if you wanted, you could approach all of those projects that you’ve built and put the complexity in there. But if you built it with that complexity to start with, and you decided you didn’t want the complexity anymore, it is more complex to remove the complexity, right?

Chris : Yeah.

Jamie : So you’re leaving yourself open to adding that complexity if you want it, if there is a need for it. Whereas if you start with something that is maybe server-side rendered, or —

Pro tip, folks: go to the website for this podcast. It’s all statically generated HTML, right? Which means that when I release a new episode, the website is rebuilt, which means that as long as the servers that the HTML files are copied to are working, you will never be able to load those pages any faster, right? It is not possible.

My point was not so that I would get fast page load times. My point was: why do I want to do it this way? Well, okay, if I had it behind a CMS like Ghost or a server-side application CMS like Ghost, or Umbraco, or WordPress, or anything like that, the server has to be on and running, and something has to poke at the server every 30 minutes to stop the application from falling asleep. That means the application’s running and listening for requests every thirty minutes, which likely means it’s probably doing a whole bunch of memory management it doesn’t need to do.

I know I’m speaking from old information here, so WordPress folks, please do write in and correct me on this. But old WordPress: for every request you send to a WordPress website, regardless of whether the plugin should fire on that request, all of your plugins in sequence fire for that request. So if you’ve got 15 plugins — one for image manipulation, one for SEO tags or caching —

Chris : Yeah, exactly, right?

Jamie : Every single request, regardless of whether it should be dealt with by that plugin, hits that plugin. That’s a huge amount of wasted electricity. I can often tell when I hit a blog of some kind. Maybe I’m reading Hacker News, right? I click a link and the page takes more than a second to load. I’ll say to myself, oh, I’ve just woken up WordPress, then. Because it takes a couple of seconds for WordPress to wake up. I’m picking on WordPress, but the same could be said for Ghost, the same could be said for Umbraco, the same could be said for any kind of CMS-powered website.

Chris : Exactly. The same could be said for all of them.

Jamie : Whereas when I hit the page for dotnetcore.show — which is the URL for The Modern .NET Show; you’d think that I’d know the name of the thing by now, right? I’ve been doing it for eight years — when you hit the website for this podcast, yes, the server is already running. But it’s not running anything in the background other than Nginx, which is looking for: which directory do I need to go into to read the file off of disk, and then send back, or read from a cache which maybe is set to fourteen, twenty-eight hours of validity, because nothing changes?

If something does change, it’s because I’ve forced a new build and deploy, which means it’s been told: invalidate all the caches for these particular paths, not for everything. So, yes, the deployment bit behind the scenes is a little bit complex, but all I needed was a website that has a bunch of pages, and each page has a player. Each player links to a file somewhere on the web. If you want to go and right-click and inspect, you’ll find out where they all point to. It just displays HTML.

I’m not trying to pick on any particular technology here, but it doesn’t need React, it doesn’t need a JavaScript framework, because the content’s all pre-built. You can’t get much simpler than that, right? It’s pre-built HTML.

Chris :

Yeah. I think a lot of people in the last five, six years have woken up to that, because how many websites are now just static websites out on GitHub, like using GitHub Pages? Lots of people are doing it for their own blogs.

I need to get back to a simpler way. I use WordPress for my personal site and my blog, but I am trying to develop a plan to move to a statically generated website for my personal site and my blog. I like WordPress for what it can do, but for me it’s a little too complex. I don’t need all the stuff. I can do most of it statically now.

It’s also funny — I talk to these companies and they’re like, well, we’re doing microservices and this and that. I go, well, how many users do you have? They’re like, oh, we have about 50 users. I’m like, you have 50 users and you’re using microservices? Why? Well, our architect said this. I said, okay, so is that architect still around? The funniest thing is, most of these companies, they get these architects who have these big ideas, and they implement these ideas, and then they’re gone after a while.

I found another interesting data point: by having complexity, on average it takes three months for new developers to come onto a project to understand these over-complex solutions. Usually by the time those three months hit, 25% of your engineers have left, because they just don’t want to deal with that much complexity. So there’s another angle: you’re wearing your developers out by implementing complexity.

You know what? I think developers and engineers love the idea of building a Ferrari, but if you actually ask them the truth, they would probably say that they would love to maintain something like a Volkswagen solution. So there are these diametrically opposed ideas. They want the flash and they want all the high performance and the glitz and the glamour and the shiny things and the bells and whistles, until they have to actually go back and bug-fix it and maintain it and upgrade it and add more complexity to it. Then they go back and they go, wow, why did we make it so complex? Why didn’t we make it simple? Then our lives wouldn’t be so tough.

Today, you can’t leave your job and go find a new job. The job market’s not great right now. So sorry everyone, you’re stuck maintaining those solutions that you built a year or two ago, or three years ago, when the market was hot and you could have a career based on moving around and showing off what you did at your previous employers. It’s not the case in today’s world.

You know that moment when a technical concept finally clicks? That's what we're all about here at The Modern .NET Show.

We can stay independent thanks to listeners like you. If you've learned something valuable from the show, please consider joining our Patreon or BuyMeACoffee. You'll find links in the show notes.

We're a listener supported and (at times) ad supported production. So every bit of support that you can give makes a difference.

Thank you.

Jamie : Like you said really early on in the conversation that folks are listening to right now, you walk into a room and you drop that shopping list of “this is what I’ve created and aren’t I fantastic”. They don’t know what any of it means, so they go, yeah, that’s totally complex. Yeah, that’s amazing. Genuinely well done for wrangling all of that complexity. Now I can push the button and a report is downloaded.

Hey folks, I’m going to let you in on a little secret here, and I’m going to upset some people. I recently built an entire PDF report generation service that uses Playwright. What I did was I got all the information, got all the data I needed, converted it to HTML, threw it at Playwright, and then said, hey Playwright, file > print PDF. It came out as a fully fledged PDF file. I didn’t need any kind of crazy expensive libraries for creating PDFs. I just said, hey, I’m in a browser context. I’ll just do file > print to PDF, and it works, right? Because it’s a simple solution to a really, really complex problem.

You think about PDF — that is really complex. But if you go in your browser right now, on any page you’re looking at — well, not any page, but pages that you’re looking at which don’t really require a great deal of interaction — you can do file > print PDF, and you get a PDF version of that page. It might not look great and you may have to create a print.css file to make it look good, but guess what? That’s a super simple solution to that problem, rather than the hyper-complex one of: which PDF library do I choose? How much money are we willing to spend on it? Is it a SaaS product? Is it a DLL? You don’t need any of that. If you’re in a browser context, file > print PDF. Done.

But yeah, nobody ever got paid for creating the simple thing, right?

Chris : Nope.

Jamie : But there is a wonderful line in — I think it’s an early episode of MASH. I want to say it’s MASH, but it could be anything; I can’t remember what it’s from. “This is such a simple design.” “Yeah, but so is the wheel. I hear that’s catching on really well.” Right?

Chris : Exactly. You know what? I remember when creating video games — this goes way back to the TRS-80s — I just built a sprite, and you just moved a sprite around the page, and then you had another sprite, and then you detected when the two sprite edges collided and you did something based on that. So that was how I developed video games back in the early to mid eighties.

But yeah, I think it all goes back to: use common sense. Can I give a list of suggestions to people?

Jamie : Absolutely. Please do, Chris. I know we’re running low on time, so I’m just going to step back and let you take over.

Chris : So I gave you the three filters: the 2 a.m. test, the half rule, and the primary path first. If I could give suggestions to people: apply those filters whenever you can. With every decision, try to apply those filters. So that’s the first thing.

The next thing: treat every dependency that you bring into your solution as a complexity cost, as an architecture task. There’s a tax that you pay for every dependency and every abstraction, like Jamie said.

Run the 2 a.m. test filter in code reviews. Ask someone in another team if they could figure out the solution to a problem in your system. If they can’t, there’s a red flag there.

When you’re in sprint planning, apply the half rule when you are building out your tasks. When you’re planning out your implementation of your tasks, apply the half rule to those.

Trace primary path before edge cases. Always do your primary path before you even think about doing edge cases. Remember that.

Every abstraction must pay for itself. Enough said. That is the challenge that this simplicity-first approach boils down to. It’s not rocket science. Rocket science is very complex. Most of our solutions that we build are not rockets, so we don’t have to worry about that. Ours is just common sense.

It’s remembering to be simple. It’s remembering that complexity is not sophistication, that everything you do has a complexity budget. You only have so much complexity budget to use, and if you use that all up in the beginning, you’ve got nothing left down the road. So remember that.

That’s from Uncle Woody. Uncle Woody is giving you some wisdom and some advice from 30 years in this industry. Okay, Jamie, I’m done.

Jamie : That is wonderful advice, and thank you so much for sharing that summary. I know we didn’t get a great deal of time to talk about the actual book that’s coming out, and where folks can go get it. I know we’re super running low on time, but what about folks who want to check out the book? They want to figure out how to get in touch with you, maybe follow you on socials if you’re on socials. What’s the best way to do all of that?

Chris : If they want to go out to my personal site, that’s woodruff.dev. If they want to learn more about simplicity first, just go out to simplicity-first.dev and they’ll learn about the manifesto, the philosophy, they’ll learn about the books. I even put the three filters out there. I’ve got essays to read. I even have, if people want to hire me to come in to do some architecture assessments, they can find some information out there too. So you can find all that at simplicity-first.dev.

Jamie : Amazing. Thank you very much for being on the show, Chris. We’re right down to the wire, so —

Chris : Yeah, yeah. Maybe I can come back after the book’s done, or whatever. Jamie, I really appreciate you having me on the show. Like I said, it’s been an honour, and I’m a big admirer of yours. It takes a lot to have a podcast, so you do a lot of good for the community. Thank you.

Jamie : Thank you ever so much, Chris. I really appreciate that. Yes, definitely we’ll have to have you on again once the book’s out, and hopefully in a period of time where both of us are not as rushed.

Chris : Yes. Thank you so much.

Jamie : Thank you.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places