A wind farm getting blown away by a typhoon is ironic. A geothermal plant getting blown away is not.

It's not ironic, it's unfortunate.

Ethanol requirements are corporate welfare for Big Corn.

It has nothing to do with renewable fuels or dependance on imported oil. The second the US has large scale ethanol production not using corn, any requirements for ethanol use will disappear.

Why does it need a picture of the card? That seems strange. RTFA, but it doesn't have any more detail than your comment. I did like this nugget:
"If it loses contact with your phone for a self-designated amount of time, Coin will deactivate itself."

Nice security feature. Until my phone runs out of charge, and suddenly I can make a call and I can't use my credit cards.

I have the same thought from all the proposed smart phone-as-wallet apps. Great, let me put all my eggs in one easy to lose, easy to break basket. This one was interesting until they made it dependant on keeping a live phone near by.

And the customer is not always synonymous with user. The role of the BA is important, but it should be part of facilitating communication between the developer and the user, not a firewall keeping them apart.

I liked /. more before it became predominantly slashvertisements and marketing focus groups.

What did I think of the movie? I thought they should rastify Thor by 10% or so.

IAAQISDFAFRC. (I am a quality IS developer for a FDA-regulated company.)

Rarely is the end user the customer. Not to discount the needs of the user, but the doctor or nurse using the product is not the same as the customer paying the bills and setting the requirements.

The FDA is a regulator, but that does not capture the relationship between the company and the government entity. For example, I'm selling a vial of serum A. The regulator wants to make sure the vials actually contain serum A and if there is an issue, I can track down which vials went where and to whom so I can send out a notification or a recall if necessary.

But the labels and packaging with the vials, the FDA will have more input on those than my "customers." Documentation on validation of my systems is going to be more visible to the FDA than my "customers." Reports on product complaints, process deviations, documentation discrepancies, all go to the FDA, not my "customers."

For the software developer working under the regulations of the FDA and other such agencies, those agencies are very much our customers.

As for the example above, regulation may tell you what data the software needs to collect and how to handle that data, but it will not tell you in specifics how to collect that data. So for that nurse, required fields and commonly-used functions should be quick and easy to access. That certain fields are required, I've never known a developer to favor requiring fields when not necessary, so that almost certainly is due to the customer. That the nurse has to enter a value each time and not have the data default to a value from the last record, that's regulation. If it wasn't necessary for the nurse to take the measurement at each exam, the field wouldn't be required. Having a default value is the path to inaccurate data and false records.

What happens often with that scenario is by talking to the people in Finance, the developer ends up thinking he or she has learned something about finance, and can write up requirements which read well and will be accepted by the users, but actually has very little understanding of what the users need and will produce awful software.

There are a few reasons for this. First, every area of expertise has its jargon. Often jargon is an ordinary word with a different, specific meaning in a certain context. So better to follow someone through their work flow and know you're getting lost or not understanding some steps than to have a description you think you understand.

Second, something obvious to anyone who has even a 101 intro level of understanding in a field may be completely unexpected to someone outside of that field. When talking to the folks in Finance, there is some basic assumption so elementary they never mention because everyone in finance covered it in day one, but is completely unknown to the developer with no finance background. Talking will almost never solve this issue. They won't think to mention it; the developer won't know what question to ask.

Third, we relegate tasks to "muscle memory." When describing oft-performed tasks, people invariable miss steps. There are little things that, while vital to successful completion of the process, we forget just because we've done them so many times, they happen without conscious thought. You won't know where these are until you try to replicate results from a procedure someone has described, or if you observe that someone doing the procedure.

So for someone who doesn't know a fucking thing about finance who is developing a system to be used for finance, there's so much more to be gained by watching the finance people bang their heads than just talk to the finance people. As for the Finance Manager, talking to this person should be strictly reserved to some or all of 1) budget of the project, 2) timeline of the project, 3) availability of the finance people for requirements gathering.

Something something Gemba something something Kaizen something something reason US auto manfucaturing had to play catch-up to the Japanese

That post should be mod'ed to +6 and stapled to the forehead of every project manager or system owner who thinks developers should be kept away from end users.

Which is why the developer needs to stop listen and start looking. "I want a drop box" is useless as a business requirement. Even "they want a way to make working with files so seamless that it seems like they have a single global filesystem" is useless. Does the developer have the same understanding as the end user of a term like 'filesystem'?

You are right that it is about understanding needs. However for the daily tasks users perform most often, the repetitive tasks that cause the most pain, the user does not know and cannot articulate what he or she needs. This is not a slight against users.

Here's an exercise: write a procedure, as if you were verbally instructing someone, as how to tie a shoe. Don't look at your shoes! Without visual aids or string for demonstration, with just words, tell someone how to tie a shoe. Unless you've spent a lot of effort dedicated to writing detailed instructions, you are probably not going to come up with a good guide to tying shoes. Does this mean you don't know how to tie your shoes?

No, it means two things. One, some things are easier to communicate through demonstration. And two, when we repeat the same task enough times, it becomes part of "muscle memory." We go on auto-pilot and do things we don't realize we are doing.

I agree with folks saying this is not news, but I also agree with the folks saying this is not done nearly enough.

Which is why at the better programs students take physical chemistry before organic chemistry. P-chem should cover electron orbitals, affinities, and bonds enough that o-chem is a logical application of principles, and not just memorization and intuition.

It seems most chemistry majors and almost all pre-meds do that sequence backwards (organic before physical (if they take physical at all)), so in that aspect I understand the attitude towards organic presented in TFA.

What I argue is there is nothing inherent in organic chemistry that means it must be so. In e.g. calculus, there is no way to memorize all the answers. So should students rely on intuition? Or should they learn the rules of calculus and apply them in a reasonable manner?

For me the most bothersome part of TFA is not what this student has to say, but the quotes from professors and educators. That a science educator would say something along the lines of "if a student has really good math skills, they can slide through physics, but you can’t do that in orgo," that's just shameful. It leads to this attitude from the student, that organic "doesn’t require equations or math."

go read the book! It's good.

If you're a teenager (or younger), yes, give it a read. If you're an adult, meh. There are worse ways to pass a rainy afternoon, but it's not a must read. It's young-adult fiction that does not hold up well for adults.

As for the movie, this is rare movie I thought could be longer. You get one hit of every major plot point--one fight with the bully in the first school, one interaction with Peter, one training battle with each team, etc.

What gets lost is why Ender thinks the way he does. In the movie, he's just born this tactical prodigy. In the book, he's a gifted kid, but we get to see how he learns to use those gifts.

And I didn't think the give-away for the final twist was that bad. Over all, I left not feeling angry for the money spent.

I have mod points, but I don't see the "+1 America Fark Yeah!" option.