In Europe, Ford is not a prestige badge. They are competing with the likes of Renault, VW, Nissan, and Honda. And now of course the Chinese brands like MG, BYD, Jaecoo, Sonoda, Cherry, Omoda, and others.

They just aren't offering much for the European market. We aren't keen on light trucks, and most of their EVs are shitty fossil conversions. That just leaves the dwindling fossil market for them.

Could also be a warranty issue. Some poor designs rely on firmware to enforce limits and prevent damage.

It's bizarrely common with EV cars already. Some have fake engine noises, and some even have a whole fake clutch and gear shifting system. The silence and instant, uninterrupted torque are the best things about EVs.

Electric motors have instant torque without the spinning mass and gyroscopic effects.

Hopefully as well as the simulation mode, they work on creating entirely new ways to control the bike that take advantage of it being electric.

Europe has ARM, Linux was created here, and there is plenty of domestic enterprise grade hardware in things like telecomms.

China has been transitioning away, and shows it is possible. They have domestic CPUs, RAM, storage, motherboards... Europe can catch up.

I think you're being a bit aggressive in your HIPPA explaination.

They aren't sharing specific, identity-revealing medical information about anyone.

Knowing that a user visited a website for pregnant, low-income DACA participants doesn't confirm the user is pregnant, low-income, or enrolled in DACA.

It's like saying by observing someone walk into an abortion clinic that violates HIPPA because now I know they are pregnant. I can prove no such thing from that visit - they could work at the clinic, they could be going in with someone that is pregnant, or they could be going to the clinic for any of the plethora of non-abortion related treatments and tests.

To violate HIPPA you need to have sufficient identity information to identify an individual and reveal their personal medical info. That's simplified, but knowing a person looked for information on a website doesn't *prove* anything.

As this story is about healthcare exchanges, you might have a hard time finding a printed application form.

I don't think they support a model where:

- you send in your demographic info,
- they send you a list of choices based on your information,
- you mail them your selection from the list provided,
- they send you a confirmation letter in the mail.

I don't think the open-enrollment window is long enough to facilitate that interaction.

A reasonable explanation/theory, but based on the ab-so-lute-ly ludicrous money spent to create these federally-funded websites, why were they relying on, as you describe them , "automated site builder tools"?

The time and cost involved reminded of the story around the build-out of Xerox PARC - they started with nothing, had to invent their workstations and invent a means to network those machines, then design and build the physical servers the sites ran on...

Bottom line, including tools to capture metrics around usage is a perfectly valid thing to include in these sites, but using a "free" tool that harvests user data on a gov't website is a big no-no!

No, it's more about how teams work. Teams have a scope. They don't typically go beyond that scope. So if my team owns the Foo and Bar modules, I work on those. But if there's little important work on Foo and Bar, but a lot of important work to be done on Baz, it's generally organizationally difficult for us to work on Baz. Typically we need to be lent out by our manager and seconded to the other team. Which can be a lot of red tape and politics.

Now if you're imagining some alternate world where programmers an be moved at will- then we're already one big team instead of multiple small teams.

And no, a smaller team doesn't win every time. If it did, then then smallest team possible is teams of 1 and we'd all do that. There are sweet spots, which depend on the organization, the work to be done, and the importance of that work. For some that's bigger, for some smaller. I've definitely worked on teams that were both too small for the work, and that were too big.

They can, under some circumstances. If the scope of what they work on is too small to fill the team's feature set. Or if the work they would be doing is significantly less important than other work to be done, having them in one large team makes it easier to move to more important work and can get critical features built faster. In that case it may not be overall more work done, but it may move the important stuff quicker. If larger teams weren't useful on some level, we wouldn't have teams at all- we'd all be individuals.

They're one of the 4 biggest stock brokers in the US. If you aren't trolling, you're showing yourself to be really ignorant.

In the end- good engineers with sufficient experience and support will get stuff working with any methodology. Bad ones or ones insufficiently supported will fail with any methodology.

There are some things that agile works well for, but it's really limited to domains where you can quickly build something tangible for feedback and you have stakeholders willing and able to give frequent feedback. UIs are a good example. It's a horrible fit for anything that requires actual research, or that can't be shown to low technical knowledge customers frequently (in other words anything that actually needs weeks or months of backend work, algorithm writing, or infrastructure to be written).

The problem with that is the skills needed to manage and the skills needed to do real work (let's take programming as an example) are pretty distinct. Someone can have both, but they tend to have one or the other. Forcing those without the skills to do the practical work into doing it doesn't actually help the team, it just slows everyone down. And if they get on the critical path of any project you can be royally fucked.

There are a couple of ways to solve this problem:

1)Larger team sizes. This can work if the team owns enough to keep everyone busy, but it can lead to effectively being independent subteams calling themselves one team while being inconvenienced by each other.

2)Each manager managing multiple independent teams. This can work if it doesn't overload the manager. The biggest problem is when the manager decides one team is more important and doesn't support the other(s) enough. This works better the closer the teams are, as it requires the manager to know fewer sets of collaborators and politics

New Orleans and a whole bunch of other cities around the world...

So they pump water out of the water table below the city, and it flows thru pipes under the city, which are broken, so the water returns to (ultimately) the water table...right?