Parody? I think you've chosen the wrong side of Poe's law here.

One of the founding principles of the USA was that we would not punish the families of wrongdoers. (It's a part of Section 9, Article 1 -- no bill of attainder.)

This is one of the principles that has been kept pretty well. The US government may have become much more tyrannical in other areas, but this is one thing they've not done much of. Any of it that has been done has been limited and very covert. I can't think of any significant cases.

So I wouldn't worry too much about the US government punishing your family for something you've done. At least not yet.

You could pre-render the page, compress it, then store that to SD. That'd probably be significantly faster than storing the full bitmap to slow storage, even with the compress/decompress overhead.

Hmm, excellent analysis. I'm actually surprised that nobody else pointed that out.

Nobody comes here any more -- it's too crowded.

Current estimates are that Google has about 2 million servers.

Agile actually has some answers to these problems.

I think the first problem you need to work on is code quality. Nothing should get released that has not been thoroughly tested. There should be no compromise on this. You're already seeing the consequences -- things don't work, developers get blamed, and nobody is happy.

Next, realize that deadlines are bullshit -- especially in larger companies. I've found that arbitrary dates are chosen, and then they're treated like they've been set in stone. The Agile solution is for everything to be put in priority order. Always work on whatever is most important. Or put another way, work on whatever will provide the most business value. Management should be the final arbiters of what's most valuable/important. Once you start working this way (or even just realize that deadlines are made up), your stress level will go down significantly.

Being Agile means being able to adapt to reality. (I think that's Agile's main reason for success -- it realizes such things like the fact that we're terrible at estimating and works with that reality.) Your reality seems to be that people want to re-prioritize frequently and get features turned around quickly. So change your process to something that can do that. Stop doing iteration planning, since you don't know what you'll need that far ahead of time. Instead, allow stories to be re-prioritized until the developers start on them. And consider doing continuous deployments.

Alternatively, factor in the amount of extra work that gets added to every iteration, and leave that much extra time. This should actually already be factored in to your velocity, because velocity for iterations is defined by the amount of stories (or story points) completed within the iteration -- but only for stories that were discussed during the iteration planning. So for example, if you had 20 stories defined at planning, and 8 stories were added, but you only got 12 of the original stories and 5 of the added stories done by the original end of the iteration, then your velocity (what you can expect to accomplish each iteration) would be 12 stories.

Another reality that Agile accepts is that you can either get everything you want when it's ready, or whatever is ready whenever you want. Most shops tend to go with fixed time periods, but a lot are starting to move to continuous deployment. If you go with fixed time periods, they need to be fixed. If something misses the deadline for this iteration, it has to wait until the next. If things were correctly prioritized and your iterations are short enough, this should not be too big of an issue. If you go with something like continuous deployment, people will get what they want quicker, but will have to deal with more uncertainty about when they'll get it.

Of course, Agile can't solve every problem. If management is unwilling to prioritize things, or people are unwilling to deal with the reality of what can be accomplished in the given time, then you'll have to deal with those in the same way as in any situation. Which probably means learning to set expectations better, playing office politics, or finding another job.

Yeah, obviously they should have said the "northern" part of Antarctica.

Wait, 424F? I thought it was 451F. I want my money back.

Easy, just use Google Maps to find the nearest pay phone.

Oh....

That computing problem would be scary in itself. But given that CAN and LIN buses are used in automobiles, it's really scary, because causing a system failure in a car could lead to loss of life.

I once had a PHP file that I inherited that was 6000 lines long. It had 0 functions in it -- everything was linear, with if statements testing for modes, sub-modes, and sub-sub-modes. Poor Eclipse couldn't parse that much code without any structure.

Also, the "brilliant" programmer used a single MySQL table, using it as a key-value store for every type of data in the application.

I don't think it's very likely that you'd be able to find a body to transplant your head onto.

The donor body would have to be a brain-dead (or persistent vegetative state) living body. (We don't know how to revive a body after it's been dead for a few hours.) Brain-death is not all that common, especially with a healthy body. Now find the families of those brain-dead folks who would not object to their loved one's head being sawed off for their body to be attached to another person's head. Not gonna happen.

The Internet is the culmination of all human knowledge, plus porn.

Whoever thought it was a good idea to add industrial control systems to that mix was an idiot, and should be shot.