In a follow-up story to the one it published over the weekend, the New York Times on Monday reported that the National Highway Traffic Safety Administration (NHTSA) refused in 2003 to publish research data that indicated the risk of cell phone use and driving for fear, in part, of angering the US Congress.

The research was gathered as background support for a planned NHTSA proposal to conduct a long-term study into the risks of cell phone use and driver safety.

The New York Times story states,

"The former head of the highway safety agency said he was urged to withhold the research to avoid antagonizing members of Congress who had warned the agency to stick to its mission of gathering safety data but not to lobby states."

At stake, according to the Times, were billions of dollars in funding for the NHTSA and the US Department of Transportation if Congress didn't like what the NHTSA research indicated. 

However, another NHSTA official disagreed and said that the research wasn't published because the data was not conclusive, not because a fear of Congressional funding cuts.

There was also speculation in the story that pressure was put on the NHTSA by cell phone companies not to publish the information, but no proof was offered.

The NHSTA today says it will not publish the 2003 research because it was only background material meant for agency use, not the public's.

You can read it here anyway, courtesy of a Freedom of Information Act lawsuit submitted by The Center for Auto Safety and Public Citizen, who found out about the research.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less