May be just me, but I am quite frustrated with complexity of systems nowadays, even more how it’s became a norm for developers to import a library for every little sh*t…

Like, do you even need to import that OSS library, can’t you make it without it? Is it really worth it to import that monstrous library of 10k loc, just so you can save writing those 50loc for just once?

It almost feels like it’s driven by logic “if you don’t own the code, then you don’t need to maintain it”. But ironically you still need to mantain it, only now not the code (best case), but the library itself. You have to upgrade it (for security, bug fixes) and you better pray there’re no breaking changes. And if you encounter an edge case/bug that no one addressed yet, then well, I bet you wished you didn’t use that library in the first place.

It’s so much easier to support small piece of code within your codebase, than fix a bug in a library, that possibly has thousands of unnecessary dependencies, enormous abstraction trees, and infinity loc to support all possible use cases, which your project doesn’t even care about.

Just to make it clear, I am not talking, about cases where some library would really do some heavy lifting for you, it would be non-sensical not to use it in that case.

And talking about complexity, let’s not even mention microservices, kubernetes, and other hyped stuff…

Does anyone else shares the sentiment?

  • 9
    Reminds about this old stackoverflow question with answers suggesting to use jquery for summing up numbers
  • 4
    Agree wholeheartedly. Besides, maintaining the dependencies gets even worse and worse every year.
  • 2
    Your rant reminds me of this: https://devrant.com/rants/5107044/
  • 1
    It izz what it izz, specialise in what you like in development world. But I agree, I constantly need to remind my juniors that yes a package is technically faster but you'll learn way more by doing it yourself.
  • 2
    @gintko i hope that's a joke making a jab at SO, and not an actual, real, screenshot
  • 2
    @Midnight-shcode this one is not real, but I think it’s based on a real post that was deleted long ago, though could not find anything with wayback machine. Either way, it doesn’t change the fact, that some answers on SO indeed suggest to use jquery (or other libraries) for simple stupid things
  • 1
    @gintko artifacts from a time where using jquery was the norm. Before promises , fetch API, Node and the ever-growing number of JS frameworks.

    Unless you used a bunch of aliases for things like window or document, JQuery resulted in shorter, easy to read code.

    Calling $.ajax() vs creating an XmlHttpRequest object and going through its verbose flow was a godsend.

    Nowadays answers that mindlessly go "just use jquery bro" get downvoted.
  • 4
    Many devs still havn't grasped that dependencies are both an asset and a liability as well. That's why they fail to properly weigh both aspects against each other.

    Package managers have exacerbated the problem because they made recursive dependencies "easy". That let devs fall into the "kid in candy store" mode so that they download code from all over the internet with no idea whose code they're even running.
  • 2
    @Fast-Nop This is so accurate!
  • 4
    This is what happens when people hear some principle or guideline, think it sounds good, and blindly use it going forward but without actually thinking deeper about it and definitely without being critical in each individual situation to see if it REALLY applies and makes sense.

    DRY is a good general principle. KISS is a GREAT guiding light. YAGNI is GENERALLY correct. Curly's Law should USUALLY be followed. Not re-inventing the wheel is typically good advice.

    But none of those are absolutes, and if you just stick to them every single time without any thought then you wind up doing stupid things like bringing in a library to left-pad a string, and then disaster strikes.

    You have to understand the principles enough to know when coloring OUTSIDE the line is actually the right choice, because sometimes it absolutely, positively is.
  • 2
    3 years ago the company for which I work switched to Microservices and now for every hour we spend develping software (bugfixes and features) we spend five maintaining the ridiculously complex homemade cloud platform since the actual Operations team is too lazy to take care of the monster they built.

    Fuck this cloud shit, I want to get into iOS or desktop development.
  • 0
    @Noook can u share link of the interview
  • 2
    As you cannot reason with devs, you can annoy them by meetings.

    Every dependency needs a proposal with reasoning, meeting and vote.

    Problem solved. (Not joking, in some teams this was the only viable solution to stop them)
  • 1
    @IntrusionCM my approach is just to not approve PRs, unless logical reasoning is given. Of course, it’s not perfect and doesn’t work for larger teams, thus streamlined process would work the best (even though introduces some friction).
  • 1
    @gintko yeah...

    In my case we had frontend devs who wanted e.g. hardware upgrades as their clusterfuck of e.g. middleware bukkake with 7 plus middlewares just didn't work out so great...

    Could name a few other examples (mixing several frameworks, creating incompatible dependency chains, incompatible node versions in same project, etc.) but in my opinion devs should be stopped from adding dependencies unless they are able to handle the responsibility.
  • 0
    For my current project, I somehow approved PR of my colleague to import some fishy validation library. And it was obvious it was fishy, as he had to rely on reflection, to make it worse he had to do some custom field mapping (because library didn’t support custom field names). Yet I approved it, perhaps was lazy, or just felt bad for my coleague to basically refactor everything (in case I rejected it) - kind of proves there’s no place for emotions when reviewing.

    Anyway, now everytime I have to work with that validation library it makes my blood boil. Something, that’s supposed to be single if, now requires bunch of boilerplate code all over the project…
Add Comment