The Pursuit of Simplicity

Hi welcome to my first blog post on 'The Pursuit of Simplicity'. Thank you for taking the time.

My perspective on simplicity: Over the years I observed a pattern I work in which basically boils down to 'Don't reinvent the wheel'. In my early java and spring days I saw that, in the company I worked at, we did a lot of configuration over and over again. Even sometimes wrong. I by accident stumbled upon spring-boot which was a godsend for me. Because it solved all our issues we had. Since the company was a software agency, building software for clients, that meant we regularly setup new projects in spring. So I introduced spring-boot and felt that our lives got way easier from that point on to just use the wheel someone else build and concentrate on the project at hand. And this pattern continues, when ever I encounter a challenge during a product/project I first look around what is out there and just use it. Another example from the agency days was that we had to build a system which generated a video out of a javascript animation basically. We also needed sound in the shape of the actual voice but also sound effects during the video. I don't remember the exact details of the implementation anymore, but I remember that my boss said I should do it in java with some stream-buffer thing to compose the audio track. I found this pretty hard researching it in the sense of that I did not felt comfortable to build upon this suggestion for our client, since we (and therefore I) were liable for the end result. So I looked into other solutions and found a python library which I could use to do exactly what I needed: cut and mix audio. And the result was neat. It worked and that is what counted. So rather than developing a solution entirely from scratch basically I searched for tools which could aid me in fulfilling the task. I believe that this a more sustainable solution, because I build upon a battle tested tool and could focus on my problem. Even though I am responsible for the tool I used at least a set of really smart people, who build this tool, maintained it so I didn't had to compared to a custom-from-scratch solution my boss suggested.

Over the years I was really a fanboy of java and spring, even though java as a language sucked in so many ways and NullPointerExceptions are the smallest of the problems. I found it hard to write sustainable good enough readable code with it. So when kotlin came around I jumped on it and was happy. Again all the service of simplicity: Not only for me but also for others which had to work with my code. So the pursuit of simplicity is not to find something that is easy or not complicated, but rather which touches multiple other aspects like reliability, tooling, modern features and safety for example. Also the spring-boot ecosystem grew crazy since I first introduced it in the above mentioned company, it was great to use it and build with it. Why? Because I could concentrate on my tasks at hand. Like playing with lego: You don't build the lego bricks your self first in a factory in order to build your crazy spaceship you though of in school staring out the window. No. You went home after school totally excited about what you would build and search for the right pieces to compose your spaceship. Boom. Done. You can start playing with it.

Custom Solutions

I have seen so many software developers over the years who rather spend time reinventing the wheel to prove something to themselves or because they found a little thing was wrong on an existing solution and rather build something entirely from scratch themselves just to feel better. What I found they all missed was, that they knew how it worked, because they mainly or entirely worked on it alone, but they did not thought about what comes after that. What if this perfectly abstracted piece of software needed change? What if a bug occurs in that neatly crafted piece of code and they are gone and therefore all the knowledge? Most of the time a custom solution is overengineered just to prove a point, because they wanted to try out a pattern they read about which they thought might fit or something else. In the end the product/project is left with a custom piece of code which has to maintained and extended. So that said only because you don't have fuchsian colored lego bricks, don't go into the factory and make them yourself. Go onto lego.com see if they have lego bricks in fuchsian and buy them, if not just use another color. Please.

Ok back to the topic. In the frontend I observed the same pattern for my behavior to look out for tools which make my life easier. After using Java Server Pages (JSP) and also a bit of GoogleWebToolKit (GWT) I was so relived to when angualarJS finally arrived. Yes I mean version 1. I also introduced in the company and used it in a couple of projects we build and it was great. It felt so easy. Then react came along and again things were so easy compared to angularJS.

The last stop I made a couple of years ago was when I was introduced to golang in the company I joined mid 2020. Before I was quite ignorant towards golang because I thought that only the big companies with these weird performance challenges use it to solve these.

Performance optimization

By the way: If you think you have a performance problem with 200 users and have to optimize for. Think again. You can optimize performance always later.

The team I joined was using golang and I was hooked immediately: Because again compare to kotlin/spring it made things so easy. And it was fast. By then I had build a little time tracking web application on spring/kotlin/react, which I rewrote with golang (the server side). The result was that the then memory usage was only 3% compared to the spring/kotlin version (here you can see the entire history in the github repo). It was crazy. Everything was easier: testing, extending and maintaining the service was a breeze. I only realized my blatant ignorance years later and really regret not looking into golang much earlier.

This brings me to today. I recently and finally looked into rust and fell in love. Because again. I think rust solves a lot of problems golang has. For example that golang is not strongly typed. Rust is so strongly typed I have not seen since scala. And I really enjoyed scala from an academical perspective, but it never felt right to put it into production for me. I know it sounds totally contrary talking about rust in a blog post and blog titled 'The Pursuit of Simplicity', but hear me out. I know that rust is hard to learn and that you have to take care of a lot of things. But what I think you get in the end is a rock-solid piece of software which you can put somewhere and let it run. And it runs and runs without hick-ups or anything. That sounds intriguing to me. To worry about the software while building it, but forget about if once it is done. I always take this little time tracking web application: I mainly use it. I have not yet made it public for everyone, because I am not confident that it will hold up and not cost me a ton of time fixing and maintaining it a seconds person uses it. Rust with its compiler and tooling helps me quite a bit as a rookie rust developer to write correct rust software which does not create weird runtime behavior when a seconds or third person uses it. That I am sure of, even though I just stared this journey.

Another side note to the frontend: I had the same problem in the frontend. After react became so complex and weird (to me) I searched for alternatives and looked into elm, svelte and sveltkit. And yes they do seem simpler in their way but not in my definition of simplicity. In early 2024 I heard about htmx (yes you know that would come now) and I immediately fell in love. It was again simple and it sparked a though in me 'Do I really need a frontend framework?'. Turns out, at least what I do in my 9to5 app, no. I was remembered of the time that I had the bad idea building a online e-commerce shop myself (yes I am guilty my self of creating custom solutions where they don't have to) for a friend and his fashion label. In this online shop (written in spring/java) I used ajax to make my life easier for the admin pages. And it felt great back then. I did not use a frontend framework, because I didn't know one and the other solutions in the java space like GWT, RichFaces (or how ever that abomination was called) didn't really fit my need of moving fast. I know I am aware of the irony. But using Java Server Pages (jsp) with Thymeleaf as a templating engine meant I could render a chunk of the page, for example the items in a list of orders, on the server side and just put it into the HTML DOM. Done. A little javascript here and there. It was certainly not a infinitely scalable solution. But it worked and did not require any framework. I am of the strong believe that many many web pages who use framework xyz don't really need it. They would be better of with a simple server side rendered page, communication with ajax and a little javascript sprinkled on it. This is what htmx can do for me and if that does not work there is also hyperscript and if that does not work standard javascript also works perfectly fine. What are the benefits? I think not only is the setup simpler, but also the experience more enjoyable for the user since you have to ship less javascript and just present what the user needs. Pretty fast. No fancy edge functions which take 10 seconds to cold start or anything. Simple server which serves (pun intended) the frontend to the user, which they interact with. Done.

That is simplicity. I think with all the cool tools and frameworks we got quite lost in what we actually need. And most people don't have FANG level problems. But everyone is looking over mimic what they are doing, without realizing that they don't have the same problems as they have and therefore don't need the same solutions.

Thanks for reading and see you in the next post.

Bye.

/opinion/