> part of the problem was caused by bad design
The entirety of the problem was that the design was bad! Adding a layer of abstraction is a design choice.
Avoid Mini-Frameworks
101–110 of 119 posts
Re: Avoid Mini-Frameworks
#102Earlier quoted context omitted.
> 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…
> 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.
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.)
Re: Avoid Mini-Frameworks
#103I don’t blame the dev teams who ended up creating mini-frameworks. In many big tech companies, central framework teams are chronically underfunded. What I do blame are ego-driven mini-frameworks built by senior principal+ engineers that don’t actually solve real problems.
Re: Avoid Mini-Frameworks
#104Earlier quoted context omitted.
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 wrappi…
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 ins…
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.
Re: Avoid Mini-Frameworks
#105> Also, people lack the motivation to maintain existing stuff, because you don't get paid more or promoted doing this. Therefore, mini frameworks often die with the departure of the original authors, unless it has gained major adoption before that, which happens less likely than not.
I wonder how much of the problem stated in the article is actually a result of this resume-driven development style? The author says how the mini-framework was pushed by their engineering manager, I know it's cynical but I assume the real goal of the project was for the manager and engineers building the framework to have something fancy to show for their next promotion packet.
Re: Avoid Mini-Frameworks
#106I don't really understand the concept. What is the definition of "mini-framework" ? The author should have given a few examples. I have the impression that he confuses "obscure" with "mini". Either framework or library..
I think concrete examples of this are tricky because these "mini frameworks" only exist inside of a companies' proprietary codebase. My understanding of the concept is its an abstraction layer built on top of a more general abstraction, except the more general version is well documented and well understood by the company (for an internal framework) or even overall developer community (for something open source).
Re: Avoid Mini-Frameworks
#107Making good abstractions is hard. And it is very easy to start feel like you know you have a great abstraction when you don't. And unfortunately it's easy and fun to make abstractions, kinda like making babies. And has kind of similar weight to it too. I just have to say.. stay safe out there.
> stay safe out there Are you the Internet of Bugs gentleman?
Haha, I just looked up. I'm not
Re: Avoid Mini-Frameworks
#108This was great. I enjoyed the alternative definition of "framework" as something that introduces new concepts (differing from the more common idea that it's code that calls YOUR code.) This article reminded me of two classic pieces of writing. The first is 20+ years old now: Joel Spolsky's law of leaky abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... One of the reasons these mini-framewor…
I was also reminded of Spolsky, namely https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
Re: Avoid Mini-Frameworks
#109Sometimes someone genuinely has a clear vision that is superior to the status quo and is capable of executing it, improving quality, performance and maintainability. The challenge is distinguishing these cases from the muddled abstractions that make everything worse. This argument feels a bit like "no one gets fired for buying IBM." Blanket advice like this is an invitation to shut down thinking and stymie innovation. At the same time, the author is not wrong that imposing a bad abstraction on an org is often disastrous. Use your powers of reason to distinguish the good and bad cases.
Re: Avoid Mini-Frameworks
#110Earlier quoted context omitted.
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 o…
> 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…
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.