Live data from Hacker News

Why I Hate Frameworks (2005)

factoryfactoryfactory.net

351–360 of 407 posts

Re: Why I Hate Frameworks (2005)

#351
post #340

Earlier quoted context omitted.

Senior here. Where I work, everyone has the authority of the position below them. The middle management above my team decides language, framework, and architecture. They were hired from much larger companies, so naturally they just know more. I think our 10mil/yr company doesn't need the complexity of a 100mil/yr solution because we're not Amazon and we're never going to be Amazon. But, we now we have dozens of lambd…

Yeah that's quite toxic. If the project is successful, the top level gets the praise for the vision. If it doesn't, the team gets the blame for lousy execution. The responsible for executing should have a day in a lot more things, else it's gonna be a blame game.

You had it right with your first statement. Blame always goes to the top. They don’t do anything, making decisions is easy, compared to actually getting it done on a deadline.

Get all the credit when things go well, deserve all the blame when things don’t. Because it’s also poor management when your workers aren’t properly managed and thus don’t properly build out your vision.

Re: Why I Hate Frameworks (2005)

#352

Earlier quoted context omitted.

> But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan complexity of the factory factory factory. Sometimes I wonder if that's the point of all this complexity. (EDIT: I mean really excessive complexity as alluded to in the article with factory factory factories, or 100 microservices all in differe…

Senior here. Where I work, everyone has the authority of the position below them. The middle management above my team decides language, framework, and architecture. They were hired from much larger companies, so naturally they just know more. I think our 10mil/yr company doesn't need the complexity of a 100mil/yr solution because we're not Amazon and we're never going to be Amazon. But, we now we have dozens of lambd…

Of course that’s off the record. Because the questions arise from that would place blame where it belongs, on whoever told you that.

Their vision? Like from a dream they had? That was the end of their contribution? Share the vision and play no role in managing anyone building it out? Nice. That honestly sounds like someone that needs kneecapped.

Re: Why I Hate Frameworks (2005)

#353
post #350

Earlier quoted context omitted.

React: - completely changes how you write your frontend - changes the language itself (JS -> JSX with embedded HTML) - has lots of react-* libs built around it - comes with a script initializing an app skeleton I would call that a framework. And it's a very good one.

Sure, to me a library is something you call, like ReactDOM.render(), React.useState(), etc, and a framework calls the code you create. You create files and modules for a framework in the way that it dictates, and a library doesn't constrict you in any way. But defining react as a framework or a library isn't easy, the word "React" isn't just one thing. JSX, initializing script, and the app skeleton are all optional t…

Oh, this is new to me. It's not recommending create-react-app, it wants me to use Next.js or something. Yeah that seems like a bit much. I was even doing a React project recently and went straight to create-react-app, bypassing all this, haha.

Re: Why I Hate Frameworks (2005)

#354
post #294

Earlier quoted context omitted.

What you wrote matches my experience. Not that I approve of it, of course, but it is often like that. "The senior in the team is in charge of deciding what approach to use." The only thing I'd like to add is that the senior is rarely free in their decision. It is often an unspoken choice dictated by culture and upper management. (Ironically it's worse in companies with technically apt management.) You work in a Java…

Choose the tool you know is the best answer tho.

That assumes you and everyone you work with want to use that tool... you can write COBOL in any language, you won't always like the result.

Re: Why I Hate Frameworks (2005)

#355
post #294

Earlier quoted context omitted.

What you wrote matches my experience. Not that I approve of it, of course, but it is often like that. "The senior in the team is in charge of deciding what approach to use." The only thing I'd like to add is that the senior is rarely free in their decision. It is often an unspoken choice dictated by culture and upper management. (Ironically it's worse in companies with technically apt management.) You work in a Java…

Choose the tool you know is the best answer tho.

Not only that, but let’s face it, a popular Java framework is going to be far more stable and long lived for years to come compared to what someone grabs off GitHub. A business sticks around for a long time. Some guy building with the flavor of the month is a big problem.

Re: Why I Hate Frameworks (2005)

#356

Earlier quoted context omitted.

Yes, something like that. On the other hand young workers usualy greatly overestimate their impact on getting things done and the work required to check their work. (I know I was like that)

Yeah... That's not wrong. On the other hand, those kind of "fake" internships are rampant here in France, specially with smaller companies or startups. From personal experience they don't bother checking their work. And how could they, the other employees are interns too.

I used to work in France, I was employed by a French company. I do remember the contractors that were French were pretty disgruntled. But I certainly miss being over there. The work culture is so much better than in the US. The pay may be suppressed, but at least everyone gets to enjoy life. Although, at the company I worked at, the pay was not as far off from the US side as the French folks thought it was. Definitely not when you consider how much better they were treated.

Re: Why I Hate Frameworks (2005)

#357

Earlier quoted context omitted.

> But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan complexity of the factory factory factory. Sometimes I wonder if that's the point of all this complexity. (EDIT: I mean really excessive complexity as alluded to in the article with factory factory factories, or 100 microservices all in differe…

What you wrote matches my experience. Not that I approve of it, of course, but it is often like that. "The senior in the team is in charge of deciding what approach to use." The only thing I'd like to add is that the senior is rarely free in their decision. It is often an unspoken choice dictated by culture and upper management. (Ironically it's worse in companies with technically apt management.) You work in a Java…

That's a really common trend today even outside of frameworks and software development. It's super common for people to make a worse choice when they know a better one is right in front of them, because blame if the worse choice fails will be diffused, but blame if the better choice fails will be placed entirely on them.

Re: Why I Hate Frameworks (2005)

#358
post #292

Earlier quoted context omitted.

Yeah fair enough. The whole factory factory factory thing feels separate to me. I think of it as a disastrous, productivity destroying meme that spreads through words like “hidden implementation” and “one interface, multiple implementations”. You don’t to be a senior to be vulnerable to the mind virus, though once it gets into the heads of your senior engineers your whole team or company can be in peril. The disease…

Sounds like you haven't really understood the benefits of polymorphism, encapsulation etc. The general idea is to compartmentalize your logic and only expose the important parts like if you need to generate pdfs from html you may need to use a lot of moving parts to make that happen but you hide all of it and only expose an interface with a single action that takes html and returns a pdf. If you later need to change…

I’ve mostly worked in Microsoft shops. And I used to not like that. A lot of the guys around me adopted the attitude of, “what does Microsoft have that does that? “. As I’ve gotten older, I think that Microsoft has enough churn of their own. But it’s far less than opening up to the wild west that is GitHub entirely.

I’m pretty grateful. Everything I work on is either C# or JavaScript. And I do like the abstractions and architecture that comes out of that space. It’s probably similar to a Java shop that way.

A lot of the comments here sound like people are really hacking away with some short-lived library, not framework, off of GitHub in some random language that no one else on the team knows, and now the company will have to hire for forever. Or rewrite. That doesn’t sound like fun to me at all. I definitely wouldn’t build my own business on it.

Re: Why I Hate Frameworks (2005)

#359

I disagree with the problem statement; that the framework is trying to solve a meta-problem. The problem with frameworks is instead that they assume that they're in control. They're the program, you're just writing a plugin. This makes it unnecessarily hard to use them in all but the most straight-forward use cases. And they're usually also trying to do too much; config for starting, special way of testing, incompati…

There are still good frameworks that don't take unnecessary control. I think the most common bad ones have some ulterior lock-in motive, usually some company trying to extend its influence, and you have to look out for that.

Re: Why I Hate Frameworks (2005)

#360
post #276

Earlier quoted context omitted.

> But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan complexity of the factory factory factory. Sometimes I wonder if that's the point of all this complexity. (EDIT: I mean really excessive complexity as alluded to in the article with factory factory factories, or 100 microservices all in differe…

Thing is, I've had non-Seniors-Developers asking for more complex stuff as often as I had seniors doing it. It's cultural. Complexity is often part of developer culture, period. I've even had a non-technical CEO asking to use Angular around 2013-2014. Developer culture is leaking. Also a lot of accidental complexity comes from the business/staffing side. So, you need to have 200 developers because some high-up said s…

> Complexity is often part of developer culture, period.

I’d even say no one seems to realize that the default tendency for a developer is to complexify. One either needs to learn to keep things simple by experience or is forced to it by constraints like time.

Post reply on HN