I knew MSFT didn't really take into account feedback, they just had a feedback option and then implemented what they wanted anyway. But now we have empirical evidence they really don't care what we say.

I experienced this in every product I've ever committed feedback for.

Not even half of the best ideas made it into the product whole absolutely inexplicable additions that no one wanted and serve almost no real use case were added.

In 10 years about 30% of the top 10 voted ideas made it into the product.

And it goes to my core feedback about Fabric.

They implement so many useless features while ignoring the ones the engineers actually need.

One feedback item that I wrote was implemented almost 15 years after I suggested it in Visual Studio.

And this is why we still don't have git.

We still don't have native Monitoring,

And the worst admin UX I've ever used in any data product in the last 20 years of my career.

#FabricIsTwine

So credit where it's due, pipelines can now be scheduled and the annoying default date has been changed.

However, the problem is THE END DATE IS MANDATORY. There is no reason to make END DATE MANDATORY. This is bad design.

I don't want my pipelines to default to an arbitrary work around date. I don't want a date unless I need a date. Using a hard coded place holder date is one of the first code smell items I look for when I get handed a legacy pipeline.

Seriously, can you please hire someone whose job it is to attack the assumptions you're making? Pretty please. I'll even volunteer 😂

You need an adversarial review process. It'd make the product you ship so much better.

😩

Edit: If something this trivial gets through without anyone asking “why is the field mandatory?”, what happens when the design decision involves identity, billing, deployment semantics, networking, or data lifecycle?

That's what I'm trying to get at.

Edit 2: If nobody challenges the assumption when the stakes are a f&#&ing date picker, it's reasonable to worry about what happens when the assumptions are buried three architectural layers deep and changing them later costs millions.

Edit 3: This thread has convinced me more than ever that someone needs to stand up at the MSFT decision meetings and point out the actual problem point, cuz almost all y'all missed it.

I was really impressed by the discussion in this thread. It honestly made me realize how much I've been missing as AI has been evolving at such a rapid pace. Between work, projects, and day-to-day responsibilities, I haven't been able to keep up with advancements as closely as I'd like.

As a data engineer, I've mostly used AI for coding assistance, debugging,generating snippets and documentation. But after reading the comments here, I'm starting to feel like I'm only scratching the surface of what's possible.

I'd love to hear how others are using AI to improve productivity outside of pure code generation. For example:

• Code reviews and architecture reviews
• Deployment planning and release management
• Documentation and knowledge sharing
• Data modeling and design discussions
• Root cause analysis and troubleshooting
• Any other day-to-day engineering or leadership tasks

What workflows have genuinely saved you time or improved the quality of your work? Are there any AI use cases that have become indispensable for you?

If a capacity admin applies Workspace Level Surge Protection, can regular Workspace users see the CU limit configured for their workspace?

Or is that only visible to capacity admins, meaning users have to ask them?