[baobun]

If you look above the unorthodox library/framework distinction, I think the criticism is about birthing new (inadvertently leaky) abstraction layers with new semantics to capture the specifics of the domain. Often with either esoteric words attached to supposedly novel patterns, and/or unconventional usage of existing terminology.

The promise is to simplify and unify things but as noted, such efforts often have the opposite effects.

"Teams are struggling with properly adopting FooTech - our FooBarTool wraps it in a beautiful package and magically solves everything with a single command and one config file"

"We should template all this yaml"

[dpark]

> magically solves everything

This is the real problem. Too often frameworks/libraries are geared towards making things magic instead of making things solid. Magic solutions are usually very one dimensional. e.g. The Magic only works for a really narrow use case, or at low load. I don’t think this is specifically a problem with “mini frameworks” but homegrown stuff exhibits this more, if only because magic solutions tend to die in the wild when the bug tracker is full of “this only works for trivial case; make it actually work”.

When frameworks/libraries advertise how easy they are to get started, there is often a lot of magic to make it trivial to start and they don’t scale to real projects without breaking through all the magic abstractions.

[bccdee]

That's one thing I'll say for in-house "mini-frameworks": Real frameworks often try to present a smooth façade of abstraction which is hard to punch holes through. An in-house "mini-framework," though, is often just a hodgepodge of compostable abstractions which you can individually take or leave without too much hassle.

Of course, your hodgepodge ecosystem will eventually ends up a bit of a mess, but I'll take that over a flashy off-the-shelf framework that insists on handling everything itself.

[gejose]

> lot of magic to make it trivial to start and they don’t scale to real projects

Ruby on Rails is probably a great counter example here though.

[TOGoS]

I have never really grokked Ruby on Rails and I passionately hate all the frameworks that try to adapt it to some other language.

That said, I suspect that Ruby on Rails itself occupies kind of a special space where the magic is acceptable because people who write Ruby are used to having very very sharp tools and have learned to wield them carefully. Give that magic to a PHP or Java programmer and there is immediately gallons of blood on the floor.

(says former Rubyist who was put off by the RoR stuff because I'm apparently more of a Haskeller at heart.)

[wouldbecouldbe]

Yeah had so many discussion with senior developers in my life to argue for just keeping things simple, but my god they love abstractions. They are clearly always very smart and understand the code base well. Maybe it’s their intelligence wanting to be more utilised or maybe they are bored and trying to over engineer simple problems

[foobarchu]

I would narrow this down further. Programmers (myself guilty) live abstractions they control. It gives them the ability to tweak little things and feel like they've done it in a more maintainable way.

Programmers HATE using other people's abstractions, which is why "mini frameworks" tend to tall apart after expanding to teams that don't have control over it. In my experience, this leads to new mini frameworks wrapping the first one, forever targeting a static version of the underlying MF, to allow for adding new appendages without going through a gatekeeper.

[ozim]

It is easier to write your own code than to understand someone’s else code.

It would be much better if we get more humble people who get down to work to understand why and how existing code or framework works instead of trying to work around it or simply throwing all away and writing their own code.

Thera are of course some exceptions - but those are like pro athletes - no you are not the one, learn existing code instead of making excuses about some edge cases you ran into so you have to rewrite all from scratch.

[hogrug]

It's a mixed bag.. If you spend much time in a poorly reviewed ecosystem then you are quickly taught that if you try to make things work in their broken crap you will lose a lot of time and have no code to demonstrate you were working at all.

If you always inject the same repair layer approach of your own crap then you ship more reliably and have your pleased client and your lock-in. The pleased client then has to decide if they should listen to a replacement who says you are insane but can't seem to ship anything.

[skydhash]

This view needs to be balanced. There's a lot of cases where the previous code didn't abstract the domain well, or the domain has changed (mostly at the application level). Fighting the ill-fitted abstraction is a real chore in this case and quickly lead to complex code.

I'm all for aggressive refactoring if it leads to something simpler.

[baobun]

It sounds like you are agreeing - that digging into the existing layers can be a good idea that is often neglected or resisted to a fault. That we should treat existing software less like black boxes.

There are caveats here too of course - forking every single thing and excessive NIH syndrome comes with their own costs and risks.

[andoando]

But the whole software stack is built on abstractions on abstractions on abstractions. Its just a matter of finding the right ones

[swordfeng]

You know what I feel when I see someone adding a dependency injection framework to a micro micro service with merely 6 classes...

[TOGoS]

> inadvertently leaky

I think this is the main problem.

I don't mind layers of abstraction when they work well and their components compose nicely. Like a well-designed programming language. These can actually be quite fun to work with.

Layers of abstraction where the boundaries between that layer and those around it are fuzzy to non-existent and where certain cases magically work and everything else is a janky mess because it was never designed to work are what give me headaches and want to throw my work laptop out the window on a regular basis.

[baobun]

I concede I had a bit of second thoughts after posting the comment you replied to.

After all, hindsight is 20/20 and at the end of the day a major part of our work is making (appropriate) abstractions. Picking good terminology is sometimes hard. I guess to point out that the message shouldn't be read as "all abstractions bad (stop trying)" but to be more conscious about them and to restrain from piling new "magic" on top of a tower of old apocrypha.