Having owned a couple Fords and known several folks that have joined the ranks of 'only if there's no other option,' it's usually the transmission. I tell people that if you lovingly maintain a Ford, and the transmission is makes it past 50K miles, then then it's going to be a great vehicle.

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

I get sick after 10 minutes last time I tried it (a few years ago). It's not anywhere near solved. Of course I have no desire to try the new versions, because even if it was solved it doesn't actually make anything useful better.

Back in the day lots of people did. Because there was no built in browser to use before IE came out. And pirating it would require getting a cd from someone else, and cd burners weren't a thing yet. Your options were use AOL with whatever they had built in on their cds, or use Netscape which you'd need to buy.

If tickets were an auction, the problem would instantly solve itself. You could even still have a secondary market for last minute buyers. And the extra revenue would go to the venue/artists, rather than a random scalper.... if those even exist anymore. I expect it's more likely Ticketmaster themselves selling them as resell at a 3x markup.

I'm from NM. We used to have a saying here when it came to education, "Thank God for Mississippi," because we were always competing with them to not be dead last. In ~ten years they've gone to 34th (or higher depending on the source). If they can keep that trend even level, I'd imagine the other stats will start to follow suit.

Honestly, it's the same phenomenon as with technology platforms: enshittification. There was a great original concept. It was implemented on a tight budget, but done well. It was compelling and relatable to the end-users/viewers. It got some traction, some additional budget, and scaled with the original concepts in mind. It eventually gets acquired by big money, and now it's a capital asset. Now the requirements/story are being dictated by Harvard Business School types and getting focus groups.

I think the timescale is just more drawn out with tv/movies than with software.

I didn't miss the jr. high "figure out what g is" stuff in the beginning of the book. I was kinda bummed at how much the selective breeding was glossed over as they had to cram a line into the movie to explain the disaster at the end. But a the same time the movie is two and a half hours long. While there are a handful of other cuts I think they could have gotten away with (the extended Karaoke scene maybe), there wasn't a ton of fat to trim to keep the runtime reasonable.

I don't think Xenonite is made of Xenon exclusively, but it is strange enough that handheld spectrometers can't deal with it. Maybe it offgasses xenon when bombarded by charged particles? One thing the movie glossed over is how Rocky's species is in many ways much less technologically advanced than Humans. Their materials science is outstanding due to the hellish nature of their home world, but they don't have electronics. Their math and science are back in the early 20th century. They went interstellar before discovering relativity. Mostly due to the fact that the astrophage is basically magic. In the book one background character mentions offhand that the astrophage is a miracle that will solve countless problems and everybody just glares at him angrily because even though he is right it's also killing them. On the other hand, while reading the book I had thoughts of an interstellar ferry service that collects astrophage and brings it back to Earth where it is tricked into releasing its energy into the atmosphere to warm the planet and light up cropland. Spin drives open up the entire solar system to exploitation and the astrophage is the perfect energy storage medium.

Something like this needs density. If there's not enough people using it, then the per use cost will be far too much to make it economically viable. That makes cities much more attractive to startups like this. Of course there you have airspace issues with large buildings, so the true sweet spot may be relatively dense but very high income suburbs. But it sure as heck won't be rural.

You can do that with github and many of the others as well. My employer has a private github.