Which Kneecap

Software development is about trade offs ( so many things in tech are ). This comment on HackerNews from beat captured that ( emphasis mine ):

It’s turtles all the way down.

Using a lightweight, comprehensible framework is good, until you hit the limits of that framework and start pulling in lots more libraries to fill the gaps (the Sinatra/Cuba world). Using a heavyweight, complete library is good, until you start suffering from bugs caused by incomprehensible magic buried deep inside (the Rails world).
I see the same problem in microservices versus monolithic apps. If you use microservices, you have a lot of duplication and inter-component configuration management complexity. If you use monolithic apps, you get the big ball of mud.

Or, as I sometimes put it, “Which kneecap do you want to get shot in?”

The underlying problem isn’t fashion, or bloat. It’s that software is very, very complex. Unless you’re doing hardcore embedded work in assembly language, you’re building a raft on an ocean of code you won’t read and can’t understand.

A friend of mine put it well once. He said that you should have deep understanding of systems one layer from yours (ie your frameworks), and at least a shallow understanding of things two or three layers away (operating systems, etc). If you don’t have some grasp of the things you depend on, you’re relying on magic and are vulnerable. But you can’t realistically expect to know it all.

The full HackerNews thread is here, and the post that spawned the thread: Popularity.