Gov't Blocks Private Testing for Mad Cow Disease

I had intended to keep this blog mostly technical, but this just makes me angry. Creekstone Farms Premium Beef was blocked from performing "mad-cow" tests on 100% of its beef by U.S. Dept. of Agriculture and USDA. This is an issue that affects both free market practice within the the United States and an international competitiveness issue as Creekstone was trying to use the testing to increase its ability to sell its beef to other countries.

The authority to block the testing seems to be granted by a 1913 law allowing the USDA to regulate "treatment" of animals. The court accepts the argument of the government that treatment includes diagnosis and testing. The LegalTimes blog writes:
"There is a two- to eight-year incubation period for mad cow disease. Because most cattle slaughtered in the United States are less than 24 months old, the most common mad cow disease test is unlikely to catch the disease, the appeals court noted. If the government does not control the tests, the USDA is worried about beef exporters unilaterally giving consumers false assurance."

Here's where it gets at least a little technical. Maybe instead of blocking a company wanting to perform additional testing on it's products, the USDA should be advising the company how best to perform its testing. The language implies that there is a more accurate test for the disease - why not require the better test if they are concerned about false assurances. Or design an experimentally robust methodology to maybe hold back a few cows from slaughter to age them to maturity where the disease could be detected. Anything is better than willful ignorance of a fatal disease!

One technical aspect we have to come to grips with here is that in this case is that tests often aren't perfect. It's a wide problem. Almost all medical tests have statistical probabilities in at least four states:

• true positive: the cow has the disease and the test correctly identifies it
  
• true negative: the cow is disease free and the test correctly indicates this.
  
• false positive: the cow is disease free and the test incorrectly indicates that is diseased
  
• false negative: the cow is diseased and the test incorrectly indicates it's safe

One does have to worry about all the outcomes, especially when testing 100%. Look at Bayesian inference in Wikipedia, particularly the portions relating to medical testing. In particular, one needs to look at false positives when the rate of disease is lower then the false-alarm rate - there is a legitimate concern here that tests and followup tests may cost a lot of money, cause a lot of concern , and not increase safety overall.

Overall though, the actions of the government here seem particularly onerous when we lose an opportunity for government to work with a private company that seems willing to implement new approaches to at least characterize the rate of a serious disease. It also seems like the government values the profits of the beef industry over pushing forward to proactively address a public health concern. If the tests aren't perfect now, we should be able to create policy to handle the real complexities while allowing the free market to bring down costs of safer products.

Imagine if a government agency told one car manufacturer that it couldn't install seat belts and airbags because consumers might demand the additional safety procedures from other car makers. "Volvo, you are barred from putting traction control in your cars because Ford might be put at a disadvantage... " Shouldn't we be promoting a free market that actively competes on adding customer safety into products!

(From the Federal appeals court via the LegalTimes blog via Slashdot)

History of Agile Software Principles

In an article inside Crosstalk, the Air Force Journal of Software Engineering, Alistar Cockburn reviews a 1968 NATO software engineering conference. He observes that many of the core beliefs and techniques of the modern Agile software development movement aren't such recent developments after all. Both the 1968 conference and the Agile movement focus on the central effect of people over processes.

I understand that there is a strong temptation to develop processes with a mindset that success will result when all that is needed is to capture the collective history of all past processes within the current one. Over time, I believe that approach is guaranteed to be ineffective.

It's not that you don't want to develop processes, but if one focuses on the development of process before people, your process will build up unwieldyness, and the people applying it will either lose confidence in the process, or worse, may not recognize why the steps they are taking are going wrong. To capture knowledge of past projects, you need to allow time to writeup retrospectives. To transfer the knowledge, you want to encourage time for less-experienced engineers to talk and read about past projects. Then going forward, people are better informed to create and apply approaches to the problem at hand.

It takes people to figure out if things are working. For example, I don't think that most aerospace software development can blindly follow the iterate smaller / continuous flow focus of the current Agile software development. They need to consider that they're not purely software systems, and that costs of design-reversals can be much higher when hardware and physical environments are in play.

p.s. if you new to the term Agile Software development see the Agile Manifesto or search on "Agile Software", or "Lean Software" or post a comment.

Ending Oil Dependence in Ten Years

I'll probably be trying to examine both Obama's and McCain's technology policies a little more closely, but for today, just a little note:

Last night, at the Democratic National Convention, Barack Obama's acceptance speech mentioned that he would set a goal to "in ten years, we will finally end our dependence on oil from the Middle East." The technologies Barak cited in the speech were numerous, but the first one mentioned was natural gas. Now most of our oil goes to transportation energy so could he have had natural gas vehicles in mind?

Lung Popping Wind Turbines

New Scientist writes on a report of wind turbines killing bats, two species in particular accounting for 60% of winged animal deaths. The bats lungs are apparently being damaged by the low-pressure region surrounding wind turbine blades.

Though one could trade off the cost-benefit of bat deaths vs general power generation pollution deaths, maybe we need to install ultra-sonic whistles on turbine blades. About 4,000 to 18,000 Hz might work. (and here).

Health and the Anti-Kidnapping RFID Implant

A Gizmodo article describes Radio-Frequency IDentification (RFID) tags being implanted into people as an anti-kidnapping measure by a company called Xega in Mexico. The system reportedly involves an external GPS unit keeping in contact with the RFID tag. Besides the problem of getting separated from the external GPS, there may be some health implications too. I don't know if Xega uses the same packaging/RF technologies a VeriChip, but there were studies linking RFID to "induced" tumors in mice, as described in this Salon article. Hmm, protection against kidnapping now, or possible cancer later - decsions, decisions...

Coverage on the RFID tags also on Slashdot here.

Introduction

After a long intense period of focusing for a workplace milestone, I finally have some time to work on the Digikata site. The site has been re-hosted onto Blogger and Google Apps. On Digikata, I'll be posting notes about various topics of personal and some of professional interest to me. My profession is software engineering, and my specialty is in the aerospace industry. Educated as an aerospace engineer, I have a wide set of experience in software engineering, modeling and simulation, embedded hardware, and aerospace vehicles. I've been fortunate to not be one of those individuals who don't use anything covered in their college education - as a matter of fact, I've had a opportunity to use all the range of different skills that go into aerospace.

In terms of personal interests, in no particular order, those would be general tech geekery, math, economics, open source software, cooking, mountain biking, reading, personal finance, green tech, programming (ruby, web, C++, etc) and .. well ok, so basically, I'll be talking about whatever interests me. (Like the webcomic Xkcd).