MCP is currently too difficult to setup and too complicated for consumers to understand. Once somebody big enough figures out distribution and integration a la the App Store, and the market starts to understand MCP integrations as extensions your AI client can orchestrate across (do one thing in App A, another in App B, etc all with a single prompt), it’ll be off to the races.
MCP is too simple actually. You just use one command? I think the problem is that most MCP "servers" do not work. They are either too early/alpha, not well supported, too limited, etc. Everyone is trying to write blog post but not actually do the product development.
This is true. Most of the MCP servers I have seen are also some of the worst examples of software I have ever seen. Given the people who are attracted to it, it's likely they're all vibe coded.
Precisely, such a change represents substantial risk in an incredibly risk-averse industry. People at orgs in such industries are in constant CYA mode, looking to point responsibility (and therefore blame) to anyone else.
The time to go and implement such a change probably pales in comparison to the amount of time spent in meetings getting people to agree to make the change.
> This is how things like SAFe are born, that try to make "agile safe for the corporation" and of course they're nothing more than corporate BS under an agile name
SAFe was truly one of the worst things I encountered with consulting clients. Planning days were an unbelievable exercise in futility. Waterfall masquerading as agile, the absolute worst of both worlds.
> SAFe was truly one of the worst things I encountered with consulting clients.
we've been using SAFe for a few years, I despise every minute of the planning process. Feel like a mix between using a crystal ball and forcing square pegs in round holes... Of course the additional disfunctionality at my company between sales, PO/PM/BO and engineering doesn't help, though it seems that I've avoided the worst SAFe train of the company.
My last job was SAFe. When I started I was given Staff level title and had dreams of maybe moving into lead or management at some level. Once I saw the process I became completely unmotivated to go in that direction.
For them I understood some of the motivation. Hardware & equipment manufacturer, which involves scheduling complicated industrial processes for months/years out. So you need some semi-coherent vision of where things will be, so having a multiquarter waterfall-esque plan was going to be needed.
I agree that some of the outputs of the SAFe process aren't useless, like expressing dependencies between teams and discussing objectives, but the process is way too costly for what it achieves. Maybe if the name was changed to something like SCRUM and Waterfall evil child...
> I also really don't get the apparent hate for react, usually from people who haven't used it all that much
In defence of the haters, I think we’ve all seen our share of horrendously organized React SPAs. Dependency hell, (seemingly) infinite prop drilling, components thousands of lines long, the list goes on.
Some people think they hate React, when in reality they hate a specific implementation of it.
I contracted on a few different projects over a few years, with React involved in all of them. Each team had their way of doing something, and goodness me... each team I joined was way different than the previous one with respect to approach, style, testing, etc. And anything I did that was "wrong" (meaning, not to their particular approach), I was ... belittled or talked down to as if I was some imbecile. In a couple cases, I used an approach with company B that they'd discarded a year before, but 6 months earlier, my work with company A's team led us down adopting that same approach, with decent results. But company B knew better, saying that approach was 'crap' (but... looking at their own internal docs, 2 years earlier, it was the hottest approach).
I was shocked at how much time some teams spent on reinventing wheels rather than using some off the shelf components. "We need everything to be done in house so we can document it and have full control". But... designing all your own widgets is going to take months. "React makes it easy though, so don't worry - we know what we're doing' Yet... they didn't - untestable components that couldn't support what the original requirements called for months earlier, etc.
You know how people crap on PHP because there's so much 'bad' PHP out there? But others say "it's just how you use it - frameworks XYZ are great!". I feel the same way about React. There's probably some great examples out there, but I somehow tend to see a lot of lesser quality stuff.
Most of the use cases I've seen up close... there wasn't any real magic or benefit to React vs something else, but everyone was jacked to get more React experience on their resume for their next gig. It didn't really matter if the resulting output was good or not, just that they used React.
I don't hate React - it's a library. I'm tired of much of the B-team players requiring it to be considered "professional" (while simultaneously) eschewing testing and documentation).
For people who have chosen it, and get to stay on the same project for several years, honing their skills on one codebase and iteratively improving, great. Enjoy.
I feel like the frontend community is suffering from the "eternal september" problem. Like PHP, it is very easy to get started so you get a lot of inexperienced developers writing very opinionated blogs that are shared with other inexperienced people who can't see the flaws. Interestingly it seems that the PHP community has matured and now consist of very reasonable and experienced "leaders", while the JS/TS community as a whole is still a long way from maturity. Don't get me wrong, there are many excellent JS/TS developers, but they face an endless stream of adversity.
In my previous startup the frontend developers decided to develop their own design library from scratch. My suggestion was to start with an established library and just adjust the style to match our look, but they wanted full control and ownership of the code. 3 years later, most of them left for new jobs and the library only contains a very basic set of components. Apparently accessibility and the rest of the "remaining 80%" part of the "80% completed" components were more difficult than they assumed. At least they had fun and could pad their resumes when they applied for new jobs, leaving others to maintain their m
This mindset was so different from the backend teams in the same startup. They preferred stable and known frameworks and libraries, and focused on the business logic. I had a feeling that the backend teams just got stuff down with little drama, while the frontend team was engaged in endless debates and rewrites. They had their own issues of course, but once they had fought the battle of choosing which language and stack to use, they stuck with it.
I worked with both and tried to stay away from most of the discussions, but it is clear to me that autonomy only works when you have a good balance of senior and junior developers that can have a discussion with the others without needing to "win" every time. As a senior developer myself, I have often learned new approaches from junior developers who have found a problem and dug in deep. Unfortunately I have seen too many senior developers and junior developers not listening to good advice from each other. The juniors think the seniors are outdated, while the seniors think the juniors are not capable.
> Most of these sound like team/people problems, not technology problems.
I wonder what are the frameworks or libraries that have exactly one widely accepted, idiomatic and correct way of doing most things, where the technology itself discourages anything else? Angular, maybe, at least with how batteries included it is?
One example where it's leaky is when you want to memoize something, and now you need to memoize all its dependencies, recursively, and you end up with a 30 file PR.
I say this as a big fan of React, and I'm hoping the compiler turns out a success.
Well, they're part of the effects abstraction. And they are leaking because you have to manually track them. You are already using the dependency variables inside the hook function. And now you need to duplicate them into an array and keep the array updated as your effect hook changes. This is leaky.
I personally would rather create a .drawio file visually and keep that under version control. Sure, the diffs aren’t that meaningful, but that’s what commit messages are for.
Pretty much. Fuck. I just watched higher ups sign off on a project I know for a fact has defects all over the place going into production despite our very explicit: don't do it ( not quite Tesla level consequences, but still resulting in real issues for real people ). The sooner we can start having people in jail for knowingly approving half-baked software, the sooner it will improve.
Should we require Professional Engineers to sign off on such projects the same way they are required to for other safety critical infrastructure (like bridges and dams)? The Professional Engineer that signed off is liable for defects in the design. (Though, of course, if the design is not followed then liability can shift back to the company that built it)
I hesitate, because I shudder at government deciding which algorithm is best for a given scenario ( because that is effectively is where it would go ). Maybe the distinction is, the moment money changes hands based on product?
I am not an engineer, but I have watched clearly bad decisions take place from technical perspective so that a person with title that went to their head and a bonus that is not aligned with right incentives mess things up for us. Maybe some proffesionalization of software engineering is in order.
You are only technically correct. And even then, in terms of civics, by having people held criminally liable government is telling you what to do ( or technically not do ). Note that no other body can ( legally ) do it. In fact, false imprisonment is in itself a punishable offense, but I digress..
Now, we could argue over whether that is/should/could/would be the law of the land, but have you considered how it would be enforced?
I mean, I can tell you first hand what it looks like, when government gives you a vague law for an industry to figure out and an enforcement agency with a broad mandate.
That said, I may have exaggerated a little bit on the algo choice. I was shooting for ghoulish overkill.
I am here to learn. You can help me by educating me. I do mean it sincerely. If you think you have a grasp on the subject, I think HN as a whole could benefit from your expertise.
Civil liability isn't determined by the "gov't" it's determined by a jury of your peers. More interesting to me is how you came to the impression that you had any idea what you were talking about to the point you felt justified in making your post.
My friend. Thank you. It is not often I get to be myself lately. Allow me to retort in kind.
Your original response to my response was in turn a response to the following sentence by "snovv_crash":
"This isn't a matter of the government saying what you need to do. This is a matter of being held criminally liable if people get hurt."
I do want to point out that from the beginning the narrow scope of this argument defined the type of liability as criminal and not civil as your post suggested. In other words, your whole point kinda falls apart as I was not talking about civil liability, but about the connection of civics and government's ( or society's depending on your philosophical bent ) monopoly on violence.
It is possible that the word civic threw you off, but I was merely referring to the study of the rights, duties, and obligations of citizens in a society. Surely, you would agree that writing code that kills people would be under the purview of the rights, duties and obligations of individuals in a society?
In either case, I am not sure what are you arguing for here, It is not just that you are wrong, but you seem to be oddly focused on trying to .. not even sure. Maybe I should ask you instead.
<<More interesting to me is how you came to the impression that you had any idea what you were talking about to the point you felt justified in making your post.
Yes, good question. Now that I replied I feel it would not be a bad idea ( edit: for you ) to present why you feel ( and I use that verb consciously ) you can just throw salad willy-nilly not only with confidence, but, clearly, justification worthy of a justicar.
tldr: You are wrong, but can you even accept that you are wrong.. now that will be an interesting thing to see.
<< that you had any idea
I am a guy on the internet man. No one has any idea about anything. Cheer up:D
What you’re describing is early Facebook. Your feed was only from your 1st degree connections. Content mattered because it was from people you cared about (and inherently knew, because users wouldn’t accept friend requests from people they didn't know). It really was the pinnacle of social media.
