Radical Simplicity
ฝัง
- เผยแพร่เมื่อ 26 ส.ค. 2024
- Recorded live on twitch, GET IN
Article
www.radicalsim....
By: Stephan Schmidt | / stephanjschmidt
My Stream
/ theprimeagen
Best Way To Support Me
Become a backend engineer. Its my favorite site
boot.dev/?prom...
This is also the best way to support me is to support yourself becoming a better backend engineer.
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-K...
Get production ready SQLite with Turso: turso.tech/dee...
![ถามตรงๆ กับ อาจตุพร ทำไม ประเทศไทย ใครเป็นนายก ก็โดนด่า พอออกเเล้วคนคิดถึง!!?? l [Nickynachat]](http://i.ytimg.com/vi/3YFLMXxBGAs/mqdefault.jpg)
“An idiot admires complexity, a genius admires simplicity” - Terry A. Davis
Holy C❤
theres other end to this too. simply using hacks, patches everywhere and creating bad code.
go for simplicity, not easiness.
do it cause its simple, not easy...
Reminder that what terry was talking about were things like _the linux kernel_ which are complex not because its designers were dummies but because they solve real problems that people have instead of being bedroom projects like templeos.
It's easy to keep your stuff simple when it's useless.
@@isodoubIet because certainly all products in the real world need to be overengineered. I suppose Terry can't have right opinions even when he makes """"""bedroom projects"""""".
You can admire simplicity (comparing any BSD or Mach or Inferno with Linux), you're aware of that, right?
Tom’s a genius
lol I went to school for aerospace engineering and their was this professor in a propulsions class that said, “we compare hard thing to rocket science, but rocket science is mostly plumbing”.
I didn’t end up building rockets but I always try to remember that the really genius things are a lot of simple concepts built on top of each other (very neatly).
Right? I taught theory of computation to 20 year olds. When one of them would see how easy some of those concepts are, it was a great moment.
Rocket Science is all bells, whistles and slick advertising after Von Braun. But that's NASA just like any other agency that soaks up billions of dollars to basically look important while adding nothing to the actual working code.
It's honestly a really good parallel - the most amazing part of rocket science was figuring out how to make the rocket go flying up into space without exploding in the process. That's a solved problem, at this point. There is still room to innovate, but most of the job is building the thing that geniuses 70 years ago figured out.
Do people in the US refer to colleges as school too?
@@daphenomenalz4100 lol we definitely do. Or college. I've noticed over the last few years that people have been using "university" like brits do (e.g. when I was in university...) and they didn't used to. We still don't use "hospital" or "holiday" like them though. It's still "I'm going to THE hospital" and "I'm on vacation" for us. But I think it's interesting that that usage of "university" or "uni" is catching on here.
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. - Gall's Law
"A complex system designed from scratch never works"
You can use formal methods to design complex systems and formally verify that they will work before implementation. Processor architectures, for example, or other complex hardware systems. Amazon also uses some formal methods for their distributed architectures and they manage to deliver massively complex working systems on schedule in time for re:Invent each year.
@@fennecbesixdouze1794 Surely processor architectures are a prime example of what was being talked about? 8086 was a hell of a lot simpler than x64! Modern implementations might well be done via formal methods and design software but they inarguably evolved from simpler working architectures.
I don't think we love complexity as such, I think we love feeling like wizards. And a lot of the work is not wizardry, it's bricklaying and plumbing.
Edit: LOL just reached the plumbing part. Well then.
Shut up, we are wizards
... your comment reminds me of when i started to learn programming on my own and gave some comment on some fb group about posts of "spaghetti" code etc...
everyone tried to sound smart geniuses etc...
i just gace my input after what i think of high-level languages and scripting in general...
that 95% of time you're not a wizard, but a peon... ur just glueing APIs together... not actually making anything useful... so i agree.. Bricklaying is a good metaphor....
.. to me wizardry is more like... when my friend accidentally when drunk puts a parental control on his steam.,,. forgots what he used...
and then uses wireshark to do magic and brute force it in less than a day, without getting noticed or banned from valve....
that's wizardry to me
I need ma kick
I think if you want your self to be labelled as wizard then create some big shit like linux kernel like what torvalds did other wise just consider yourself soy dev and move on 🤷🏽♂️🤷🏽♂️
No, we like complexity. Makes is feel smart to know something most people won’t bother to learn. Not because it’s useful, but because we can feel smug about it.
You overlooked TIME. One overlooked problem with the overly complex environments we have today is not that we want them, or that we decided to get them and build them. It's because they grew like a Coral Reef. The technology parts, products and architectural layers accumulated over time. Each piece probably made sense at the time. Retiring or replacing parts is hard. And over time you have to get all your pieces working together. Eventually you have something that's not pretty but hopefully functional. That's just the real world.
Ah so this is where the traffic for my website is coming from :-)
Hey, nice read!
o7
I think you need to clarify what you mean when you say "scrum" because everything in the article was very reasonable and I think you have a different take on Scrum than primeagen
Where's the explanation for that Scrum take? Can't see it.
Congrats on being PrimeDotted
That title's kerning is a crime
radi cal simpu ci ty
It has to be on purpose, right?
My father warned me against getting into computers because you end up doing nothing but plumbing. I thought what does he know, as he had never owned a personal computer in his life. Turns he did know more than I could possibly imagine.
I spend all my time on planning. And none of my time on development, or solving problems. I have accomplished nothing. Therefore, I have optimized for simplicity.
Zero bugs written, so success!
don't reinvent the wheel, but lean on publicly available knowledge on how wheels are constructed instead of licensing the wheel factory for X dollars a month because you need 4 of them.
Check requirements for Wheels for Airplanes, Baby strollers, Mario Kart, Oil press and Python libs.
Yep. Don't reinvent the design for the wheel, but build it yourself.
@@parkourbee That is the exact scaling issue in this video. If your product uses wheels, but isn't wheels, don't turn it into two projects by trying to build your own wheels. Just buy them from an existing wheel expert and work on the real project. When the project is good and making money, then bringing wheels in house might be a good idea.
@@barongerhardt I agree for some things, but some wheels, like auth, often need to be fit specifically to your car. Other wheels, like analytics, can be self-hosted like with Plausible. And then of course there's npm install wheel.
@@parkourbee He says later in the video, not to take a the complexity and problems of a whole lib just for one short, easy to implement function. These as well as thin vs thick client are parts of the art. Early on, in almost every case it is better to buy as many solutions as possible. Then as things grow, pick the things that are causing bottle necks. Then comes the cost saving efforts, from easy to hard.
We got a new project at work. The business logic is about 120 lines of python parsing code slapping that stuff into an SQLite Database that gets packaged with a go app into a container. The business logic is essentially a few lines of SQL.
The frontend however is an Angular app that has a few thousand lines of typescript already...
SQLite is about 116k lines of code, Go is about 167k lines of code, and python is about 154k lines of code.
So your backend project is actually about half a billion lines of code.
@@fennecbesixdouze1794 what a poor take from you.
I'd bet $100 that the front end could be written with fewer lines of plain old HTML/JS/CSS in static files, than with Angular/React/Vue. With cherry picked use cases, these frameworks save you a lot of code and complexity. With real world, these frameworks force you to write a monstrosity.
@@fennecbesixdouze1794 If you count lines of code in the back end components (even in the COMPILER!), then we have to do the same thing for the front end. The Angular app runs on a web browser, most of which are many millions of lines of code, and the TS compiler is about 250K lines, and should we count the javascript engine that the TS compiler runs on? So if you want to compare lines of code this way, the front end is still enormously more.
@@fennecbesixdouze1794Right, then let's also count lines of code for operating system you run on, IDE, git, git server, server hardware code and literally everything that is somehow involved
One of the reasons why I enjoy working with trading exchange services is that we literally have no CPU time left other than what we use for business code and service reliability.
The only way to reach tens to a few hundred microseconds of RTT is by running the code with zero fat and waste.
What do you do?
People love complexity. Looove it. Relish it. I have a colleague who's constantly stressed out and complains about convoluted legacy solutions. Yet he excels in designing the most complex solutions where seemingly simple tasks can grow indefinitely in lines of code. And he fights me whenever I point out that this or that could be made much simpler or that he shouldn't implement something until it's actually required. Most developers I've worked with has been like this to some degree. They love being "smart", love introducing new design patterns or frameworks or a fancy nosql technology or establishing message queue contracts or refining some foreign key constraints. And they loooove discovering "problems", that is hypothetical issues that nobody has experienced yet. I'm sick of it.
Dude I wish you were on my team. I have the same arguments all the time. Simple SQL database and java or c# or go or some other reasonable back-end language for a back end api, then html/css/js in static files for your front end, and your first 10K users will be fine. If you are fortunate enough to need to support more than 10 thousand users, you will find out that the bottlenecks are not where you thought they would be, and you will be in a much better position to design a more scalable solution for your particular needs.
@@freeideas thx u. I work in a small telco. We have some 70,000 users (depending on how to define it), but even with this simple stuff still works wonders. Sometimes the amount of code exercise some of these "clean code" dudes produce is amazing. A nightmare example is that we needed to use a third party API to get a company credit score. A simple REST API that should be perhaps 8 - 10 lines of code: make an HTTP request, check the response code, unpack the JSON, perhaps cache it for some time. Simple stuff, right? Wrong. We only had use a single endpoint from this API, but some genius thought "why don't we implement a clean internal interface for all of the endpoints exposed by this API? We could use it in some future projects". The stupid thing ballooned to 3,000+ LoC across dozens of files, with inheritance trees, interfaces, etc etc.. with a full unit testing suite.... for doing a simple HTTP request and unpacking the response.
True. Many times it's Resume Driven Development. Even if the project doesn't really need it, they'll bring unnecessary stuff to have "professional experience" on them to pad their resumes.
They also typically love whiteboard masturbation and/or complicated abstractions that cover a wide variety of usecases (most of those usecases never even arrive, or have very simple alternative solutions).
Developers love complexity lol. They want to "grow", never content with building a simple solution that just works given the project scope. It hurts my soul seeing simpler solutions getting "scalable" and "dry" by them when there wasn't any need for that scalability or dryness.
But they're the ones getting pats on the back for being "productive" (producing more code, when most of it isn't even needed) and they also get to make their resumes padded which helps them in job hunts for higher salaries.
Simplicity wherever you can. Complexity whenever you have to.
this has the same problem as "use the right tool for the job"
@@lifelover69 the word you're looking for is "aphorism"
Be ever deleting
It really bugs me when people don't differentiate between complexity and complication. (Admittedly, the distinction is kind of systems science jargon.) Complexity is when a few simple parts lead to lots of rich behavior. Complication is when you have a giant pile of exceptions. Lambda calculus is complex but uncomplicated. HTML is uncomplex but complicated.
This comment needs to go higher.
I think you are correct. Complexity is about emergence, aka the result is bigger than the sum of all parts.
"Simplicity taken to an extreme becomes elegance"
-Jon Franklin
Previous job was maintaining a 15y+ old B2B app that had a postgres db for 20k users, ~1tb data. We had upgrade servers whenever Linux ran out of updates. For performance it was always "add index".
Often, stack complexity is the result of hiding company politics in the codebase instead of effectively solving them in a meeting.
this!
Definetely. Status games and lack of skill masking by bluffing it up with buzzwords and cargo cult tech.
I read that as Radical Stupidity. This happened because I have heat induced dyslexia.
Simple minds think alike.
I wouldn’t be surprised if the name of that font _is_ Dyslexia. Wtf is that spacing?
“radical stupidity” 😂
To be fair the keming was also pretty radical
I work at a company that is having trouble pushing its monolith app further to service our clients. We have 5 developers and I'm pretty sure ownership doesn't have tens of millions of dollars of runway. The problem is not that our user base is so large (it's on the order of tens of thousands), but more that we tend to get pinched really hard at certain times and can't scale for momentary needs. We also have an enormous amount of data to keep track of despite the small user base (and it really matters for our users, we're not just hoarding data). Poor architectural decisions that evolved over many years also plays a significant role.
Enormous in the GB?
@@haydenflinner like gigabytes? yeah if not larger. hundreds of tables, hundreds of millions of rows in some, query times in the minutes in some cases, far more factored out tables than there really should be ("single source of truth" taken way too far)
I didn't notice exactly when it happened, but congrats on the 500k!
This might end up becoming the main channel at this rate.
Haha lol
I built a major project for my last company in Django with Alpine and HTMX to handle any frontend reactivity needed, including the chat feature it needed. Daisy for UI. Built in Django features for as much as possible before relying on something else. I even kept it as a SQLite DB. I wrote only 16 lines of Javascript.
When an engineer working on another project asked why I went with that stack, I answered that it was stable, battle-tested, simple to maintain, and that by the time we scale past its ability to keep up we'll have the money for a team to build at the level of complexity required for that context. Apparently, that was the right answer. Ha, he told me if React had been involved at all, I'd have probably been fired.
They ask after the fact. And based on that they fire you? Doubt…
could you explain why he told you that about React? I'm about to start a major project using Django and planned to use React for the frontend. But since it's my first major web dev project and I'm using it to basically learn and decide on a stack, I'm curious to know why React was a bad choice there. Django is a must cause I'm doing the heavy lifting in python.
Did you really say Alpine and HTMX are "battle-tested"?
@@stefanalecu9532 I was specifically talking about Django. I should have been more specific. HTMX is as reliable as the templating engine you run it on.
@@stefanalecu9532 with this setup the app is server rendered, quite unlikely that you run into an actual htmx bug, and even less likely it has any breaking effect.
Going vertical does not get you high availability. There, enough said (JK, here's more. I used to vertically scale on aws us-east-1. Things were great. Then aws networking and Ubuntu plus docker destroyed us. What I mean is, aws had a network failure affecting our availability zone. We are forced to live in horizontal scaling because business demands that there be masures in place against this sort of thing. Uptime matters. My application supports doctors around the world. When should I have down time? I can't. My performance needs aren't huge at all, but I can't be down. Ergo, I have 3 VMs across AZs. I'm not doing this for fun I'm doing it because I have to.)
The problem is developers buying into the current thing no matter if it fits their project or not.
Why does a CRUD app for a handful of users need to have a bunch of microservices? Why not a modular monolith?
The predominant dogma in the developer community doesn't even allow posing that question.
Mock them with logical submission until they trigger themselves and start throwing ad hominem.
Many engineers would rather build a cool new tool than solve another boring app requirement. Hence tool explosion and complexity
I am working on a project that has 4 Teams totaling 25 people. We have 5 Java microservices, 8 AWS lambdas, a mongoDB for main storage of data, 3 AWS SQS queues, 2 nextJS frontends, redis for caching, dynamoDB for storing some other random stuff and 12 AWS SNS topics for what is essentially a CRUD app that sends out notifications when something happens. I have no clue how we ended up here. The local dev environment, building and shipping is hell.
It feels like there's a lot of good sentiment sprinkled in with examples that aren't the best just because it's that all they know. If you're in a box all your life, then you're not too familiar with what's outside of it, and that's if you even recognize that the box exists.
As backend engineer in a small agency, for me radical simplicity is choosing and implementing the proper cloud services to solve problems. But i always deeply learn about them and have at least one fallback FOSS product which can do the same on-prem.
Treating PostgreSQL and PHP as golden hammers sounds horrible.
I basecame while watching this video
The part where you said raise your hand if you have more micro services than users killed me… too relatable
As a dev, I feel pleasure from refactoring code to one-liners
Anything can be a one-liner, "join-lines" is not a refactoring move.
@@FrederikSchumacher Who said anything about "join-lines"?
@@FeLiNe418 It was a polemic overstatement. He was hinting that many things that could be on one line shouldn't.
@@vaxrvaxr I don't count stuff like
int x = 1; String text = "blabla"; long n = 1000;
as a one-liner.
@@vaxrvaxr Something like that. I did intentionally misunderstand and oversimplify my response to @FeLiNe418 in an attempt of humor. However the statement could be expanded into a discussion. What is a one-liner? What is refactoring? Was the intention to communicate "radical simplification" by removing code? Consider taking 200 lines out of a 300 line mess and refactoring it into a separate function, the statement would be satisfied, however the phrase "refactor into one-liners" would carry different meaning. Consider removing a home-rolled caching solution and replacing it with a common third-party library, this could be considered "refactor into one-liners". Does any of this create joy? Is joy so created a relevant KPI? Why not?
honestly speaking, I have to kind of disagree with this because I've spent most of my career, literally years, solving problems around performance constraints. which is outside of your bubble that you drew and was all done quote on quote in the pursuit of simplicity. I've really often found that the simple solution while it gets you out the door quickly it always comes back to bite you in a incredibly expensive way. I'm talking like spending millions of dollars kind of thing.
I'm interested in whether you're conflating simple and easy. I've found that simple things can be more easily refactored, and are thus less expensive to correct. Simple can be hard to achieve. Easy, on the other hand, often means coupling with something that can eventually fight everything you need to do. Regardless, you're sometimes forced to make decisions before you know what you need, and those mistakes can be expensive if the decisions were based on very wrong assumptions. Other than that, I have never experienced anything where reducing complexity and dependencies was not a good strategy to fixing something terrible. Can you give an example? (On a side note, it's called 'quote unquote')
@@Muskar2 I've been meaning to write a blog post about this actually. think I'll spend some time today/tomorrow doing it and see if prime is interested in covering it.
@@hi117117 do it and reply when you do it.
Honestly I think "The Lean Startup" should be a must read for developers, and use the same lean principals for development. Goes right to the point of using frameworks for "future" requirements when for example you have to few users and the data is too small to even need to cache anything.
Hasura is written HASKELL! I remember when you asked for one example of a real world program written in Haskell, here it is. They are also a billion $ unicorn company. Food for thought...
Humans love planning for infinity despite living a very limited time. We don't live forever, companies don't live forever. But we love making plans for how the startup that has 90% chance to fail will manage problems that only happen if it doesn't fail.
Same reason why people don't use health potions etc in rpgs and finish the game with a backpack full of one use items.
I call it "showing the brilliance". You try to quickly be as useful as possible, even if that means helping somebody else solve a problem and making them look good. Works best when you're not trying to be a manager.
Teachlead had a great joke. I remove any code that doesn't spark joy. My codebase is now just empty
I don't know how Uncle Bob is going to feel about being considered the enabler of the agile methodologies deprecation.
11:33 definitely a valid argument. An app I’m working on now is just a tool to execute calls to another API. Now there is a need to make it easier and automate the tasks but it’s nothing a script can’t do. In fact that’s how it started. Now I’m just making it persistent with scheduled jobs.
4:27 The sites did not get more complicated. MapQuest and Google Maps is a great example of the old way vs the new way. MapQuest worked fine, and Google Maps made it better at the expense of astronomical cost and complexity. MapQuest could have been progressively enhanced to do the exact same thing Google Maps does today on that old ass tech. It would be way less complicated too.
Sorcery was forbidden because it was trying to go a shortcut instead of doing the work. If you think of your self as a coding wizard, then likely you just want to npm install your way through the problem you are solving or bowing down before your Gippety idol instead of doing the work YOURSELF.
Radical Simplicity = Naive Simplicity. Why use a database? Why not use flat files? The reason is because you gain experience and understand the pain points you will encounter in advance. Having basic infra in place when you start is going to save you time in the long run. Radical simplicity feels like an excuse for radical laziness.
I work on a custom operating system for edge computing and the feedback cycle can be very long. For some stuff we have python modules so we can run it on a cluster and iterate more quickly there. But to actually test how it interacts with the rest of the system, we have to run a test with the running OS. Feedback takes 30 minutes to several hours. It is unclear how we can ensure that a cluster running the OS works as intended without actually running it on a cluster
radical simp city
I remember Sim City. It was great on the SNES.
Man, I was a webdev from 2004 to 2013ish, when I became chronically ill. It’s so cool to hear you name all the stuff that used to be normal to me. Sqlite, postgres, lucene. I get the impression everything is just frameworks stacked on top of each other nowadays. I absolutely loved the feeling of starting a project with a clean slate. Just an empty db and base project directory. Starting by creating a crud layer, some basic mvc functionality and maybe a js framework, like jquery or mootools. Man, those were the days! 😊
that's why python modules exist - to introduce radical simplicity
Radical simplicity works well if your project is straightforward and won't need changes, like many mechanical and electrical engineering projects where once it's built, it's done. But not every project is like that. For complex systems, you can't just assume the design is final. That's why we focus on modularisation and sometimes overengineer. Sure, this adds complexity, but any experienced engineer knows it's worth it. Modularisation isn't easy, but it allows for flexibility and future updates. And there's nothing wrong with over-engineering when done right, you learn to judge when it's necessary with experience.
You also have to accept that customers often don't know exactly what they want at first. It’s part of the job to help them figure that out as you go.
That vertical scaling bit got me 😂 pretty good! 22:39
This video and article touched my soul. I have come to a similar conclusion only recently.
Also I had to laugh out loud several times 😆
we don't like complexity
we just do it unconsciously
The Great Tom laughs at simplicity. In fact, he wants a system that explodes when you put comments in the code.
10:45, Primeagen going down the dark path of complexity already.
I love when I can get my head around complexity, especially when its clear that there isn't an understanding of the complexity around you, or if what people think they understand about it is not correct and that is preventing a more efficient system. That's what makes coding fun, having your understandings tested as you plow through the details until it comes together. And when you get surprised and have to adjust your logic or code when things don't turn out working quite like you thought, you learn even more about your own ability to mentally model things, and get better at intuitive modeling (sort of... your understanding reflex?) for the next complex problem.
“Micro-lith” is the best approach IMHO. Declare your managed micro-services in IAC such as CDK. Treat it as one small codebase. Basic pipeline deployment.
I'm building a small project right now with a prediction of about 20 TOTAL ACCOUTS and maybe 1 or 2 accesses per minute PEAK.
I just use django. I was asked why I didn't use something more performant.
That is the world we live in.
I feel your pain
As developers we love complexity
no we don't lol
0
_“An idiot admires complexity, a genius admires simplicity, a physicist tries to make it simple, for an idiot anything the more complicated it is the more he will admire it, if you make something so clusterfucked he can't understand it he's gonna think you're a god cause you made it so complicated nobody can understand it. That's how they write journals in Academics, they try to make it so complicated people think you're a genius”_
*- Terry Davis (creator of TempleOS)*
@@sierragutenberg michael is actually mask off. he doesn't mean it's a mark of a genius to say "we love complexity". he is speaking to the reality of the situation.. that this field and many like it are infested with incompetent, complexity-loving morons who can hide in the shadows. Michael, i get what you're saying. these goofballs don't really work in the field and can't relate.
as a programmer I hate you
It's simple for monolith situations. Instead of trying to start with some kind of micro architecture trying to solve problems you don't have whilst introducing a bunch of problems you didn't envisage, just run monolith - then one day a portion of that monolith will be better served not being part of the main stack due to mass-usage or heavy computation, or simply that it doesn't need to run immediately like sending an email - so pull it out and put that into it's own service with a message queuing system.
Rinse and repeat
I'm an "invent the wheel" kind of guy personally, writing a game with pygame has been extremely informative and I'm loving the process, there's so many little ways to optimize
What did you just say? "Hold my beard"?!
25:10
"If you have more microservices than users press 1" man you did not have to slap that hard
And our tech complexity Loves certifications that Devs wear like champs 😎
FIX YER KERNING BLAG!
Keming looks fine to me
Nah, fixing kerning is too complicated! We're radical dude
@@Ardren With that kerning, CLINT would spell something else (no space between L and I)🤣
what do you mean. how do people determine kerning is broken
Look at the headlines. The letters being too close or too far apart is bad kerning
A marketing site should use something like Astro. This is because you almost definitely don't want to ship large amounts of code to the client in order to show the site. You want primarily HTML and CSS shipped.
React Server Components are the way to do Astro without doing Astro, except not as good for static content.
Trying to make things simpler is a huge challenge. If this was about being challenge, pick that one. Caring about maintenance, developer experience, code simplicity.
Agree with Prime, apps are more complex nowadays. I remember trying to write partial page reload by hand and it was so tedious and so annoying and bugprone, that I hand rolled my own library to handle it. I couldn't possibly imagine working on a website like that in a large organization doing it by hand. Nothing would ever ever work for longer than a day.
"the creators of Rails do Radical Simplicity" LOL
How delusional.
"Can we just be real for a second?" I thought we were still being real from the last time you said that
The kerning on that Radical Simplicity logo text is terrifying
congrats on 500k bro
One of the reasons why small companies try to support scaling early is because they want to be ready for a potential instant boom of users. For example, your competitor shot themselves in the foot and now their users are looking for an alternative but your services aren't able to keep up with the demand. You've now lost a massive opportunity for growth. I have seen it happen. But yes, it is still a massive risk to bet everything on that.
There's also the venture capital side of things that explains why we see this so often.
For Postgres vertical scaling makes sense, but for stateless horizontal makes more sense. With vertical scaling each scale event causes downtime. With Postgres this is usually fine depending on service level objectives and you can retry queries to mitigate. With stateless workloads horizontal scaling is very easy, cheaper, and has way better uptime of course.
There are also languages that poorly scale vertically, like Javascript.
The end of the article, scrumm and list of languages, is just SEO spam. Good article before that though, thanks for sharing
This indirectly answers why we get new frameworks, languages and so on. Clearing out the clutter
People love pulling things out of their ass in these articles. "Complexity comes from people just wanting to be challenged" (citation needed)
Scaling for users aside, I just like each team able to set their own tooling and processes, especially deployment cadence, when working with microservices
For years we been writing plain PHP/JS/CSS with no frameworks and making good money. New junior dev recently cried like we are cavemen banging stones.
I like the sentiment. I don't like the implementation. The idea is a good thing to strive for. But the suggested tech stacks on the site suggest very much personal branding. Not simplicity in the actual world. No one has a simple experience with python dependency management after a year. SSR is really simple, if your clients have a good internet connection. It is a whole other story when you are doing other stuff.
*
"I like minimalism. I only wear black clothing" well good luck in a country where winters are 30°c.
Your situation may have a specifically simple solution. But 1. That solution is not universal 2
You won't know it before hand. 3. If you start with a wrong solution the graceful change to the right solution introduces 90% of the complexity.
I've been taught and my development team always employ this method: Start simple and optimize only when needed.
"Quickly open up my fly..."
The same thing happens on the factory automation industry (and I'd argue that in many other fields this is a thing). A standard is set, the standard is used and abused beyond what it was made for, the standard is updated to work better within those wildly expanded requirements and that ends up validating the hacks and convoluted solutions. Just look at how many "naming conventions" exist for sensors and other devices on a factory because at some point someone decided that it'd be a good idea to give the smallest size possible to a naming field, and those conventions have been kept up for backwards compatibility.
So you're telling me that the hardware component naming garbage was completely avoidable?
the urge to make system complex comes from the need of making system more configurable, extendable, quick to add similar features.
But the problem is we devs dont always see when we need to do something once and forget about it and when we need to do actual optimization.
Leading us into loop of premature optimization.
Got to introduce complexity for job security.
"bro had diarrhea"
Think of it this way: a lot of very front-ends could be written in BASIC on the early IBM PCs.
Type 1 in the chat if you have more microservices than users LMFAO
Monolith processing of data is faster than micro services EVERY time!
4:42 We also know a bunch more about security and other things than we did in 2005. 2005 apps are not secure as has been proven by breaches, hacks and all kinds of things over and over again. Regulations have become strictor and more detailed. Customers are more demanding. Engineers are more demanding. People aren't satisfied with stuff they used to do, because once you know a faster, easier whatever solution is out there, you aren't satisfied doing the old thing slowly or manual. It's like using hand tools vs power tools. Most people aren't satisfied spending 2 minutes predrilling and then driving a screw in by hand when we now have impact drivers that do it in a few seconds.
“I want to flex on fancy projects rather than fancy code and configuration. That's why I'm a Gopher.” -- Bill Kennedy
All my new projects get written in PHP now for speed and simplicity. If, after a few days, it seems like some advanced stuff is needed, I'll rewrite in something else, but it's rare that it happens. Because some code has already been written, it's easier to think "Do I *really* need that thing though?"
Prime - there's always some dev working on js build systems.
Me - currently working on js build system 😅
I worked at a company with a simplicity mantra. Which sounded good, until I started looking through the code and realized 90% of the code base was built on an anti-pattern. Lambdas were calling lambdas, there were lambda chains that had calls 5 deep. The application had no chance of scaling. I think over simplicity can have the same problem as over complexity. Any kind of dogma is going to ruin your code base unless people take the time to think about what they're doing. I see all too much people just applying concepts without properly weighing the pros and cons in a given situation.
The principal engineer at this company thought event driven architecture was too complex. So he said every team had to use this anti-pattern not realizing it was anti-pattern documented by AWS.
I also worked in company where they had a sql db with 1000+ tables and they didn't use ORM because it's "too complicated", but dynamic SQL which is "simpler".
@@across_the_rainbow_bridge This feels like a situation where someone labeled something complex because the don't understand it.
@@danieldowd3156
Well it's a bit more complicated I would say.
This is 30 years old codebase which had several rewrites in similar or different UI-s.
Some were successful, some weren't.
Database is self reflective, by this I mean that views are defined in tables.
To implement such features in entity framework is not easy.
Then you have problems with builds if you change the database, you have to build entire model again and deploy it. They didn't like this. It is more complicated. It is much easier to have everything inside stored procedures.
Then you have layers over layers of abstraction, which complicates things, you need to look through 10 files to find out what is being done, while writing everything in a stored procedure is much simpler.
It is also much easier to deploy just database and be done with it.
SQL queries execute faster also.
If you have entire logic in the database you can fix directly in production. You can write a fix stored procedure on test server, copy paste it and just run at the deployed version.
You don't have to worry about types as much.
There are benefits to such approach. Some things are "simpler". I just think it is stupid to develop software in such a way. Because generally "simpler" is not better.
i remember we migrated from AngularJS to NG6 large enterprise app, and it went for 2.5 sec full load to 12 :D
I just use HTML, CSS, jQuery and PHP with phpmyadmin.
So in actuality, you're using HTML, JS, CSS, jQuery, PHP, MySQL or MariaDB, phpmyadmin, Apache or nginx, and _hopefully_ some kind of stable Linux distro underneath.
I'm saying "hopefully" because otherwise you're using either a rolling-release distro or Windows to host a website, and I'm not sure which is scarier.
Just because modern magic hides the complexity of your setup, doesn't mean said complexity isn't ready to ruin your day when you least expect it.
Gotta be aware of your setup's true complexity, no matter how simple it seems compared to the alternatives, or you'll end up with a server full of footguns.
@@oleg4966I use nixos unstable btw
@@oleg4966 i think youre simplifying the mountains of complexity that is built on top many of the same features you mentioned. Its not like these arent included in modern stacks, theyre just hidden, along with all of the added build step complexity and redundant client side logic like auth, routing, etc.
Jup, software is all layers, and this will always be the case unless you want to write code with zeros and ones.
Same here. After years of lifetime wasted with extremely DRY complex high sophisticated solutions I try just to keep the end in mind. KISS all over the place is the only way.
44:56 well summarized bro... that's the gold right here
When Prime describes solving through vertically scaling as being some sort of simple option that will solve most people's problems, I think he's really clueless about anything beyond his little world that he's been exposed to.
For your system to be able to scale up vertically it has to be pretty well-designed.
I worked at dev shop building operational software for small to medium sized businesses. Each project had about the same lifecycle, and almost every single time we ran into scaling issues when we went to deploy for the client, and I'd have to go in and help the Dev fix it up.
These were not scaling issues that could be solved by increasing CPU or memory on a single instance, or when they could be it would have made the software prohibitive to operate for the client.
Usually database magic had to be done. Adding layers of cacheing, or optimizing ORM queries by hand, or managing database indices etc. In some cases, the performance issue came down to just terrible design of the software to begin with: promising some dashboard that would have absurdly customizable queries on them that would be served up in a certain way that was very naïve to performance implications.
So there were many different causes and many different solutions, but rarely if ever was vertical scaling a reasonable option.
Also, horizontal scaling is not synonymous with microservices.
Bro he worked on Netflix.
I think his world is a little bigger then you give him credit for.
@@wezzelinator
That's not what I meant by "bigger".
Yes, I know Netflix is "big" in the sense that they operate at scale.
When I say his world is small, what I mean is that there are very, very few companies that operate at that scale and Prime clearly doesn't understand the kinds of problems the rest of us are solving for clients and what scaling or performance mean for us.
There is a kind of simpliccity in using a tool that can do everything properly down the line
Basecame was the best mini highlight
Real men invent their own programming languages!
The kerning on that font drives me crazy